MOSN 高性能网络扩展实践 王发康 2021 Gopher Meetup HZ About Me 王发康 蚂蚁集团 可信原生技术部，技术专家 蚂蚁集团技术专家，专注于高性能网络服务器研发，MOSN、Tengine 开源项目核 心成员，目前关注云原生 ServiceMesh、Nginx、Envoy、Istio 等相关领域。 喜欢开源，乐于分享。 https://github.com/wangfakang 实践效果 03 MoE Roadmap 04 MoE 背景介绍 MoE 是什么 为什么做 MoE 方案调研与分析 MoE 背景介绍 — 什么是 MoE 处理性能高 （C++） 研发效能高 (GoLang、生态) 高性能、高研发效能、生态打通 MoE = MOSN + Envoy 相互融合，各取所长 在 Service Mesh 领域，Envoy 和 MOSN 作为其数据面 sidecar 跨语言语言支持（C/C++/Rust）、 隔离性、安全性、敏捷性 处于试验阶段，性能损耗较大； WASM 目前仅对C/C++/Rust 友好， 对 GoLang Runtime 还未完全支持； 不能复用已有的 SDK，需要做网络 IO 适配改造 External-Proc Extension 跨语言支持、隔离性 需要跨进程通信性能低（UDS vs CGO 1KB Latency 差 8 倍)； 需要扩展具备

如何帮助业务快速排障 如何提供方便便捷的性能分析 调优能力 … 4 多Beats/Logstash接入 管控 提供多产品接入管理，多beats标准 化、界面化、自动化的日志接入方案 5 案例:1000+业务10000+台 主机如何快速实现日志接入？ 业务规模 1000+业务、 10000+业务主机、每天百T日志增量 日志需求 收集业务日志文件用于故障分析与告警监控 收集主机性能数据做容量分析 日志热数据保存七天 检测数据是否上报 传统Beats接入流程 配置更改 现网配置是否全部一致？ 日志上报是否有延时？ Filebeat是否资源消耗过多？ Filebeat异常退出如 何处理？ 如何做上报性能调优？ 6 系统架构 云Kafka Api-server2 Consul 云ES Agent-1 Agent-N Agent-1 Agent-N 数据流 配置监听 Agent注册 案例:如何管控整个日志数据流相关资源性能与容量？ 资源限制 cgroup cpulimit 定时检测 kill nice值 beats优化 缓存设置 工作协程 设置 资源配额 调整 Agent运行时监控 日志延时分析 Beats cpu/mem管控 ES/kafka容量管理 日志覆盖率分析 13 案例:高并发写入场景下Beats与ES性能优化 日志上报是 否有延时？

BPM、EAI… 3、管理监控 BAM、BI 4、协作平台 OA、CRM 5、数据化运营 SEM、O2O 6、互联网平台 AI、IoT 数据化运营 大数据 智能化管控 互联网平台 跨企业合作 稳态IT：安全、稳定、性能 敏态IT：敏捷、弹性、灵活 各行业IT应用系统不断丰富与创新 总部 机关 内部员工 分支 机构 内部员工 移动 接入 内部员工/合作伙伴 OA CRM HRM …… BPM MES 稳态IT 2 0 1 5 年 P i v o t a l 提 出 云 原 生 概 念 P i v o t a l 、 C N C F 同 时 提 出 云 原 生 是 一 种 充 分 利 用 云 计 算 优 势 构 建 和 运 行 应 用 的 方 式 。 D o c k e r 被 认 为 是 能 够 适 应 于 云 原 生 理 念 的 技 术 ， 而 微 服 务 被 认 为 是 适 合 D o c k 从支持应用不同维度发展，最终走在了一起 2010年WSO2提出 类云原生的概念 云原生应用相比传统应用的优势 低成本 高敏捷 高弹性 云原生应用 传统应用 部署可预测性 可预测性 不可预测 抽象性 操作系统抽象 依赖操作系统 弹性能力 弹性调度 资源冗余多 缺乏扩展能力 开发运维模式 DevOps 瀑布式开发 部门孤立 服务架构 微服务解耦架构 单体耦合架构 恢复能力 自动化运维 快速恢复 手工运维 恢复缓慢 云原生应用相比传统应用的优势(例子)

