网易数字&云原生论坛：如何优雅的步入微服务2.0时代（32页）.pdf

1、如何优雅地步入微服务如何优雅地步入微服务2.02.0时代？时代？网易轻舟技术专家，翁扬慧来自网易杭州研究院，技术专家轻舟微服务 NSF 产品的研发负责人多年微服务架构设计与项目开发经验，对Spring Cloud，Dubbo、gRPC、Istio、Envoy等技术有过深入学习。目前主要负责网易轻舟微服务的核心方案设计以及业务落地推进工作；开源爱好者，Istio社区成员，热衷于开源技术的分享和交流。自我介绍自我介绍目录背景篇（Situation）：为什么为什么 服务网格是微服务的 2.02.0 时代？01决策篇（Decision）：如何如何 决策业务团队是否应该使用服务网格？02展望篇（Dest

2、ination）：微服务2.02.0时代，服务网格 下一步下一步 怎么走？04方案篇（Solution）：如何如何 优雅地从微服务框架迁移至服务网格？03Situation为什么为什么 服务网格是微服务的 2.0 时代？微服务概念最早被提出2011201220132014201520162017201820192020Kubernetes2014年6月Spring Boot2013年9月Docker 2013年3月Dubbo2011年10月NETFLIX OSS2012年3月gRPC2015年Spring Cloud2016年LinkerdIsitoConsul ConnectSMIOSMSO

3、FA MOSN微服务的发展历史回顾微服务的发展历史回顾以框架为主的微服务 1.0 时代服务网格 微服务 2.0 时代一般只提供特定语言的SDK，例如Spring Cloud和早期版本的Dubbo，都只是局限于Java开发语言框架的适用范围有限框架的适用范围有限除了添加相关的包依赖之外，还需要在业务代码里插入各种治理逻辑代码，并且工作在业务运行时。框架对业务的侵入性大框架对业务的侵入性大框架往往包含了不同功能的组件，引入依赖后会导致业务应用体积大、构建慢、占用资源多等问题。引入框架带来的负担重引入框架带来的负担重010203040506当框架需要升级版本时，需要业务方配合修改应用依赖，涉及打包、

4、发布、测试，成本过高。业务方往往比较排斥，对于线上业务，更是阻力重重。框架的升级成本高框架的升级成本高不同的服务治理框架都有各自的局限性，涉及到特定的服务治理功能例如故障注入、灰度发布、安全通信等也有所欠缺。框架提供的治理能力有限框架提供的治理能力有限云原生架构大势所趋，将业务迁移至K8S之后，注册中心该如何选择成了最先需要考虑的问题。框架与云原生架构演进的冲突框架与云原生架构演进的冲突微服务框架存在的问题微服务框架存在的问题异构语言统一服务治理体系有Google、IBM等大厂背书提供丰富的服务治理能力治理、监控、安全一体化云原生应用云原生应用可扩展性、可升级性、易维护性故障和资源的隔离性提供

5、安全、快速、可靠安全、快速、可靠的服务间通讯服务网格是用于处理服务间通信的基础设施层处理服务间通信的基础设施层，负责为构建复杂的云原生应用传递可靠的网络请求。服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。解耦应用业务和服务治理能力轻量级网络流量代理应用程序对代理无感知服务网格的定义与优势服务网格的定义与优势Decision如何如何 决策业务团队是否应该使用服务网格？现有业务系统是否已经服务化拆分，目前面临的问题是否只能依靠服务网格来解决，明确服务网格的技术引入究竟是真正的“痛点”还是“痒点”。业务问题是否只能用服务网格解决？业务问题是否只能用服务网格解

6、决？01就目前而言，服务网格Istio仍比较依赖K8S，业务至少需要先迁移到Docker容器平台。如果业务是Spring Cloud架构，迁移会相对比较顺畅，但如果是Dubbo，目前社区支持尚不完善，可能需要自定义开发适配。业务架构是否已经满足网格的条件？业务架构是否已经满足网格的条件？02服务网格解耦了开发和运维，这就意味着所有的运维操作是独立于业务开发流程的。业务团队是否有配套的基础设施平台比如CICD、统一的治理平台等。是否已经有是否已经有/能开发配套的基础设施？能开发配套的基础设施？04使用服务网格需要对云原生技术（如Kubernetes，Docker等）有深入的了解，想要在生产环境上