#IstioCon 百度APP基于Istio实现 基础架构升级 许超 #IstioCon 背景 l 核心业务线已完成微服务改造，数万个微服务对架构服务治理能力提出了更高的要求。 l 高级架构能力能否多语言、多框架支持？ l 运维架构能力是否具备可移植性？是否能低成本复制新的产品线？ l 可观测性不足，是否有通用机制提升产品线可观测性？ Ø 部分模块上下游超时配置不合理，超时倒挂，集中管理调整成本比较高。 比如常用运维降级、止损能力各个产品线重复建设，方案差异大，OP期望运维能力在不同产品线之间能够通用化， 集中化管理，甚至做到自动决策 Ø 精细故障能力（异常query、注入延迟等）期望能够标准化、低成本跨产品线复制 Ø 百度APP架构缺少上下游模块视图和流量视图，黄金指标不足，导致容量管理压测效率低、混沌工程实施成 本高、故障定位成本高。 #IstioCon 目标 l 服务治理策略平台化 联合公司内部，通过合作共建方式实现完整的Service l 关键技术 Ø 内核劫持，使用Loopback IP 与 服务发现一一对应。 Ø RPC劫持，构建可快速扩展标准方案。 Ø 自身稳定性，降级（兜底）、隔离、监控多种方式保证。 ①bns, 百度内部基础设施层,服务发现。 ②bns-agent,服务发现接入层。 ㊟ 内核劫持：Loopback方案 Ø loopback地址的管理和分配。 Ø 需要打通业务和loopback之间的映射管 理。

#IstioCon ServiceMesher 数据来源：https://cloudnative.to/blog/service-mesh-end-user-survey-report/ 罗广明（百度） 马若飞（Freewheel） 邱世达（Alibaba） 宋净超（Tetrate） 赵化冰（腾讯） 关注的技术 所在行业 工作年限 职位分类 成员 4000+ 管理委员会及 社区成员画像 #IstioCon

支持代码级更新？23/25 展望-推动组织变革 FAAS 实践进展24/25 总结 FAAS 实践进展 • 深入掌握后可谨慎使用 • 可能颠覆组织和职能的运作方式，推进需要技巧 • 目前社区尚小，亟需扩大开发者群体和用户群感谢聆听 酷家乐技术博客 我的微信

（header: user:others) Envoy AwesomRPC （header: user: ***) Pilot 代码改动 • 解析 CRD • 生成 xDS 配置下发 优点： • 控制面改动小，可以快速实现对新协议的支持 问题： • Pilot 目前缺少一个良好的协议扩展机制 • Pilot 需要理解 Envoy filter 中协议特定的知识 • Pilot 代码中维护众多七层协议的代价较大

Endpoint的配置管理有防抖动处理，即使集群中的部署变化再快， 也不会阻塞Istio • Istio其他配置管理没有防抖动处理（ VirtualService/DestinationRule等），如果用程序自动化注入这些 配置要注意在客户端实现限流 • Istio的配置管理缺少兼容性设计，CRD无法做到平滑升级 • Istio的架构和基本原理 • FreeWheel的Istio实践 • 未来工作

secretName: istio.default证书过期 üroot-cert.pem 实际有效期1年，没有找到更新方式，手动更新？ ücert-chain.pem 和 key.pem 实际有效期90天，程序控制有效期45天 ü证书过期会被重新生成并挂载到/etc/certs ü触发envoy热启动ü方案一： • 把重新生成证书时间改为凌晨http://www.servicemesher.com

一个可执行文件。 Adapter作为grpc服务端，运行在独立的pod当中， Mixer通过通过rpc调用，将属性与日志发送给Adapter。基于Mixer的二次开发的流程 • 编写grpc服务端程序，接收来自mixer的数据，并实现自身业务逻辑 • 编写handler、instance、rule配置文件 • 编译打包adapter，上传至docker仓库 • 编写k8s的deployment和service配置文件