Volcano加速金融行业大数据分析平台 云原生化改造的应用实践 汪 洋, 华为云 Volcano 社区核心贡献者 大数据平台云原生面临的挑战 传统大数据平台云原生化改造成为必然趋势 大数据分析、人工智能等批量计算场景深度应用于金融场景 作业管理缺失 • Pod级别调度，无法感知上层应用 • 缺少作业概念、缺少完善的生命周期的管理 • 缺少任务依赖、作业依赖支持 调度策略局限

个电商下单APP，只需要利用中台提供的能力要素，并在APP端组织业务 流程或者产品流程，下单后，商品自动送到用户手中，而无需企业打通 上下游业务链路，可以支撑快速的组织创新和业务创新。 高级能力-低代码或无代码平台 为了进一步加速业务APP交付速度，而专业业务人员并不熟悉IT领域知识，但是低代码可以使得非IT人员快速构建业务系统成为可能，低代码平台是业 务研发和运行一体的平台，其内部实现并不容易，想落地更不容易，关键在于人们 部门的系统、不同类型 的技术，如 RPA、BPM、 微流逻辑等串联在一起， 实现端到端的智能自动 化。是种生态型平台。 高级能力-混合云（资源角度） 控制力 服务、位置、规则可控 高安全 安全自主可控 高性能 硬件加速、配置优化 固定工作负载 私有云 混合云 SLB 工作负载可迁移 敏捷 标准化、自动化、快速响 应 低成本 按需伸缩、按需使用付费 弹性 可弹性无限拓展 弹性工作负载 公有云 ETCD ETCD 说明 全托管K8S 全托管K8S服务带来了发布和扩容效率的提升、更稳定的容器运行时、节点自愈能力，结合发 布自动化、资源管理自动化等能力可以实现应用与基础设施层的全面解耦 统一化ServiceMesh 将应用的分布式复杂性问题托付给Mesh层的数据面和控制面组件，实现全链路精准流量控制、 资源动态隔离以及零信任的安全能力，保证应用架构的稳定性目标的实现。 Serverless化 极大地降低了开发人

Nginx、Envoy、Istio 等相关领域。 喜欢开源，乐于分享。 https://github.com/wangfakang MOSN 开源交流群2 目 录 MOSN 云原生演进历程 01 MOSN 网络层扩展思考和选型 02 对应解决方案和实践介绍 03 MOSN 开源进展同步 04 MOSN 云原生演进历程 MOSN 简介 — 演进历程 MOSN 从 Service Mesh 技术 MOSN 简介 — 2021 roadmap 云原生 • 云原生网络平台建设 • 升级 Xprotocol 框架 • 支持 WASM • 区块链网络框架 • 代码热更新 • 高性能网络层扩展 • 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 相互融合，各取所长

智能时代迈进的背景下，分析云原生安全的发展情况和面 临的威胁，并研究云原生安全能力，能够为企业整体的云安全防护体系建立提供 帮助，从而保障企业业务和数据更安全的在云上运转。 1.1 云原生及云原生安全 过去十年，企业数字化转型加速推进，相继经历了服务器、云化到云原生化 三个阶段。在云化阶段，云主机是云计算的核心负载之一，云主机安全是云安全 的核心；在云原生阶段，容器和无服务器计算成为核心工作负载，容器安全、 Serverless ，由于云原生安全的核心是要 保证云原生应用及数据安全，因此云原生安全技术体系也需要围绕云原生应用的 生命周期来构建，相关安全能力包括容器安全、代码及应用安全、平台安全以及 基础设施安全在内的四层关键能力，以及多云之间的安全管理和防护能力，部分 云原生安全能力如图 4 所示。 图 4 云原生安全能力体系 云原生安全作为一种新兴的安全理念，不仅要解决云计算普及带来的安全问 云原生安全威胁分析与能力建设白皮书 5，从攻击者角度展 示云原生应用关键技术面临的安全威胁。 图 5 云原生关键技术威胁全景 路径 1：攻击者通过攻击镜像层，改变云原生应用的不可变基础设施，引导 云原生安全威胁分析与能力建设白皮书 20 受害者使用该镜像创建容器，进而实现入侵容器、宿主机的目的。路径 1 显示 针对镜像层可能存在的攻击手段，包括：镜像投毒攻击、镜像仓库攻击、中间人 攻击、敏感信息泄露攻击和针对镜像不安全配置的攻击。

Request/Connection metrics MOSN(GoLang) • Admin API • Debug log • GoLang runtime 指标 Envoy 和 MOSN 交互层 • MOSN（GoLang） 侧执行时间统计 • 交互异常数统计 • GoLang 程序异常场景下的容灾处理 MoE 方案介绍 — 方案总结 研发 效能 双模 支持 生态 丰富 • 将 现有的 filter 能力 • 同时具备云原生 xDS 、REST API服务元数据管理通道能力 • 复用 Envoy 高效网络通道，如为 Dapr 能力提供底层 gRPC 通道 • 具备硬件加速集成能力 • 内存管理 Zero Copy • MOSN/GoLang 和 Envoy 生态 拉通 • 实现多个社区技术共享，增强 Service Mesh、Dapr 等领域的 生态 性能 较高

