单体架构、SOA、微服务架构

1. 单体架构(巨石架构)   

• 单体架构是一种将所有功能打包在一个容器中运行的设计风格；
• 一个实例中集成了一个系统的所有功能；
• 通过负载均衡软件/设备实现多实例调用

1.1 单体架构的优点

• 易开发、易调试、易部署，运维方便，在开发小型项目重有独特的优势，给个人开发应用的时候比较合适。

1.2 单体架构的缺点

• 可靠性差，一旦某个模块出现问题，可能会拖垮整个应用；
• 扩展困难，只能通过运行更多的服务器来进行水平扩展，比如订单服务所需要的资源较多，遇到瓶颈的时候却需要将整个应用进行扩展；
• 升级困难，不可持续发展，遇到新的技术或者框架往往需要重构所有业务模块；

2. 面向服务的架构SOA

 

 

 

• 是一种 分布式服务架构的常见方式，他将应用程序的不同功能单元(称为服务)进行拆分，并通过这些服务之前定义明确的接口和协议联系起来，进而实现跨服务单元/系统交互的能力；
• SOA是面向服务的架构，它是一种设计方法，设计通常是自上而下的，服务之间松散耦合，ESB集成不同协议的服务，做消息的转化、解释、路由从而联通各个服务，解决企业通信问题，服务松耦合、可扩展；

2.1 面向服务架构的优点

• 系统集成：在系统的角度，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】
• 系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】
• 业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】
• 松耦合
• 独立性
• 可重用

2.2 面向服务架构的问题

• SOA架构存在中心化问题，共用一套数据库；
• 随着大型互联网公司和组织架构对大规模弹性部署和敏捷开发的需求，面向服务的架构（SOA）逐渐难以应付

3. 微服务架构

• 微服务是一种软件架构的风格，它是专注于单一责任与功能的小型功能区块(即服务)为基础，服务之间互相协调 、互相配合，为用户提供最终价值。每个服务运行在其独特的进行中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕具体业务进行构建，并且能够被独立部署；
• 微服务就是去中心化的SOA扩展，每个微服务有自己独立的数据库，它强调服务彻底点组件化，一个组件就是一个服务，服务的切分粒度更小。服务之间通过轻量化的协议进行通信，可以根据服务本身独立化部署。

3.1 微服务的特点

• 服务拆分粒度更小，每个微服务都需要满足单一职责原则，微服务本身是内聚的，因此微服务通常比较小。比如示例中每个微服务按业务逻辑划分，每个微服务仅负责自己归属于自己业务领域的功能；
• 去中性化，进一步拆分了服务间的耦合度；
• 灵活组合，在微服务架构中，可以通过组合已有的微服务以达到功能重用的目的；
• 技术异构，在一个大型系统中，不同的功能具有不同的特点，并且不同的团队可能具备不同的技术能力。因为微服务间松耦合，不同的微服务可以选择不同的技术栈进行开发。有利于系统的演进；

3.2 微服务比SOA的优势

• 复用率更高
• 快速响应
• 弹性扩展
• 支持异构

3.3 微服务缺点

• 复杂度高，微服务间通过REST、RPC等形式交互，相对于Monolithic模式下的API形式，需要考虑被调用方故障、过载、消息丢失等各种异常情况，代码逻辑更加复杂。对于微服务间的事务性操作，因为不同的微服务采用了不同的数据库，将无法利用数据库本身的事务机制保证一致性，需要引入二阶段提交等技术。同时，在微服务间存在少部分共用功能但又无法提取成微服务时，各个微服务对于这部分功能通常需要重复开发，或至少要做代码复制，以避免微服务间的耦合，增加了开发成本；
• 运维复杂，在采用微服务架构时，系统由多个独立运行的微服务构成，需要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才对够更好的运维系统；
• 影响性能，相对于SOA和单体应用架构，微服务的间通过REST、RPC等形式进行交互，通信的时延会受到较大的影响。