前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >微服务架构的进化之路

微服务架构的进化之路

作者头像
全球技术精选
发布2021-10-09 16:03:23
5230
发布2021-10-09 16:03:23
举报
文章被收录于专栏:全球技术精选全球技术精选

第一代

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

第二代

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

第三代: 服务网格

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

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

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

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-09-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 半栈程序员 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 第一代
  • 第二代
  • 第三代: 服务网格
  • 第四代: 多运行时微服务架构
相关产品与服务
服务网格
服务网格(Tencent Cloud Mesh, TCM),一致、可靠、透明的云原生应用通信网络管控基础平台。全面兼容 Istio,集成腾讯云基础设施,提供全托管服务化的支撑能力保障网格生命周期管理。IaaS 组网与监控组件开箱即用,跨集群、异构应用一致发现管理加速云原生迁移。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档