ServiceMesher 社区介绍 宋净超（Jimmy Song） 2019年12月28 日ServiceMesher 社区于 2018 年 4 月 由蚂蚁金服发起成立。 20 个月 社区微信交流群拥有超过 4000+ 成员。 4000+ 社区成员来自 3000+ 企业。 3000+ 成立时间 /01 社区概况 社区成员 成员企业 9 场 线下 meetup 分别于杭州、北京、上海、深圳、广州、 分别于杭州、北京、上海、深圳、广州、 成都等地举办了 9 场 meetup。/02 社区创始人&管理委员会成员 敖小剑 蚂蚁金服 宋净超 蚂蚁金服 罗广明 百度 马若飞 FreeWheel 邱世达 博云 钟华 腾讯 孙海洲 中科院计算所 吴钧泽 好未来 殷龙飞 北控三兴 赵化冰 中兴通讯ServiceMesher 社区成立以来组织了一系列翻译活动，如： • Envoy 官方文档 官方文档 • Knative 入门 • Istio 官方文档 1.1 版本和 1.4 版本 社区官网投稿情况： • 翻译文章：147 篇 • 原创文章：122 篇 /03 社区活动2019年 10 月31 日 正式开始 istio 1.5 官网文档的翻译。 2 个月 累计合并 PR 数超过 300 个。 300+ 超过 60 人参与了官网的翻译。 60+ 持续时间 合并 PR 数

Mesh，Sofa和社区主流开发框架 Service Mesh落地要面临的实际要求选择开源产品，还是选择自研？ 起点：开源 起点：自研 全新打造；或依托现有SDK Fork，增强，扩展，定制，集成 回馈社区，反哺开源 维持版本更新，同步升级 未来肯定会开源 可扩展和可定制化是必备的 可 控 性 社 区 支 持 技术输出 内部落地 如何让开源产品接受我们的改动？ 如何让社区和客户认可我 性能和稳定性远远不能满足蚂蚁的 要求 • 但我们非常认可Istio的理念和方向 Conduit • 只支持k8s，而蚂蚁尚未普及k8s • 数据平面由Rust编写，过于小众，难于 从社区借力。 • 同样存在技术栈问题 • 公司和产品在社区知名度和影响力有限国内公司的选择之一：自研 华为：CES Mesher • 使用Golang编写 • 由go chassis演进而来 • 走的是已有类库->加proxy->再加 蚂蚁本身业务上的开放策略，要求技术也要开放，而且要在更丰富的场景下去磨炼 • 在此期间，我们趟坑无数，走了N多弯路，演进了N个版本，我们期望能过通过开源和 开放，让社区跑的更快，节省更多时间 • 我们认为金融领域下的分布式架构设计有独特的原则，作为实践者，我们期望能在标准 化上跟社区一起沉淀和共建，期望做些贡献，有些建树Sofa Mesh的开源态度 ü 开源的时机 • 产品完成甚至使用多年之后 ü 开源的内容 •

根据安全Sidecar返回的可信属性，进行权限校验逻辑。使用可信身份服务构建敏感数据下发通道使用可信身份服务构建敏感数据下发通道 密钥更新通道 安全Sidecar 的认证能力中依赖密钥等敏感信 息，在参考社区SDS方案的基础上，实现敏感 信息的管理及安全下发通道。  用户将密钥等信息通过CRD方式提交至K8s， 通过K8s的RBAC方式控制访问权限  拓展Citadel Watch 密钥相关的CR，筛选后 生产级落地实践Service Mesh Sidecar 的TLS 生产级落地实践 灰度控制 新功能总是离不开灰度过程，社区已有的Policy CRD 实现 Namespace + Service 的灰度能力不能满足 蚂蚁金服生产落地的要求，需要具备单机灰度、回滚能力。 借鉴社区 SourceLabel 和 Sidecar CRD 的设计思路，创造性提出具备“正交”组合能力的ScopeConfig 方 案 ScopeConfig 方案是通过label selector 能力选择指定范围内（批量 or 单实例）的Pod 实例，同时关 联社区现有CRD，从而实现保留在兼容社区CRD设计方面的灵活性，又能实现任意CRD的更细粒度控 制能力 以TLS 开关为例，在发布TLS开关时，先提交 ScopeConfig 通过 Pod IP 这个label 实现单实例开关控制， 在观察正常后，逐步调整ScopeConfig

发展趋势：云原生中流砥柱”的演讲，当时主要讲了三块内容： - Service Mesh产品动态 - Service Mesh发展趋势 - Service Mesh与云原生 今天的内容可以视为是上次演讲部分内容的深度展开，如社区 关心的Mixer v2，以及我个人看到的一些业界新的技术方向， 如web assembly技术，还有产品形态上的创新，如google traffic director对servicemesh的虚拟机形态的创新支持。 1：ServiceMesh灵魂拷问一：要架构还是要性能？ 大规模微服务架构下的Service Mesh探索之路 2018-06-30 蚂蚁先行一步 Part 1：ServiceMesh灵魂拷问一：要架构还是要性能？ Istio社区的Proposal Mixer V2 Architecture https://docs.google.com/document/d/1QKmtem5jU_2F3Lh5SqL p0IuPb80 想不到你这浓眉大眼的家伙也背叛革命了。 AWS Google SMI出来之前： • Istio迟迟未贡献给CNCF • Istio API 是私有API，未见有标准化动作 • Envoy xDS v2 API是社区事实标准，但这是Envoy • 统一数据平面API，感觉更像是Envoy在推动 SMI出来之后： • ServiceMesh玩家除Istio之外几乎都参与 • 未见Istio有积极回应SMI

