作者 | 易立 阿里云资深技术专家
起源 | 阿里巴巴云原生公众号
本系列文章：
- 第一篇 – 云原生基础设施
- 第二篇 – 云原生软件架构
- 第三篇 – 云原生利用交付与运维（本文）
过来的 2020 是充斥不确定性的一年，但也是充斥时机的一年。突发的新冠疫情为全社会的数字化转型按下减速键。云计算曾经不再是一种技术，而是成为撑持数字经济倒退和业务翻新的要害基础设施。在利用云计算重塑企业 IT 的过程中，生于云、长于云、最大化实现云价值的云原生技术失去了越来越多企业的认同，成为企业 IT 降本提效的重要伎俩。
然而，云原生改革也不只是基础设施和利用架构等技术层面，同时也在推动企业 IT 组织、流程和文化的改革。
在 CNCF 2020 年度调研报告中，曾经有 83% 的组织也在生产环境中应用 Kubernetes，然而面临的前三大挑战是复杂性，文化扭转与平安。
为了更好地减速业务翻新和解决互联网规模的挑战，云原生利用架构与开发方式应运而生，与传统单体利用架构相比，散布式微服务架构具备更好的、更快的迭代速度、更低的开发复杂性，更好的可扩展性和弹性。然而，正如星战宇宙中，原力既有光明也有光明的一面。微服务利用在部署、运维和治理的复杂性却大大增加，DevOps 文化和背地撑持的自动化工具与平台能力成为要害。
在容器技术呈现之前，DevOps 实践曾经倒退多年。然而，如果”开发“与”运维“团队不能用雷同的语言进行交换，用统一的技术进行合作，那就永远无奈突破组织和文化的藩篱。Docker 容器技术的呈现，实现了软件交付流程的标准化，一次构建，随处部署。联合云计算可编程基础设施和 Kubernetes 申明式的 API，能够通过流水线去实现自动化的继续集成与继续交付利用和基础设施，大大减速了开发和运维角色的交融。
云原生也是对团队业务价值和性能的重构。传统运维团队的一些职责转移到开发团队，如利用配置和公布，升高了每次公布的人力老本，而运维职责将更加关注零碎的稳定性和 IT 治理。Google 提倡的 SRE Site Reliability Engineering（站点可靠性工程），是通过软件和自动化伎俩，来解决零碎的运维复杂性和稳定性问题。此外，平安与老本优化也成为云上运维关注重点。
平安是企业上云的外围关切之一。云原生的敏捷性和动态性给企业平安带来新的挑战。因为云上平安是责任共担模型，须要企业了解与云服务商之间的责任边界，更要思考如何通过工具化、自动化的流程固化平安最佳实际。此外，传统平安架构通过防火墙爱护边界，而外部的任何用户或服务受到齐全的信赖。2020 突发的新冠疫情，大量的企业须要员工和客户近程办公与协同，企业应用须要在 IDC 和云上部署和交互。在物理平安边界隐没之后，云平安正在迎来一场粗浅的改革。
此外，新冠疫情进一步让企业更加关注 IT 老本优化。云原生的一个重要劣势是充分利用云的弹性能力，来按需提供业务所需计算资源，防止资源节约，实现老本优化的指标。然而，与传统老本估算审核制度不同，云原生的动态性、和高密度利用部署，让 IT 老本治理更加简单。
为此，云原生理念和技术也在倒退，帮忙用户继续升高潜在危险和零碎复杂性。上面咱们将介绍在云原生利用交付与运维畛域的一些新趋势。
Kubernetes 成为了通用的、对立的云管制立体
Kubernetes 这个单词来自于希腊语，含意是舵手或领航员，是“控制论”英文“cybernetic”的词根。Kubernetes 成为在容器编排的事实标准，不只得益于 Google 的光环和 CNCF（云原生计算基金会）的致力运作。背地是 Google 在 Borg 大规模分布式资源调度和自动化运维畛域的积淀和系统化思考，认真了解 Kubernetes 架构设计，有助于思考在分布式系统系统调度、治理的一些实质问题。
Kubernetes 架构的外围就是控制器循环，也是一个典型的 ” 负反馈 ” 控制系统。当控制器察看到冀望状态与以后状态存在不统一，就会继续调整资源，让以后状态趋近于冀望状态。比方，依据利用正本数变动进行扩缩容，节点宕机后主动迁徙利用等。
K8s 的胜利离不开 3 个重要的架构抉择：
- 申明式（Declarative）的 API：在 Kubernetes 之上，开发者只需定义形象资源的指标状态，而由控制器来具体实现如何达成。比方 Deployment、StatefulSet、Job 等不同类型工作负载资源的形象。让开发者能够关注于利用本身，而非零碎执行细节。申明式 API 是云原生重要的设计理念，这样的架构形式有助于将整体运维复杂性下沉，交给基础设施实现和继续优化。此外因为分布式系统的内生稳定性挑战，基于申明式的，面向终态的“level-triggered”实现比基于命令式 API、事件驱动的“edge-triggered”形式能够提供更加强壮的分布式系统实现。
- 屏蔽底层实现：K8s 通过一系列形象如 Loadbalance Service、Ingress、CNI、CSI，帮忙业务利用能够更好通过业务语义应用基础设施，无需关注底层实现差别。
- 可扩展性架构：所有 K8s 组件都是基于统一的、凋谢的 API 进行实现和交互。三方开发者也可通过 CRD（Custom Resource Definition）/ Operator 等办法提供畛域相干的扩大实现，极大扩大了 K8s 的利用场景。
正因如此，Kubernetes 治理的资源和基础设施范畴曾经远超容器利用。上面是几个例子：
- 基础架构治理 ：与开源的 Terraform 或者云供应商本身提供的 Infrastructure as Code(IaC) 工具如阿里云 ROS、AWS CloudFormation 不同，Crossplane（https://crossplane.io/）和 AWS Controllers for Kubernetes 在 Kubernetes 根底之上扩大了对基础设施的治理和形象。这样能够采纳统一的形式进行治理和变更 K8s 利用和云基础设施。
- 虚拟机治理：K8s 通过 KubeVirt 能够实现对虚拟机和容器的对立调度与治理，能够利用虚拟化补救容器技术的一些局限性，比方在 CI/CD 场景中，能够联合 Windows 虚拟机进行自动化测试。
- IoT 设施治理：KubeEdge 和 OpenYurt 等边缘容器技术都提供了对海量边缘设施的治理能力。
- K8s 集群治理：阿里云容器服务 ACK 的节点池治理，集群治理等齐全都是采纳 Kubernetes 形式进行自动化治理与运维的。ACK Infra 撑持了部署在寰球各地数万个 Kubernetes 集群，基于 K8s 实现自动化了扩缩容、故障发现 / 自愈等能力。
1. 工作负载自动化降级
K8s 控制器“把简单留给本人，把简略交给他人”的现实十分美妙，然而实现一个高效、强壮的控制器却充斥技术挑战。
- 因为 K8s 内置工作负载的局限性，一些需要无奈满足企业应用迁徙的需要，通过 Operator framework 进行扩大成为了常见的解决方案。然而一方面对反复的需要反复造轮子，会造成了资源的节约；也会导致技术的碎片化，升高可移植性。
- 随着越来越多的企业 IT 架构，从 on Kubernetes 到 in Kubernetes，大量的 CRD、自定义 Controller 给 Kubernetes 的稳定性和性能带来大量的挑战。面向终态的自动化是一把“双刃剑”，它既为利用带来了申明式的部署能力，同时也潜在地会将一些误操作行为被终态化放大。在产生操作故障时正本数维持、版本一致性、级联删除等机制反而很可能导致爆炸半径扩充。
OpenKruise 是阿里云开源的云原生利用自动化治理引擎，也是以后托管在 Cloud Native Computing Foundation (CNCF) 下的 Sandbox 我的项目 。它来自阿里巴巴多年来容器化、云原生的技术积淀，是阿里外部生产环境大规模利用的基于 Kubernetes 之上的规范扩大组件，一套紧贴上游社区规范、适应互联网规模化场景的技术理念与最佳实际。以开源我的项目 OpenKruise 形式与社区凋谢、共建。 一方面帮忙企业客户在云原生的摸索的过程中，少走弯路，缩小技术碎片，晋升稳定性；一方面推动上游技术社区，逐步欠缺和丰盛 Kubernetes 的利用周期自动化能力。
更多信息能够参考：《OpenKruise 2021 布局曝光：More than workloads》
2. 开发与运维新合作界面浮现
云原生技术呈现也带来了企业 IT 组织构造的变动。为了更好应答业务敏捷性的须要，微服务利用架构催生了“双比萨团队”（Two-pizza teams)。较小的、独立的、自蕴含的开发团队能够更好达成共识，减速业务翻新。SRE 团队成为了程度撑持团队，撑持下层研发效率晋升和零碎稳定性。而随着 Kubernetes 的倒退，让 SRE 团队能够基于 K8s 构建本人企业的利用平台，推动标准化和自动化，让下层利用开发团队通过自服务的形式进行资源管理和利用生命周期治理。咱们看到组织形式进一步产生了变动，新的平台工程团队开始浮现。
参考：https://blog.getambassador.io/the-rise-of-cloud-native-engineering-organizations-1a244581bda5
这也与 K8s 本身定位是十分相符合的。Kubernetes 的技术定位面向利用运维的基础设施和 Platform for Platform，并不是面向开发者的一体化利用平台。越来越多的企业会由平台工程团队基于 Kubernetes 构建本人的 PaaS 平台，晋升研发效率和运维效率。
相似 Cloud Foundry 的经典 PaaS 实现会建设一套独立概念模型、技术实现和扩大机制，这种形式能够提供简化用户体验，然而也引入了一些缺点。无奈和疾速倒退的 Kubernetes 体系相结合，无奈充沛组合应用多种新的技术实现，比方 Serverless 编程模型，反对 AI/ 数据分析等新计算业务。然而基于 K8s 的 PaaS 平台不足对立的架构设计和实现布局，会呈现很多碎片化的技术实现，并不利于可继续的倒退。
Open Application Model（OAM）凋谢利用模型，以及它的 Kubernetes 实现 KubeVela 我的项目，正是阿里云联结微软和云原生社区，独特推出的云原生利用交付与治理畛域的规范模型与框架我的项目。其中，OAM 的设计思维是为包含 Kubernetes 在内的任何云端基础设施提供一个对立、面向最终用户的利用定义模型；而 KubeVela，则是这个对立模型在 Kubernetes 上的 PaaS 参考实现。
KubeVela/OAM 提供了面向 Kubernetes 的服务形象和服务组装能力，能够将不同实现的工作负载和运维特色进行对立形象和形容，并提供插件式的注册与发现机制，进行动静组装。平台工程团队能够采纳统一的形式进行新性能扩大，并且放弃与 Kubernetes 上新的利用框架良好的互操作性。对于利用开发和运维团队，实现了关注点拆散（Separation of Concerns），能够将利用定义、运维能力与基础设施实现解构，让利用交付过程变得更加高效、牢靠和自动化。
在云原生利用模型定义畛域，业界也在不同方向进行摸索。比方 AWS 新公布的 Proton 是面向云原生利用交付的服务，通过 Proton，能够升高容器和 Serverless 部署、运维复杂性，并且能够和 GitOps 联合起来，晋升整个利用交付流程的自动化和可管理性。
阿里云 Serverless K8s 反对的 Knative 能够同时反对 Serverless 容器和函数来实现事件驱动的利用，让开发者应用一个编程模型，能够高效抉择底层不同 Serverless 化算力进行优化执行等。
无处不在的平安危险催生平安架构改革
1. DevSecOps 成为关键因素
麻利开发与可编程云基础设施联合在一起，大大晋升了企业应用的交付效率。然而在这个过程中，如果漠视了平安危险管制，有可能造成微小的损失。Gartner 论断，到 2025 年，云上基础设施 99% 的平安浸透问题是因为用户谬误的配置和治理造成的。
在传统软件开发流程中，在零碎设计开发实现后和公布交付前，平安人员才开始染指进行平安审核。这种流程无奈满足业务疾速迭代的诉求。”Shifting left on security“(安全性左移)”开始失去更多的关注，这将利用程序设计、开发人员尽早与平安团队合作，并无缝地嵌入平安实际。通过左移安全性，不仅能够升高平安危险，还能够升高修复老本。IBM 的钻研人员发现，解决设计中的平安问题比代码开发期间能节俭 6 倍左右的老本，比测试期间能节俭 15 倍左右的老本。
DevOps 研发合作流程也随之扩大成为 DevSecOps。它首先是理念文化的变动，平安成为每个人的责任，而非专一平安团队的责任；其次尽早解决平安问题，将平安左移到软件设计阶段，升高整体平安治理老本；最初是通过自动化工具链而非人治形式，实现危险预防、继续监测和及时响应能力。
DevSecOps 落地的技术前提是实现可验证的、可复现的构建和部署流程，这样能够保障咱们在测试、预发、生产等不同环境对架构安全性进行继续验证和改良。咱们能够利用云原生技术中的 immutable infrastructure（不可变基础设施）和申明式的策略管理 Policy as Code 联合在一起实现 DevSecOps 的落地实际。下图是一个最简化的容器利用 DevSecOps 流水线。
当代码提交之后，能够通过阿里云镜像服务 ACR 被动扫描利用，并对镜像进行签名，当容器服务 K8s 集群开始部署利用时，安全策略能够对镜像进行验签，能够回绝未通过验签的利用镜像。同理，如果咱们利用 Infrastructure as Code 的形式对基础设施进行变更，咱们能够通过扫描引擎在变更之前就进行危险扫描，如果发现相干的平安危险能够终止并告警。
此外，当利用部署到生产环境之后，任何变更都需通过上述自动化流程。这样的形式最小化了人为的谬误配置引发的平安危险。Gartner 预测，到 2025 年 60% 的企业会驳回 DevSecOps 和不可变基础设施实际，与 2020 年相比升高 70% 安全事件。
2. 服务网格减速零信赖平安架构落地
散布式微服务利用岂但部署和治理复杂性晋升，其平安攻击面也被放大。在传统的三层架构中，平安防护次要在南北向流量，而在微服务架构中，东西向流量防护会有更大的挑战。在传统的边界防护形式下，如果一个利用因为平安缺点被攻陷，不足安全控制机制来阻止外部威逼“横向挪动”。
https://www.nist.gov/blogs/taking-measure/zero-trust-cybersecurity-never-trust-always-verify
“零信赖”最早由 Forrester 在 2010 年左右提出，简略地说，零信赖就是假设所有威逼都可能产生，不信赖网络外部和内部的任何人 / 设施 / 利用，须要基于认证和受权重构访问控制的信赖根底，疏导平安体系架构从“网络中心化”走向“身份中心化”；不信赖传统网络边界爱护，而代之以微边界爱护。
Google 在鼎力推动云原生平安和零信赖架构，比方 BeyondProd 方法论。阿里和蚂蚁团体上云过程中，也开始引入零信赖架构理念和实际。其中的要害是：
- 对立身份标识体系：为微服务架构中每一个服务组件都提供一个独立的身份标识。
- 对立拜访的受权模型：服务间调用须要通过身份进行鉴权。
- 对立拜访控制策略：所有服务的访问控制通过标准化方向进行集中管理和对立管制。
平安架构是一种 cross-cutting concern，贯通在整个 IT 架构与所有组件相干的关注点。如果它与具体微服务框架实现耦合，任何平安架构调整都可能对每个应用服务进行从新编译和部署，此外微服务的实现者能够绕开平安体系。而服务网格能够提供独立于利用实现的，松耦合、分布式的零信赖平安架构。
下图是 Istio 服务网格的平安架构：
其中：
- 既能够利用现有身份服务提供身份标识，也反对 SPIFFE 格局的身份标识。身份标识能够通过 X.509 证书或者 JWT 格局进行传递。
- 通过服务网格管制立体 API 来对立治理，认证、受权、服务命名等安全策略。
- 通过 Envoy Sidecar 或者边界代理服务器作为策略执行点（PEP）来执行安全策略，能够为东西向和南北向的服务拜访提供平安访问控制。而且 Sidecar 为每个微服务提供了利用级别的防火墙，网络微分段最小化了平安攻击面。
服务网格让网络安全架构与利用实现解耦，能够独立演进，独立治理，晋升平安合规保障。此外利用其对服务调用的遥测能力，能够进一步通过数据化、智能化办法对服务间通信流量进行危险剖析、自动化进攻。云原生零信赖平安还在晚期，咱们期待将来更多的平安能力下沉到基础设施之中。
新一代软件交付形式开始浮现
1. 从 Infrastructure as Code 到 Everything as Code
基础架构即代码（Infrastructure-as-Code，IaC）是一种典型的申明式 API，它扭转了云上企业 IT 架构的治理、配置和协同形式。利用 IaC 工具，咱们能够将云服务器、网络和数据库等云端资源，进而实现齐全自动化的创立、配置和组装。
咱们能够将 IaC 概念进行延长，能够笼罩整个云原生软件的交付、运维流程，即 Everything as Code。下图中波及了应用环境中各种模型，从基础设施到利用模型定义到全局性的交付形式和平安体系，咱们都能够通过申明式形式对利用配置进行创立、治理和变更。
通过这种形式，咱们能够为分布式的云原生利用提供灵便、强壮、自动化的全生命周期治理能力：
- 所有配置可被版本治理，可追溯，可审计。
- 所有配置可保护、可测试、可了解、可合作。
- 所有配置能够进行动态剖析、保障变更的可预期性。
- 所有配置能够在不同环境重现，所有环境差别也须要进行显示申明，晋升一致性。
2. 申明式的 CI/CD 实际逐步受到关注
更进一步，咱们能够将应用程序的所有环境配置都通过源代码控制系统进行治理，并通过自动化的流程进行面向终态地交付和变更，这就是 GitOps 的核心理念。
GitOps 最后由 Weaveworks 的 Alexis Richardson 提出，指标是提供一套对立部署、治理和监控应用程序的最佳实际。在 GitOps 中，从利用定义到基础设施配置的所有环境信息都作为源代码，通过 Git 进行版本治理；所有公布、审批、变更的流程都记录在 Git 的历史状态中。这样 Git 成为 source of truth，咱们能够高效地追溯历史变更、能够轻松回滚到指定版本。GitOps 与 Kubernetes 提倡的申明式 API、不可变基础设施相结合，咱们能够保障雷同配置的可复现性，防止线上环境因为配置漂移导致的不可预测的稳定性危险。
联合上文提到的 DevSecOps 自动化流程，咱们能够在业务上线之前，提供统一的测试和预发环境，更早，更快地捕捉零碎中的稳定性危险，更欠缺地验证灰度、回滚措施。
GitOps 晋升了交付效率，改良了开发者的体验，也晋升了分布式应用交付的稳定性。
GitOps 在过来两年工夫里，在阿里团体和蚂蚁都被宽泛应用，成为云原生利用标准化的交付形式。目前 GitOps 还在倒退初期，开源社区还在不断完善相干的工具和最佳实际。2020 年，Weaveworks 的 Flagger 目并入 Flux，开发者能够通过 GitOps 的形式实现灰度公布、蓝绿公布、A/B 测试等渐进的交付策略，能够管制公布的爆炸半径，晋升公布的稳定性。在 2020 年末，CNCF 利用交付畛域小组正式发表了 GitOps Working Group 的组建，咱们期待将来社区将进一步推动相干畛域标准化过程和技术落地。
3. 运维体系从标准化、自动化向数据化、智能化演进
随着微服务利用规模的倒退，问题定位、性能优化的复杂度呈爆炸式增长。企业在 IT 服务治理畛域尽管曾经领有多种工具汇合，比方，日志剖析、性能监控、配置管理等。然而不同管理系统之间是一个个数据孤岛，无奈提供简单问题诊断所必须的端到端可见性。许多现有工具都采纳基于规定的办法进行监督、警报。在日益简单和动静的云原生环境中，基于规定的办法过于软弱，保护老本高且难以扩大。
AIOps 是利用大数据分析和机器学习等技术自动化 IT 运维流程。AIOps 能够通过大量的日志和性能数据处理、零碎的环境配置剖析，取得对 IT 零碎外部和内部的依赖的可见性，加强前瞻性和问题洞察，实现自治运维。
得益于云原生技术生态的倒退，AIOps 与 Kubernetes 等技术将相互促进，进一步欠缺企业 IT 的老本优化、故障检测和集群优化等计划。这外面有几个重要的助力：
- 可观测能力的标准化：随着云原生技术社区 Prometheus、OpenTelemetry、OpenMetrics 等我的项目的倒退，利用可观测性畛域在日志、监控、链路追踪等畛域进一步标准化和交融，使得多指标、根因剖析的数据集更加丰盛。Service Mesh 非侵入的数据遥测能力能够在不批改现有利用的前提下获取更加丰盛的业务指标。从而进步 AIOPS 的 AI 层面的准确率和覆盖率。
- 利用交付治理能力的标准化：Kubernetes 申明式 API、面向终态的利用交付形式，提供了更加统一的治理运维体验。Service Mesh 非侵入的服务流量治理能力，让咱们能够用通明的形式对利用进行治理和自动化运维。
通过阿里团体的 DevOps 平台“云效”和容器平台公布变更零碎相结合，能够实现利用的“无人值守公布”。在公布过程中，零碎继续收集包含零碎数据、日志数据、业务数据等各种指标，并通过算法比对公布前后的指标异动。一旦发现问题，就能够对公布过程进行阻断，甚至自动化回滚。有了这项技术，任何一个开发团队都能够平安的做好公布工作，而不用放心线上变更导致的重大故障了。
云原生老本优化逐步受到关注
随着企业将更多外围业务从数据中心迁徙到云上，越来越多的企业迫切需要对云上环境进行估算制订、成本核算和老本优化。从固定的财务老本模型，转化为变动的、按需付费的云财务模型，这是一个重要的观点和技术转变。然而大多数企业尚未对云财务管理有清晰的认知和技术手段，在 FinOps 2020 年调研报告中，将近一半的受访者（49%）简直没有或没有自动化办法治理云收入。为了帮忙组织更好理解云老本和 IT 收益，FinOps 理念开始风行。
FinOps 是云财务管理的形式，是企业 IT 经营模式的转变，指标是晋升组织对云老本的了解和更好地做决策。2020 年 8 月，Linux 基金会发表成立 FinOps 基金会，通过最佳实际、教育和规范推动云财务管学科。目前云厂商开始逐步加大对 FinOps 的反对，帮忙企业的财务流程能够更好适应云资源的可变性和动态性。比方 AWS Cost Explorer, 阿里云费用核心，能够帮忙企业更好进行老本剖析和摊派。详见：https://developer.aliyun.com/article/772964。
越来越多的企业在云上通过 Kubernetes 平台来治理、应用基础设施资源。通过容器来晋升部署密度和利用弹性，从而升高整体计算成本。然而在 Kubernetes 的动态性为资源计量和老本摊派引入新的复杂性挑战。
因为多个容器能够被动静部署在同一个虚拟机实例之上，能够按需弹性伸缩，咱们无奈简略将底层云资源与容器利用一一对应。2020 年 11 月，CNCF 基金会和 FinOps 基金会公布了一份新的对于 Kubernetes 云财务管理的白皮书《FinOps for Kubernetes: Unpacking container cost allocation and optimization》来帮忙大家更好了解相干财务管理实际。
阿里云容器服务也在产品中内置了很多老本治理和优化的最佳实际。很多客户十分关怀如何基于 Kubernetes 和资源弹性实现老本优化，通常咱们倡议企业更好理解本人业务类型，为 K8s 集群划分不同的节点池，在老本、稳定性和性能等多维度考量中寻找平衡点。
- 日常业务：对于可预测的、绝对不变的负载，咱们能够利用包年包月的裸金属或者大规格虚拟机来晋升资源利用率，降低成本。
- 打算内的短期或周期性业务：比方双十一大促，跨年流动等短期业务峰值，或者月底结算等周期性业务负载变动，咱们能够利用虚拟机或者弹性容器实例来应答业务顶峰。
- 非预期的突发弹性业务：比方突发新闻热点，或者长期的计算工作。弹性容器实例能够轻松实现每分钟上千实例的扩容。
更多对于 Kubernetes 布局问题，能够参考：《对于 Kubernetes 布局的灵魂 n 问》。
总结
过来十年，基础架构上云，互联网利用架构降级，研发流程麻利化几个技术大趋势相交汇，与容器、Serverless、服务网格等技术创新相结合，独特催生了云原生的理念诞生和倒退。云原生正在从新定义的计算基础设施、利用架构和组织流程，是云计算倒退的历史的必然。感激所有一起在云原生时代的同行者，让咱们独特摸索和定义云原生的将来。
片尾彩蛋，本系列三篇文章的名称向星战系列致敬，你发现了吗？
团队招聘
阿里云容器服务团队招聘啦！欢送转岗、社招举荐! 一起发明云原生激情磅礴的将来！杭州、北京、深圳均有机会哦。简历发送至：yaowei.cyw@alibaba-inc.com。
一本书理解阿里双 11 外围零碎全面云原生化过程
点击收费下载《云原生大规模利用落地指南》，从技术体系降级、到技术能力冲破、再到大促业务实际，一本书理解阿里 双 11 外围零碎全面云原生化过程！