如何优雅的步入微服务2.0时代

如何优雅地步入微服务2.0时代？网易轻舟技术专家，翁扬慧网易数帆 轻舟云原生 来自网易杭州研究院，技术专家轻舟微服务NSF产品的研发负责人多年微服务架构设计与项目开发经验，对Spring Cloud，Dubbo、gRPC、Istio、Envoy等技术有过深入学习。目前主要负责网易轻舟微服务的核心方案设计以及业务落地推进工作；开源爱好者，Istio社区成员，热衷于开源技术的分享和交流。自我介绍网易数帆 轻舟云原生 目录背景篇（Situation）：为什么服务网格是微服务的2.0时代？01决策篇（Decision）：如何决策业务团队是否应该使用服务网格？02展望篇（Destination）：微服务2.0时代，服务网格下一步怎么走？04方案篇（Solution）：如何优雅地从微服务框架迁移至服务网格？03网易数帆 轻舟云原生 Situation为什么服务网格是微服务的2.0 时代？网易数帆 轻舟云原生 微服务概念最早被提出2011201220132014201520162017201820192020Kubernetes2014年6月Spring Boot2013年9月Docker 2013年3月Dubbo2011年10月NETFLIX OSS2012年3月gRPC2015年Spring Cloud2016年LinkerdIsitoConsul ConnectSMIOSMSOFA MOSN微服务的发展历史回顾以框架为主的微服务1.0 时代服务网格 微服务2.0 时代网易数帆 轻舟云原生 一般只提供特定语言的SDK，例如Spring Cloud和早期版本的Dubbo，都只是局限于Java开发语言框架的适用范围有限除了添加相关的包依赖之外，还需要在业务代码里插入各种治理逻辑代码，并且工作在业务运行时。框架对业务的侵入性大框架往往包含了不同功能的组件，引入依赖后会导致业务应用体积大、构建慢、占用资源多等问题。引入框架带来的负担重010203040506当框架需要升级版本时，需要业务方配合修改应用依赖，涉及打包、发布、测试，成本过高。业务方往往比较排斥，对于线上业务，更是阻力重重。框架的升级成本高不同的服务治理框架都有各自的局限性，涉及到特定的服务治理功能例如故障注入、灰度发布、安全通信等也有所欠缺。框架提供的治理能力有限云原生架构大势所趋，将业务迁移至K8S之后，注册中心该如何选择成了最先需要考虑的问题。框架与云原生架构演进的冲突微服务框架存在的问题网易数帆 轻舟云原生 异构语言统一服务治理体系有Google、IBM等大厂背书提供丰富的服务治理能力治理、监控、安全一体化云原生应用可扩展性、可升级性、易维护性故障和资源的隔离性提供安全、快速、可靠的服务间通讯服务网格是用于处理服务间通信的基础设施层，负责为构建复杂的云原生应用传递可靠的网络请求。服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。解耦应用业务和服务治理能力轻量级网络流量代理应用程序对代理无感知服务网格的定义与优势网易数帆 轻舟云原生 Decision如何决策业务团队是否应该使用服务网格？网易数帆 轻舟云原生 现有业务系统是否已经服务化拆分，目前面临的问题是否只能依靠服务网格来解决，明确服务网格的技术引入究竟是真正的“痛点”还是“痒点”。业务问题是否只能用服务网格解决？01就目前而言，服务网格Istio仍比较依赖K8S，业务至少需要先迁移到Docker容器平台。如果业务是Spring Cloud架构，迁移会相对比较顺畅，但如果是Dubbo，目前社区支持尚不完善，可能需要自定义开发适配。业务架构是否已经满足网格的条件？02服务网格解耦了开发和运维，这就意味着所有的运维操作是独立于业务开发流程的。业务团队是否有配套的基础设施平台比如CICD、统一的治理平台等。是否已经有/能开发配套的基础设施？04使用服务网格需要对云原生技术（如Kubernetes，Docker等）有深入的了解，想要在生产环境上使用还需要对Istio和Envoy的原理比较清楚，并且能够熟练进行故障诊断和原因定位。团队是否能驾驭得了服务网格？03技术投资前的深思熟虑网易数帆 轻舟云原生 架构演进中的“成本”问题成本单体应用微服务技术选型成本业务服务化拆分成本分布式服务治理成本拆分增加的资源成本......微服务业务容器化改造成本容器化后的运维成本容器引入的安全成本容器引入的监控成本......容器化服务网格学习成本服务网格改造成本业务平滑迁移成本服务网格运维成本......服务网格K8S 的团队学习成本K8S 的部署运维成本CI/CD 平台建设成本监控、日志建设成本......容器编排网易数帆 轻舟云原生 网易内部业务诉求痛点随着业务规模上升，正处于业务容器化上云及混合云架构转型中，需要更全面的服务治理能力现有业务技术栈较多，SDK维护成本高、升级阻力大，需要更统一的服务治理平台来支撑不同的业务更强大的流量管理：动态路由、版本分流、灰度发布更丰富的治理特性：限流、熔断、故障注入更完整的协议治理：HTTP、中间件Redis/MQ等更灵活的环境治理：流量染色&流量穿梭更解耦的治理平台：业务与服务治理解耦，独立平台更全面的协议支持：Dubbo、gRPC、Thrift等协议的支持更精细的服务治理：支持Dubbo、Thrift的精细化治理更丰富的治理特性：动态降级、多场景限流、接口鉴权更易用的治理平台：提供人性化的服务治理平台更可控的运维能力：Sidecar热升级、流量动态拦截网易数帆 轻舟云原生 Solution如何优雅地从微服务框架迁移至服务网格？网易数帆 轻舟云原生 在正式接入网格之前，熟悉业务团队现有技术体系、整体系统架构，明确真实用户诉求，评估是否需要定制化改造，制定整体的技术演进方案如果业务团队有定制需求，例如要求支持Dubbo、Thrift协议等，需要结合社区发展趋势，对控制面（Istio）或数据面（Envoy）进行增强改造结合业务现状，制定整体的迁移方案及实施计划，评估好迁移过程中的风险，做好测试环境验证，通过灰度引流等方式逐步将业务平滑迁移至网格完成存量业务的迁移后，关注业务团队的网格使用成本，通过建设服务治理平台，完善运维体系，帮助用户通过服务网格为业务创造更多的价值接入网格的关键步骤让业务团队以最少的成本、最低的风险、最好的体验从微服务框架平滑迁移至服务网格优雅演进方案设计网格能力增强业务平滑迁移平台体系建设网易数帆 轻舟云原生 微服务框架的功能设计服务注册发现服务路由负载均衡请求容错动态限流服务实例管理熔断降级认证鉴权参数分流流量染色容器管理平台（NCS）方法级监控应用级监控应用日志采集应用诊断应用性能监控平台（APM）持续集成平台（CICD）分布式事务（GTXS）服务配置管理测试平台（易测）API网关治理规则管理可观测性流量管理服务治理管理功能链路追踪服务拓扑认证管理API网关中间件（PAAS）轻舟微服务框架功能架构总览Spring * (Spring Cloud/Spring Boot/Spring MVC)DubbogRPC支持框架网易数帆 轻舟云原生 微服务框架的架构设计用户微服务（消费方）NSF Agent用户微服务（提供方）NSF Agent注册中心EurekaZookeeperConsul外部服务控制中心前端控制台API 网关访问外部服务外部服务访问内部服务内部服务访问服务注册服务注册HTTP通信HTTP通信gRPC连接HTTP通信内部调用（东西向流量）外部调用（南北向流量）实线：数据面通信虚线：控制面通信控制中心(NSF Server)EurekaZookeeperConsulAPI 网关数据面组件配置管理服务应用诊断服务应用监控服务应用认证服务知识库服务配置管理服务应用诊断服务应用监控服务应用认证服务知识库服务控制面组件微服务控制面NSF微服务架构1.0网易数帆 轻舟云原生 服务网格的架构设计用户微服务（消费方）Sidecar(Envoy)用户微服务（提供方）Sidecar(Envoy)外部服务前端控制台API 网关访问外部服务外部服务访问内部服务内部服务访问内部调用（东西向流量）外部调用（南北向流量）实线：数据面通信虚线：控制面通信控制中心控制中心(NSF Server)配置管理服务应用诊断服务应用监控服务应用认证服务知识库服务配置管理服务应用诊断服务应用监控服务应用认证服务知识库服务API 网关数据面微服务控制面控制面控制中心istiodgRPC连接k8S API Server监听CRD配置对接注册中心OpenAPI注册中心EurekaZookeeperConsulEurekaZookeeperConsulConsulK8S RegistryNSF微服务架构2.0API Plane网易数帆 轻舟云原生 NSF Agent 的模块化设计最初的目的是为了解决Spring Cloud依赖组件体积太大的问题不便于交付、分发/ 构建效率低/ 影响应用启动读取/内存额外消耗HTTP适配器Dubbo适配器Premain + Module LoadergRPC适配器服务配置模块熔断降级方法级限流方法级监控AOPRPCMetaCoreAgent通信应用诊断模块日志采集模块链路追踪模块Traffic注册发现服务路由负载均衡参数分流服务容错Agent配置NSF Agent 模块化划分设计必需模块用户可拆卸启动器自识别加载颜色说明：启动Agent体积< 300KB全部依赖包体积> 80MBAll -In -One Jar 依赖网易数帆 轻舟云原生 服务网格服务治理能力面向应用间的服务治理接口限流*故障注入通信加密访问鉴权......微服务框架服务治理能力面向应用内的服务治理熔断降级细粒度限流配置中心应用诊断日志采集流量染色细粒度监控......微服务框架和服务网格的选择微服务框架服务网格Agent+ Sidecar=“鱼”和“熊掌”不可兼得？服务注册发现智能路由负载均衡请求容错调用监控流量管理链路追踪网易数帆 轻舟云原生 Sidecar(Envoy)Sidecar(Envoy)微服务框架融合（过渡）期服务网格使用Agent “助推”业务平滑升级CoreMetaBootTrafficRPCCoreMetaBootRPC单独Agent 模式：Agent 负责应用内服务治理Agent 和Sidecar 并存模式：Agent负责应用内细粒度服务治理（方法级）Sidecar负责应用间粗粒度服务治理（接口级）单独Sidecar 模式：Agent可自主脱离，或新业务直接不使用AgentAgentAgentAgent火箭助推器分离过程Boot第一次分离第二次分离网易数帆 轻舟云原生 基于Agent 实现业务原地平滑升级Eureka RegistrySVC CNSF AgentSidecarpodSVC ANSF AgentSVC BNSF AgentSVC DNSF AgentSidecarpodSVC ESidecarpodSVC FSidecarpodK8S Service RegistryNSF 控制面Ingress Gatewaypod网格控制面内部调用内部调用内部调用NSF Server...istiod...Agent注册K8S注册服务双注册Agent注册K8S注册拉取eureka服务拉取k8s服务旧遗留业务融合形态业务（双模）新开发业务网易数帆 轻舟云原生 基于网关实现业务上云平滑迁移SidecarSVC ASidecarpodSVC BSidecarpod云外（旧业务集群）云内（新业务集群）KongKongConsulSVC AVMSVC BVM用于出流量认证鉴权注册中心API Gateway按权重或参数控制流量比例用户访问流量流量按比例控制网格控制面istiodK8S API ServerpodEgress Gateway用于出流量认证鉴权SidecarpodpodIngress GatewaySidecarpod70%30%