架构设计以及开源策略。 前言技术选型 Technical 1ü 性能要求 • 以蚂蚁金服的体量，性能不够好则难于接受 • 架构与性能之间的权衡和取舍需要谨慎考虑 ü 稳定性要求 • 以蚂蚁金服的标准，稳定性的要求自然是很高 • 高可用方面的要求很非常高 ü 部署的要求 • 需要用于多种场合：主站，金融云，外部客户 • 需要满足多种部署环境：虚拟机/容器，公有云/私有云，k8s • 需要满足多种体系：Service 华为：CES Mesher • 使用Golang编写 • 由go chassis演进而来 • 走的是已有类库->加proxy->再加 控制平面的路线 • 部分对接Istio • 细节暂时不清楚，即将开源 新浪微博：Motan Mesh • 也是使用Golang编写 • 全新实现（原有类库是基于Java） 老成持重的稳健思路：以proxy为切入口，第 一时间获取跨语言和技术栈下沉的红利，立足 • 在此期间，我们趟坑无数，走了N多弯路，演进了N个版本，我们期望能过通过开源和 开放，让社区跑的更快，节省更多时间 • 我们认为金融领域下的分布式架构设计有独特的原则，作为实践者，我们期望能在标准 化上跟社区一起沉淀和共建，期望做些贡献，有些建树Sofa Mesh的开源态度 ü 开源的时机 • 产品完成甚至使用多年之后 ü 开源的内容 • 陈旧的技术，过时的架构 • 放弃不再使用的产品

务间的连通问题Service Mesh是下一代的SDN吗？ 通信网络 l 互不兼容的专有设备 l 基于IP的通信缺乏质量保证 l 低效的业务部署和配置 ... 微服务系统 l 互不兼容的代码库 l 不可靠的远程方法调用 l 低效的服务运维 ... 通信网络和微服务系统面临类似的问题：Service Mesh是下一代的SDN吗？ Network Layer Look at Solution Mesh发展的启发： Ø 北向接口 • 面向业务和运维 • 具有较高的抽象层次，比较容易提取统一的控制面标准？ • 主要面向layer 7及以上？ • SMI能否统一控制面标准？如何避免成为最小公分母，扩展支持其它协议？ Ø 南向接口 • 面向流量和路由配置 • xDS v2将统一数据面标准？ • xDS接口包含有较多实现相关内容：Listener, Filter, 能否可以成为一个通用的接口协议？

每个服务都尽量小，小到一个小团队能够很好的维护它； • 服务可独立部署，每次部署不会影响其他服务； • 每个服务都各自负责自己的数据和状态的存储，独立数据库； • 服务和服务之间通过设计良好的API接口通信，不暴露具体的实 现细节； • 各服务不需要统一技术栈，不需要共享公共库和框架；微服务究竟带来什么好处 Ready for market faster：快速响应市场地变化 Mix of technologies：多技术栈混合使用； SOA MSASOA MSA 尽可能多的共享和复用 share as much as possible 尽量少的共享和复用 share as little as possible 要求统一和标准化 common governance and standards 提倡协作和自由 people collaboration and freedom 服务间通过企业服务总线ESB通信 Enterprise 格负责在这些拓扑中 实现请求的可靠传递。在实践中，服务网格通常实现为一组 轻量级网 络代理，它们与应用程序一起部署，但 对应用程序透明。Service Mesh的实现原理 Spring Cloud的类库模式 Service Mesh的Sidecar模式Service Mesh：Istio架构Service Mesh：Linkerd架构Service Mesh： OCTO-Mesh架构为了解决单体的复杂度问题，我们引入微服务架构

0 0.4.0 Ø 内存复用框架 Ø Slab style buffer Ø Raw-Epoll模式 Ø 读合并 Ø 协程池化 Ø 调度均衡 Ø SOFARPC深度优化 Ø TLS官方库IO优化 Ø HTTP1.1/HTTP2.0 IO优化 Ø 日志操作异步化&多次合 并 Ø 基于RCU的高性能配置更 新安全 & 可观察性 0.1.0 0.2.0 0.3.0 0.4.0 Ø 构扩展性。 ü 性能上，针对IO、协议、内存、协程进行持续优化。相比最初版本，SOFARPC 协 议上对 0.1.0 版本 QPS 提升了 50%，内存使用减少了 40%；HTTP/2.0 相比官方库原 生实现，QPS提升了100%；HTTP/1.1 也有 30% 以上的性能提升。同时，针对具体 问题提供具体的解决方案，例如对于长连接网关场景，提供raw epoll模式来优化性 能表现。 ü 能力上，经过多轮演进，0 MOSN调用地址 ü 通过扩展cluster类型的方式 动态获取配置中心后端 ü MOSN出向路由基于明确的 服务依赖关系生成 ü 服务通过 id:version 定义 ü 适用于SOA化服务，标准微 服务 ü 适用于跨语言通信的场景蚂蚁落地 – 复杂路由 ü 基于链式路由机制扩展，使 用router match，subset等 开源能力实现 ü 适配蚂蚁三地五中心机房部 署，LDC/弹性架构

