后端架构 演进过程

架构的发展并非一蹴而就，本文将根据时间线梳理后端架构的演进。

一、原始分布式

“使用多个独立的分布式服务共同构建一个更大型系统” 的设想和尝试，比大型单体系统来得更早。

在微型计算机（下文简称为计算机）发展初期，由于运算处理能力的限制，单台计算机难以满足大型系统的运行需求。为了克服硬件的限制，人们开始探索采用多台计算机共同协作的方案。

这一阶段是对分布式架构的最原始的探索。尽管从结果来看，它并没有解决分布式的各种难题，但这一探索过程为后续的技术发展奠定了基础。

这次尝试最大的收获就是对 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 看作一个 “无限性能” 的服务器，因此，不再需要考虑分布式架构，只需要通过这个 “无限性能” 的服务器就可以支撑起大型系统。

但是，代码的书写方式发生改变，从传统的单体架构变为分散的函数

参考