《凤凰架构》笔记

服务架构演进史

原始分布式时代

「调用 远程 方法」与「调用 本地 方法」两者的复杂度相差很多，需要考虑很多额外问题，例如：

• 远程服务在哪里（服务发现）

• 有多少个远程服务（负载均衡）

• 网络出现分区、超时，或者服务出错了怎么办（熔断、隔离、降级）

• 方法参数与返回结果如何表示（序列化协议）

• 信息数据如何传输（传输协议）

• 服务权限如何管理（认证、授权）

• 如何保证通信安全（网络安全层）

• 如何使不同机器的服务返回相同的调用结果（分布式数据一致性）

单体系统时代

对于小型系统，即由单台机器就足以支撑其良好运行的系统，单体系统架构不仅 易于开发、易于测试、易于部署，且由于系统中各个功能、模块、方法的调用过程都是进程内调用，不会发生进程间通信，因此也是运行效率最高的一种架构风格，完全不应该被贴上「反派角色」的标签。

单体系统的真正缺陷在于 隔离 与 自治 能力上的欠缺，由于所有代码都共享着同一个进程空间，不能隔离，也就无法做到单独停止、更新、升级某一部分代码。

单体系统由于隔离能力的缺失，除了 难以阻断错误传播、不便于动态更新程序 以外，还面临 难以技术异构 的困难，每个模块的代码都通常需要使用一样的程序语言，乃至一样的编程框架去开发。

微服务时代

微服务是一种 通过多个小型服务组合来构建单个应用 的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。

后微服务时代

从软件层面独力应对分布式架构所带来的各种问题，发展到应用代码与基础设施软、硬一体，合力应对架构问题的时代，此即为「后微服务时代」，现在常被媒体冠以「云原生 Cloud Native」这个颇为抽象的名字加以宣传。