Nitrox软硬件一体解决方案 SSL握手性能 提升3倍 • 对Spanner实现了异步化改造 • 对openssl进行了异步化引擎改造 • 实现多芯片卡的负载均衡协议实现的改造-MTLS MTLS：1) 轻量级TLS库，小于50k；2) 优化的TLS协议 0-RTT • 减少握手延迟 • 代价：握手前发送的数据不能 保证防重放攻击，因此要求应 用程序自己保证防重放攻击 Small Ticket • 自定义Session Size • 平衡吞吐与时延 高效 优化 灵活 TLS扩展安全合规能力持续升级 国密算法 • 拥抱监管 • 安全可控 • 金融科技 AntTLS库 • 基于OpenSSL • 全面拥抱TLS1.3 • 国密优化实现，国密单证书标准支撑 • 支持SGX等可信机制 • 多硬件卡Engine • Mobile，iot设备等多终端支持 • OpenSSL Committer无线移动战役 操作响应慢

并为诸如C / C ++等语言提供一个编译目标，以便它们可以 在Web上运行。它也被设计为可以与JavaScript共存，允许两者一起工作。 WebAssembly不是一门编程语言，而是一份字节码标准。 WebAssembly字节码是一种抹平了不同CPU架构的机器码， WebAssembly字节码不能直接在任何一种CPU架构上运行， 但由于非常接近机器码，可以非常快的被翻译为对应架构 的机器码， Service Mesh Interface Universal Data Plane API “SMI 是在 Kubernetes 上运行服务网格的规 范。它定义了由各种供应商实现的通用标准。这 使得最终用户的标准化和服务网格供应商的创新 可以两全其美。SMI 实现了灵活性和互操作 性。” “SMI API的目标是提供一组通用的，可移植的 Service Mesh API，Kubernetes用户可以以 Google在ServiceMesh标准化上表现异常：而标准化是供应商不锁定的基石 Part 4：ServiceMesh灵魂拷问四：说好的供应商不锁定呢？ AWS：我原以为只有我这长相的会背叛革命， 想不到你这浓眉大眼的家伙也背叛革命了。 AWS Google SMI出来之前： • Istio迟迟未贡献给CNCF • Istio API 是私有API，未见有标准化动作 • Envoy xDS

K8s•未来应用开发一定是 云原生 •考验好产品的标准是 云原生 •经济、技术共同体是 愿景 机遇 •基于 Service Mesh 基础面开发 •是否能很好的支持 Service Mesh •使用 Service Mesh 打通技术鸿沟三位一体，构建经济共同体 技术社区 内部支撑 商业赋能 技术输入 反哺增强 标准化生产 场景验证#2 阿里巴巴在落地 Service

Proxy 作为代理组件 • 控制面以 Pilot 为核心组件 • 平台开放与扩展主要通过 Kubernetes CRD与Mesh Configuration Protocol（简称为 MCP，一套标准 GRPC 协议） • 高可用设计主要基于 Kubernetes 及 Istio 机制实现14/24 Service Mesh 在混合云架构落地 /0215/24 严选上云 Roadmap16/24 Proxy 作为代理组件 • 控制面以 Pilot 为核心组件 • 平台开放与扩展主要通过 Kubernetes CRD与Mesh Configuration Protocol（简称为 MCP，一套标准 GRPC 协议）19/24 质量保障体系 • CICD • 单元测试 • 性能基准自动测试 • 监控报警 • 版本升级机制 • Envoy 热更新机制 • 灰度发布机制：业务灰度+流量灰度

Mesh风头正劲Service Mesh产品多样化Service Mesh的优势 云原生 零入侵 可观察性 面向运维服务化之后，数据库怎么办？ 服务 • 无状态 • 根据规则路由 • 业务方处理事务 数据库 • 有状态 • 根据SQL路由 • 数据库自动处理事务数据库的进化趋势 • SQL • ACID • 分布式 RDBMS • SQL • BASE ACID • 分布式 NewSQL?数据库中间层的优势 系统 •事务 运维 • DBA 开发 • SQL数据库中间层应具备的能力 分片化 多副本 数据一致性 弹性化 治理能力 观察能力数据分片 App2 DB App1 App3 App2 DB1 DB2 DB3 App1 App3数据分片：引入中间件 App1 M1 App2 App3 S2 M2 M3 S1 S3 数据库中间件 write App3 M2 sync read S2 S3 M1 M3 write数据分片 + 读写分离：引入中间件 App1 M1 App2 App3 S2 M2 M3 S1 S3 数据库中间件 write sync read分布式事务：定义 传统事务：ACID Atomicity - 原子性 Consistency - 一致性 Isolation - 隔离性 Durability

• 对象翻译 • IngressRouterContour的优劣 • 优势 • 兼容Istio生态，融入Service Mesh生态 • 南北向流量使用Envoy • 兼容Kubernetes标准Restful接口 • 统一的Kubernetes管理接口 • Gimbal生态 • 多集群入口流量整合管理 • 劣势 • 缺少大规模落地案例 • 功能/非功能仍需加强Contour & Istio