【ArchSummit】阿里云原生微服务架构治理最佳实践

前言

📫 作者简介：小明java问道之路，专注于研究 Java/ Liunx内核/ C++及汇编/计算机底层原理/源码，就职于大型金融公司后端高级工程师，擅长交易领域的高安全/可用/并发/性能的架构设计与演进、系统优化与稳定性建设。

📫 热衷分享，喜欢原创~ 关注我会给你带来一些不一样的认知和成长。

🏆 InfoQ签约作者、CSDN专家博主/后端领域优质创作者/内容合伙人、阿里云专家/签约博主、51CTO专家 🏆

🔥 如果此文还不错的话，还请👍关注、点赞、收藏三连支持👍一下博主~

前言

2022 年 9 月 26 -27 日，有幸参加极客邦科技旗下 InfoQ 中国举办的 ArchSummit 全球架构师峰会（杭州站）。

本专栏是以“微服务架构设计模式与实践”为主题，经过推行多年，确实有很多应用程序落实了微服务架构，不过任有一些应用程序还处在 Monoliths 模式，而另一些则介于两者之间，而出现这样的情况，基本上就是公司在决定采用微服务和 Monoliths 时的技术折衷。这个专题，会相对聚焦在可落地的微服务架构经验分享。

大会内容涵盖人工智能、云计算、微服务、元宇宙、智能运维、大数据等主题，为企业管理者、架构师与开发人员提供了行业前沿视角与参考，帮助企业在数字化时代赢得先机，把握竞争优势。

本次大会官网ArchSummit 全球架构师峰会（杭州站），感兴趣的同学可以自行了解，错过杭州站的同学可以去了解一下北京站 。

本文导读

本讲由阿里云云原生应用平台高级技术专家，阿里云微服务混合云产品研发负责人，Apache Dubbo PMC member，Apache Tomcat PMC member，Apache Member • Arthas Maintainer，阿里双十一中间件稳定性负责人望陶老师所分享。

一、云原生微服务的挑战和趋势

1、微服务在云原生下的挑战

1.1 挑战

稳定，业务高可用、多可用区部署；同城/异地容灾，业务多活；微服务需要更安全、更可信。

效率，白天流量高峰期发布；云边端一体化开发部署联调；服务治理体系强依赖SDK升级；K8s下应用IP的不确定、导致服务治理规则的失效。

成本，应用迁移_上云成本很高；极致、灵活的弹性

1.2 微服务化深入服务治理是难点

下面分享一下阿里的微服务治理技术演进路线：

微服务要想服务治理的好，首先是微服务治理的划分，全链路流量治理以及微服务引擎的服务治理。

阿里把整体流程划分为三个大模块，开发态Dev，测试态Test以及变更与运行态 Ops。

其中开发态Dev分为服务元信息、服务契约管理、服务调试、服务Mock、开发环境隔离、端云互联。

测试态Test分为服务压测、自动化回归、流量录制、流量回放。

变更与运行态 Ops，分为变更态和运行态，变更态有无损下线无损上线、金丝雀发布、A/B Test、全链路灰度；运行态有离群实例摘除、日志治理、流量控制与平滑、读写流量分离、熔断降级、缓存热点治理、同AZ优先路由、服务鉴权、推空保护、访问控制

阿里全链路流量治理（漏斗模型）：

2、云原生微服务的发展趋势

后端服务BaaS化：DB，MQ, Redis, 注册中心、配置中心、服务治理中心

服务治理下沉、透明化：Java Agent, Sidecar, Java治 理和Mesh治理的统一，应用0成本. 上云

部署形态多云、混合云化：本地云端混部、多云混部、公私混部

二、运行态服务治理最佳实践

1、无损上下线

无损下线（白天大流量下发布依然丝般顺滑）

服务调用报错期的时候，由注册中心感知到服务端下线，通知消费者，客户端选择调用其他提供者，同时报错服务端确保在途请求处理完毕再下线。

无损上线

第一步应用初始化，第二部预建链接（Redis：JedisPool连接池创建后不会立即建连接；数据库：druid连接池异步创建连接），三注册服务（Dubbo/SC服务需要延迟暴露），四步，通过readiness检

查（K8s readiness检查和SpringCloud/Dubbo体系没有打通），第五步小流量预热（流量需要缓慢增加，但Dubbo 2.7.4.1以下版本存在服务预热不生效问题；Fastjson/Jetty低版本没有开启并行类

加载；JVM JIT编译问题引起cpu飙高；日志异步化），最后正常流量进入。

2、安全生产（前后端全链路灰度发布）

安全生产发布最佳实践

第一步：新建灰度Deployment，部署新版本的镜像，打上新版本的标签

第二步：配置针对新版本的标签路由规则

第三步：验证成功，扩大灰度比例。

第四步：若验证成功，将稳定版本的应用更新成最新镜像;若验证失败，把灰度的Deployment副本数调整到0或删除该Deployment

三、开发态服务治理最佳实践

多版本开发测试环境主要设计有，一、研发人员每个人独立部署一套环境；二、基于全链路流量控制进行逻辑隔离；三。入口请求打上标识，标识绑定应用 分组，形成规则推送到配置中心；四、大幅度降低研发成本

多版本开发测试环境，云上VPC主要是本地开发环境通过通道服务进行ECS代理，转发到基线环境上。

总结

本文围绕阿里云云原生的微服务挑战和趋势、运行态服务治理最佳实践、开发态服务治理最佳实践展开介绍阿里云原生微服务架构治理最佳实践展开说明和复盘。

感兴趣的同学可以自行了解其中更加详细的信息（微服务架构设计模式与实践），错过杭州站的同学可以去了解一下北京站。