函数计算在双11小程序场景中的应用 关注“阿里巴巴云原生”公众号 回复 1124 获取 PPT自我介绍 •吴天龙（花名: 木吴） •阿里云函数计算技术专家 •2013 年加入阿里云，参与分布式数据库， 对象存储等产品的开发。现任阿里云函数 计算架构师，聚焦于 Serverless 产品功 能和大规模资源伸缩调度、性能优化等系 统核心能力的研发。❖ 函数计算介绍 ❖ 双11小程序场景介绍 ❖ 技术挑战 技术挑战 ❖ Demo 目录函数计算-介绍 • 通用Serverless计算平 台 • 与云端事件源无缝集成 • 弹性伸缩，按量付费函数计算-介绍双11小程序场景介绍小程序场景的挑战 n 安全隔离 n 开发效率 n 大量的小程序是不活跃的 n 活动高峰期流量激增函数计算-冷启动优化 Download & Extract Code User Code Init Logic Execution

C实现，支持多语言扩展 • 基于Nginx扩展 • 开发不活跃 • 老牌代理系统，业界广 泛使用，服务各类场景 • C++实现 • CNCF第三个毕业项目， ISTIO原生数据平面 • 开发活跃，最新版为1.9.0 • Google, Lyft主导，业界 众多公司使用中，重点搭 载ISTIO使用，服务各类 场景 • Rust实现 • CNCF项目，最早的 Service Mesh数据平面 • 开发活跃，最新版为 Golang实现 • 新生项目，初期旨在搭建 RPC亲和，高度可扩展性 的Golang转发系统 • 开发活跃，最新版为0.4.0 • 蚂蚁+UC主导，重点搭载 SOFAMesh使用，目标服 务通用场景，金融场景SOFAMOSNSOFAMOSN内部模块设计SOFAMOSN数据流SOFAMOSN数据流持续演进路径 & 技术案例能力 0.1.0 0.2.0 0.3.0 0.4.0 Ø TCP代理/7层通用代理 kernel：2.6.32-220.23.2.el6.x86_64 p 单核模式：1 core； 多核模式： 4 core p Post请求：1k上传，1k下载 p h2load：100连接，10并发 场景 QPS RT(ms) MEM(M) CPU(%) Old http2(1 core) 2700 358ms 55M 100% New http2(1 core) 6500 152ms 36M 100%

SkyWalking 核心贡献者, Istio 贡献者。 1/28/01 /02 /03 SkyWalking 简介 遇到的挑战 应用方案 ServiceMesh 场景 下 SkyWalking 面 临的挑战 针对 Mesh 场景方案的演化 SkyWalking 历史和特 点 2/28SkyWalking 简介 /01 SkyWaling 的历史和特点 3/28Micro Service 抽象概念，用于汇集指标 Service 实例 进程，容器，Pod Instance 端点 URL，RPC，函数 Endpoint 观察维度 9/28遇到的挑战 /02 Service Mesh 场景下 SkyWalking 面临的挑战 ( Istio ) 10/28可观测性 11/28Istio 1.5 架构图 12/28挑战1：技术路线多变 基于 Log 成熟、但性能低 Mixer Instance Service Endpoint 15/28挑战3：维度匹配-Telemetry2 Instance Service Endpoint 16/28应用方案 /03 针对 Mesh 场景下的方案演化 17/28技术路线全覆盖-Mixer 18/28技术路线全覆盖-Mixer 19/28技术路线全覆盖-Mixer 20/28技术路线全覆盖-Envoy AccessLogService

üRuntime 内存使用率提升，arena 区内存申请频率低，大小更小 üMheap 申请系统内存减少约60%内存 3 ØSLAB-style buffer pool ü减少内存 copy ü压测场景下内存复用率90% ØGolang 内存模型亲和 üP中 mcache 缓存小于 32K 的小内存块，最大 2M ü小内存分配顺序 Pmcache -> mcentral -> mheap -> Xeon(R) CPU E5-2650 v2 @ 2.60GHz X 1 üOS： 3.10.0-327.ali2008.alios7.x86_64 Ø软件 üMOSN 0.1.0 üEnvoy 1.7 Ø场景 ü代理模式: client -> mesh -> server üClient直连server请求耗时1.6msSOFARPC + 1K字符串 8 指标\软件 SOFAMosn Envoy QPS峰值 Intel(R) Xeon(R) CPU E5620 @ 2.40GHz X 16 X 1 üOS: 2.6.32-431.17.1.el6.FASTSOCKET Ø软件 üMOSN 0.1.0 Ø场景 ü代理模式: client -> mesh -> server üClient直连server请求耗时1.6ms单核SOFARPC转发 11 指标\软件 SOFAMosn Envoy QPS峰值

