这是我参与「第三届青训营 -后端场」笔记创作活动的的第 3 篇笔记

什么是架构

架构又称软件架构，是有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计。设计一个软件有很多方式，架构在设计方式上起着至关重要的指导作用。可以把架构看作是软件的地基，只有在合理的架构上开发软件才能把"楼房"盖的更高。

情景引入

兰师傅开了一家新的蛋糕店，开张前要解决一些问题：

• 如何做蛋糕——独家秘方，决定亲自做
• 如何卖蛋糕——刚开始客流量应该不打，决定边做边卖

单机

软件系统需要具备对外提供服务的能力，单机，就是把所有的功能实现在一个机器里，并部署在一台机器上 优点：

• 简单，易于开发 缺点：
• 每次运维需要停止服务，用户体验不佳 单机服务的模式，除了简单以外没有任何优点，当今互联网时代，单机服务的形态一般只适合出现在预研或初创阶段，但凡业务有发展和迭代的诉求，就应该快速做架构迭代

单体 垂直切分

于是乎兰师傅又请了几位师傅，并按照职责对师傅进行了分工，现在蛋糕店的架构变成了下面这样：

我们把进程部署在多个机器上，并引入负载均衡层，经过这样的垂直切分，就来到了单体架构。多个机器就好比把蛋糕切成几大块，负载均衡层负责引导用户去事先切好的几块蛋糕处 在单体架构基础上，进一步地，再把不同应用的代码从之前一个大的进程中拆分出来，就来到了垂直应用架构。按应用拆分进程，就好比慕斯、戚风等蛋糕在不同的点发配

这种经过垂直切分的架构，尝试解决了单机服务的水平扩容、运维停服问题。

虽然它们解决了单机服务的两个最重要的问题，但也面临着很多挑战。这其中，有两个问题使得我们不得不放弃单体和垂直应用架构：

• 随着业务场景越来越复杂，服务的职责也越来越多。学过面向对象程序设计的同学都知道单一职责的重要性，在软件架构里也是一样的。开发者不仅要关心 Web 后端业务逻辑，还要关心缓存、持久化存储，甚至跟机器打交道。长此以往，RD 很难分出精力专注于业务能力的开发
• 业务发展需要上线、变更，将会影响所有其他不涉及的场景。一旦出问题，影响面不可估量

SOA | 微服务

SOA(Service-Oriented Architecture)：将应用的不同单元抽象为服务，再定义服务之间的通信标准

按单体架构的改进思路，我们把原本包含了众多复杂逻辑的进程按照功能单元抽象成多个服务，以服务为一等公民，并为它们之间的通信定义标准，便得到了 SOA 架构。 这里有两个相对比较重要的概念：

• 服务，是根据功能抽象出来的概念。比如说，处理用户登录信息的 Passport 服务，负责持久化存储的数据库服务，以及为了加快查询速度的缓存服务等
• 通信标准，是服务之间通信的基石。没有实现定义好的通信标准，就好比多个做蛋糕的师傅语言不通，难以协作

为了服务之间更好的通信，有两个大的发展方向：中心化和去中心化，而去中心化的最终形态就是微服务架构