Recommended
More Related Content
Similar to 100页PPT讲清楚云原生.pdf
Similar to 100页PPT讲清楚云原生.pdf (20)
100页PPT讲清楚云原生.pdf
- 6. 总部 机关 内部员工 分支 机构 内部员工 移动 接入 内部员工/合作伙伴 OA CRM HRM …… BPM MES 稳态IT WEB APP 移动用户 采购 平台 互联网 平台 数字 营销 敏态IT 互联网/物联网应用 创新应用 PC用户 物联网 物联终端 互联网、 大数据 AI、 IoT 数字化转型 ü 应用价值提升 ü 应用数量增长 ü 应用类型丰富 ü 应用需求多变 企业从信息化到数字化的转型带来大量的应用需求
- 7. 软件组件 运行环境 部署平台 …… …… 应用丰富及架构演进带来的开发和运维复杂性 本地IDC 虚拟化 超融合 公有云 …… 测试环境 生产环境 复杂的应用软件架构，在开发、测试、运维 团队之间建成了认知的“墙”，团队间配合效率 低，故障排查慢，阻碍了软件价值的流动 无法满足用户对于业务快速研发、 稳定交付的要求
- 8. 场景 1 如果生产中一台Web应用服务器故障，恢复这台服务器需要 做哪些事情？ 场景 2 如果应用负载升高/降低，如何及时、按需扩展/收缩所 用资源？ 场景 3 如果业务系统要升级，如何平滑升级？万一升级失败是 否能够自动回滚？整个过程线上业务持续运行不中断。 传统稳态业务环境难以高效承载敏态应用 发现故障 （假死） 创建 新实例 配置 运行环境 部署当前 应用版本 添加 监控 配置 日志采集 测试确认 服务正常运行 实例 加入集群 恢复正常
- 9. 场景 1 如果生产中一台Web应用服务器故障，恢复这台服务器需要 做哪些事情？ 场景 2 如果应用负载升高/降低，如何及时按需扩展/收缩所用 资源？ 场景 3 如果业务系统要升级，如何平滑升级？万一升级失败是 否能够自动回滚？整个过程线上业务持续运行不中断。 传统稳态业务环境难以高效承载敏态应用 发现故障 （假死） 创建 新实例 配置 运行环境 部署当前 应用版本 添加 监控 配置 日志采集 测试确认 服务正常运行 实例 加入集群 恢复正常 工作量 成本
- 10. 新一代架构（微服务）应用的对承载平台提出新要求 传统实践中，主要采用虚机/物理机+SpringCloud等微服务框架的方式承载微服务应用。但在一个虚机/服务器上 部署多个微服务会产生如下问题—— • 资源预分配，短时间内难以扩展 • 缺乏隔离性，服务相互抢占资源 • 增加环境、网络（端口）和资源管理的复杂性，治理成本高 • 监控粒度难以满足微服务应用运维的需要，线上问题难以排查定位，往往需要研发介入 我们需要一种新型的、为云而生的业务承载平台，去应对上述问题。 微服务应 用 大型 单体 应用 VM/服务器 VM/服务 器 VM/服务 器 VM/服务 器 目 标 ü 支持微服务级别的细粒度资源隔离 ü 支持快速扩缩容 ü 支持热升级，服务更新不影响业务可用性 ü 支持服务的快速地部署、扩展、故障转移 ü 支持更细致、自动化的运维，快速恢复 ü …… 过去 现在 未来 云原生的业务承载平台？
- 12. 什么是云原生->为云而生 • 落地的核心问题：业务微服务的划分和设计(DDD,咨询方案等）、部署困难、维持运行困难、云资源管理与应用 管理视角分离导致复杂性等 • 传统方案:仅仅考虑了一部分变化而引起的不稳定，如通过基于人工规则的服务治理保护链路、如时延体验较差 的部署策略等 • 云原生是告诉我们：能够适应业务变化的微服务+能够适应制品变化的DevOPS+能够适应技术环境变化的技术底 座=云原生平台；其中变化是以研发循环形式不断出现和累加的，如果不进行治理，那么这些变化就会积累，稳 定性的破坏是熵增的，而云原生基础设施就要做到对变化产生的不稳定因素进行熵减处理 • 向上站在企业立场上：是要解决微服务体系快速落地的问题，低成本支撑企业创新以及数字疆域规模扩张 1 技术架构变化：因商业或者演化而 变带来不稳定因素 2 制品变化：代码因商业而变带来新 的功能缺陷 3 配置变化：因环境而变带来的不稳 定性因素 6 外部依赖变化：ERP可用性变化 带来的不稳定因素 5 人员变化：没有知识沉淀导致的 不稳定因素 4 环境变化：因安全、流量、故障、环境崩 溃、底层IT变更而变带来的不稳定因素 非云原生：无法对应变 化=稳定性无法保证 云原生：主动对应变化= 稳定性保证
- 13. 什么是云原生(Cloud Native Computing)->为云而生 只有为云而生的应用才 是云原生应用 2 0 1 9 年 云 原 生 爆 发 成 为 主 攻 方 向 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 e r 这 种 环 境 ， 它 们 一 起 直 接 进 入 云 原 生 领 域 。 M e s o s 、 D o c k e r C o m p o s e 、 K 8 s 等 容 器 编 排 软 件 相 继 出 现 2 0 0 9 年 阿 里 云 飞 天 系 统 诞 生 聚焦于CapEx到OpEx的转变，但是应用依然需要自己解决稳定性问题 企业开始摸索大规模上云的可能性，而同时微服务架构开始出现。 2 0 0 0 年 F r e e B S D 提 出 容 器 ， 而 资 源 隔 离 能 力 早 在 1 9 7 5 年 就 已 经 存 在 2003年Docker兴起，但云原生架构依然没 有出现，Docker公司还差点死了 1 9 9 6 年 戴 尔 提 出 云 计 算 理 念 2006年亚马逊率先推出 了弹性计算云（EC2） 分水岭 云原生 Docker： 抽象云资源，使 得更容易使用 微服务： 加快业务迭代更新 从支持应用不同维度发展，最终走在了一起
- 14. 云原生应用相比传统应用的优势 低成本 高敏捷 高弹性 云原生应用 传统应用 部署可预测性 可预测性 不可预测 抽象性 操作系统抽象 依赖操作系统 弹性能力 弹性调度 资源冗余多 缺乏扩展能力 开发运维模式 DevOps 瀑布式开发 部门孤立 服务架构 微服务解耦架构 单体耦合架构 恢复能力 自动化运维 快速恢复 手工运维 恢复缓慢
- 17. 客户群体与规模 电信 制造 金融 服务业 政府 互联网 350.2亿 云原生采用规模占比与市场总规模 58% 11% 10% 8% 5% 5% 数据来源：中国云原生产业联盟2019 私有云市场规模 645.2亿 投 入 技 术 运 维 纳 管 规 模 9%客户投入占总IT投 入的一半以上 成为主要支出方向 中心集群规模为主 部署形态多元化、多云/混合云架构成为主流 自动化 用户软件发布方 式正在向自动化 转变 容器 60%以上用户已 经在生产环境应 用容器技术 微服务 微服务架构成为 主流，八成用户 已经使用或者计 划使用微服务 Serverless Serverless技术显 著升温，近三成 用户已在生产环 境中应用
- 18. 云原生对业务的支撑实例(数据来源于阿里云) 4982亿，2020年天猫双11再创消费新纪录。58.3万笔/秒，双11交易峰值再创新高，阿里云又一次扛住全球最大规模流量洪峰。这一切背后支撑的 “技术引擎”又是如何为近十亿全球购物者的狂欢提供着“无感知护航”？ 近日，在阿里巴巴双11技术沟通会上，阿里云研究员、阿里云云原生应用平台负责人丁宇表示，今年双11实现了核心系统全面云原生化的重大技 术突破，实现资源效率、研发效率、交付效率的三大提升，万笔交易的资源成本4年下降80%，研发运维效率平均增效10%以上，规模化应用交付效 率提升了100%。阿里巴巴在2020双11完成了全球最大规模的云原生实践。 与2019年全面云化相比，2020年全面云原生化革命性重构了双11“技术引擎”。从产品和技术两方面来看，产品侧，阿里云通过提 供容器服务ACK、云原生数据库PolarDB/Redis、消息队列RocketMQ、企业级分布式应用服务EDAS、微服务引擎MSE、应用监控 服务ARMS等数十款云原生产品全面支撑双11。技术侧，云原生四大核心技术实现规模和创新的双重突破，成为从技术能力向业 务价值成果转变的样本： • 支持全球最大容器集群、全球最大Mesh(ASM)集群，神龙架构和ACK容器的组合，可以实现1小时扩容1百万个容器，混部利用 率提升50%，万笔交易成本4年下降80%。 • 拥有国内最大计算平台、顶级实时计算能力。大数据平台批处理单日计算数据量达到1.7EB，实时计算峰值每秒30亿条记录； 云原生PolarDB读写性能提高50%+，计算资源利用率提高60%+。 • 云原生中间件首次实现自研、商用、开源的“三位一体”，通过阿里云服务全球客户。云原生中间件服务框架峰值调用量超百亿 QPS。 • 核心业务规模实践Serverless，弹性伸缩能力会提升10倍，大幅提升压测支撑效率和稳定性。 • 云原生技术不仅在阿里内部大规模普及，也正通过阿里云服务全社会的双11。大促期间，阿里云原生还支撑了中国邮政、申 通快递、完美日记、世纪联华等客户，稳定高效应对双11大促的流量。以物流行业为例，申通快递将核心系统搬到云上，采 用阿里云容器服务，亿级包裹过境，系统稳如泰山，IT成本还降低了30%；以大型商超为例，世纪联华基于阿里云函数计算(FC) 弹性扩容，业务峰值 QPS超过2019 年双11的230%，研发效率交付提效超过 30%，弹性资源成本减少 40% 以上。
- 20. 生态与竞争格局分析
- 23. 云原生赋能平台
- 24. 标准化能力-分布式操作系统核心-容器服务 向上提供抽象化自愈IT运营视角 高效稳定应用资源供给 价值主张 架构 云原生底座=控制器+调度器的组合+Docker=根据环境的变化而动+基于封装 一致性的大规模分发 服务编排基本原理： • 以度量为基础，以NodeSelector算法来 决定在哪儿部署容器服务 • 运行时以期望与实际的差别进行动态调 整到期望的状态
- 26. 标准化能力-分布式操作系统核心-容器服务-Operator API Server Kubectl Controller Pod,Deployme nt,etc. API Server Kubectl Custom Controller Custom Resource(CR) Operator机制 Pod,Deployme nt,etc Spec (K8s Yaml) Custom Resource Spec (K8S yaml) 通过拓展实现自定义控制器来实现对非标准资源的纳 管，比如数据库的自动拓展能力或者自动化数据同步 能力等等。
- 28. 标准化能力-按需调度-Serverless 业务价值 架构 • 彻底消除传统服务端基础设施依赖，降低研发复杂性和运维难度 • 按实际调用量进行自动的容量扩缩 • 专注业务逻辑开发，无须关心基础设施 • 只需要将视频存入存储，接入极其简单，达到极致业务体验 • 按需加载资源，使用时调度，不使用时自动回收，达到极致 成本的体验。 • 并行执行，可以同时出产不同维度业务结果，达到极致性能 体验。比如上图，同时从不同维度进行业务处理。 • 减少了传统微服务体系中容量规划和服务治理的负担，专注 于业务本身。 • 可以支持大部分业务场景：Web，视频、大数据、AI、运维 场景等等。
- 29. 标准化能力-按需调度-Serverless SSR前端一体化渲染 SSR 顾名思义就是 Server-Side Render, 即服务端渲染。原理很简单，就是服务端直接渲染出 HTML 字符串模板，浏 览器可以直接解析该字符串模版显示页面，因此首屏的内容不再依赖 Javascript 的渲染（CSR - 客户端渲染）。 1. 首屏加载时间：因为是 HTML 直出，浏览器可以直接解析该字符串模版显示页面。 2. SEO 友好：正是因为服务端渲染输出到浏览器的是完备的 html 字符串，使得搜索引擎能抓取到真实的内容，利 于 SEO。但是SSR会占用更多服务器资源，需要更多的渲染时间，高并发场景下可能导致业务堵塞。 结合 Serverless 和 SSR 的特点，我们可以发现他们简直是天作之合。借助 Serverless，前端团队无需关注 SSR 服 务器的部署、运维和扩容，可以极大地减少部署运维成本，更好的聚焦业务开发，提高开发效率。 同时也无需关心 SSR 服务器的性能问题，理论上 Serverless 是可以无限扩容的。
- 30. 标准化能力-工程能效-DevOps-研发平台和应用传送带 • 提高协作效率和质量(关注的不是部署效率、而是协作研发效率) • 减少变更带来的风险:制品一致性、配置一致性、环境一致性 • 打通研发与运维:谁定义谁负责，平台提供业务OPS工具，减少研发和运维视角割裂带来的高成本 • 可以作为研发人员的唯一工作台，将底层技术收敛到统一平台上，减少企业研发管理成本。 运行态 任何微小的变化都可能引发故障，如何避免？ 任何变更都需要提交到git中，并经过版本管理后 重新持续集成，变更有痕迹可查，随时可以找到对 应版本的变更进行回滚。
- 31. 微服务PAAS-应用架构治理-总论 Applications Data Runtime Middleware OS Virtualization Servers Storage NetWorking 传统IT Applications Data Runtime Middleware OS Virtualization Servers Storage NetWorking IaaS Applications Data Runtime Middleware OS Virtualization Servers Storage NetWorking PaaS BpmPaas iPaas MFT Paas Baas Container Service RDS Service Cache|MQ Service Big Data Service aPaas 专业PaaS(2B) 技术Paas(2D) IaaS+ • Paas可以看做是从应用角度管理资源的平台 • Paas可以看做是应用运行态稳定性保障的平台 • Paas可以看做是连接各种服务的啮合中心 以应用为中心的云原生，落地的关键在PaaS，根据 企业面对的市场或情况不同，有可能是单纯的技术 PaaS，或就是专业Paas，或两者兼顾之。技术Paas 应该有拓展能力，可以向不同专业PaaS发展。
- 32. 标准化能力-微服务PAAS-应用架构治理-运行态稳定性管理-1 • 资源的治理，比如扩缩容、自愈等等 • 流量的治理，比如熔断、限流、可观察性、运维等等 • 代码的质量，比如DevOps、CICD等等 以上是完成运行态稳定性管理的三要素，其中代码的质量是交给DevOps的，从以上可以看到Paas要真得能够实现运行态稳定性管理， 就必须集成容器服务底座、服务治理和DevOps才能实现。容器服务底座和DevOps前面也都讲过，这里不在重述。 Token Zuul 网关 Hystrix 熔断限流 Service A Service B Service C Nacos Config 熔断监控 Turbine Zipkin EFK prometheus • 适合大部分客户希望原封不动的低成本迁移上云。 • 大部分周边依赖无法做到平台化，导致管理碎片化严重，并与 微服务框架直接关联，成本较高。 Ingress Service A Service B Service C k8s-ETCD ConfigMap Zipkin EFK prometheus • 适合新项目上云，如果是已经存在的项目就需要修改代码 • 注册中心、配置中心、跟踪链、日志分析、性能分析、流量网 关等都是平台提供的，也需要碎片化适配，并与微服务框架直 接关联，治理能力也必须委托给微服务框架。 有没有可能集成两种部署方式的优势呢，即可以实现透明化迁移同时可以保证标准化能力呢？ 本质而言，我们是需要一个可以托管各类微服务的通用云原生应用架构治理平台
- 33. 标准化能力-微服务PAAS-应用架构治理-运行态稳定性管理-2 Ingress k8s-ETCD ConfigMap Zipkin EFK prometheus • ServiceMesh为容器云打通通信网格(东西南北流量)、补充服务治理能力的同时，也将平台能力与微服务运行 RT环境彻底隔离，平台能力可以做到标准化。 • 无论是原生运行模式还是PaaS运行模式，都能非常好的在一个通用平台上部署，并保留各自的优点和克服了 前面所分析的缺点。 S M 控 制 面 Service A Service B Enovoy Enovoy Token Zuul 网关 Hystrix 熔断限流 Nacos Config 熔断监控 Turbine Zipkin EFK prometheus S M 控 制 面 Service A Service B Enovoy Enovoy k8s-ETCD 商业价值：大幅度降低迁移成本、可以低成本承载多种微服务架构形态 通过ServiceMesh将平台能力彻底从具体微服务体系剥离出去并带来安全、服务治理等能力 形成一个完整的运行态稳定性保障体系，并同时支持各类微服务框架，形成更丰富的应用承载能力 MCP Sync
- 34. ServiceMesh-1 上文提到的ServiceMesh，对新一代云原生PaaS层的构建起到了非常重要的作用 现在 Node A 业务逻辑 熔断器 服务发现 网络堆栈 Node B 业务逻辑 熔断器 服务发现 网络堆栈 Node A 业务逻辑 网络堆栈 Node B 业务逻辑 网络堆栈 熔断器 服务发现 熔断器 服务发现 SideCar SideCar Node A 业务逻辑 网络堆栈 Node B 业务逻辑 网络堆栈 熔断器 服务发现 熔断器 服务发现 SideCar SideCar 统一化Service Mesh’s Control Plane • 通过将服务治理、通信、安全等从微服务框架中以独立进程剥离出来，解决了微服 务治理的碎片化以及基础设施耦合问题。 • 但是Sidecar（数据面）在国际化组织和企业联盟的努力下，也形成了叫做UDPA （Universal Data Plane API）的标准，使得在不同场景下的数据面在API层面达成统 一，比如云端Mesh和边缘Mesh由于API的统一，可以使用统一的控制面(配置下发 管理)来实现统一管理和统一服务化抽象，并向应用角度抽象，降低用户使用成本。 iptable iptable eBPF eBPF
- 35. ServiceMesh-2 上文提到了ServiceMesh的原理，并说它向应用方向抽象为研发简化使用网格的方式，思路就在基础设施即代码上 Spring Cloud • Spring-Cloud-Netfix • Spring-Cloud-Sleuth • Spring-Cloud-Gateway • Spring-Cloud-Bus • Spring-Cloud-Consul • Spring-Cloud-Config • Spring-Cloud-Security • Spring-Cloud-.... Netfilex OSS • eureka • hystrix • turbine • archaius • atlas • Fegin • Ribbon • Zuul 需要多长时间，才 能使得整个团队掌 握和熟练掌握？ 担心的是：业务团 队在技术上不是长 项 依赖于某一种微服 务框架，可能其服 务治理能力不全、 只能绑定在一种语 言进行研发、升级 怎么办？ 1 2 • 第二个困难已经被Mesh技术架构解决了 • 第一个困难就需要为研发用户提供高级抽象-IaC 抽象成虚拟服务和目标规则这两种声明性API(Yaml),使得配置非 常形象易懂，并且彻底将左侧需要了解的细节进行了屏蔽和简化， 只需要学习规则，而不需要了解下面很多种实现，大大降低了使 用者的难度，并实现了版本化能力
- 36. ServiceMesh-3-新发展-多运行时Mesh架构(机甲) Bilgin Ibryam 分析并总结了分布式应用的四大需求 总体而言就是下面这几个方面的事情： • 生命周期（Lifecycle） • 网络（Networking） • 状态（State） • 捆绑（Binding） 每种需求存在的问题和局限性，导致传统解决方案如企业服 务总线（ESB）及其变体（如消息中间件，轻量级的集成框架 等）不再适用。随着微服务的发展，以及容器和 Kubernetes 的普及和广泛使用，云原生开始影响这些需求的实现方式。 未来趋势是通过将所有传统的中间件功能移至其他运行时来 全面发展，最后的目标是在服务中只需编写业务逻辑。 思路大体是：Smart Runtime， Dumb Pipes。 阿里MOSN负责人敖小剑:“业务逻辑在编码开始阶段应该 是“裸奔”的，专注于业务逻辑的实现，而尽量不涉及到底 层实现逻辑；而在运行时，则应该装备“机甲”，全副武装， 大杀四方。熟悉的味道是吧？标准而地道的云原生思想” 但是，可以预见的是它很占用资源，所以这个问题需要得 到很好的解决，它不仅可以让微服务只关注业务逻辑，也 能够形成更标准的PAAS平台基础，而无惧因场景而变的 基础设施碎片化问题。
- 37. ServiceMesh-4-新发展-服务网格编排平台 上文提到了UDPA，它在数据面上进行了统一接口的努力，而控制面抽象并没有标准，目前大家都采用Istio的控制 面，Istio的设计上还是略显复杂，而其他厂商的控制面存在差异，所以控制面也想基于统一的愿望做到简化部署、 更加抽象简化的使用方式迈进。一家叫做Gloo.io的公司开始这方面的尝试! • 帮助用户快速获得服务网格的经验 • 接管服务网格中的关键功能 • 统一了 Ingress 流量（南北向）和网 格流量（东西向）的管理。将 Gateway和服务网格合二为一。 • 为自由组合任何服务网格和 Ingress 打开了大门。 • 使用户可以在不同的服务网格间迁 移。 • 统一的用户体验，是用户可以使用 同样的工具管理不同的网格。 • 不同服务网格之间的粘结剂，让它 们可以自由与其他网格连接在一起。
- 39. ServiceMesh-6-新发展-ServiceMesh与Serverless融合 Service Mesh 技术和 Serverless 技术是工作在不同纬度的两个技术： • Service Mesh 技术的关注点在于服务间通讯，其目标是剥离客户端 SDK，为应 用减负，提供的能力主要包括安全性、路由、策略执行、流量管理等。 • Serverless 技术的关注点在于服务运维，目标是客户无需关注服务运维，提供 服务实例的自动伸缩，以及按照实际使用付费。 理论上 Service Mesh 技术和 Serverless 技术并没有冲突的地方，可以结合使用。 事实上目前业界也开始出现这个趋势，而融合的方式有两种： • 在 Serverless 中引入 Service Mesh：典型如 Knative 项目和 Knative 的 Google Cloud 托管版本 Google Cloud Run，通过引入对容器的支持和使用 Istio， Knative 将 Serverless 的支持扩展到 Function 之外，在极大的扩展 Serverless 适 用范围的前提下，也将服务间通讯的能力引入到 Serverless。 • 在 Service Mesh 中引入 Serverless：典型如 Google Traffic Director 产品，在提 供 Service Mesh 各种能力的同时，支持按照流量自动伸缩服务的实例数量，从 而融入了部分 Serverless 的特性。 对于 Serverless 和 Service Mesh 的结合，我们展望未来形态：应该会出现一种新 型服务模式，Serverless 和 Service Mesh 合二为一。只要将服务部署上来，就自 动可以得到 Service Mesh 的服务间通讯能力和 Serverless 的无服务器运维。
- 40. ServiceMesh-7-新发展-Mesh Broker架构 服务消费者 中心化 Mesh Broker 服务提供 者 连接创建 连接创建 服务注册 • 无端口监听 • 占用资源少 • 无网络要求 • 无底层基础设施依赖：任何PaaS间可以通信 • 无服务注册依赖，无负载均衡需求 • 简化运维：中心化后，只需要管理服务器就可以了 • 业务异步化 缺点： 单点故障，需要提供高可用方案，如Broker部署在K8S中，HPA 控制器可以保证其高可用性，因为它本身无状态。
- 42. 标准化能力-API网关 Web应用 移动应用 第三方应用 Gateway （如K8S的 Ingress） Catalog服务 REST Recom服务 TCP Catalog服务 gRPC Web应用 移动应用 第三方应用 WebApp GateWay Catalog服务 REST Recom服务 TCP Catalog服务 gRPC Mobile GateWay Public GateWay API网关是一个服务器，是整体系统的唯一流量入口。 API网关封装了系统内部细节，为每个客户端提供一个定制的外化API。 还具有其它职责，如身份验证、监控、负载均衡、 缓存、请求分片与管理、静态响应处理、协议转换等，它将公共的非 业务功能能力进行了集成和管理，同时也简化了微服务的研发和部署。 为什么需要API网关 传统网关上容器云(K8S) Gateway 网关Controller K8S Scheduler Gateway Gateway 传统Gateway在云原生高弹性环境下容易变成单点故障区，或者流量 瓶颈点，所以需要根据业务规模进行容量和稳定性治理，那么就需要 通过定制化一套CRD声明管理控制器，控制器根据POD实例情况来通 知k8s调度对齐进行容量和稳定性治理 网关上容器云之后，面临一个隐含的问题，就是K8s或 者其他容器云都具备自己的流量网关，而ServiceMesh 也有自己的网关组件（比如Istio的Istio Gateway Pod）， 对于用户需要维护两个网关，明显是感觉奇怪的，但 是问题往往没有那么简单。 REST TCP gRPC REST 专业型网关 通用型网关
- 43. API网关和ServiceMesh之间的关系 网关访问内部服务，算东西向还是南北向？意思是说网关在调用服务的方向上和ServiceMesh的功能几乎重叠了! GW API GW API 过去两者的关系很清晰，而且由于当时Service Mesh和API Gateway是不同的产品，两者的重合点只是在功能上。而随着时间的推移，当 Service Mesh 产品和 API Gateway 产品开始出现相互渗透时，两者的关系就开始变得暧昧。基于gloo的思路，其实可以得到更一致的整合，但是目前gloo理念还在l 路上，所以需要采用一种简单胶水先把流量入口的配置统一起来。 还有就是，具体落地时发现Istio和K8S Ingress网 关不仅仅是功能重叠，而且产生了对立面的部分： GW Istio GW Service A Service B API API 外部访问哪一个？ 如果仅仅从GW作为唯一路口，由于没有经过Istio GW,那么流 量跟踪是不完整的，在平台上显示的可观察性是缺少数据的。 解决方案 GW Istio GW GW不访问微服务直接转发流量给Istio GW Istio GW Istio Envoy 另一种办法，干脆直接用Istio GW替代 Ingress GW，但是不是所有微服务都需要 Mesh化，所以第一种方案是具备兼容性的。 但是问题就来了，还是会存在两个GW，如何管理？ 这就需要从Istio的方向，在PaaS控制台上逻辑上啮合成统 一的管理接口，底层自动关联和管理一致的配置
- 44. 全生命周期API管理-1 服务是从内研发视角来看的，但是对于外部消费者只想找到并集成API而已，并不想了解API背后的运维细节或者需要协调运维能力！API成了一 种可以交易的商品，可以购买增强自己APP的能力，比如在自己APP里显示天气预报数据，从外部去管理应用平台，形成了一种新PaaS组织方式。 • 逻辑API：已有API的组 合，形成一个新API • 声明API：需要生成代 码框架（任何语言）， 契约驱动研发 • BaaS API:数据库接口、 中间件接口外化成API • API门户：消费者可以 根据领域-能力查询到 想要的API。 • 自动生成SDK方便集成。 • 发行计划：向下兼容， 对比发布 • API文档：每一个API有 一个活档，指导集成。 形成市场，能力 互补
- 45. 全生命周期API管理-2-Azure API Management 配置Http Header， 比如CORS等 配置入站协议转 换等 配置后端治理策略 等，比如限流规则 定义API或者导入 API
- 46. 全生命周期API管理-3-Azure API Management • 把自己关在小黑 屋里面，自己就 可以自助的从API 使用角度定义、 驱动研发、发布 或者实施与自己 APP的集成。 • API作为产品，可 以给订阅、可以 被交易。
- 47. 标准化能力-微服务PAAS-从监控到可观测-研发人员的第五感-1 知道 知道的 不知道 不知道的 主动性 被动性 监控 可观察 健康检查 告警 指标 日志 追踪 问题和根因 预警 监控&稳定性 分析&追踪&排错&探索 • 从稳定性目标出发，首先需要有提示应用出问题的手段 • 当提示出现问题后，就需要有定位问题位置的手段，进 一步要有能够指出问题根因、甚至提前就预警的手段。 拓扑流量图：是不是按预期运行 分布式跟踪:哪些调用 故障或者拖慢了系统 监控与告警： 主动告诉我 问题发生了！ 微服务部署后就像个黑盒子，如何发现问题并在 远端运维是主要的课题，那么就需要从宏观告知 研发人员，并且提供日志、跟踪、问题根因分析 等工具进一步从微观帮助研发人员定位和解决问 题，这是这里在业务上的价值-稳定性赋能。
- 48. 标准化能力-微服务PAAS-从监控到可观测-研发人员的第五感-2 可观察性是云原生特别关注的运维支撑能力，因为它的主动性，正符合云原生对碎片变化的稳定性保障的思想 数据的全面采集 数据的关联分析 统一监控视图与展现 Metric 是指在多个连 续的时间周期 内用于度量的 KPI数值 Tracing 通过TraceId来 标识记录并还 原发生一次分 布式调用的完 整过程和细节 Logging 通过日志记录 执行过程、代 码调试、错误 异常微观信息 数据之间存在很多关联，通过 关联性数据分析可获得故障的 快速界定与定位，辅助人的决 策就会更加精确 根据运维场景和关注点的不同，以不同图表或者曲 线图来表示整体分布式应用的各维度情况，使得开 发人员可以清晰的观测到整体分布式应用的详细运 行情况，为高精度运维提供可视化支撑 人工发展阶段：符合人分析问题的习惯 宏观->微观 精细化发展阶段：依靠数据赋能，加强可视化能力，进一步简化运维 监控告警 分布式跟踪链 日志查询 根因分析 响应动作 自动化 高端观察性 各维度统计分析 观察性 Prometheus Skywalking EFK Hadoop Spark Cortex .......
- 49. 传统交付方式的不足之处 手册文档 配置参数 应用 应用 配置参数 应用 应用 软件环境 硬件环境 遗留系统 安装配置点 安装配置点 安装配置点 集成点 集成点 集成点 1. 交付人员学习手册文档，需要在客户 环境做“安装配置”和“与遗留系统集成” 两方面工作。 2. 安装配置：在硬件上安装软件，不乏 针对硬件特性的适配、还需要安装OS 等，最后还要在OS上安装应用，并且 还要保证应用软件依赖拓扑结构不会 出错。 3. 集成点：包括新环境的硬件、软件和 应用与遗留系统的集成，比如，监控、 服务注册中心、文件传输、消息集成、 ITSM等系统的部署集成。 4. 由于上层所依赖的底层环境在不同交 付环境中是不同的，而传统交付方式 缺乏脚本能“理解”的方式来表达这些 差异，此外由于事后更新OS、三方库 或者系统，这些变更又缺乏校验关系， 升级时很难给予企业信心，这种交付 方式很难被自动化。
- 50. 标准化能力-微服务PAAS-OAM-万花筒PAAS-1-引子 客户环境交付 制品 • 云应用交付最难的还不是RT的 碎片化，最难的是环境依赖的 碎片化，比如，硬件环境、网 络环境、运维规范等的碎片化。 尤其是运维方面的差异化，必 然导致私有Paas的出现！ • 虽然服务网格、虚拟化等正在 努力解决交付困难的问题，但 是依然对除RT外的环境依赖碎 片化无能为力。 • 背后的原因在于特定环境依赖或者运维规范问题渗透到了PaaS本身， 或者大家常说的定制化场景，如果不进行解耦就会有长期存在的矛盾。 • 为了应付定制化，客户需要等待平台研发的排期，因为平台研发需要定制 化处理定制化场景下的软件、运维工具或者规范等等，并需要不断的测试。 • 为了应付各类的环境的问题，势必要求交付人员的能力非常强，也是成本 居高不下的原因之一。 在K8s这种环境中，存在两种定制化的手段：其一是Deployment API，但是它 却把研发和运维的描述放在了一起；其二是Operator（CRD），我们不得不为 不同客户开发很多不同特质的Operator，交付成本依然很高。 研发人员一般对于运维是没有太多 强经验的，而Deployment这种设 计使得维护一个客户交付更加困难。 即使让运维人员定制规则，也无法 让运行态和运维指标达成一致的效 果。 定制Operator这种解决方案，看似 比较合理,但是强烈依赖于K8S这种 容器调度系统，无法做到通用化， 所以客户必须要求先做针对K8S的 应用改造。 K8S没有应用概念，用户面对的是Workload和Pod这样的概念，以及对应的运维概念（比如 HPA),在层次上是靠近对资源的抽象治理层面，对于业务研发人员而言是不友好的。应用 =Workload+运维特性+.......多种东西的集成，也无法在应用级别上进行管理。 ISV研发团队
- 51. 标准化能力-微服务PAAS-OAM-万花筒PAAS-2 阿里和微软在19年发布了一个叫做OAM的规范，这是基于10年云原生道路锤炼得到的自动化交付方案 构建镜像 多区域分发 配置 ApplicationConfiguration Component 微服务 数据库 MQ Cache Trait 灰度 监控告警 弹性扩缩容 高可用 负载均衡 客户环境 • 关注点分离：开发者关注应用本身，运维人员关注模块化运维 能力，让应用管理变得更轻松、应用交付变得更可控； • 平台无关与高可扩展：应用定义与平台层实现解耦，应用描述 支持任意扩展和跨环境实现； • 模块化应用运维特征：可以自由组合和支持模块化实现的运维 特征描述。 • Components：在 OAM 中，“应用”是由多个概念共同组合而成。第一个概念是： 应用组件（Components），它是整个应用的重要组成部分。应用组件既可以包 括应用运行所依赖的服务：比如 MySQL 数据库，也包括应用服务本身：比如拥 有多个副本的 PHP 服务器。开发者可以把他们写的代码“打包”成一个应用组件。 • Trait描述了应用在具体部署环境中的运维特征，比如应用的水平扩展的策略和 Ingress 规则，它们在不同的部署环境里却往往有着截然不同的实现方式。 举一 个例子，同样是 Ingress，它在公有云上和本地数据中心的实现完全不同：前者 一般是 SLB 这样的云服务，而后者则可能是一个专门的硬件。这也就意味着针 对两个环境的 Ingress 运维工作，将会有天壤之别。 但与此同时，无论是在哪 个环境里，这个 Ingress 规则对于应用开发人员来说，可能是完全相同的。Trait 的目标就是要达成无论在何种环境，规则都是相同的效果。 • AppConfig:运维人员将Commpoent和Trait打包成可交付的应用。 基于镜像的封装性，通过AppConfig将应 用两个维度的东西整合整体化“集群镜像” 方式的交付，底层差异影响减少到最小
- 52. 标准化能力-微服务PAAS-OAM-万花筒PAAS-3 以上解耦的结果，隐含着更深层次的能力，不是简单解耦那么简单，它使得统一通用PaaS成为可能 组件市场|仓库 平台运维特性 应用编排 运维特性编排 版本化 应用 • 两端解耦之后，两端方面都可以形成一个没有 私有PaaS特征依赖的市场，而强大的开源社区 比平台提供商自己还要强大，利用容器底座的 承载能力和OAM抽象化编排能力，可以不等 排期的构建各种特征的Paas。业务应用由于不 依赖于运维特性，也实现了标准化，也可以加 入组件市场，此时开放PaaS+开放应用市场可 以构建对应各种环境的应用了。 • 云原生蓬勃而多样的生态成了这种Paas的基础。 • 编排不在以服务为单位，而是以应用为单位， 再也不会出现由于理解不一致导致的交付失败 的情况，而不论底层容器云实现如何，应用的 交付的方式都是一致的。 DevOps是一种文化，是一种组织赋能，在无所不在，OAM除了在交付过程中提供了基于应用 的交付方案，同时将CICD与底层实现解耦，可以插接无限制的工具组件，使得可以对应不同交 付场景所要求的不同工具链。比如叠加serverless能力加快镜像构建速度、叠加安全左移能力等 等。OAM使得整体PAAS在通用化的情况下，向多种客户环境交付赋能。
- 56. 标准化能力-微服务PAAS-OAM交付流程模式-场景流程 • 由于互联网迭代相对于其 他企业业务更新迭代更加 频繁，引发的变更循环会 积累更多的破坏稳定性的 因素。 • 分成开发、测试（或者还 需要增加预发）、生产等 环境，要将一个变更后的 制品通过些环境的层层验 证，才能进行交付 • 由于比如电商更多关心的 是自己的业务，所以更多 购买了不同厂家的云计算 平台，以便减少费用和投 入，所以云原生平台本身 就能够纳管多云环境，由 于OAM的存在向上统一化 了抽象的规则，对下隔离 了多云的差异，可以很好 的满足企业的需求
- 59. 标准化能力-微服务PAAS-OAM交付流程模式-场景流程 • 大型企业一般会有软件外 部部门或者外包合作厂家， 算是一种合作研发方式。 • 大型企业具备很多分支机 构或者自建数据中心 • OAM整体交付能够很好的 适应这些环境的差异，实 现了自动化部署。
- 60. 标准化能力-让管理和运维更轻松-基础设施即代码-1 Applications Data Runtime Middleware OS Virtualization Servers Storage NetWorking PaaS 云原生PaaS建立在更深 层次的软硬件栈中，而 云原生从某种角度而言 是对OS以及以上资源的 抽象！ 所以问题出现了 • OS、虚拟机、物理服务器、存储设备、网络设备是组成云 原生运行的物质条件，但是它们的安装、运维由谁负责？ 随着微服务和云原生平台结合起来后，OS以 及物理服务器本身的数量和种类也爆发性增加，如果沿用传 统方式管理，压力会很大 • 配置漂移：服务器的配置可能会随着时间增加。比如有人为 了解决一个特定用户的问题，修改了其中一台服务器的配置， 这样他们之间就存在了差异。 很有可能会发生，只有在某 个环境里面的台服务器上，应用才能正常运行的情况。 • 雪花服务器：雪花服务器的意思是该服务器和你的网络中任 意其它的服务器都不同，特殊到无法复制。比如，在别的服 务器上升级ruby语言后，应用可以运行，但是在某台机器上 就是不可以。 • 脆弱的底层基础设施：总有一些服务器，在你on-call的时候， 你需要对着它们拜一拜，祈祷它们不要出问题。 • 自动化恐惧症：缺乏对自动化的信心因为我的服务器配置不 是一致的。我的服务器不一致是因为我没有频繁和一致的运 行自动化。 • 侵蚀：侵蚀就是问题随着时间的推移蔓延到正在运行的系统 的意思。比如，服务器磁盘被日志文件塞满，操作系统升级， 内核补丁，以及基础设施软件（如Apache，MySQL，SSH， OpenSSL）升级去修复安全漏洞等。 问一个具体的问题：在成 千个服务器上的K8S自己 的安装和维护升级谁来负 责？
- 61. 标准化能力-让管理和运维更轻松-基础设施即代码-2 云原生平台在抽象化OS的同时，却对更底层基础设施的运维无能为力，因为它完全面向应用，甚至连自己如何 被安装、运维都无能为力！就像是从房子里面去搭建一个整体房子一样困难。 事实是这正是传 统运维工作的领 域，但是我们需 要提升抽象程度 来简化传统运维 传统的基础设施管理方法是人工的手动处理模式，不仅仅效率低下，而且还有很 多人为操作的风险，比如误操作。同时，对基础设施的配置更改需要文档记录， 如果没有做好配置更改记录，可能带来另外一些重复性操作的风险。另外，随着 虚拟化和云平台的引入，企业的基础设施变得很复杂，也引入了很多工具和平台， 虽然能在基础设施的提供和管理上增加部分效率，但是对于环境的一致性保证以 及在数分钟内实现特定场景下基础设施就绪是很难实现的。因此需要一种全新的 管理方法，而IaC借助了软件开发中的代码管理经验，通过代码描述基础设施的配 置及变更，再执行代码完成配置和变更。 K8S OS DB F5 路由器 防火墙 .... Ansible Salt Chef Pupet 实际上云原生平台自己也采用了IaC来管理应用， 比如K8S的Yaml，这种方式有利于隔离实现细节。 ITIL 需要具体学习不同软 硬件的知识才能管理 只需要写IaC声明性代码来管 理基础设施 实施
- 64. 标准化能力-承载无忧-E2E云原生纵深安全保障-2-商业价值 由于市场经济、政治环境、自然环境（比如新冠疫情）对数字经济运行带来了很多深刻的影响和变化，比如企业协作更加紧密，导致数据传输安全成 为重要课题、由于国家安全考虑等相关法律法规强制个人或者企业必须遵从安全规范从何直接影响到IT架构、由于新冠疫情，商业活动方式也发生了改 变，比如云广交会，另外80%企业已经上云，产生了大量的业务数据，综合而言安全问题成为一个经济稳定运行的大问题， 腾讯安全战略研究部联合腾讯安全联合实验室近日共同发布《产业互联网安全十大趋势(2021)》(下简称《趋势》)，基于2020年的产业实践和行业风向， 从政策法规、安全技术、安全理念、安全生态、安全思维等维度为产业互联网的安全建设提供前瞻性的参考和指引，助力夯实产业互联网的安全底座。 《趋势》认为，2021年将进一步完善个人信息保护体系，企业对个人信息利用规范化，数字安全合规管理将成为企业的必备能力。与此同时，企业还 应将安全作为“一把手工程”，在部署数字化转型的同时，推进安全前置。 前沿的数字化技术也让产业安全有了更多内涵。5G、AI、隐私计算等技术在构筑数字大楼的同时，不仅带来了全新的安全场景，也成为网络安全攻防 当中的利器;2020年井喷的远程办公，拷问传统安全边界防线，让“零信任”这一有着十年历史的理念再次受到关注，成为企业构建后疫情时代安全体系 的基石;云上原生的安全能力让成本、效率、安全可以兼得，上云正在成为企业解决数字化转型后顾之忧的最优解…… 安全是为了预防资产损失，所以当安全投入 的成本大于能够避免的资产损失价值时，变 得毫无意义！ 而传统安全开发周期管理由于角色分离、流 程思路老旧、不关注运维安全等问题严重拖 慢了DevOps的效率！ 所以急需一种新型的基于云原生理念的安全 角色、流程以及技术的方案！ 传 统 安 全 工 作 传 统 由 独 立 安 全 工 程 师 负 责 ， 与 开 发 人 员 沟 通 安 全 问 题 ， 产 生 大 量 沟 通 成 本 传 统 安 全 检 查 编 码 和 测 试 之 后 ， 安 全 工 程 师 才 介 入 ， 如 果 发 现 问 题 ， 又 需 要 研 发 修 复 和 重 新 测 试 ， 严 重 影 响 效 率 传 统 安 全 流 程 强 调 上 线 前 解 决 一 切 问 题 ， 某 一 环 节 堵 塞 影 响 全 局 D e v O p s 效 率 。 依 赖 于 人 员 个 人 经 验 来 先 验 的 进 行 实 施 ， 而 很 多 入 侵 风 险 是 不 可 预 知 的 ！
- 65. 标准化能力-承载无忧-E2E云原生纵深安全保障-3-与传统安全方案的差异 • DevOps的实施，使得Dev和Ops界限被彻底打破，开发人员要全 覆盖的负责所有事宜，并要负责项目的进程。这意味着安全责任 将成为团队每个人的责任。 • 流程变化为安全左移、安全右移、默认安全、安全编排自动化和 响应。 • 技术，关键在于构建自动化的安全检查以及防御工具链，而工具 的自动化程度、误报率、漏报率都影响着整体流程的效率和可行 性。 安全问题左移一个研发阶段，修复成本就将 提升十倍，所以将安全自动化检查和问题发 现从运行态左移到研发态，将大大提高效率 和降低成本 默认安全策略，可以天然的规避大部分 安全问题，使得人员配置和沟通工作大 量减少，提高了整体效率! 安全右移是为了恰到好处的安全，一些非严 重安全问题，没有必要堵塞主研发流程，可 以交于线上安全防御系统。提高了整体实施 效率！ 安全编排自动化和响应作为连接各个环 节的桥梁，安全管理人员或者部分由 AIOps组件可以从全局视角观察，动态 调整策略，解决新问题并及时隔离或者 解决！ DevSecOps
- 66. 标准化能力-承载无忧-E2E云原生纵深安全保障-4-技术建议方案 技术 说明 优点 缺点 SAST(静态应用程序 安全测试) 百盒测试，通过污点跟踪对源代码或者二进制程序（也包括Docker镜像 等）进行静态扫描，尽可能前置，在IDE编写代码或者提交代码时进行， 将极大优化整体效率和成本 可以无视环境随时可以进行，覆盖漏洞类型全面， 可以精确定位到代码段 路径爆炸问题，并一定与实际相符合，误报率较 高。 DAST(动态安全应用 程序安全测试) 黑盒测试，通过模拟业务流量发起请求，进行模糊测试，比如故障注入 或者混沌测试 语言无关性，很高的精确度。 难以覆盖复杂的交互场景，测试过程对业务造成 较大的干扰，会产生大量的报错和脏数据，所以 建议在业务低峰时进行。 IAST(交互式应用程序 安全测试) 结合了上面两种的优点并克服其缺点，将SAST和DAST相结合，通过插桩 等手段在运行时进行污点跟踪，进而精准的发现问题。是DevSecOps的 一种推荐方式。 如果在被动模式下运行IAST，那么开发测试过程 中就可以完成安全扫描，不会像DAST一样导致业 务报警进而干扰测试，同时由于污点跟踪测试模 式，IAST可以像SAST一样精准的发现问题点 SCA（软件成分分析） 有大量的重复组件或者三方库的依赖，导致安全漏洞被传递或者扩散， SCA就是解决此类问题的办法，通过自动化分析组件版本并与漏洞库相比 较，快速发现问题组件，借助积累的供应链资产，可以在快速定位的同 时，推动业务快速修复。 安全左移的一种，在上线前发现依赖组件的安全 问题，快速借助供应链资产库，帮助业务修复问 题。 需要进行大量的安全特征以及资产库的建设或者 三方集成。（涉及业务能力） RASP(运行时安全应 用程序自我保护) 可以看做是IAST的兄弟，RASP通过程序上下文和敏感函数检查行为方式 来阻止攻击，属于一种主动的态势感知和风险隔离技术手段 可以自动化的对非预计风险进行识别和风险隔离 对系统性能有一定影响 可信计算 核心目标是保证系统和应用的完整性，从而保证系统按照设计预期所规 定的安全状态。尤其是像边缘计算BOX这种安全防护，根据唯一Hash值 验证，可以实现极为简单的边云接入操作，运行态并不会影响性能。 可信根一般是一个硬件，比如CPU或者TPM，将 从它开始构建系统所有组件启动的可信启动链， 比如UEFI、loader、OS、应用等，可以确保在被 入侵修改时的阻断行为，另外可以将可信启动链 的Hash值上传云端管理，可以做到中心管控验证 的目的。 加密技术 数据的安全生命周期返程三种不同状态：存储中、传输中、使用中，但 是对第三种场景，一直以来缺少保护手段。通过加密技术建立的可信运 行环境TEE（比如IntelSGX，蚂蚁的KubeTEE等）可以保护运行中的数据 和代码，完成了安全闭环。 依赖于硬件和更高阶密码学，可以彻底阻断物理 设备以及软件的攻击，是高级的安全保障技术。 TEE是运行态主动防护的高级手段，对高安全生产 环境建议使用。 成本较高，所以要视业务场景要求取舍。 Mesh零信任 mTLS服务间访问授权，主要针对Pod层WorkLod的访问控制 应用透明，全局管理视角，细粒度安全策略 Check&Report机制影响通信性能，并只涉及到服 务通信级别的安全，对node没有防护 Calico零信任 主要针对Node层的访问控制，可以让攻击者难以横向移动，隔离了风险 应用透明，全局管理视角，细粒度安全策略，针 对Node层面构建安全 采用IpTables，有一定的性能消耗 Cilium零信任 采用eBPF,为Mesh打造具备API感知和安全高效的网络层安全解决方案， 克服了Calico SDN安全和性能方面的不足 应用透明，全局管理视角，细粒度安全策略，针 对Node层面构建安全，端到端安全需要和以上安 全方案集成。
- 67. 说说应用基本依赖的四大件：数据库、存储、中间件和大数据 下单服务 交易支付 支付网关 锁定库存 库存数据库 前台类目 商品查询 BFF 商品数据库 文件存储 logging MQ 交易数据库 大数据 营销分析 业务赋能 典型微服务应用 云原生应用 下单服务 交易支付 支付网关 锁定库存 库存数据库 前台类目 商品查询 BFF 商品数据库 文件存储 logging MQ 交易数据库 大数据 营销分析 云原生PaaS平台 • 四大件在云原生场景下带来什么客户 价值？ • 四大件在云原生场景下技术架构有什 么创新？ 业务异步化|削峰填谷
- 68. 高级能力-云原生数据库-应用的基石-1-价值和差别 先从一个广告词来看看云原生数据库和一般数据库的差别 项目 传统数据库 Oracle 云原生 Hbase 存储架构 存算一体: 调整困难、只能满 足一定的吞吐量要 求 存算分离: 自动调整、拓展能 力强，满足更大吞 吐量 存储自动扩缩容 手工填加机器， 手工同步 完全自动化 高性能 存在性能瓶颈 类似日志方式的顺 序写，性能高 易用程度 封闭体系，集成各 类优秀能力较差 集成能力强，多模 态接口，兼容各类 协议 可用性、稳定性 需要强大的旁路运 维能力 简化运维、自动化 容量和故障转移 云原生数据库其特点，使得应用场 景会更加广泛
- 69. 高级能力-云原生数据库-应用的基石-2-技术架构 Application Application Application Read Read Write DB Server User Space File system Data Router&Cache DB Server User Space File system Data Router&Cache DB Server User Space File system Data Router&Cache RDMA Read Only Read Only R/W Parallel-Raft Protocol&Storage Serverless Data Chunk Data Chunk Data Chunk • 云原生的本质在于为云这种弹性资源下能够为应用提供 稳定的基础架构，所以云原生数据库相对于传统数据库 最大的不同也在这个方面：弹性 • 对于数据存储的高性能、高稳定性、高拓展、资源成本 等等都需要同时满足（和传统CAP相悖） • 接入层需要能够根据规则的路由，以及兼容各类协议接 口以及数据模型，并能根据应用的规模来自动拓展。 • 实现HTAP(OLTP+OLAP)，将在线事务|分析混合计算模型 基础上，实现多模数据模型，使得集成成本经一步降低。 • 计算层，与存储彻底剥离开来，实际是微服务化架构， 可以自由伸缩，并自动故障转移，采用读写分离，适应 高负荷的场景。另外也需要进一步将计算和内存分离出 来，使得计算层彻底变为无状态，可以做到灵活的拓展 能力和故障恢复能力。这样在计算层也实现了Serverless 模式。 • 通过RDMA，绕过CPU，直接和远端内存通信，在计算 与存储分离、计算与内存分离架构上，提升网络利用率 和性能，也能得到传统数据库网络和性能上一样的体验。 • 底层Data Chunk，采用去中心存储，单体失败不影响数 据的完整性，并且自动自愈(Serverless)。 • 通过跨域数据同步能力，实现多地域数据多活。 这个例子，也给数据库云原生化上的技术架构演进提 供了一个范本，并不是原封不动的迁移就变成云原生
- 71. 高级能力-云原生数据库-应用的基石-4-端到端安全 DB计算层 分布式共享 存储 分布式 内存 DB计算层 分布式共享 存储 分布式 内存 TDE透明加密 SSL • 在SSL和TDE保护下，好像数据在传输和存储过程中得到了保护，但是TDE 是存储时加密、计算层读取时解密，否则计算层无法进行计算。 • 计算层获得的数据依然是明文，非法用户依然可以通过dump手段获得数 据或者篡改数据。如果计算层获得的数据也加密，计算层将无法进行计算。 所以云原生数据的安全是要实现“可用但不可见”的能力。 • 可信执行环境（TEE)采用Intel SGX技术实现的密文数据上的计算操作， TEE中的内存是受保护的，用户查询语句在客户端应用加密后发送给云数 据库，云数据库执行检索操作时进入TEE环境，拿到的结果是密文状态， 然后返回给客户端，数据面从传输、计算到存储全链条都是处于加密的， 只有可信执行环境内才进行明文计算。 • SSL+TDE+TEE=E2E云原生数据库安全方案。 RDMA
- 72. 高级能力-云原生数据库-应用的基石-5-应用迁移 IDC 应用 A B C Oracle|MySQL 用于 Oracle|MySQL的 JDBC Cloud 应用 A B C 多模云原生数据 库 用于云原生DB的 JDBC 极少量 改动 修改驱 动包 数据迁 移 • 由于云原生数据库支持多模，所以通过 ETL或者DTC等工具迁移数据是非常方便的 • 应用程序只需要修改JDBC的依赖即可以在 新环境中运行，迁移成本低。 • 或者由于云原生数据库支持多协议能力， 比如原生APP使用MYSQL协议访问传统数 据库，可以不加修改的，还是使用老的 MYSQL协议驱动，依然可以和云原生数据 库进行连接。
- 73. 高级能力-云原生存储-应用的基石-1-云原生化需求（从应用角度） 我们从云原生数据库那里基本可以嗅出云原生对四大件的诉求性质了，所以这里我直接给出对云原生存储的要求 1. 敏捷化需求 • 云原生应用场景对服务的敏捷度、灵活性要求非常高，很多场景期望容器的快速启动、灵活的调度，这样即需要存储卷也能敏捷的根据 Pod 的变化而调整。 需求表现在： • 云盘挂载、卸载效率提高：可以灵活的将块设备在不同节点进行快速的挂载切换； • 存储设备问题自愈能力增强：提供存储服务的问题自动修复能力，减少人为干预； • 提供更加灵活的卷大小配置能力。 2. 监控能力需求 • 多数存储服务在底层文件系统级别已经提供了监控能力，然后从云原生数据卷角度的监控能力仍需要加强，目前提供的PV监控数据维度较 少、监控力度较低； 具体需求： • 提供更细力度（目录）的监控能力； • 提供更多维度的监控指标：读写时延、读写频率、IO 分布等指标； 3. 性能要求 • 在大数据计算场景同时大量应用访问存储的需求很高，这样对存储服务带来的性能需求成为应用运行效率的关键瓶颈 具体需求： • 底层存储服务提供更加优异的存储性能服务，优化 CPFS、GPFS 等高性能存储服务满足业务需求； • 容器编排层面：优化存储调度能力，实现存储就近访问、数据分散存储等方式降低单个存储卷的访问压力。 4. 共享存储的隔离性 • 共享存储提供了多个 Pod 共享数据的能力，方便了不同应用对数据的统一管理、访问，但在多租的场景中，不同租户对存储的隔离性需求 成为一个需要解决的问题。 具体需求 • 底层存储提供目录间的强隔离能力，让共享文件系统的不同租户之间实现文件系统级别的隔离效果。 • 容器编排层实现基于名词空间、PSP 策略的编排隔离能力，保证不同租户从应用部署侧即无法访问其他租户的存储卷服务。
- 74. 高级能力-云原生存储-应用的基石-2-技术架构 Rook是一个集成了Ceph、Minio等分布式 存储系统的云原生存储方案，意图实现一 键式部署、管理方案，且和容器服务生态 深度融合，提供适配云原生应用的各种能 力。从实现上，可以认为 Rook 是一个提 供了 Ceph 集群管理能力的 Operator。其 使用 CRD 方式来对 Ceph、Minio 等存储 资源进行部署和管理。 Ceph文件存储 MiniO对象存储 • Operator：实现自动启动存储集群，并监控存储守护进程，并确保存 储集群的健康； • Agent：在每个存储节点上运行，并部署一个 CSI / FlexVolume 插件， 和 Kubernetes 的存储卷控制框架进行集成。Agent 处理所有的存储操 作，例如挂载存储设备、加载存储卷以及格式化文件系统等； • Discovers：检测挂接到存储节点上的存储设备。 Rook 将 Ceph 存储服务作为 Kubernetes 的一个服务进行部署，MON、OSD、MGR 守护进程会以 pod 的形式在 Kubernetes 进行部署，而 rook 核心组件对 ceph 集群 进行运维管理操作。 Rook 通过 ceph 可以对外提供完备的存储 能力，支持对象、块、文件存储服务，让 你通过一套系统实现对多种存储服务的需 求。同时 rook 默认部署云原生存储接口的 实现，通过 CSI / Flexvolume 驱动将应用 服务与底层存储进行衔接，其设计之初即 为 Kubernetes 生态所服务，对容器化应用 的适配非常友好。
- 75. 高级能力-云原生中间件-应用的基石-MQ为例 云原生消息服务是云原生的通信基础设施 消息中间件在云原生的应用场景，主要是为微服务和EDA架构提供核心的解耦、异步和削峰的能力，在云原生体系 架构中消息服务还发挥着数据通道、事件驱动、集成与被集成等重要作用。云原生倡导面向性能设计，基于消息队 列的异步调用能够显著降低前端业务的响应时间，提高吞吐量；基于消息队列还能实现削峰填谷，把慢服务分离到 后置链路，提升整个业务链路的性能。 高SLA 云原生应用将对消息这种云原生BaaS服务有更高的SLA要求，应用将假设其依赖的云原生服务具备跟云一样的可用性，从而不需要去建设备份链 路来提高应用的可用性，降低架构的复杂度。只有做到与云一样的可用性，云在服务就在，才能称为真正的云原生服务。 低成本 （Serverless化） 在过去，每家公司自建消息中间件集群，或是自研的、或是开源的，需要投入巨大的研发、运维成本。云原生时代的消息服务借助Serverless等 弹性技术，无需预先Book服务器资源，无需容量规划，采取按量付费这种更经济的模式将大幅度降低成本。 易用性 （Mesh化） 在云原生时代，消息服务第一步将进化成为一种所见即所得、开箱即用的服务，易用性极大的提高。接下来，消息服务将以网格的形式触达更复 杂的部署环境，小到IoT设备，大到自建IDC，都能以跟公有云同样易用的方式接入消息服务，且能轻易地满足云边端一体化、跨IDC、跨云等互 通需求，真正成为应用层的通信基础设施。 多样性 云原生消息服务将致力于建设大而全的消息生态，来涵盖丰富的业务场景，提供各式各样的解决方案，从而满足不同用户的多样性需求。云原生 消息队列要求建设多个子产品线来支撑丰富的业务需求，比如消息队列RocketMQ，Kafka，微消息队列等。 标准化 容器镜像这项云原生的核心技术轻易地实现了不可变基础设施，不可变的镜像消除了IaaS层的差异，让云原生应用可以在不同的云厂商之间随意 迁移。但实际上，很多云服务提供的接入形式并不是标准的，所以依赖这些非标准化云服务的应用形成了事实上的厂商锁定，这些应用在运行时 是无法完成真正的按需迁移，所以只能称为某朵云上的原生应用，无法称为真正的云原生应用。因此，消息服务需要做到标准化，消除用户关于 厂商锁定的担忧，云原生消息队列必须采纳很多社区标准，支持了多种开源的API协议，同时也在打造自己标准化接口。 总结一下，传统的消息队列将从高SLA、低成本、易用性、多样性和标准化几个方向持续进化为云原生的消息服务。 具体要求
- 76. 高级能力-云原生中间件-应用的基石-MQ为例-2-Serverless化 Serverless最核心的理念是“按需”，云原生消息Serverless化主要是从两个维度落地按需的概念。一方面根据业务规 模自动化扩缩容实例规格、队列数等逻辑资源；另一方面，根据服务端负载自动化扩缩容计算、存储等物理资源。 2W TPS 10W TPS 根据业务流量自动升降配 .... 逻辑资源按需扩缩容 MQ集群 MQ集群 根据Load等Metrics做 出扩容决策 PV1 Broker1 PV2 Broker2 PV3 Broker3 PV4 Broker4 MQ集群 根据Load等 Metrics做出 扩容决策 PV1 PV3 Broker1 PV2 PV4 Broker2 漂移 物理资源按需扩缩容
- 77. 高级能力-云原生中间件-应用的基石-MQ为例-2-Mesh化 中间件和服务以及其他组件一道组成一个完整应用，就像前面说的电商场景，如果服务云原生化了，中间件就成了 短板，这就是云原生领域一个著名的推断：云原生化能力是否落地往往主要影响要素在最短板的那一个-水桶效应。 MCP Server NameServer Citadel Mixer Pliot Galley Injector MQ Broker Envoy MQ Broker Envoy MQ Broker Envoy 注册 Service Service Service Pub sub Pub sub Pub sub xDS Config • MQ Broker把Envoy作为 它与服务之间的代理 • Envoy拓展兼容了 PubSub通信的协议，比 如RocketMQ的通信协 议 • Service的代码依然使用 MQ的SDK与其他服务进 行通信 • 由于Envoy把MQ当做服 务一样接管流量，所以 也可以对它进行监控、 做服务发现、负载均衡 以及流量治理（比如灰 度部署） 云原生消息Mesh化 将消息的富客户端 能力下沉到SideCar， 将消息的服务发现、 负载均衡、流量监 控等职责与业务逻 辑隔离，在运行时 完成透明装配，同 时提供细粒度的消 息灰度和治理能力
- 78. 高级能力-云原生大数据|AI-业务赋能的基石-1 数据才是企业的真实资产，而应用就是手段( )，然后经历 的阶段，为业务提供营销证据或者策略的支持( )，但是云原生环境下，大数据平台应该如何改造才能满足这样的云原生化业务实现上的需要？ 大数据发展了近30年，甚至比云计算的历史还要 早，它带有那个时代的架构思路，体系庞大而且 复杂，因为业务上极其重要的地位，发出现先发 的优势，但是带来了后发的劣势: • 大数据平台为业务的营销、决策等活动进行 数字化支撑，这是新时代数字化的核心平台， 唯有数据才是企业的资产。 • 大数据平台大体分成两层：数据应用和数据 工程化引擎 • 在云原生场景下，希望应用能够适应敏态化 的业务场景，数据应用也不例外，目前都在 进行服务化改造和云原生改造 • 大数据引擎早就上云了(IaaS),但是并未云原生 化。 • 但是大数据引擎平台，架构思路过时、组件 众多、体系完整等，以及组织认知和能力、 在线业务的依赖等等，大量的历史包袱导致 大数据平台在云原生环境下落地艰难。那么 如何实现大数据云原生化呢？立足满足现在 和未来的企业需求进行渐进式改造推进是比 较合理的方式。(阿里巴巴甚至根据新时代的 诉求，把原先的大数据平台JStorm都给舍弃 掉，全面奔向MaxCompute云原生体系)
- 79. 高级能力-云原生大数据|AI-业务赋能的基石-2-架构改造上的问题和困难 • 弹性扩缩容能力无法满足快速增长的业务需求：随着业务的发展，流量和数据量突增，尤其对于实时计算，需要资源 能够及时的扩容，以满足业务需求。尽管一些大数据管控平台尝试实现自动的扩缩容（如通过集群负载情况，进行扩 容），然而，在传统大数据平台架构下，通常需要资源申请、依赖软件安装、服务部署等一系列步骤，该过程通常比 较慢，对于集群负载的缓解，不够及时。 • 在离线分离部署及粗粒度调度无法提高资源的利用率：在传统Hadoop架构下，离线作业和在线作业往往分属不同的集 群，然而在线业务、流式作业具有明显的波峰波谷特性，在波谷时段，会有大量的资源处于闲置状态，造成资源的浪 费和成本的提升。在离线混部集群，通过动态调度削峰填谷，当在线集群的使用率处于波谷时段，将离线任务调度到 在线集群，可以显著的提高资源的利用率。然而，Hadoop Yarn目前只能通过NodeManager上报的静态资源情况进行 分配，无法基于动态资源调度，无法很好的支持在线、离线业务混部的场景。 • 操作系统镜像及部署复杂性拖慢应用发布：虚拟机或裸金属设备所依赖的镜像，包含了诸多软件包，如HDFS、Spark、 Flink、Hadoop等，系统的镜像远远大于10GB，通常存在镜像过大、制作繁琐、镜像跨地域分发周期长等问题。基于 这些问题，有些大数据开发团队不得不将需求划分为镜像类和非镜像类需求，当需要修改镜像的需求积累到一定程度， 才统一进行发布，迭代速度受限，当遇到用户紧急且需要修改镜像的需求时，势必面临很大的业务压力。同时，购买 资源后，应用的部署涉及到依赖部署、服务部署等环节，进一步拖慢应用的发布。 资源弹性扩容不及时 无法满足业务需要 资源使用率低 导致使用成本过高 操作系统和应用部署复杂 拖慢业务发布 云原生化可以解决上面的问题，演进的挑战有： 改造成本高 迁移风险高 组织架构造成额外的成本 主要体现在Yarn的复杂性 主要体现在领域专业性上
- 80. 应用改造成本高：将运行在Hadoop平台的大数据应用迁移到云原生平台，一方面需要大数据团队将业务应用进行 容器化改造，如系统任务的启动方式、基础设施的适配（环境变量、配置文件获取方式的变更等），这些都需要 大数据团队来做适配，在资源管理的方式，则从适配Yarn修改为适配Kubernetes，总体改造成本比较高；另一方面， 需要在大数据应用的资源申请层面进行改造，使其具备直接向Kubernetes集群申请资源的特性，也称为Native on Kubernetes。目前Apache Spark、Apache Flink已经从框架内核不同程度的支持了该特性，但整体的完整对依赖于 社区的努力。 迁移风险高：一次变更引入的改动越多，引发故障的几率也越多。在Hadoop领域，大数据应用的资源，由 Hadoop Yarn负责管理和调度，具体来说，大数据应用运行在Yarn提供的Container之中，这里的Container，是 Yarn中资源的抽象，并非Linux Container，将其迁移至以容器为技术的云原生架构，跨越了底层基础架构，改动面 比较大，风险相对也更高。 组织架构造成额外的成本：企业里负责开发和运维Hadoop系统的团队，和容器团队通常分属不同的部门，其技术 栈也有明显区别，在迁移的过程中，存在过多的跨部门沟通，带来额外的迁移成本，如果改动比较大，跨部分沟 通的成本会非常大。
- 81. 高级能力-云原生大数据|AI-业务赋能的基石-3-解决办法 大数据本身架构和组织因素导致改造投入成本很高，云原生化应该遵循循循进进的渐进式演进道路， Yarn-NodeManager Hadoop Yarn计算节点 Yarn-ResourceManager Hadoop Yarn管理节点 已有的Hadoop集群 注册|任务下发 Yarn-NodeManager Yarn-NodeManager Hadoop Yarn计算节点 K8S集群 注册|任务下发 渐进式演进方案主要有弹性扩缩容和离在线混合部署两种模式，两个模式的侧重点略有不同 • 弹性扩缩容主要聚焦于如何利用云原生资源，借助serverless技术，快速扩容资源以补充算力，满足业务实时需 求。 • 离在线混部主要聚焦于利用在线业务空闲时段的闲置资源，通过将大数据离线计算任务调度到在线业务闲置资 源的上，在保证业务稳定性的基础上，大幅提升资源的使用效率。 • 这两种模式都使用了Yarn on Kubernetes Pod的形式，如图，其基本思想是，将Yarn NodeManager运行在 Kubernetes集群中新扩容的Pod容器内，新扩充的Pod是根据从外部Yarn-ResourceManager收集的度量数据推断 的，当Yarn NodeManager Pod启动后，根据配置文件自动向已有的Hadoop集群的Yarn ResourceManager发起 注册，最终以Kubernetes Pod的形式补充Yarn集群的算力，算是借鉴了混合云的一些思路。此时我们避开了复 杂的ResourceManager改造问题，只需要考虑直接制作Yarn-NodeManager镜像。 API Server 迁移风险高， 所以不迁移 主要矛盾：算力
- 82. • 在弹性扩缩容和资源申请方面，借助基于Kubernetes的serveless服务，做到资源按需创建、按需使用和付费；而 资源的调度方式，则依然保证不变。具体来说，Kubernetes只是资源的提供方，只提供创建和销毁资源的API，业 务方负责调用该API来创建和销毁资源，资源在Kubernetes上创建完成之后，该资源的Yarn NodeManager组件自 动向Yarn ResourceManager注册，以Kubernetes Pod的形式提供算力，后续执行作业时涉及到的资源调度，依然 由Yarn负责。 • 在镜像和发布周期方面，容器镜像技术精简了应用的运行环境，镜像只需提供应用必须的依赖环境，使其存储空 间得到了极大的减少，上传和下载镜像的时间变的更短，快速启动和销毁变的很容易，总体极大的缩短了应用的 发布周期。 • 在资源利用率方面，借助云原生架构的技术能力，多方位提升系统的资源利用率，如细粒度调度（将CPU和内存 这两个核心资源划分的更细，从而更充分的分配系统资源）、动态调度（基于节点真实负载情况，而非静态划分 的资源，将任务调度到已分配了资源但是未实际使用的节点上，从而更充分的提高系统算力），在离线混部（根 据离线任务和在线任务的周期性，削峰填谷，从而充分利用系统闲置资源）。 • 在应用改造成本、迁移风险和组织架构方面：通过渐进式的迁移，大数据应用团队无需改造既有架构，只需制作 当前所用的Hadoop版本的镜像，即可完成在Kubernetes上创建容器资源补充算力，这种方式，可以最低程度的 减少变更，从而尽可能的降低迁移风险，与此同时，大数据团队保证Yarn资源调度和使用，容器团队保证Yarn pod的稳定运行，分工明确，能最大限度的保证系统的稳定性。
- 83. 高级能力-自动化-AIoT以及赋能业务-边缘计算(Edge Cloud )-1 远端控制 云端分析系统 设备端 自动化解决用户使用体验问题，计算量属于窄带范畴， 所以计算算力重点在于云端，云端计算体系架构成熟， 成本较低，在业务上本地的设备根据模式信号反馈一些 动作，比如下雨关窗帘，是自动化范畴，上传云端的数 据都是属性数据，比如谁什么时候干了什么，后续云端 根据个人喜好数据为用户提供比如按照个人喜好调节温 度、或者提送广告内容等 自动化特征 智能家居 智能办公室 智能信号灯... 远端控制 云端分析系统 设备端 (现场)边缘计算BOX 业务场景复杂，对算力、通信要求很高，计算放置于 云端时效性差，另外无法现场就对业务进行处理，比 如计算路口交通事故预警，给予司机及时提示等，所 以将算力卸载在距离业务现场、设备最近的地方，就 是边缘计算的场景，它的价值空间远超AIoT，可以更 大范围为客户赋能，IoT和边缘计算一定走向融合。 定位为基于物模型的计算 定位为基于业务的计算
- 84. 高级能力-自动化-AIoT以及赋能业务-边缘计算(Edge Cloud )-2 • 为了更好的为客户业 务场景赋能，比如路 口的交通事故识别和 预警等等需要低时延 高算力的场景，需要 实现云边一体纳管， 简化运维，降低成本， 客户专注于业务领域。 • 无论是AIoT还是边缘 计算，核心要素是计 算，计算平台的训练 平台位于云端，而推 理计算位于BOX端， 并且能够适应各类算 法和硬件的要求，形 成一个通用计算平台， 更普遍的为客户场景 赋能。 • 一切围绕如何将算力 输送到业务场景为中 心思想，构建技术体 系。
- 85. 高级能力-业务双引擎循环驱动-业务数据化、数据业务化 互联网业务、万物互联业务等等造就了海量数据，而海量数据应该也必须能够提炼出价值为业务反向赋能，形成正向业务价值循环 云原生平台(PaaS+Caas+IaaS) • 无法适应前端业务的快速创新 • 业务团队无法轻盈的离开IT架构快速 构建业务产品 • 企业战略无法得到统一下达和规范实 施 • 营销基于经验，即使基于数据，数据 不完整，分析算力不足，实施缓慢 • 其对应的企业组织架构无法适应灵活 作战的需要 • 业务流程无法复制，但是将企业核心 能力可以下沉(是能力下沉而不是技术 组件下沉)，加速企业创新速度 • 规范IT全生命周期管理，提高研发效 率和质量 • 提供行业最佳实践，助力企业快速落 地中台战略。 • 组织转变为前端小团队作战，后端中 台支撑的局面，可以适应业务灵活性 问题。 业务系统连接一组人，或者说企业业务实际能力提供者，通过双中台可 以将最上层业务产品诉求直接下沉到能力端，比如我们需要快速搭建一 个电商下单APP，只需要利用中台提供的能力要素，并在APP端组织业务 流程或者产品流程，下单后，商品自动送到用户手中，而无需企业打通 上下游业务链路，可以支撑快速的组织创新和业务创新。
- 86. 高级能力-低代码或无代码平台 为了进一步加速业务APP交付速度，而专业业务人员并不熟悉IT领域知识，但是低代码可以使得非IT人员快速构建业务系统成为可能，低代码平台是业 务研发和运行一体的平台，其内部实现并不容易，想落地更不容易，关键在于人们现在存在巨大的误区！工具思维导致落地艰难！ 业务沟通、需求分析与设计的交流平台 低代码平台表达的是业务逻辑。低代码平台的作用是将业务需求中的逻辑关系理清楚，帮助企业实现这个逻辑。 好的低代码平台要能适应企业的需求变化，提供需求变更管理 如果组件的实现方式依旧是 coding，依旧是别人熬夜，你来拖拉拽，这不叫低代码，这叫劳动力外包。国内这类 伪低代码产品，靠着模板走量批发的模式。客户买的是人工，不是技术 • 低代码平台与企业技术 栈的融合能力成为一个 重要的考验指标 • 有的企业系统已经运行 了几十年，拥有自己的 UI 体系、数据库体系和 中台体系，完全更改是 不现实的，低代码平台 要做的是与这么多技术 融合，帮助企业更好地 改进。 • 降本增效是最初级的成 果，如果能够深入企业 业务当中，低代码平台 可以带来的东西会更多。 将业务沉淀抽象化(比如 中台化),向上呈现。 • 低代码平台可以把不同 部门的系统、不同类型 的技术，如 RPA、BPM、 微流逻辑等串联在一起， 实现端到端的智能自动 化。是种生态型平台。
- 87. 高级能力-混合云（资源角度） 控制力 服务、位置、规则可控 高安全 安全自主可控 高性能 硬件加速、配置优化 固定工作负载 私有云 混合云 SLB 工作负载可迁移 敏捷 标准化、自动化、快速响 应 低成本 按需伸缩、按需使用付费 弹性 可弹性无限拓展 弹性工作负载 公有云 ETCD ETCD Image Image Data X • 企业可以在业务高峰时使用混合云补充 算力，并在低谷时从公有云撤回算力， 经济性和业务支撑两不误 • 可以结合私有云和公有各自的优势，尤 其是数据安全方面，这是客户使用公有 云的最大顾虑 • 在云原生产生之前，混合云架构就存在 了，云原生的混合云，除了具备传统混 合云的属性和特性，也同时具备了支撑 现在应用程序更好在不同云形态部署、 运行的能力。 • 云之间同步服务元数据为相同的服务治 理提供基础，同步镜像，为同一服务拓 展算力提供基础，同步Data，为隔离 底层云分布，在业务上的一致性上提供 基础。 • SLB会根据算力资源需要进行切流。 • 混合云本质是一种资源运用形式，资源 使用地位不对等，以私有云为主体。 控制台 控制台
- 88. 高级能力-多云（资源角度） 调研机构Gartner公司指出，80％的内部部署开发软件现在支持云计算或云原生，不断发展的云计算生态系统使企业能够更快、 更灵活、更实时地运营，从而带来竞争压力。接受云原生和多云方法作为一种新常态，意味着企业可以避免云计算供应商锁定， 可以提供超过5个9的响应率（99．999％），以避免每次停机导致平均数百万美元的损失。企业管理者终于意识到，云计算供 应商锁定会阻碍多云方法所带来的创造力、可用性和流动性。 • 云原生PaaS可以屏蔽多云的差异， 统一的不分何种云上的一致的运行 同一服务或者应用。 • 避免厂家锁定，客户可以自由选择 资源分布和费用组合，更加灵活。 • 中心云统一纳管运维和输出服务。 • 是一种以资源视角的云交付形式， 不同于混合云，底层云的资源使用 地位等同。 AWS Aliyun Azure 云中立
- 89. 高级能力-分布式云(交付角度） 分布式云（Distributed Cloud）就是分布在不同地理位置的云，是公有云“进化”的最新形态 中心Region 传统公有云 分布式云 覆盖热点区域的 边缘数据中心 客户本地机房的边缘节点或者 边缘计算盒子 粗犷上云 低时延 高弹性 强合规 云边一体纳管
- 90. 高级能力-去中心化云（服务角度） 中心Region 传统公有云 去中心云 靠近的小云相似 于混合云、多云 纳管或者分布式 整体服务对等 性能、安全可控， 满足可控信息互通 的要求 • 涵盖所有云，涵盖所有业务形态 • 满足性能、安全要求 • 满足云间通信 • 是未来下一代云，目前云厂商还在摸索阶段 • 有望成为云计算终极形式，云原生ServiceMesh以及 OAM等会得到更广阔空间的提升和发展。 2020年，全球数据存储总量预计为58ZB，平均每年增 长1倍。当前数据爆炸时代带来了三大问题。一、储存 成本问题： 通过当前的中心化云计算处理和存储海量 新增数据费用高昂；二、隐私和安全问题： 当前的中 心化云计算无法保证个人数据的隐私和安全性；三、数 字资产流动性问题： 数据是一种资产，互联网巨头数 据垄断无法实现数据权益的流动性；因此在面对数字经 济新纪元的到来，需要一个去中心化的云计算平台来解 决这些问题，预计到2022年，每10个字节的数据中，将 有7个字节的数据是没有数据中心的。 综合IDC、麦肯锡报告、华为报告，在2019年，全球中 心化云计算市场规模为2602亿美元，云存储市场为 491.3亿美元；而与之对应的去中心化云存储市场约30 亿美元，去中心化云计算市场约100亿美元。未来，10 年到20年，去中心化云计算、云储存市场有望实现10年 100倍的增长，达到 的规模。
- 91. 高级能力-精益化运维-云原生AIOps • 传统云原生的运维，虽然依赖于度量， 但是通过监控、日志分析、跟踪链等发 现问题根因所在周期长，依靠人的经验 （并且人的经验无法数据化沉淀），而 得到问题根因后，只能通过人工去修复 或者管理 • 而大数据或者基于监督的AI技术的成熟、 运维领域模型趋于完整、云原生底座也 更成熟的基础上，利用大数据分析根因 （关联性分析）和利用AI进行基于根因分 析的自动化处理成为可能。 • 在精细化的基础上，完整较为成熟的自 动化能力，节约了人力成本同时提高了 效率，也极大得保证了业务连续性。 • 但是，目前真正落地的企业很少，原因 在于大部分企业组织或者文化问题在落 实上的顾虑，因为“机器人”比人是否可靠 仍然在争论中，可参考或者背书的实例 少，导致落地缓慢。
- 92. • 组织结构升级 • 企业IT文化、工作流程、知识体系、工具集的总合升级 • 应用架构升级 • re-platform • re-build • re-host • 运维模式升级 • 从传统面向操作规则的运维转变为面向观测数据的自动化运维 • 重新定义软件交付模式 • 整体打包交付 • Git=Single Version Of Truth • 声明式API • 尽量采用OpenAPI作为系统集成胶水 • 重塑研发流水线 • 任何变更都提交git，有迹可循 • 变更经过几层验证，生产验证后自动合并，保证Single Version Of Truth • 随时可以集成测试 • 持续研发必然带来持续集成、持续测试、持续交付、持续..........
- 93. 淘 宝 和 天 猫 合 并 建 设 业 务 中 台 ， 三 大 中 间 件 核 心 系 统 上 线 。 阿 里 云 正 式 成 立 ， 自 研 飞 天 操 作 系 统 并 开 启 云 化 时 代 。 2 0 0 9 支付宝最后一个小型机下 线，自研飞天操作系统全 面支撑集团业务 2 0 1 3 电商核心系统全面上云， 大规模集群支撑集团“双十 一”，日交易额2684亿元 2 0 1 9 T4项目启动，容器调度技 术开始支撑集团的在线业 务，云原生时代开启 2 0 11 在线和离线调度系统打通混合 部署，底层资源池统一，支撑 百万级电商交易活动。 云原生技术全面商业化，容器 技术对外开放 2 0 1 7 云原生技术全面升级，阿 里巴巴原生用云， Serverless时代开始。 2 0 2 0 2009-2016 应用架构互联网化 2017-2019 核心系统全面云原生化 2020- 云原生技术全面升级 • 以业务场景为驱 动，以时代趋势 为助推，阿里超 前的实现云原生 的落地。 • 企业应该结合自 己的组织、业务、 市场特点来规划 实施云原生。 攘外必先安内
- 94. 项目 说明 全托管K8S 全托管K8S服务带来了发布和扩容效率的提升、更稳定的容器运行时、节点自愈能力，结合发 布自动化、资源管理自动化等能力可以实现应用与基础设施层的全面解耦 统一化ServiceMesh 将应用的分布式复杂性问题托付给Mesh层的数据面和控制面组件，实现全链路精准流量控制、 资源动态隔离以及零信任的安全能力，保证应用架构的稳定性目标的实现。 Serverless化 极大地降低了开发人员，特别是服务于前端的后端开发人员的运维负担，亚秒级的容器启动 速度和单物理机千容器的部署密度降低了serverless应用的技术障碍。 OAM统一交付能力 基于OAM的软件交付理念和工具重新定义了内部的DevOps流程，实现了应用的“一键安装、 多处运行”的应用编排目标 AIOps精细化运维 依托于K8S和ServiceMesh等度量数据精确性的提升，并给予AI算法从不同维度计算应用架构运 行态势，实现基于响应的自动化运维方案，大大降低了用户使用门槛，更安全更可靠的交付 最终软件产品。 目前的重点在于底座进一步实现应用与底层基础设施解耦，全面提升研发、运维效率，降低应用落地的整体成本