微服务架构的进化之路

微服务架构的进化之路

第一代

微服务架构的进化之路

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

第二代

微服务架构的进化之路

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

第三代: 服务网格

微服务架构的进化之路

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

第四代: 多运行时微服务架构

微服务架构的进化之路

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

参考:《阿里云云原生架构实践》

(0)
下一篇 2021年6月19日 上午11:19

相关推荐

发表回复

您的电子邮箱地址不会被公开。