软件的架构是一种抽象的结构，它由软件的各个组成部分和这些部分之间的依赖关系构成。简单来说，就是选择合适的技术、组件、中间件和设计模式来进行组装，支撑业务的落地。
任何一个架构风格，都可以实现功能性需求，但是一个好的架构风格可以在功能性需求之上，提升非功能性需求（扩展性、稳定性、安全性等）。
下面聊聊单体架构到分布式架构的演进进程，以及如何进行架构的抉择。

1、单体架构
在项目初期，应用系统往往都是采用单体架构，因为其业务简单，集中，打一个包进行单点部署，可以快速上线，满足了业务初期的需求。
单体架构类型：

• 大泥团单体架构：毫无分层、所有模块聚焦在一起，相互穿插；
• 分层单体架构：进行了简单的分层，比如传统的 MVC 三层架构，是通常的选择；
• 模块化单体架构：随着业务的发展，由分层单体架构演变而来，特点就是引入了多个业务模块并且提供相应的服务能力；

在业务初期，单体架构的优点，无论从那个方面来说，都优于其他架构风格，但是随着业务的增加、复杂，单体架构的缺点也逐渐暴露出来。
单体架构的优点：

• 应用开发简单；
• 易对应用程序大规模更改；
• 测试简单、直观；
• 部署简单；
• 横向扩展简单；

单体架构的缺点：

• 代码库膨胀；
• 复杂度增加；
• 开发速度越来越慢；
• 难以扩展；
• 系统的稳定性降低；
• 需要长期依赖可能过时的技术栈；

2、分布式架构
《分布式架构体系》中提到，分布式架构的核心理念是按照功能、业务、领域等对系统进行拆分，通过合理的拆分结构，实现各业务模块的解耦，同时通过系统级容错设计，在廉价硬件基础设施上构建起高可用、可扩展的开放技术体系。
在进行系统拆分之前一定要明确设计的目标，避免目标方向错误带来的人力、成本的资源浪费。在弄清楚目标之前，我们先了解下分布式架构的缺点，通过了解这些缺点来衡量满足我们目标的前提下，需要进行哪些方面的取舍，就如 CAP 原则一样，只能满足其中的两个，AP 或者 CP。
分布式架构的优点：

• 可用性高；
• 可扩展性高；
• 系统容错性高；
• 业务代码可读性高；

这些优点正是解决单体架构存在的问题，如可用性、系统容错性，但也存在缺点。

分布式架构的缺点：

• 服务多，人员对拆分后的业务模块需要花费成本去理解；
• 技术栈升级耗费人力；
• 分布式事务的保持；
• 业务模块之间的RPC调用；

Ⅰ、功能拆分
相对简单，梳理出系统中的业务进行服务拆分，无需进行太多代码的研发，拆分后部署到不通的节点，对业务进行了解耦，提高了系统的稳定性。
Ⅱ、业务拆分

• 以业务本身为导向，充分了解系统业务模型，划分业务边界；
• 业务依赖的范围，细分功能，尽量减少功能之间的重复依赖；
• 根据拆分功能的影响大小进行评估，拆小保大；
• 拆分的过程中不要修改业务逻辑，不要进行拆分之外的任何优化动作（除非是bug）；

目前典型的分布式架构是选择微服务架构风格，但应用落地需要根据具体的业务进行分析、抉择。