# 《凤凰架构》笔记

## 服务架构演进史

### 原始分布式时代

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

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

### 单体系统时代

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

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

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

### 微服务时代

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

### 后微服务时代

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://gitbook.fantasticmao.cn/tech/fen-bu-shi-xi-tong/feng-huang-jia-gou-bi-ji.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.