环境建议使用。 成本较高，所以要视业务场景要求取舍。 Mesh零信任 mTLS服务间访问授权，主要针对Pod层WorkLod的访问控制 应用透明，全局管理视角，细粒度安全策略 Check&Report机制影响通信性能，并只涉及到服务 通信级别的安全，对node没有防护 Calico零信任 主要针对Node层的访问控制，可以让攻击者难以横向移动，隔离了风险 应用透明，全局管理视角，细粒度安全策略，针 对Node层面构建安全 对Node层面构建安全 采用IpTables，有一定的性能消耗 Cilium零信任 采用eBPF,为Mesh打造具备API感知和安全高效的网络层安全解决方案， 克服了Calico SDN安全和性能方面的不足 应用透明，全局管理视角，细粒度安全策略，针 对Node层面构建安全，端到端安全需要和以上安 全方案集成。 说说应用基本依赖的四大件：数据库、存储、中间件和大数据 下单服务 交易支付 支付网关 锁定库存 • 接入层需要能够根据规则的路由，以及兼容各类协议接 口以及数据模型，并能根据应用的规模来自动拓展。 • 实现HTAP(OLTP+OLAP)，将在线事务|分析混合计算模型 基础上，实现多模数据模型，使得集成成本经一步降低。 • 计算层，与存储彻底剥离开来，实际是微服务化架构， 可以自由伸缩，并自动故障转移，采用读写分离，适应 高负荷的场景。另外也需要进一步将计算和内存分离出 来，使得计算层彻底变为无状态，可以做到灵活的拓展

自动化运维 快速恢复 手工运维 恢复缓慢 云原生应用相比传统应用的优势(例子) 来实现计算资源向应用的无缝融合，以极简稳定的、 自动化的方式向上提供业务价值，并直面交付成本问题 企业管理层 业务架构师或者PM 产品|数据|应用|技术架构师 架构咨询团队 企业自己决定 云原生平台+架构咨询团队 数据平台 DevOps 微服务 PAAS 容器云 运行时以期望与实际的差别进行动态调 整到期望的状态 标准化能力-分布式操作系统核心-容器服务-基本技术原理 事实标准的K8S容器服务设计 成应用与物理资源（IaaS，虚 拟机、物理，多云）的中间抽 象层，因为应用很复杂，很容 易陷入差异化定制市场，抽象 层的市场范围会更广，作为开 源平台，更容易成为通用性市 场选择。通用性才能做到普适 定制化能力，才能成为云原生 的操作系统。 标准化能力-分布式操作系统核心-容器服务-Operator 来启动虚拟化Pod， 此时可以同时在统一的 容器云平台下运行微服 务化容器化或者未容器 化的传统软件了； 另一个方向是，将底层计 算、存储和网络进行超融 合，提供极其简单的底层 运维能力，进一步简化云 原生+资源层整体运维和 提升资源利用质量。 标准化能力-按需调度-Serverless 业务价值 架构 • 彻底消除传统服务端基础设施依赖，降低研发复杂性和运维难度 • 按实际调用量进行自动的容量扩缩 • 专注业务逻辑开发，无须关心基础设施

Apache BookKeeper： 企业级流存储层 分布式⽇志/流存储 • 低延时、⾼吞吐、持久化 • 强⼀致 (repeatable read consistency) • ⾼可⽤ • 单节点可以存储很多⽇志 • I/O隔离 Apache BookKeeper： 诞⽣场景 streamnative.io 企业级流存储层： 节点对等的架构 • openLedger(组内节点数⽬ openLedger(组内节点数⽬, 数据备份数⽬, 等待刷盘节点数⽬） • openLedger(5, 3, 2) streamnative.io 企业级流存储层： 读写⾼可⽤性（容错） streamnative.io 企业级流存储层： 稳定的 IO 质量 ⾼性能、强⼀致性、读写隔离、灵活SLA • Pulsar 的根本不同 • Apache Pulsar 简介 • Pulsar 的云原⽣架构 •

2）引入中间件，研发人员+运维人员=》研发团队 3）引入数据库，研发+运维+DBA=》研发中心、CTO/公司管理层 3、一般场景下，不解决性能问题（特别是延迟）。 分布式数据库使用的约束： 4.数据库网格 4.数据库网格 Service Mesh 是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服 务拓扑，Service Mesh 保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中，

弹性扩缩容 高可用 负载均衡 客户环境 • 关注点分离：开发者关注应用本身，运维人员关注模块化运维 能力，让应用管理变得更轻松、应用交付变得更可控； • 平台无关与高可扩展：应用定义与平台层实现解耦，应用描述 支持任意扩展和跨环境实现； • 模块化应用运维特征：可以自由组合和支持模块化实现的运维 特征描述。 • Components：在 OAM 中，“应用”是由多个概念共同组合而成。第一个概念是： 厂商去实现，譬如： kubevela。 OAM实现原理分析 • OAM是更高级的抽象， 执行面打包都是通用 格式，比如HELM，很 好的兼容了现有的基 础设施，无论怎样的 基础设施，都能在高 层保持一致的情况下， 在差异化的环境下运 行，而让业务研发人 员更加关注业务，而 不是基础设施本身。 • OAM本身就是基础设 施即代码的典范设计， 在中间层隔离了用户 使用和底层执行体， 进一步加强了统一性。