微服务平台的发展趋势

张明 •关于我 张明 网易数帆·轻舟微服务产品经理 ⚫10余年云计算领域研发及产品设计经验，先后在华为，网易从事云计算、微服务产品规划工作⚫热爱技术的产品经理⚫对虚拟化、容器、容器网络、微服务、服务网格等领域有深刻的理解，目前专注于微服务、服务网格和云原生领域。 微服务平台演进历史01 目录 02轻舟微服务平台介绍 03微服务平台选型建议 •应用架构演进 •应用微服务化需要考虑哪些因素 •微服务发展历程 •微服务框架萌芽期 Service 互联网大厂早期微服务架构实践，通过自研组件实现大型应用的拆分： 业务逻辑 自研SDK ➢尚未形成微服务技术框架标准➢尚未出现开源的组件，企业自研所需组件 协议编解码 服务注册发现 服务路由 负载均衡 熔断降级 •开源微服务框架爆发期 Service 互联网大厂微服务实践过程中，逐步形成了由一系列标准化组件组成的微服务框架事实标准，中小企业基于开源框架，开启了微服务实践之路： 业务逻辑 开源SDK 协议编解码 ➢阿里Dubbo开源➢Netflix微服务技术架构开源➢springcloud项目推出 服务注册发现 服务路由 负载均衡 熔断降级 •微服务框架成熟期 Service 随着Spring Cloud、Dubbo等开源微服务框架的广泛使用，公有云厂商率先推出了商用微服务框架，随后各大厂商陆续推出了支持私有化部署的商用微服务框架： 业务逻辑 商用SDK 协议编解码 服务注册发现 ➢统一管控、监控平台➢统一技术栈➢功能丰富，兼容开源 服务路由 负载均衡 熔断降级 •开源服务网格诞生 Service 服务网格为服务间通讯的基础设施层，通过一组轻量级网络代理（Sidecar Proxy）拦截流量进行服务治 业务逻辑 轻量级SDK 理： 协议编解码 ➢异构语言统一服务治理体系➢应用逻辑代码和服务治理能力无耦合➢应用程序对代理无感知 服务发现 负载均衡 熔断降级 •商用服务网格推出 Service 微服务框架厂商，陆续推出了商用服务网格产品，在开源的基础上提供更高的性能，更完善的功能： 业务逻辑 轻量级SDK ➢提供统一管控平台➢数据面性能优化➢功能更加丰富 协议编解码 服务发现 负载均衡 熔断降级 …… •统一微服务平台诞生 统一微服务平台，支持Spring Cloud、Dubbo等微服务框架和服务网格： 业务逻辑 业务逻辑 轻量级SDK 商用SDK ➢统一管控平台➢相互通信➢平滑向服务网格迁移 协议编解码 服务注册发现 •开源微服务框架vs商用微服务框架 ➢配置参数分散，缺少管控入口➢技术栈分散，没有统一的标准➢注册中心、API网关等等众多组件需自行部署和维护➢功能不完善，例如开源Hystrix不支持动态配置➢未提供日志服务、分布式事务等组件 ➢统一的管控平台➢统一的技术栈➢用户无需关心组件部署，仅使用功能➢功能完善，提供丰富的治理能力➢组件更丰富 •微服务框架vs服务网格 微服务架构 Service 业务逻辑 业务逻辑 轻量级SDK 服务注册发现 协议编解码 ➢支持异构语言➢基于流量的服务治理➢依赖于K8S容器平台➢引入Sidecar，性能下降明显 ➢开发语言限定，Spring Cloud仅支持Java开发语言➢基于方法级的服务治理➢不限定部署形态，支持虚拟机、容器等等➢性能影响小 微服务平台演进历史01 目录 02轻舟微服务平台介绍 03微服务平台选型建议 •轻舟微服务平台 ➢统一微服务平台 支持传统微服务框架和服务网格统一管控 ➢基于开源，兼容开源 ➢代码无侵入 基于SpringBoot的应用无需适配开发基于Spring Cloud的应用无需修改代码 ➢服务治理能力丰富 提供服务注册、发现、路由、限流、熔断、降级、认证鉴权、配置管理、监控、调用链跟踪等等服务治理功能 ➢灵活部署 支持跨多云平台，支持容器、虚拟机、物理机等负载类型 •基于Agent的微服务框架 •微服务框架对比 Service 业务逻辑 SDK 服务注册发现 轻量级SDK 协议编解码 负载均衡 基于Agent的微服务框架 基于SDK的微服务框架 ➢开发语言限定，Spring Cloud仅支持Java开发语言➢业务逻辑通过引入SDK包（开源或商用）实现服务治理 ➢开发语言限定，Spring Cloud仅支持Java开发语言➢业务逻辑使用开源SDK接入轻舟微服务，无需替换依赖包➢应用系统通过Spring boot开发，直接通过Agent增强，无需在业务逻辑代码中引入SDK •基于轻舟的服务治理平台和体系化建设 微服务平台演进历史01 目录 02轻舟微服务平台介绍 03微服务平台选型建议 •服务网格场景：多语言支持 •服务网格场景：老应用无改动升级 流量控制 安全 可观测 1、监控；2、Metrics；3、无侵入； 1、认证鉴权；2、无侵入； 1、流量控制；2、熔断降级；3、超时重试；4、无侵入； •微服务框架场景 虚 拟 机 部 署 维 持 现 有 框 架 I stio功能 Istio成 熟 度 1、不支持Dubbo协议；2、时延增加不可接受；…… 1、版本迭代快；2、生产实践少；…… 1、已使用SpringCloud等微服务框架； 1、未使用容器； •微服务框架选型 •商用微服务平台考量因素 成功的大型互联网应用实践案例支持与第三方容器、CICD平台对接 丰富的服务治理能力基于开源技术代码无侵入 与底层基础设施解耦兼容开源支持传统微服务框架和服务网格 提供丰富的组件 支持虚机、容器等负载类型 •展望未来 “前途是光明的，道路是曲折的“