这是我参与「第五届青训营 」笔记创作活动的第5天。本次讲述架构的一些定义和演变过程

架构定义

架构，又称软件架构：

• 是有关软件整体结构与组件的抽象描述
• 用于指导软件系统各个方面的设计 通俗地讲，实现软件的方法有很多种，架构在方法的选择上起着至关重要的作用 架构的重要性：用盖房子来做举例子，地基对于一栋楼房的主要性，架构对于一个软件的重要性也是类似的：
• 架构没设计好，软件容易崩，用户体验上不去。最终要么重构，要么放弃
• 架构设计好了，软件的稳定性上去了，用户体验高了，口碑一点点就打造出来了
• 良好的架构基础，也为软件的未来发展提供了更多的可能。为用户赋能，实现自身价值

架构的演变

单机架构：All in one

该架构的特点就是把所有的东西都在一个进程里，部署在一个机器上。 优点：

• 简单 缺点：
• 运维需要停服，用户体验较差。当遇到问题时，需要将服务器中的整个服务都关掉，这对用户很不友好
• 承载能力有限，会出现 C10K 问题，也就是单机处理 10K 个并发连接的问题

单体架构：分布式部署

在单机架构的基础上，将进程部署到多个机器上，并且引入负载均衡层，即蛋糕店的大堂经理，其根据负载的情况将用户请求引导到某一个单体架构的节点中。 优点：

• 具备水平扩容能力
• 运维不需要停服 缺点：
• 后端进程职责太多，越来越臃肿
• 爆炸半径较大，进程中一个很小的模块出现问题，都可能导致整个进程崩溃

垂直应用架构

在单机架构基础上，将进程按照某种依据切分开，比如按照功能模块进行切分。 垂直应用架构与单体架构的区别在于：单体架构是将整个应用程序部署在一个机子上，但是垂直应用架构是将应用中的某一个功能进程部署在一个机子上。比如，A 软件和 B 软件的后端原先采用单机架构部署，那就是一个进程部署在多个机器上；如果用垂直应用架构，可以将 A 和 B 的后端拆分为 A、B 两个进程，然后再按照单体模式的思路，部署在多个机器上。 优点：

• 一定程度上减少了后端进程职责
• 一定程度上缩小爆炸半径 缺点：
• 没有根本解决单体架构的问题，随着业务场景越来越复杂，服务的职责也越来越多。如果说将所有的职能集中在一起，则会出现开发人员业务的问题。

在软件开发中，开发者不仅要关心 Web 后端业务逻辑，还要关心缓存、持久化存储，甚至跟机器打交道。长此以往，RD 很难分出精力专注于业务能力的开发，解决这种问题的方法就是分工协作，即将职责根据服务的种类进行垂直划分。

SOA (面向服务架构)

SOA（Service-Oriented Architecture） 架构中，服务为一等公民，将进程按照不同的功能单元进行抽象，拆分为『服务』。有了服务之后，SOA 还为服务之间的通信定义了标准，保证各个服务之间通讯体验的一致性。 其中两个重要的概念：

• 服务，是根据功能抽象出来的概念。比如说，处理用户登录信息的 Passport 服务，负责持久化存储的数据库服务，以及为了加快查询速度的缓存服务等
• 通信标准，是服务之间通信的基石。没有实现定义好的通信标准，就好比多个做蛋糕的师傅语言不通，难以协作 优点：
• 各服务的职责更清晰
• 运维粒度减小到服务，爆炸半径可控 缺点：
• ESB (企业服务总线) 往往需要一整套解决方案

微服务

简单来说微服务是 SOA 架构的去中心化版本。在 SOA 架构中，ESB 起到了至关重要的作用。但从架构拓扑来看，它更像是一个集中式的模块，即一个服务中心，如果该中心出现了单点故障，则会出现全体应用的崩溃，由此出现了微服务这一种去中心化的 SOA 架构。 微服务的特点就是服务与服务之间的联系都是各自进行的，没有通过通信总线中转交流 优点：

• 兼具 SOA 解决的问题
• 服务间的通信更敏捷、灵活 缺点：
• 运维成本

垂直/水平分工带来的问题

• 数据一致性：多个服务之间的数据保持同步一致
• 高可用：各个服务之间如何实现高效的合作
• 治理：当一个服务出现问题之后，如何实现容灾
• 解耦和过微：微服务的目标是强化单一职责，需要合理地控制职责范围，从而减小爆炸半径，但也不能太小，导致运维成本升高

小结

• 架构演进的初衷：满足软件迭代诉求，提高迭代效率
• 架构演进的思路：垂直切分——分布式，水平切分——分层/模块化