编 码 和 测 试 之 后 ， 安 全 工 程 师 才 介 入 ， 如 果 发 现 问 题 ， 又 需 要 研 发 修 复 和 重 新 测 试 ， 严 重 影 响 效 率 传 统 安 全 流 程 强 调 上 线 前 解 决 一 切 问 题 ， 某 一 环 节 堵 塞 影 响 全 局 D e v O p s 效 率 。 依 赖 于 人 员 个 人 经 验 来 先 验 的 进 行 实 施 ， 而 很 多 来阻止攻击，属于一种主动的态势感知和风险隔离技术手段 可以自动化的对非预计风险进行识别和风险隔离 对系统性能有一定影响 可信计算 核心目标是保证系统和应用的完整性，从而保证系统按照设计预期所规 定的安全状态。尤其是像边缘计算BOX这种安全防护，根据唯一Hash值验 证，可以实现极为简单的边云接入操作，运行态并不会影响性能。 可信根一般是一个硬件，比如CPU或者TPM，将从 它开始构建系统所有组件启动的可信启动链，比 Check&Report机制影响通信性能，并只涉及到服务 通信级别的安全，对node没有防护 Calico零信任 主要针对Node层的访问控制，可以让攻击者难以横向移动，隔离了风险 应用透明，全局管理视角，细粒度安全策略，针 对Node层面构建安全 采用IpTables，有一定的性能消耗 Cilium零信任 采用eBPF,为Mesh打造具备API感知和安全高效的网络层安全解决方案， 克服了Calico SDN安全和性能方面的不足

接口，抓取各个node（即kubelet）的 /metrics/cadvisor 接口的 prometheus 协议的数据 • 这个抓取器只需要部署一个实例，调用 apiserver 的接口即可，维护较为简单，采集频率可以调的稍大，比 如30s或60s • 所有的拉取请求都走 apiserver，如果是几千个node的大集群，对 apiserver 可能会有较大压力 Kubernetes Node - 容器负载监控 抓取方案 scheduler 通过 /metrics 接口暴露监控数据，直接拉取即 可 • scheduler 在 Kubernetes 架构中，是负责调度对象到合 适的node上，会有一系列的规则计算和筛选。重点关注调 度这个动作的相关指标 • 采集方式可以参考 categraf 仓库的 k8s/deployment.yaml，大盘可以参考 k8s/scheduler- dash.json • rest_clien etcd_disk_backend_commit_duration_seconds • etcd_disk_wal_fsync_duration_seconds etcd 强依赖硬盘做数据持久化，一定要用IO性能高的盘，要 特别关注硬盘相关的写入指标 Kubernetes 资源对象 的监控 Kubernetes资源对象的监控 kube-state-metrics • 所谓的资源对象，就是指Deploy

弹性可靠、松耦合、易管理可观测的应用系统，提升交付效率，降低运维复杂度， 代表技术包括不可变基础设施、服务网格、声明式 API 及 Serverless 等。云 原生技术架构的典型特征包括：极致的弹性能力，不同于虚拟机分钟级的弹性响 应，以容器技术为基础的云原生技术架构可实现秒级甚至毫秒级的弹性响应；服 务自治故障自愈能力，基于云原生技术栈构建的平台具有高度自动化的分发调度 调谐机制，可实现 采用容器集群技术的等级保护对象要求，包括第一级至第四级的安全要求。 3 云原生能力成 熟度模型 第 1 部分：技术架构 由中国信息通信研究院牵头编写，规定了基于云原生技术的平台架构的能力 成熟度评估模型，从服务化能力、资源弹性能力、可观测性、故障自愈能力、 自动化能力、无服务器化能力以及安全性等方面对技术架构进行评估。 4 云原生能力成 熟度模型 第 2 部分：业务应用 由中国信息通信研究院牵头编写，规定了基于云原生构建的业务应用的能力 网关具有身份认证、访问控制、数据校验、限流熔断等功能，可以帮 云原生安全威胁分析与能力建设白皮书 56 助安全团队管理 API。但是，当所有后端服务的流量都必须通过 API 网关进行 通信时，会对原有通信性能和 API 的稳定性产生影响，这是推进 API 网关工作 的负责人员需要面对的最大挑战。 （4）API 安全审计工具 该工具通过对 API 资产的流量上下文及敏感数据的持续分析，可以实时发 现

