这是我参与「第三届青训营 -后端场」笔记创作活动的的第三篇笔记
架构的演进
1. 单机架构
软件系统需要具备对外提供服务，单机，就是把所有功能都实现在一个进程里，并部署在一台机器上。
优点：简单
问题：运维需要停服
单机服务的模式，除了简单之外没有任何优点。当今互联网时代，单机服务的形态一般只适合出现在预研或初创阶段， 但凡业务有发展和迭代的诉求，就应该快速做架构迭代。
2. 单体架构与垂直应用架构
把进程部署在多个机器上，并引入负载均衡层，经过这样的垂直切分，就来到了单体架构。多个机器就好比把蛋糕切成几大块，负载均衡层负责引导用户去事先切好的几块蛋糕处。进一步地，再把不同应用的代码从之前一个大的进程中拆分出来，就来到了垂直应用架构。按应用拆分进程，就好比慕斯、戚风等蛋糕在不同的点发配。
优点：水平扩容；运维不需要停服
问题：职责太多，开发效率不高；爆炸半径（即影响范围）大
随着业务场景越来越复杂，服务的职责也越来越多。开发者不仅要关心Web后端业务逻辑，还要关心缓存、持久化 业务发展需要上线、变更，将会影响所有其他不涉及的场景。一旦出问题，影响面不可估量。
3. SOA (Service -Oriented Architecture)与微服务架构
- 将应用的不同功能单元抽象为服务
- 定义服务之间的通信标准
按照这个思路，把原本包含了众多复杂逻辑的进程按照功能单元抽象成多个服务，以服务为一等公民，并为它们之间的通信定义标准，便得到了SOA架构。
这里有两个相对比较重要的概念:
服务，是根据功能抽象出来的概念。比如说，处理用户登录信息的Passport服务，负责持久化存储的数据库服务，以及为了加快查询速度的缓存服务等
通信标准，是服务之间通信的基石。没有实现定义好的通信标准，就好比多个做蛋糕的师傅语言不通，难以协作
为了服务之间更好的通信，有两个大的发展方向:中心化和去中心化。中心化的方案形态较重，拓展性不佳，普及性不佳。 而去中心化的方向，最终的形态就是微服务架构。
