1. 软件架构演进
软件架构是指软件整体结构与组件的“顶层抽象描述”。其作用是用于指导整个软件系统各方面的设计。
1.1. 单体架构
特点：
软件全部功能集中在一个项目内（All in one）。
所有的功能打一个包部署到服务器。
应用与数据库分开部署。
- 通过部署应用集群和数据库集群来提高系统的性能。
优点：
- 项目架构简单，前期开发成本低，周期短，小型项目的首选。
缺点：
- 全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
- 系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。
- 技术栈受限，只能使用一种语言开发
1.2. 垂直架构
也杯称为“烟囱架构”、“水平分层架构”
按照业务进行切割，形成小的单体项目。
特点：
- 以单体结构规模的项目为单位进行垂直划分项目即将一个大项目拆分成一个一个单体结构项目。
- 项目与项目之间的存在数据冗余，耦合性较大。
- 项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。
优点：
- 项目架构简单，前期开发成本低，周期短，小型项目的首选。
- 通过垂直拆分，原来的单体项目不至于无限扩大。
- 不同的项目可采用不同的技术。
缺点：
- 全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
- 系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。
1.3. SOA 架构
特点：
- 基于 SOA 的架构思想将重复公用的功能抽取为组件，以服务的方式给各各系统提供服务。
- 各各项目（系统）与服务之间采用 webservice、rpc 等方式进行通信。
- ESB 企业服务总线作为项目与服务之间通信的桥梁。
优点：
- 将重复的功能抽取为服务，提高开发效率，提高系统的可重用和可维护性。
- 可以针对不同服务的特点制定集群及优化方案。
- 采用 ESB 减少系统中的接口耦合。
①服务以接口为粒度，为开发者屏蔽远程调用底层细节，使用Dubbo面向接口远程方法调用，屏蔽了底层调用细节； ②业务分层以后架构更多清晰，并且每个业务模块职责单一，扩展性更强； ③数据隔离，权限回收，数据访问都通过接口，让系统更加稳定，安全； ④服务应用本身无状态化，这里的无状态化指的是应用本身不做内存级缓存，而是把数据存入db； ⑤服务责任易确定，每个服务可以确定责任人，这样更容易保证服务质量和稳定；
缺点：
- 系统与服务的界限模糊，不利于开发及维护。
- 虽然使用了 ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。
- 抽取的服务的粒度过大，系统与服务之间耦合性高。 ①粒度控制复杂，如果没有控制号服务的粒度，服务的模块就会越来越多，就会引发超时，分布式事务瓦内特； ②服务接口数量不宜控制，容易引发接口爆炸，所以服务接口建议以业务场景进行单位划分，并对相近的业务做抽象，防止接口爆炸； ③版本升级兼容困难，尽量不要删除方法、字段，枚举类型的新增字段也可能不兼容； ④调用链路长，服务质量不可监控，调用链路变长，下游抖动可能会影响到上游业务，最终形成连锁反应，服务质量不稳定，同时链路的变成使得服务质量的监控变得困难；
1.4. 微服务架构
“网格架构”
特点：
- 将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。
- 微服务遵循单一原则。
- 微服务之间采用 RESTful 等轻量协议传输。
优点：
- 服务拆分粒度更细，有利于资源重复利用，提高开发效率。
- 可以更加精准的制定每个服务的优化方案，提高系统可维护性。
- 微服务架构采用去中心化思想，服务之间采用 RESTful 等轻量协议通信，一般采用API网关管理，相比 ESB 更轻量。
- 适用于互联网时代，产品迭代周期更短。 ①微服务很⼩，便于特定业务功能的聚焦 A B C D； ②微服务很⼩，每个微服务都可以被⼀个⼩团队单独实施（开发、测试、部署上线、运维），团队合作⼀定程度解耦，便于实施敏捷开发； ③微服务很⼩，便于重⽤和模块之间的组装； ④微服务很独⽴，那么不同的微服务可以使⽤不同的语⾔开发，松耦合； ⑤微服务架构下，我们更容易引⼊新技术； ⑥微服务架构下，我们可以更好的实现DevOps 开发运维⼀体化；
缺点：
- 微服务过多，服务治理成本高，不利于系统维护。
- 分布式系统开发的技术成本高（容错、分布式事务等），对团队挑战大。 ①分布式复杂难以管理，当服务量增加，管理越加复杂； ②微服务架构下，分布式链路跟踪难；