Build 如何在这些⼯具直接进⾏选择和切换？ Cloud Native Buildpacks buildah buildkit kaniko Function Serving 4 种函数调⽤类型（CNCF Serverless ⽩⽪书） Function Serving 同步函数: HTTP / blocking / Req & Resp 运⾏时： Knative Serving 什么是图数据库 为什么需要图数据库？ 传统数据库 图数据库 图模型的结构 图语义的查询 性能 Nebula Graph! 如何发⾳：[ˈnebjələ]， 它有哪些特点？ Nebula Graph 介绍 了解更多 >>> ⽂档：Nebula 架构 官⽹：⽤户案例 ⼀个可靠的分布式、线性扩容、性能⾼效的图数据库 世界上唯⼀能够容纳千亿顶点和万亿条边，并提供毫秒级查询延时的图数据库解决⽅案

务”�的拆分粒度中，这可能导致 “微服务”拆分粒度过细，数量进⼀步剧增的问题。最终，“微服务”之间的调⽤关系就像跨部⻔协作，也变得 越来越复杂，问题在想要新增需求时尤为突出。 “微服务”带来便利的同时，对开发⼈员⽽⾔，还带来了额外的挑战：如何快速启动完整的开发环境？开发的 需求依赖于其他同事怎么联调？如何快速调试这些微服务？ ⽽对于管理⼈员来说，也同样带来了⼀系列的挑战：如何管理开发⼈员的开发环境？如何让新⼊职的同事快 在单体应⽤的时代，对于开发者来说是极为友好的，�开发者使⽤本机运⾏应⽤，修改代码后实时⽣效，通过 浏览器访问 Localhost 实时查看代码效果。 单体应⽤和“微服务”应⽤不同，单体应⽤是 “ALL-IN-ONE” 组织⽅式，所有的调⽤关系仅限于在⾃身的类和函 数，应⽤对硬件的要求⼀般也不会太⾼。 ⽽开发“微服务”应⽤则⼤不相同，由于相互间的依赖关系，当需要开发某⼀个功能或微服务时，不得不将所 有依赖的服务都启动起来。随着微服务数

创建Ingress查看Kiali 路路由-> 命名空间istio-system,点击创建。输⼊入名称为kiali, 域名也为kiali, 选择服务kiali及端⼝口20001. 后续步骤中会随时查看Kiali，来展示服务之间的调⽤用关系。 部署应⽤用 使⽤用 kubectl 部署简单的服务 1 kubectl apply -f app.yaml 上⾯面的命令会启动全部的3个服务，其中也包括了了 addedvalues

MOSN 在云原生的探索和实践 王发康 2021 GopherChina About Me 王发康 蚂蚁集团 可信原生技术部，技术专家 蚂蚁集团技术专家，专注于高性能网络服务器研发，MOSN、 Tengine 开源项目核心成员，目前专注于云原生 ServiceMesh、 Nginx、Envoy、Istio 等相关领域。 喜欢开源，乐于分享。 https://github.com/wangfakang roadmap 云原生 • 云原生网络平台建设 • 升级 Xprotocol 框架 • 支持 WASM • 区块链网络框架 • 代码热更新 • 高性能网络层扩展 • fastGRPC • 协程收敛 epoll 模型 • CGO 性能优化 • 支持 zipkin，Jaeger 等 • 支持 ZK，Nacos 等 • 支持 Dubbo 3.0 • 支持 thrift， kafka 1.10 • 支持 Ingress 和 Gateway • 推动 UDPA 多协议建 设 核心能力 微服务 性能优化 MOSN 网络层扩展思考和选型 MOE 背景介绍 — 什么是 MOE 处理性能高 （C++） 研发效能高 (GoLang、生态) 高性能、高研发效能、生态打通 MOE = MOSN + Envoy 相互融合，各取所长 在 Service Mesh 领域，Envoy