MOSN 高性能网络扩展实践 王发康 2021 Gopher Meetup HZ About Me 王发康 蚂蚁集团 可信原生技术部，技术专家 蚂蚁集团技术专家，专注于高性能网络服务器研发，MOSN、Tengine 开源项目核 心成员，目前关注云原生 ServiceMesh、Nginx、Envoy、Istio 等相关领域。 喜欢开源，乐于分享。 https://github.com/wangfakang • WASM extension • External-proc extension 可扩展性、灵活性、生态 价值意义 • 技术共享，融合 Envoy 和 MOSN 优势 • 增强 Envoy 和 GoLang 社区生态粘性 MoE Envoy 和 GoLong 生态打通 维护成本高、可扩展性弱 MoE 背景介绍 — 方案调研 方案名称 优势 劣势 Lua Extension 倍)； 需要扩展具备 gRPC server 能力， 多进程管理复杂 MOSN(GoLang) Extension 可复用 MOSN 现有的 filter 能力， 改造成本低； 研发效率高，灵活性高； GoLang 支持的库比较多（Consul、 Redis、Kafka etc），生态较好 引入 GoLang 扩展后,有一定性能损 耗,业务场景可接受，另外有优化 空间 扩展方案调研 MoE

原生技术架构的典型特征包括：极致的弹性能力，不同于虚拟机分钟级的弹性响 应，以容器技术为基础的云原生技术架构可实现秒级甚至毫秒级的弹性响应；服 务自治故障自愈能力，基于云原生技术栈构建的平台具有高度自动化的分发调度 调谐机制，可实现应用故障的自动摘除与重构，具有极强的自愈能力及随意处置 性；大规模可复制能力，可实现跨区域、跨平台甚至跨服务的规模化复制部署。 由此可见，云原生作为一种新兴的安全理念，是一种构建和运行应用程序的 细分为需求、设计、编码、测试、集成、交付、防护、检测和响 应阶段；而纵轴则是按照云原生系统和技术的层次划分，包括容器基础设施安全、 容器编排平台安全、微服务安全、服务网格安全、无服务计算安全五个部分，二 维象限中列举安全机制（蓝色标注部分）已经基本覆盖全生命周期的云原生安全 能力。此外，DevSecOps 涉及的能力范围几乎覆盖了横轴和纵轴的各个阶段， 如图中的紫色部分。最后，云原生安全体系中还包括了一些通用技术能力（黄色 ，一是面向云原生环境的安 全，其目标是防护云原生环境中的基础设施、编排系统、微服务、无服务和服务 网格等安全。二是具有云原生特征的安全，指具有云原生的弹性敏捷、轻量级、 可编排等特性的各类安全机制。在此基础上，未来云原生环境必将与云原生技术 的安全互相融合，成为统一的整体，并且将经历如下三个发展阶段： （1）安全赋能于云原生体系，构建云原生的安全能力。当前云原生技术发 展迅速，但相应的

Nginx、Envoy、Istio 等相关领域。 喜欢开源，乐于分享。 https://github.com/wangfakang MOSN 开源交流群2 目 录 MOSN 云原生演进历程 01 MOSN 网络层扩展思考和选型 02 对应解决方案和实践介绍 03 MOSN 开源进展同步 04 MOSN 云原生演进历程 MOSN 简介 — 演进历程 MOSN 从 Service Mesh 技术调 • 高性能网络层扩展 • fastGRPC • 协程收敛 epoll 模型 • CGO 性能优化 • 支持 zipkin，Jaeger 等 • 支持 ZK，Nacos 等 • 支持 Dubbo 3.0 • 支持 thrift， kafka 等 协议 • 支持 Istio 1.10 • 支持 Ingress 和 Gateway • 推动 UDPA 多协议建 设 核心能力 微服务 微服务 性能优化 MOSN 网络层扩展思考和选型 MOE 背景介绍 — 什么是 MOE 处理性能高 （C++） 研发效能高 (GoLang、生态) 高性能、高研发效能、生态打通 MOE = MOSN + Envoy 相互融合，各取所长 在 Service Mesh 领域，Envoy 和 MOSN 作为 其数据面 Sidecar 之一 ，用于解决传统服务治 理体系下的痛点如：多语言中间件组件开发适配

