云原生微服务的典型架构是什么样的？

自从微服务架构理念在 2011 年提出以来，典型的架构模式按出现的先后顺序大致分为四代。

第一代微服务架构中，应用除了需要实现业务逻辑之外，还需要自行解决上下游寻址、通讯，以及容错等问题。随着微服务规模扩大，服务寻址逻辑的处理变得越来越复杂，哪怕是同一编程语言的另一个应用，上述微服务的基础能力都需要重新实现一遍。

在第二代微服务架构中，引入了旁路服务注册中心作为协调者来完成服务的自动注册和发现。服务之间的通讯以及容错机制开始模块化，形成独立服务框架。但是随着服务框架内功能日益增多，用不同语言的基础功能复用显得十分困难，这也就意味着微服务的开发者被迫被绑定在某种特定语言上，从而违背了微服务的敏捷迭代原则。

2016 年出现了第三代微服务架构 - 服务网格，原来被模块化到服务框架里的微服务基础能力，被进一步的从一个SDK 演进成为一个独立进程 - Sidecar。这个变化使得第二代架构中多语言支持问题得以彻底解决，微服务基础能力演进和业务逻辑迭代彻底解耦。这个架构就是在云原生时代的微服务架构 - Cloud Native Microservices，边车（Sidecar）进程开始接管微服务应用之间的流量，承载第二代中服务框架的功能，包括服务发现、调用容错，到丰富服务治理功能，例如：权重路由、灰度路由、流量重放、服务伪装等等。

近两年开始，随着 AWS Lambda 的出现，部分应用开始尝试利用 serverless 来架构微服务，这种方式被称之为第四代微服务架构。在这个架构中，微服务进一步由一个应用简化为微逻辑（Micrologic），从而对边车模式提出了更高诉求，更多可复用的分布式能力从应用中剥离，被下沉到边车中，例如：状态管理、资源绑定、链路追踪、事务管理、安全等等。同时，在开发侧开始提倡面向 localhost 编程的理念，提供标准 API 屏蔽掉底层资源、服务、基础设施的差异，进一步降低微服务开发难度。这个也就是目前业界提出的多运行时微服务架构（Muti-RuntimeMicroservices）。

以上内容摘自《云原生架构白皮书2022新版》电子书，点击https://developer.aliyun.com/special/download?id=8548可下载完整版