Service Mesh技术实践及落地风险控制.pdf

Service Mesh技术实践及落地风险控制 技术创新，变革未来 • 大促趋于常态化 ➢ 工程成本变得突出，呼唤更智能、更易用、更敏捷的开发、部署、运维和管控平台 • 不少业务成了国家级基础设施 ➢ 对业务的弹性要求极高，技术体系化成了保障的关键路径 • 业务多样性让多语言应用间高效且经济的互联互通变得普遍 ➢ 集团内：收购子公司 ➢ 集团外：服务阿里云上不同技术栈的客户 • 中间件技术部从服务于集团业务全面转为服务于阿里云上的客户 • 云原生理念被广泛传播且认可范围持续扩大 • R P C 框架的现状 ➢ 与应用强耦合，推动业务方协同升级困难 ➢ 因版本难以收敛而导致风险更不可控 ➢ 框架因与业务绑定而难以快速迭代演进，进而影响基础设施的演进效率 • 初期目标 ➢ 将服务发现、服务路由等能力下沉至mesh ，对R P C 框架做瘦身 ➢ 借m e s h 化的机会去除通过Groovy脚本定制路由的能力 ➢ 构建云原生的m e s h 运维与管控体系，实现m e s h 的升级与运维对业务无感 • 借力开源、反哺开源 演进 ➢ 选型：Istio + Envoy • 平滑演进 ➢ 初态是终态的一种特殊形式 • 方便落地与回滚 ➢ 动态流量无损透明拦截 • 流量无损热升级 现状 过渡态 终态 （云原生） 同一机制 • 功能层面做到对业务无影响 ➢ M e s h 功能的开关对业务流量无影响 ➢ 流量无损热升级 • 控制应用的m e s h 化机器数 ➢ 单元内单台m e s h 化- 单元内多台m e s h 化- 单元内全量m e s h 化- 多单元m e s h 化 • 通过监控与报警实现运维工作闭环 ➢ 可灰度、可监控、可回滚 ➢ 持续完善统计信息的收集 • 云原生运维能力建设 • 历史包袱比新技术的成熟度更难应对 ➢ 关键：兼容、平滑、做减法 • 落地效率是设计技术方案时的关键考量点 ➢ 关键：无侵入、高效回滚 • 控制 “爆炸半径”去催熟新技术 ➢ 关键：可控问题其实是催化剂 •M e s h 的数据平面需要支持服务路由扩展插件 ➢ 关键：平衡 “收”与 “放” • 要点 ➢ VirtualService规则与Istio原生的一致 ➢ 路由插件是B U 维度的定制 谢谢聆听！ 20