现，查找所有node，通过 Kubernetes apiserver 的 proxy 接口，抓取各个node（即kubelet）的 /metrics/cadvisor 接口的 prometheus 协议的数据 • 这个抓取器只需要部署一个实例，调用 apiserver 的接口即可，维护较为简单，采集频率可以调的稍大，比 如30s或60s • 所有的拉取请求都走 apiserver，如果是几千个node的大集群，对 /metrics/cadvisor 暴露的是 cAdvisor 的监控数据（prometheus协 议），在 /stats/summary 暴露的是容 器的概要监控数据（普通json协议）， 在 /metrics 暴露的是自身的监控数据 （prometheus协议） • Kubelet 的核心职责就是管理本机的 Pod 和容器，典型的比如创建 Pod、销 毁 Pod，显然我们应该关注这些操作的 成功率和耗时 • Categraf apiserver 的耗时分布，histogram类型，按照 url + verb 统计 • scheduler_framework_extension_point_duration_s econds 调度框架的扩展点延迟分布，按 extension_point 统计 • scheduler_pending_pods 调度 pending 的 pod 数量，按照 queue type 分别统计 • schedu

制品的安全分发(签名、漏洞扫描与安全策略) - 资源清理与垃圾回收 - 构建高可用(HA)制品仓库服务 - Harbor集成与扩展 - 路线图 - 参与贡献Harbor社区 云原生与制品管理 [1] 云原生(cloud-native)技术使组织能够在现代化和动态的环境下（如公有云、私有云 和混合云）构建和运行可扩展的应用程序。云原生典型技术包括容器、服务网络、 微服务、不可变基础设施和声明性API等。 v1.0 by Registry: •制品存储仓库 •分发制品的媒介 •访问控制与管理的节点 初识Harbor [1] 官方网站：goharbor.io CNCF毕业项目 落地在很多企业级 产品中 Apache 2.0协议下 开源 GitHub代码库: https://github.com/goha rbor/harbor/ 一个开源可信的云原生制品仓库项目用来存储、签名和管理相关内容。 Harbor社区 management Settings 提供以项目为单位的逻辑隔离，存储共享 不同角色具有不同的访问权限，可以与其它用户系统集成 配额管理 制品的高效分发-复制 [1] 基于策略的内容复制机制：支持多种过滤器(镜像库、tag和标签）与多种触 发模式（手动，基于时间以及定时）且实现对推送和拉取模式的支持 初始全量复制 增量 过滤器 目标仓库 源仓库 目标项目 源项目

直接在业务代码使用。 支持常见的数据库和JDBC。 轻量级，不需要额外的资源和机器。 1.数据库框架 1、改造对业务系统具有较大侵入性； 2、对于复杂的SQL，可能不支持； 3、对于跨库和跨分片的数据，需要额外机制保障一致性； 4、缺乏较好的数据平滑迁移和过渡方案； 5、Java Only（或其他）。 数据库框架使用的约束： 2.数据库中间件 2.数据库中间件 作为中间件，独立部署，对业 务端透明。 IDE操作。 对业务系统侵入性小。 透明化的引入中间件，像一个数据库一样提供服务能力。 2.数据库中间件 1、框架本身的一些问题； 2、需要单独的资源部署，以及维护； 3、接入端需要实现数据库协议，对非开源数据库无法支持。 数据库中间件使用的约束： 3.分布式数据库 3.分布式数据库 类库/框架 数据库中间件 分布式数据库 数据网格 TDDL Sharding-JDBC DRDS Vitess ? Spanner Aurora GaussDB PolarDB OceanBase TiDB Cockroach DB …… 3.分布式数据库 1.水平扩展性 2.计算存储分离 3.分布式事务 4.多副本机制 5.SQL接入支持 6.云原生支持 容量 性能 一致性 可高用 易用性 伸缩性 代替单机数据库（注意，主要解决容量问题）。 3.分布式数据库 1、需要较多的机器资源；

率低，故障排查慢，阻碍了软件价值的流动 无法满足用户对于业务快速研发、 稳定交付的要求 场景 1 如果生产中一台Web应用服务器故障，恢复这台服务器需要 做哪些事情？ 场景 2 如果应用负载升高/降低，如何及时、按需扩展/收缩所 用资源？ 场景 3 如果业务系统要升级，如何平滑升级？万一升级失败是 否能够自动回滚？整个过程线上业务持续运行不中断。 传统稳态业务环境难以高效承载敏态应用 发现故障 （假死） 创建 新实例 测试确认 服务正常运行 实例 加入集群 恢复正常 场景 1 如果生产中一台Web应用服务器故障，恢复这台服务器需要 做哪些事情？ 场景 2 如果应用负载升高/降低，如何及时按需扩展/收缩所用 资源？ 场景 3 如果业务系统要升级，如何平滑升级？万一升级失败是 否能够自动回滚？整个过程线上业务持续运行不中断。 传统稳态业务环境难以高效承载敏态应用 发现故障 （假死） 创建 新实例 新一代架构（微服务）应用的对承载平台提出新要求 传统实践中，主要采用虚机/物理机+SpringCloud等微服务框架的方式承载微服务应用。但在一个虚机/服务器上 部署多个微服务会产生如下问题—— • 资源预分配，短时间内难以扩展 • 缺乏隔离性，服务相互抢占资源 • 增加环境、网络（端口）和资源管理的复杂性，治理成本高 • 监控粒度难以满足微服务应用运维的需要，线上问题难以排查定位，往往需要研发介入 我们需要一种新型的、为云而生的业务承载平台，去应对上述问题。

