单体架构VS微服务架构

单体架构简单定义：一个归档包（例如war包）包含所有功能的应用程序，我们通常称为单体应用。而架构单体应用的方法论，就是单体应用架构。

单体架构的优点：

• 架构简单
• 开发、测试、部署方便

单体架构的缺点：

• 随着业务的增加,项目复杂性变高
• 部署慢、频率低
• 扩展能力受限
• 阻碍技术创新

单体架构在构建小型的、简单的应用系统的时候是比较适合的，但是对于一些庞大的并且复杂的应用系统时，单体架构就不太合适了。

微服务的"定义"：In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
Martin Fowler大佬原文地址https://martinfowler.com/articles/microservices.html
译文：微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制（通常用HTTP资源API）。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，它们可以用不同的编程语言编写并使用不同的数据存储技术。

微服务的特性：

• 每个服务可独立运行在自己进程里
• 一系列独立运行的微服务共同构建起整个系统
• 每个服务为独立的业务开发，一个微服务只关注某个特定的功能，例如用户管理、订单管理等。
• 可以使用不同的语言与数据存储技术（契合项目情况和团队实力）
• 微服务之间通过轻量的通信机制进行通信，例如通过REST API进行调用。
• 全自动的部署机制

微服务通用全景架构图：

微服务的优点：

• 单个服务易于开发、维护
• 单个微服务启动较快
• 局部修改容易部署
• 技术不受限
• 按需伸缩

微服务的缺点：

• 运维要求高（需维护的服务比较多）
• 分布式固有的复杂性（比如网络延迟、分布式事务等等）
• 存在重复劳动

微服务的一般适用场景：

• 大型、复杂的项目
• 有快速迭代的需求
• 访问压力大

不适用微服务的场景：

• 业务稳定
• 迭代周期长