第1篇：单体架构与微服务架构的对比

1. 单体架构

维基百科单体应用（Monolithic applicaion)介绍如下：

In software engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.

A monolithic application is self-contained and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task, but can perform every step needed to complete a particular function.

In software engineering, a monolithic application describes a software application that is designed without modularity. Modularity is desirable, in general, as it supports reuse of parts of the application logic and also facilitates maintenance by allowing repair or replacement of parts of the application without requiring wholesale replacement.

总结起来，单体应用就是：
一个自包含的、缺乏进程间架构设计的应用程序。

比如一个独立的war包可以完成用户所有的操作和数据访问。

2. 微服务架构

维基百科对微服务架构的介绍如下：

Microservice architecture – a variant of the service-oriented architecture (SOA) structural style – arranges an application as a collection of loosely-coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight.

A consensus view has evolved over time in the industry. Some of the defining characteristics that are frequently cited include:

• Services in a microservice architecture (MSA) are often processes that communicate over a network to fulfil a goal using technology-agnostic protocols such as HTTP.
• Services are organized around business capabilities.=
• Services can be implemented using different programming languages, databases, hardware and software environment, depending on what fits best.
• Services are small in size, messaging-enabled, bounded by contexts, autonomously developed, independently deployable, decentralized and built and released with automated processes.

A microservice is not a layer within a monolithic application (example, the web controller, or the backend-for-frontend). Rather it is a self-contained piece of business functionality with clear interfaces, and may, through its own internal components, implement a layered architecture. From a strategy perspective, microservices architecture essentially follows the Unix philosophy of “Do one thing and do it well”.

总结起来，微服务架构具有如下特点：

• 应用由一组松散耦合的服务组成
• 每个服务是一个独立的进程，服务间采用与技术无关的协议进行网络通信
• 每个服务都是围绕业务能力组织的
• 各个服务可以根据业务能力需要，采用不同的技术栈，如编程语言、数据库、硬件、通信协议等
• 各个服务可以独立开发、独立部署
• 相对于单体应用，每个微服务的体量较小

3. 单体架构与微服务架构的优缺点

(1)单体架构

优点：

• 易于部署：只需要部署单个服务
• 易于扩展：在负载均衡器后面运行应用程序的多个副本来扩展应用程序
• 开发方便：可以在一个服务中开发新功能

缺点：

• 庞大的单体代码库让导致应用程序可能难以理解和修改。随着时间的推移，开发速率通常会放缓。

• 单体架构中模块边界是通过目录和包名来划分的，模块化可能会随着时间的推移而瓦解。代码质量会随着时间的推移而螺旋式下降。

• IDE 过载 ，代码库越大，IDE 越慢，开发人员的生产力越低。

• Web 容器过载， 应用程序越大，启动所需的时间就越长，浪费开发人员的生产力。

• 持续部署困难，每次部署时都要部署整个应用程序，这可能中断整个后台服务。此外，未变更的部分可能会受到变更部分的影响，因此与重新部署相关的风险会增加，从而阻碍频繁更新。这对于用户界面开发人员来说尤其是一个问题，因为他们通常需要快速迭代和频繁重新部署。

• 扩展应用程序可能很困难，单体应用程序只能通过运行更多的程序副本来扩展应用，无法根据组件的特点进行扩展（如CPU密集型的和内存密集型的组件）。 此外，由于单体应用使用同一套缓存、数据库等，应用程序可能并不会由于副本的增加而得到相应的扩展。

• 不适合多团队协同开发，单体应用程序的阻止了团队独立工作，团队必须协调他们的开发工作和重新部署。团队进行更改和更新生产要困难得多。

• 无法为不同业务选择不同的技术栈，单体应用中所有的业务功能都是采用相同的技术栈进行开发。

• 很难进行技术迁移，由于代码和功能越来越多，如果应用程序一开始选用的框架已经过时，那么将应用程序逐步迁移到更新更好的框架可能具有挑战性。

• 质量难于保证，单体应用由于体积过于庞大而无法进行全面和彻底的测试，并且由于模块间缺少故障隔离，随着时间的推移，一个模块的可能会影响整个应用程序，如内存泄露。

(2)微服务架构
优点：

• 大型复杂应用可以持续交付和持续部署: (1)较小体积的服务可以进行充足的自动化测试和手式测试，因此bug少；(2)可能通过消费者驱动的契约测试保证服务的更新不影响其他服务，因此无需同其他开发团队进行协调；(3)较小体积的服务部署速度快、启动时间短，因此对其他服务的影响时间短。
• 通过持续部署，可以快速获得客户和用户的反馈。
• 服务体积较小，业务功能相对单一，易于维护。
• 可以根据服务的特点对服务进行扩展，如CPU密集型服务可以选用核数多，内存大的硬件。
• 更好的容错性，服务间有很好的故障隔离，单个服务的故障，不会导致整个应用崩溃。
• 更容易实验和采纳新的技术，每个服务可以根据其业务特点采用不同的技术，另外由于服务体积小，在向新的技术迁移时成本和风险都会小很多。

缺点：

• 服务的拆分和定义是一项挑战，服务的拆分和定义没有统一的方法，由于不合理的拆分和定义，很可能导致一个分布式的单体应用（服务间紧密耦合）。
• 增加了技术复杂性，微服务作为一种分布式系统架构，设计和开发人员需要考虑额外的复杂性，如数据一致性、接口访问延迟、进行间通信、服务不可用、测试等。
• 增加了运维复杂性，需要同时管理和监控多个服务，并且每个服务都可能采用不同的技术。
• 需要高度自动化的基础设施，微服务的持续部署需要高度自动化的基础设施进行支撑，如CI/CD、容器编排平台等。
• 需要协调多个团队的开发和发布计划，采用微服务架构的应用一般由多个团队同时进行开发，需要根据服务的依赖顺序制定服务的开发和发布计划。