② 存储 ② 存储 ③ 查询 ③ 查询 看云网更清晰 Simplify the growing complexity. MultistageCodec的性能提升：~10X 标签存储类型 机制 标签长度 CPU 内存 磁盘开销 使用Int Tag 直接存索引 16B 1 1 1 使用LowCard(String) Tag 索引和标签分离 16B 10 1 1.5 (Card.=5000) the growing complexity. 落地及推广思路：让开发团队尝到甜头 • 引导开发团队使用标准化的标签标记机制 • 服务上线时，在K8s depoyment中标记丰富label • * 服务注册时，向服务注册中心中注册丰富的信息 • * 处理请求时，在标准协议的Header中增加标签 • 逐步减少需要直接在观测数据中注入的标签 • 减少重复的、不标准的标准注入 • 让每个标签只在一个地方注入 应 用 DeepFlow：零侵扰的云原生应用可观测性平台 数据分析 解析 聚合 关联 压缩 零侵扰的采集与分析 发送 零侵扰的云原生应用可观测性 Flow 数据节点 云原生，水平扩展 监控数据 性能指标 调用日志 网络链路 由业务代码驱动的可观测性数据、云API数据 调用关系 知识图谱 链路追踪 黄金指标 关联 应用链路（Tracing） 应用日志（Logging）

云原生CI持续集成 使用Dockerfile进行云原生方式的CI构建， 拓展形成ARM、x86双架构流水线，底层 安全漏洞统一修复 全面云原生安全 支持代码安全扫描、镜像安全扫描、开源 协议扫描、依赖漏洞扫描。并可给出修复 建议。支持开源风险持续治理。 108 48 78 6 84 1 1 16 14 0 50 100 150 200 250 本单位 省公司 分类分级标记 ü 关联责任人 ü 关联内外网业务 ü 漏洞及投毒检测 ü 自主可控率分析 ü 许可证合规分析 ü 自动化修复技术 ü 安全可信私有源 ü 供应链准入审查 ü 供应链准出机制 ü 过程持续验证 !"#$%&'( !"#$)*+,- !"#$%&' 安全开发-代码扫描SAST 源代码审计针对源代码缺陷进行静态分析检测。它在对目标软件代码进行语法、语义分析的技术上，辅以数据流 镜像通过发版。 安全测试-APP扫描 移动应用安全检测和个人信息合规检测能力，基于磐舟平台，容器化部署，紧邻租户业务系统，支持浏览器 访问及API。已对接磐舟CI/CD流程，资源可弹性管理，可满足高可用、高扩展、高容错等特征。 待检测APP APP自动化检测 APP安全检测报告 APP安全检测 个人信息保护专项检测 按照安全检测报告对APP进行整改 人工辅助 包含的服务 l Android 应用的自动化安

Rainbond⾃自身的⽇日志管理理机制 2.对接 Elasticsearch 3.演示示例例 ⼤大纲 RAINBOND 线上培训（第⼋八期） 2019/7/31 1.RAINBOND⾃自身⽇日志管理理机制 1.1 ⽇日志界⾯面 RAINBOND 线上培训（第⼋八期） 2019/7/31 1.RAINBOND⾃自身⽇日志管理理机制 1.1 ⽇日志界⾯面 RAINBOND 2019/7/31 1.RAINBOND⾃自身⽇日志管理理机制 1.1 ⽇日志界⾯面 RAINBOND 线上培训（第⼋八期） 2019/7/31 1.RAINBOND⾃自身⽇日志管理理机制 1.2 Rainbond⽇日志收集原理理 RAINBOND 线上培训（第⼋八期） 2019/7/31 1.RAINBOND⾃自身⽇日志管理理机制 1.3 ⽇日志来源，以及相关原理理 node服务功能与⻆角⾊色 rbd-eventlog组件功能与⻆角⾊色 NODE服务会监视DOCKERD进程，观察其创建与销毁容器。获取⽂件系统中容器⽇志的路径，
 监视来⾃容器标准输出和标准错误输出，并以UDP协议分发到RBD-EVENTLOG组件。 接收来⾃NODE服务的推送，⽤WEBSOCKET协议将⽇志内容推送到⽤户所操作的应⽤控制台。 RAINBOND 线上培训（第⼋八期） 2019/7/31 2.对接ELASTICSEARCH