微服务架构的特点_微服务架构适用场景

微服务架构的特点

微服务架构是一项在云中部署应用和服务的新技术。

架构特征如下：

1）组件以服务形式来提供

微服务是面向服务的

2）围绕业务功能进行组织

微服务更倾向于围绕业务功能对服务结构进行划分、拆解。这样的服务是针对业务领域有着完整实现的软件，

它包含使用接口、持久存储以及对应的交互。因此团队应该是跨职能的，包含完整的开发技术--用户体验、数据库和项目管理。

3）产品不是项目

传统的开发模式致力于提供一些被认为是完整的软件，一旦开发完成，软件将移交给维护或实施部门，然后开发组就可以解散了。

而微服务要求开发团队对软件产品的整个生命周期负责。这要求开发者每天都要关注软件产品的运行情况，并与用户联系的更紧密，

同时承担一些售后服务支持。越小的服务粒度越容易促进用户与服务提供商之间的关系。

4）强化终端与弱化通道

微服务的应用致力于松耦合和高内聚，它们更喜欢简单的REST风格，而不是复杂的协议（例如BPEL或集中式框架）。要么采用轻量级

消息总线（如RabbitMQ）来发布消息。

5）分散治理

跟传统的集中式管理有很大区别，微服务把整体式框架中的组件分拆成不同的服务，在构建时将会有更多的选择。

6）分散数据管理

当整体式的应用使用单一逻辑数据库对数据进行持久化时，企业通常会选择在应用的范围内使用一个数据库。微服务让每个服务管理

自己的数据库。

7）基础设施自动化

云计算特别是AWS的发展减少了构建、发布和运维微服务的复杂性。微服务的团队更加依赖于基础设施的自动化，毕竟发布工作相当无趣。

8）容错性设计

任务服务都可能因为供应商的不可靠而出现故障，微服务应为每个应用的服务和数据中心提供日常的故障检测和修复。

9）改进设计

由于设计会不断更改，微服务所提供的服务应该能够替换，而不是长久的发展。

微服务架构适用场景

随着互联网的高速发展，微服务现在已经成了热门话题，我们今天就来聊聊微服务架构的使用场景，在之前，我们先讲讲单体架构，单体架构就是我们最传统的项目前端代码和后端代码耦合在一起。

单体架构的适用场景

业务场景简单，功能不复杂，研发人员较少。

公司处于创业初期：为了生存，需要的是快速开发出功能，然后到市场上试错。

性能要求及其苛刻：一些对性能要求比较高的系统，例如股票软件。

需求比较稳定的系统也不适合做成微服务，例如：公司内部OA，考勤系统等。

微服务的使用场景

需求层面：

公司发展到一定规模，需求变化频繁，并且研发团队达到10人左右

性能层面：

对响应时间要求不苛刻的系统，比如：电商系统

数据一致性层面：

尽量避免分布式事务问题，对数据一致性不太高可保证最终一致性

微服务的目的

项目快速迭代

项目持续交付
责任编辑：YYX