Service Mesh 高可用在企业 级生产中的实践 罗广明 百度高级研发工程师1/总页数 讲师介绍 • 罗广明、百度高级工程师 • ServiceMesher 社区（servicemesher.com）治理委员会核心成员 • 云原生社区（cloudnative.to）联合创始成员 • 百度云智学院认证讲师 • 目前在「百度云云原生团队」负责微服务治理与相关中间件研发 • 对云原生架构与技术、研发流程、团队文化有深入研究，对 保证服务高可用3/总页数 Service Mesh 与 Spring Cloud 应用的互通、共治 /014/总页数 优点 • 微服务架构的集大成者 • 轻量级组件 • 开发灵活、简便 • 社区生态强大、活跃度高 Spring Cloud 的优缺点 缺点 • 仅适用于 JAVA 应用、Spring Boot 框架 • 侵入性强 • 升级成本高、版本碎片化严重 • 内容多、门槛高 • 治理功能仍然不全5/总页数 Failresnd34/总页数 治理策略 & 高可用 – 总结 • 从手段看高可用 • 从架构看高可用 • 从硬件看高可用 • 从软件看高可用 • 从治理看高可用 本质35/总页数 写在最后 – 开源与社区 • 什么是开源？ • 事物规划为可以公开访问的，因此人们可以修改并分享。 • 也泛指一组概念：开源的方式！ • 如何参与开源？ • 开源能带来哪些好处？36/总页数 • Service Mesh

在一定压力访问或 有客户端主动断开请求时，会进入一段存在问题的断言（assert）逻辑，导致 envoy crash， 此时请求方体现为 502 异常 • 社区目前给出的优化建议是在 envoy 编译选项使用 -opt（默认为 -dbg） • 社区已在新版本清理这段问题断言逻辑：https://github.com/envoyproxy/envoy/issues/9083 • Mixer 性能陷阱 性能陷阱 • 如打开 Mixer 的策略执行功能，每一次调用 Envoy 都会同步调用 Mixer 进行一次策略检查， 导致性能下降的非常迅速 • 社区也已经意识到并着手进行优化 • 作为 Mixer 策略执行的替代品， Istio 的 RBAC 也是可以满足一部分功能的，比如服务白名 单我们就是通过 RBAC 来实现21/24 规划与展望 /0422/24 性能优化方向 • 方案1: 采用 采用 eBPF/xDP(sockops)，优化路径为 SVC <-> Envoy，延迟性能提升10-20%。 Envoy 部署方式 per-pod，跟社区方向一致，也是目前严选采用的部署方案。 • 方案2: 采用 DPDK+Fstack 用户态协议栈，优化路径为 Envoy <-> Envoy，延迟性能提升 0.8-1 倍。Envoy 部署方式为 per-node，功能和运维层面的限制还在评估当中。

在Istio中集成方法级的调用跟踪 • 在Istio中集成Kafka调用跟踪上游开源社区参与情况 所有通用的故障修复、性能优化和新特性都提交PR合入了上游社区。包括： • Consul Registry性能和资源占用优化 • 多网络平面支持 在产品化过程中对Istio的改进会持续向社区进行贡献！Service Mesh中文社区 https://www.servicemesher.com 个人博客 https://zhaohuabing

从 SOFAMosn 到 MOSN，让社区来建设 MOSN 社区组织：MOSN Community Organization 项目地址：github.com/mosn/mosn 项目域名：mosn.io Modular Open Smart Network-proxy9/10 MOSN 未来发展思路与方向 更完善的文档及 Demo 安全审计 社区 更多的协议及服务框架支持 Dubbo、SpringCloud、

com 阿里巴巴核心应用落地 Service Mesh 的挑战与机遇 关注“阿里巴巴云原生”公众号 回复 1124 获取 PPT自我介绍 •2010 四川大学毕业 •2010-2016 社区、我的淘宝、中间件软负载 •2016-2019 自主创业、挖财中间件负责人 •2019-今 阿里服务网格团队 专注软负载、服务治理、分布式；Nacos 奠 基人、《Service Mesh 实战作者》；爱好骑 愿景 机遇 •基于 Service Mesh 基础面开发 •是否能很好的支持 Service Mesh •使用 Service Mesh 打通技术鸿沟三位一体，构建经济共同体 技术社区 内部支撑 商业赋能 技术输入 反哺增强 标准化生产 场景验证#2 阿里巴巴在落地 Service Mesh 中遇到的挑战#1 在 SDK 无法升级的情形下如何实现应用的 mesh 化

Proxy 版本：3.0.X 分布式事务 版本：3.1.X Sidecar 版本：4.0.X 多数据副本 版本：4.1.X 弹性伸缩 版本：4.2.X 已完成 图例： 进行中 规划中联合社区打造开源解决方案Sharding-Sphere：官网 http://shardingsphere.io/Sharding-Sphere：官档 http://shardingsphere.io/d io/document/current/Sharding-Sphere：Github https://github.com/sharding-sphere/sharding-sphereSharding-Sphere：社区建设 http://shardingsphere.io/community/Sharding-Sphere：使用案例 http://shardingsphere.io/community/cn/company/欢迎加入我们