# 《凤凰架构》笔记

## 服务架构演进史

### 原始分布式时代

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

* 远程服务在哪里（服务发现）
* 有多少个远程服务（负载均衡）
* 网络出现分区、超时，或者服务出错了怎么办（熔断、隔离、降级）
* 方法参数与返回结果如何表示（序列化协议）
* 信息数据如何传输（传输协议）
* 服务权限如何管理（认证、授权）
* 如何保证通信安全（网络安全层）
* 如何使不同机器的服务返回相同的调用结果（分布式数据一致性）

### 单体系统时代

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

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

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

### 微服务时代

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

### 后微服务时代

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