在当下『路口』的思考 • 大量的应用还跑在非 k8s 体系上（VM、独立的注册中心等） • 当下这些 brownfield 应用的业务价值往往更大，如何把它们纳入 Service Mesh 统一管控？ 现实场景 – Brownfield 应用当道 图片来源：https://medium.com/next-level-german-engineering/comparison-of-two-differ -4e5298736d4213/39 Part 2： 在当下『路口』的思考 • Mixer V1 性能堪忧 • Mixer V2 遥遥无期 • Pilot 性能也有较大隐患 现实场景 – 云原生方案离生产级尚有一定距离 图片来源： https://istio.io/docs/reference/config/policy-and-telemetry/mixer-overview/14/39 01 2018年初开始用Golang 开发 Sidecar SOFAMosn， 年中开源基于 Istio 的 SOFAMesh 技术探索 02 2018年开始内部落地，第一 批场景是替代 Java 语言之外 的其他语言的客户端 SDK， 之后开始内部小范围试点 小规模落地 03 2019年上半年，作为蚂蚁金融级 云原生架构升级的主要内容之一， 逐渐铺开到蚂蚁主站的业务应用，

先原生，后二开 • 先管控面，后数据面落地场景—Spock测试平台 • 历史问题 • 分布式系统性能测试问题 定位难 • 多版本并发测试 • 故障注入较困难（代码侵 入性强） • 测试环境不稳定，后端Pod 频繁重启 • 解决方案 • Contour产品化 • Istio的灰度发布和流量管理 • Istio的Tracing产品化落地场景—云存储系统 • 历史问题 • 灰度发布 系统故障隔离 • 跨集群访问 • 线上问题链路追踪 • 解决方案 • Istio南北流量分流策略产品化 • 基于Istio的QoS产品化 • 跨集群流量调度 • 基于Istio的Tracing产品化落地场景—大数据产品 • 系统优化之路 • 多版本灰度升级 • 根据流量做横向伸缩 • 分布式系统性能测试问题 定位难 • 解决方案 • Istio南北流量分流策略产品化 • 基于Istio的QoS产品化

是否会出现Envoy之外的大量数据面实现？ • 建议：对xDS接口进行改进，去掉实现相关内容 Ø Service Mesh的发展 • 控制面对数据面软硬件的统一控制能力？ • 通过控制面API接入各种丰富的应用场景 - 下一个热点？总体架构-高层视图 DexMesh控制面 MSB-SDClient MSB-Consul Jaeger DexMesh数据面 Pod Microservice Envoy Other business logic ... 提供七层网关能力， 但和服务网格是割裂 的 提供七层网关和网格 能力，但缺少API管 理能力 提供API管理能力， 缺少服务网格能力在DexMesh场景下Mesh和API Gateway的分工与协同 External request MSB API Gateway API Management Ingress Sidecar Service 存量网络设备 “金丝雀”设备 消息上报 “金丝雀”用户 灰度发布应 用 运维 通过Envoy插件和Istio协议扩展来实现？产品化增强-其他 • APP：灰度发布、流量控制，更多的APP待业务场景触发 • IPV6支持增强 • 在Istio中集成方法级的调用跟踪 • 在Istio中集成Kafka调用跟踪上游开源社区参与情况 所有通用的故障修复、性能优化和新特性都提交PR合入了上游社区。包括：

心跳检查在Service Mesh场景下网络代理有着不同于接入层的挑战 • 无论应用是否接入Mesh，接入了多少Mesh，都需要保证可正常处理请求，做到可 灰度、可回滚的兼容，平滑迁移 • 通用的框架能力（SOFAMosn/Envoy）无法直接满足复杂的、定制的业务能力，需 要进行针对性的扩展实现 • 需要融合主站已有的应用体系，如注册中心、配置中心等，这些也需要扩展实现 • 大规模场景下需要面对的资源占 html总结 应用网络SDN 通信能力持续升级 安全与合规 § 南北，东西应用层流量的全局管 控，调度和安全能力 § 全方位的安全防护，全链路加密， 应用层的零信任网络 § 随通信基础设施，通信场景的变 化而演进 § 金融级的通信安全基础设施关于未来 § 云原生，多云混合云时代，南北，东西流量的边界逐渐模糊 § 应用网络代理层部分能力固化，下沉至系统网络栈或者智能硬件设备 § 物理通信基础设施的升级势必带来应用网络层的变革

运维Agent • 单个Pod升级Agent • 多个Pod发布编排 Agent发布流程19/24 数据平面容灾方式 服务类应用 • 场景：出流量由入流量产生 • 方案：由原有健康检测机制摘除流量 借助原有服务治理能力 特殊应用 • 场景：流式计算、定时任务 • 方案：出流量降级至本应用的其他Agent 出流量容灾20/24 数据平面性能优化 方案整体 • 新增MOA Mesh协议

TLS 生产级落地实践 分享内容基于 Secret Discovery Service Sidecar 的证书管理方案 Kubernetes Secret 证书管理流程 在 Kubernetes 场景下，证书是通过 secret 的方式来管理，使用时通过 secret mount 以 Volume 形式挂载。 存在以下三个问题：  Secret 管理方式与现有密钥管理系统有冲突，需要密钥管理系统强依赖 SDS 证书管理方案 ISTIO Policy | Mesh Policy ScopeConfigService Mesh Sidecar 的TLS 生产级落地实践 开关切换 RPC 通信场景下，为保证平滑无损的TLS切换能力，需 要分别控制 Server (Provider) 和 Client (Consumer)端的 TLS 行为  对于Server 端利用Istio 的Policy