后端架构 演进过程
架构的发展并非一蹴而就，本文将根据时间线梳理后端架构的演进。
一、原始分布式
“使用多个独立的分布式服务共同构建一个更大型系统” 的设想和尝试，比大型单体系统来得更早。
在微型计算机（下文简称为计算机）发展初期，由于运算处理能力的限制，单台计算机难以满足大型系统的运行需求。为了克服硬件的限制，人们开始探索采用多台计算机共同协作的方案。
这一阶段是对分布式架构的最原始的探索。尽管从结果来看，它并没有解决分布式的各种难题，但这一探索过程为后续的技术发展奠定了基础。
这次尝试最大的收获就是对 RPC、DFS 等概念的开创，以及得到了一个价值千金的教训：某个功能能够进行分布式，并不意味着它就应该进行分布式，强行追求透明的分布式操作，只会自寻苦果。
—— Kyle Brown，IBM Fellow
二、单体架构
随着计算机的发展，摩尔定律稳定发挥作用，计算机的性能以每两年增长一倍的速度提升。很快，仅需一台计算机即可支撑大型系统，单体架构开始占据主流。
单体架构具有以下特点：
- 优点：
- 便于开发、测试、部署
- 与 IPC（InterProcess Communication，进程间通信）、RPC（Remote Procedure Call，远程过程调用）相比，系统中的相互调用都是进程内调用，运行效率更高
- 缺点：
- 对代码的拆分（分层、分模块）只能实现开发时的隔离，无法实现运行时的隔离，所有的代码都运行在同一个进程中，可能因某个 Bug 导致整个系统的全面崩溃
- 整个系统一同部署，无法做到针对某一模块的单独更新
- 难以实现技术异构，要求系统中的每个模块均使用相同的语言甚至技术栈
三、微服务
在微服务架构下，一个大型系统将由若干个小型服务组成。这些小型服务基于业务划分，可以独立开发、测试、部署。
微服务架构具有以下特点：
- 优点：
- 服务独立自治，加上熔断降级等运维手段，不会 “一崩皆崩”，可以保证整个系统的高可用
- 各服务可以选择不同的技术栈
- 可以根据服务的特点、重要程度、运行压力，更精准地分配计算资源
- 缺点：
- 服务治理、负载均衡、RPC、配置中心、服务容错、链路追踪、网关等问题并没有被广泛认可的解决方案，尽管 Spring Cloud 通过统一的接口屏蔽了不同组件的差异，使得普通开发者无需关心具体组件，但架构师在技术选型时需要投入较大的时间精力
四、后微服务（云原生）
在微服务架构中，我们会引入大量的组件，包括：Spring Cloud Nacos、 Spring Cloud Gateway、Spring Cloud LoadBalancer 等，这些组件都是为了解决微服务问题而存在。针对这些问题，之所以选择在应用层而非基建层解决，是因为基建的发展速度相对较慢，无法满足需求。
随着以 Kubernetes 为代表的容器编排技术的发展，微服务问题在基建层面有了可行的解决方案，如下：
| Kubernetes | Spring Cloud | |
|---|---|---|
| 弹性伸缩 | Autoscaling | |
| 服务发现 | KubeDNS / CoreDNS | Spring Cloud Nacos |
| 配置中心 | ConfigMap / Secret | Spring Cloud Nacos |
| 服务网关 | Ingress Controller | Spring Cloud Gateway |
| 负载均衡 | Load Balancer | Spring Cloud LoadBalancer |
| 服务安全 | RBAC API | Spring Cloud Security |
| 跟踪监控 | Metrics API / Dashboard | Spring Cloud Sentinel |
| 降级熔断 | Spring Cloud Sentinel |
在此背景下，后微服务（云原生）架构应运而生。应用层无需再过多关注微服务治理，而是将更多精力集中在业务本身；服务部署在 Kubernetes 之上，借助容器编排技术对微服务进行治理。
需要注意的是，Kubernetes 并非针对微服务而生，在微服务治理上，与微服务组件相比，它的能力存在缺失和倒退。
例如：
- 并不支持降级熔断
- 只支持简单负载均衡，无法支持复杂规则
五、服务网格（Service Mesh）
一方面，我们不希望在应用层中保留微服务组件；另一方面，后微服务（云原生）架构的微服务治理能力难以满足要求。在这种背景下，服务网格（Service Mesh）架构开始出现。
服务网格本质上是边车代理模式（Sidecar），它以流量劫持的方式，为服务间通信额外增加连接稳定性、安全性、可管理性和可观测性。具体来说：
- Pod 中会被自动注入一个额外的网络代理服务器，它会以类似中间人攻击的方式进行流量劫持，在服务无感知的情况下接管通信
- 网络代理服务器会与控制器进行通信（Control plane tra），以接受指令、上报数据
- 网络代理服务器会接管服务间通信（Data plane traffic，数据平面通信），以实现微服务治理
五、无服务（Serverless）
随着云计算技术和云计算平台的发展，Serverless 出现。
Serverless 由云计算平台提供，无需考虑部署、运维等问题。
可以将 Serverless 看作一个 “无限性能” 的服务器，因此，不再需要考虑分布式架构，只需要通过这个 “无限性能” 的服务器就可以支撑起大型系统。
但是，代码的书写方式发生改变，从传统的单体架构变为分散的函数