简介： 云原生是零售云的最重要的技术底座，云原生是什么，会走向哪里，在零售2B交付的场景上该如何应用，怎么能够结合帮助建设零售云系列产品体系，值得我们的思考和探索，也将有效指导我们接下来几年的零售云项目和产品建设。

零售云是阿里三朵业务云：零售云、金融云和政务云之一，将开辟阿里在电商、零售行业的新蓝海，2B快速交付、赋能合作伙伴更快业务增长和节省成本。云原生是零售云的最重要的技术底座，云原生是什么，会走向哪里，在零售2B交付的场景上该如何应用，怎么能够结合帮助建设零售云系列产品体系，值得我们的思考和探索，也将有效指导我们接下来几年的零售云项目和产品建设。

云原生定义、阿里巴巴云原生架构方法论及产品体系

云原生定义

Cloud Native 翻译为云原生，是 Matt Stine 提出的一个概念，它是一个思想的集合，包括 DevOps 、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native 既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。Cloud Native 也可以说是一系列技术、企业管理方法的集合。

云原生的本质

云原生本质是以应用为中心，让应用能最大限度享受到云计算的红利。云原生是云计算的下一站，云原生架构是引领未来十年的新一代技术架构。云原生让云计算变得标准、开放、简单高效、触手可及。

云原生应用开发的最佳实践原则：12-Factor

1、 基准代码：一份基准代码（Codebase），多份部署（deploy）

基准代码和应用之间总是保持一一对应的关系，一份代码可以部署在开发环境、测试环境、预发环境及产线环境。

多个应用共享一份基准代码是有悖于 12-Factor 原则的。解决方案如下：

将共享的代码拆分为独立的类库，然后使用依赖管理策略去加载它们。所有部署的基准代码相同，但每份部署可以使用其不同的版本。比如，开发人员可能有一些提交还没有同步至预发布环境；预发布环境也有一些提交没有同步至生产环境。但它们都共享一份基准代码，我们就认为它们只是相同应用的不同部署而已。

2、 依赖——显式声明依赖关系（Dependency）

12-Factor 规则下的应用程序不会隐式依赖系统级的类库。它一定通过依赖清单，确切地声明所有依赖项。大多数编程语言都会提供一个打包系统，比如 java 使用 maven ，应用依赖了哪些第三方库，要显示地定义在 POM 文件里。

3、 配置：在环境中存储配置

配置要和代码完全分离，环境变量可以非常方便地在不同的部署间做修改，却不动一行代码。配置主要包括数据库信息，缓存信息，第三方服务证书，每份部署特有的配置，如域名等信息。

判断一个应用是否正确地将配置排除在代码之外，一个简单的方法，看该应用的基准代码是否可以立刻开源，而不用担心会暴露任何敏感的信息。

4、 后端服务：把后端服务当作附加资源

后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库，消息系统及缓存系统。

12-Factor 应用的任意部署，都应该可以在不进行任何代码改动的情况下，进行后端服务的切换，比如将本地 MySQL 数据库换成第三方服务（例如阿里云的 RDS）。另外，部署可以按需加载或卸载资源。例如，如果应用的数据库服务由于硬件问题出现异常，管理员可以从最近的备份中恢复一个数据库，卸载当前的数据库，然后加载新的数据库 。整个过程都不需要修改代码。

5、 构建->发布->运行：严格分离构建和运行

基准代码 转化为一份部署(非开发环境)需要以下三个阶段：

构建阶段，将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码,获取和打包依赖项,编译成二进制文件和资源文件。

发布阶段，将构建的结果和当前部署所需配置相结合，并能够立刻在运行环境中投入使用。

运行阶段(“运行时”)，针对选定的发布版本，在执行环境中启动一系列应用程序进程。

每一个发布版本必须对应一个唯一的发布 ID,一旦发布就不可修改，任何的变动都应该产生一个新的发布版本。另外，发布管理工具需要能方便的回退至较旧的发布版本。

6、 进程：以一个或多个无状态进程运行应用

运行环境中，应用程序通常是以一个和多个进程运行的。12-Factor应用的进程必须无状态且无共享，任何需要持久化的数据都要存储在后端服务内，比如数据库或缓存。

7、 端口绑定：通过端口绑定提供服务

12-Factor应用完全自我加载，而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务，并监听发送至该端口的请求。比如，在线上环境中，请求统一发送至公共域名，然后路由至绑定了端口的网络进程。

8、 并发：通过进程模型进行扩展

在 12-factor 应用中，进程是一等公民。12-Factor 应用的进程主要借鉴于 unix 守护进程模型 。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的进程类型。例如，HTTP 请求可以交给web进程来处理，而常驻的后台工作则交由 worker进程负责。

9、 易处理：快速启动和优雅终止可最大化健壮性

12-Factor 应用的进程是易处理的，即它们可以瞬间开启或停止。这有利于快速、弹性的伸缩应用，迅速部署变化的代码或配置，稳健的部署应用。

进程应当追求最小启动时间，并且一旦接收到终止信号（SIGTERM），可以优雅的终止。进程还应当在面对突然死亡时保持健壮，例如底层硬件故障。无论如何，12-Factor应用都应该可以设计能够应对意外的、不优雅的终结。

10、 开发环境与线上环境等价：尽可能的保持开发，预发布，线上环境相同

12-Factor 应用的开发人员应该避免在不同环境间使用不同的后端服务，即使适配器已经可以几乎消除使用上的差异。这是因为，不同的后端服务意味着会突然出现的不兼容，从而导致测试、预发布都正常的代码在线上出现问题。这些错误会给持续部署带来阻力。从应用程序的生命周期来看，消除这种阻力需要花费很大的代价。

11、 日志：把日志当作事件流

12-factor 应用本身从不考虑存储自己的输出流。不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接的标准输出（stdout）事件流。开发环境中，开发人员可以通过这些数据流，实时在终端看到应用的活动。

12、 管理进程:后台管理任务当作一次性进程运行

一次性管理进程主要指一些管理或维护应用的一次性任务，比如，运行数据迁移，运行一些提交到代码仓库的一次性脚本等。它们应该和正常的常驻进程使用同样的环境。这些管理进程和任何其他的进程一样使用相同的代码和配置，基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。

以上了解了 12-Factor 应用原则。在我们学习 K8s 的过程中，个人认为 K8s 结合service mesh 很好的满足了上面的每条原则。设计 K8s 和 ServiceMesh 的人很伟大，提出 12 原则的 AdamWiggins 很伟大。

阿里巴巴云原生架构方法论

阿里巴巴云原生架构设计方法

阿里巴巴独有的云原生架构设计方法——ACNA（Alibaba Cloud Native Architecting）如下：

ACNA 是一个 「4+1」 的架构设计流程，「4」 代表架构设计的关键视角，包括企业战略视角、业务发展视角、组织能力视角和云原生技术架构视角；「1」 表示云原生架构的架构持续演进闭环。

值得一提的是，ACNA 除了是一个架构设计方法，也包含了对云原生架构的评估体系、成熟度衡量体系、行业应用最佳实践、技术和产品体系、架构原则、实施指导等。

另外，云原生架构演进是一个持续迭代的过程，每一次迭代都是从企业战略、业务诉求到架构设计与实施的一个完整闭环，整体关系如下图：

阿里巴巴云原生成熟度模型

由 于 云 原 生 架 构 包 含 了 6 个 关 键 架 构 维 度（ 简 写 为 SESORA，Service + Elasticity + Serverless + Observability + Resilience + Automation），因此我们先定义关键维度的成熟度级别：

阿里巴巴云原生产品体系

阿里巴巴云原生产品家族包括容器产品家族、微服务产品家族、Serverless 产品家族、Service Mesh 产品家族、消息产品、云原生数据库家族、云原生大数据产品家族等。

1、容器产品家族

2、微服务产品家族

EDAS（企业分布式应用服务）是一个面向微服务应用的应用全生命周期 PaaS 平台，产品全面支持 HSF、Dubbo、Spring Cloud 技术体系，提供 ECS 集群和 K8s 集群的应用开发、部署、监控、运维等全栈式解决方案。

MSE（微服务引擎）是一个面向业界主流开源微服务框架 Spring Cloud、Dubbo 的微服务平台， 包含治理中心、托管注册 / 配置中心，一站式的解决方案帮助用户提升微服务的开发效率和线上稳定性。

ACM（应用配置管理），是一款应用配置中心产品，实现在微服务、DevOps、大数据等场景下的 分布式配置服务，保证配置的安全合规。

CSB Micro Gateway（微服务网关服务）针对微服务架构下 API 开放的特点，提供能与微服务环 境的治理策略无缝衔接的网关服务，实现高效的微服务 API 开放。

GTS（全局事务服务）用于实现分布式环境下特别是微服务架构下的高性能事务一致性，可以与多种数据源、微服务框架配合使用，实现分布式数据库事务、多库事务、消息事务、服务链路级事务及各种组合。

ARMS（应用实时监控服务 ) 是一款应用性能管理产品，包含前端监控、应用监控和 Prometheus 监控三大子产品，涵盖了浏览器、小程序、APP、分布式应用和容器环境等性能管理，实现全栈式性能监控和端到端全链路追踪诊断。链路追踪（Tracing Analysis）为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、 链路拓扑、应用依赖分析等工具，能够帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈，提高 微服务时代下的开发诊断效率。

PTS（Performance Testing Service）是一款云化测试工具，提供性能测试、API 调试和监测 等多种能力，紧密结合监控、流控等产品提供一站式高可用能力，高效检验和管理业务性能。

3、Serverless 产品家族

FC（函数计算）是一个事件驱动的全托管 Serverless 计算服务，用户无需管理服务器等基础设施， 只需编写代码并上传，函数计算会准备好计算资源，并以弹性、可靠的方式运行业务代码。

SAE（Serverless 应用引擎）实现了 Serverless 架构 + 微服务架构的完美融合，真正按需使用、按量计费，节省闲置计算资源，同时免去 IaaS 运维，有效提升开发运维效率；SAE 支持 Spring Cloud、Dubbo 和 HSF 等流行的微服务架构。

Serverless 工作流是一个用来协调多个分布式任务执行的全托管 Serverless 云服务，致力于简化开发和运行业务流程所需要的任务协调、状态管理以及错误处理等繁琐工作，让用户聚焦业务逻辑开发。用户可以用顺序、分支、并行等方式来编排分布式任务，服务会按照设定好的顺序可靠地协调任务执行， 跟踪每个任务的状态转换，并在必要时执行用户定义的重试逻辑，以确保工作流顺利完成。

4、Service Mesh产品家族

服务网格（ASM）提供全托管的微服务应用流量管理平台，兼容 Istio 的同时，支持多个 Kubernetes 集群中应用的统一流量管理，为容器和虚拟机中应用服务提供一致的通信、安全和可观测能力。

AHAS（应用高可用服务）是专注于提高应用及业务高可用的工具平台，目前主要提供应用架构探测感知，故障注入式高可用能力评测和流控降级高可用防护三大核心能力，通过各自的工具模块可以快 速低成本的在营销活动场景、业务核心场景全面提升业务稳定性和韧性。

5、消息产品家族

消息队列 RocketMQ 版是阿里云基于 Apache RocketMQ 构建的低延迟、高并发、高可用、高可 靠的分布式消息中间件。该产品最初由阿里巴巴自研并捐赠给 Apache 基金会，服务于阿里集团 13 年， 覆盖全集团所有业务，支撑千万级并发、万亿级数据洪峰，历年刷新全球最大的交易消息流转记录。

消息队列 Kafka 版是阿里云基于 Apache Kafka 构建的高吞吐量、高可扩展性的分布式消息队列服 务，广泛用于日志收集、监控数据聚合、流式数据处理、在线和离线分析等，是大数据生态中不可或缺 的产品之一，阿里云提供全托管服务，用户无需部署运维，更专业、更可靠、更安全。

消息队列 AMQP 版由阿里云基于 AMQP 标准协议自研，完全兼容 RabbitMQ 开源生态以及多语 言客户端，打造分布式、高吞吐、低延迟、高可扩展的云消息服务。

微消息队列 MQTT 版是专为移动互联网 (MI)、物联网 (IoT) 领域设计的消息产品，覆盖互动直播、 金融支付、智能餐饮、即时聊天、移动 Apps、智能设备、车联网等多种应用场景；通过对 MQTT、 WebSocket 等协议的全面支持，连接端和云之间的双向通信，实现 C2C、C2B、B2C 等业务场景之 间的消息通信，可支撑千万级设备与消息并发，真正做到万物互联。

阿里云消息服务 MNS 是一种高效、可靠、安全、便捷、可弹性扩展的分布式消息服务 , 能够帮助应 用开发者在他们应用的分布式组件上自由的传递数据、通知消息，构建松耦合系统。

事件总线 EventBridge 是阿里云提供的一款无服务器事件总线服务，支持阿里云服务、自定义应用、 SaaS 应用以标准化、中心化的方式接入，并能够以标准化的 CloudEvents 1.0 协议在这些应用之间路 由事件，帮助用户轻松构建松耦合、分布式的事件驱动架构。

6、数据库产品家族

PolarDB 是阿里巴巴自主研发的下一代关系型分布式云原生数据库，目前兼容三种数据库引擎：MySQL、PostgreSQL、高度兼容 Oracle 语法；计算能力最高可扩展至 1000 核以上，存储容量最高 消息产品家族 云原生数据库产品家族 6 7 The Cloud-native Architecture White Paper by Alibaba Cloud 50 可达 100T。PolarDB 经过阿里巴巴双十一活动的最佳实践，让用户既享受到开源的灵活性与价格，又享受到商业数据库的高性能和安全性。

PolarDB-X（原 DRDS 升级版）是由阿里巴巴自主研发的云原生分布式数据库，融合分布式 SQL 引擎 DRDS 与分布式自研存储 X-DB，专注解决海量数据存储、超高并发吞吐、大表瓶颈以及复杂计算效率等数据库瓶颈难题，历经各届天猫双 11 及阿里云各行业客户业务的考验，助力企业加速完成业务数字化转型。

7、大数据产品家族

云原生数据仓库 AnalyticDB MySQL 版（简称 ADB，原分析型数据库 MySQL 版）是一种支持 高并发低延时查询的新一代云原生数据仓库，全面兼容 MySQL 协议以及 SQL:2003 语法标准，可以对 海量数据进行即时的多维分析透视和业务探索，快速构建企业云上数据仓库。产品规格按需可选，基础 版成本最低，适合 BI 查询应用；集群版提供高并发数据实时写入和查询能力，适用于高性能应用；弹性 模式版本存储廉价按量计费，适用于 10TB 以上数据上云场景。

云原生数据仓库 AnalyticDB PostgreSQL 版，支持标准 SQL 2003，兼容 PostgreSQL / Greenplum, 高度兼容 Oracle 语法生态；具有存储计算分离，在线弹性平滑扩容的特点；既支持任意 维度在线分析探索，也支持高性能离线数据处理；是面向互联网，金融，证券，保险，银行，数字政务， 新零售等行业有竞争力的数据仓库方案。

云原生几个核心技术和未来发展趋势

1. 容器

容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境间快速、可靠地运行。

随后开源的 Kubernetes，凭借优秀的开放性、可扩展性以及活跃开发者社区，在容器编排之战中脱颖而出，成 为分布式资源调度和自动化运维的事实标准。Kubernetes 屏蔽了 IaaS 层基础架构的差异并凭借优良的可移植性， 帮助应用一致地运行在包括数据中心、云、边缘计算在内的不同环境。企业可以通过 Kubernetes，结合自身业务特 征来设计自身云架构，从而更好支持多云 / 混合云，免去被厂商锁定的顾虑。伴随着容器技术逐步标准化，进一步促进了容器生态的分工和协同。基于 Kubernetes，生态社区开始构建上层的业务抽象，比如服务网格 Istio、机器学 习平台 Kubeflow、无服务器应用框架 Knative 等。

Kubernetes 已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes 提 供了分布式应用管理的核心能力：

资源调度：根据应用请求的资源量 CPU、Memory，或者 GPU 等设备资源，在集群中选择合适的节点来运 行应用；

应用部署与管理：支持应用的自动发布与应用的回滚，以及与应用相关的配置的管理；也可以自动化存储卷 的编排，让存储卷与容器应用的生命周期相关联；

自动修复：Kubernetes 可以会监测这个集群中所有的宿主机，当宿主机或者 OS 出现故障，节点健康检查 会自动进行应用迁移；K8s 也支持应用的自愈，极大简化了运维管理的复杂性；

服务发现与负载均衡：通过 Service 资源出现各种应用服务，结合 DNS 和多种负载均衡机制，支持容器化 应用之间的相互通信；

弹性伸缩：K8s 可以监测业务上所承担的负载，如果这个业务本身的 CPU 利用率过高，或者响应时间过长， 它可以对这个业务进行自动扩容。

Kubernetes 的控制平面包含四个主要的组件：API Server、Controller、Scheduler 以及 etcd。如下图：

2. 微服务

微服务四代架构演进：

第一代

第一代微服务架构中，应用除了需要实现业务逻辑之外，还需要自行解决上下游寻址、通讯，以及容错等问题。随着微服务规模扩大，服务寻址逻辑的处理变得越来越复杂，哪怕是同一编程语言的另一个应用，上述微服务的基础能力都需要重新实现一遍。

第二代

第二代微服务架构中，引入了旁路服务注册中心作为协调者来完成服务的自动注册和发现。服务之间的通讯以及容错机制开始模块化，形成独立服务框架。但是随着服务框架内功能日益增多，用不同语言的基础功能复用显得十分困难，这也就意味着微服务的开发者被迫被绑定在某种特定语言上，从而违背了微服务的敏捷迭代原则。

第三代

2016 年出现了第三代微服务架构 - 服务网格，原来被模块化到服务框架里的微服务基础能力，被进一步的从一 个 SDK 演进成为一个独立进程 - Sidecar。这个变化使得第二代架构中多语言支持问题得以彻底解决，微服务基础 能力演进和业务逻辑迭代彻底解耦。这个架构就是在云原生时代的微服务架构 - Cloud Native Microservices，边车（Sidecar）进程开始接管微服务应用之间的流量，承载第二代中服务框架的功能，包括服务发现、调用容错，到丰富的服务治理功能，例如：权重路由、灰度路由、流量重放、服务伪装等。

第四代

近两年开始，随着 AWS Lambda 的出现，部分应用开始尝试利用 Serverless 来架构微服务，这种方式被称之为第四代微服务架构。在这个架构中，微服务进一步由一个应用简化为微逻辑（Micrologic），从而对边车模式提出了更高诉求，更多可复用的分布式能力从应用中剥离，被下沉到边车中，例如：状态管理、资源绑定、链路追踪、事务管理、安全等等。同时，在开发侧开始提倡面向 localhost 编程的理念，提供标准 API 屏蔽掉底层资源、服务、 基础设施的差异，进一步降低微服务开发难度。这个也就是目前业界提出的多运行时微服务架构（Muti-Runtime Microservices）。

OAM

2019 年末，阿里云联合微软共同发布了 Open Application Model (OAM) 开源项目，其主要目标是解决从 Kubernetes 项目到“以应用为中心”的平台之间最关键环节——标准化应用定义。

OAM 的第一个设计目标就是补充“应用”这一概念，建立对应用和它所需的运维能力定义与描述的标准 规范。换而言之，OAM 既是标准“应用定义”同时也是帮助封装、组织和管理 Kubernetes 中各种“运维能力”。

OAM 项目的第二个设计目标就是提供更高层级的应用层抽象和以应用关注点分离的定义模型。

相 比 于 传 统 PaaS 封 闭、 不 能 同“ 以 Operator 为 基 础 的 云 原 生 生 态” 衔 接 的 现 状， 基 于 OAM 和 Kubernetes 构建的现代云原生应用管理平台的本质是一个“以应用为中心”的 Kubernetes，保证应用平台能够无缝接入整个云原生生态。同时，OAM 进一步屏蔽掉容器基础设施的复杂性和差异性，为平台使用者带来低心智负担的、标准化的、一致化的应用管理与交付体验，让一个应用描述可以完全不加修改的在云、边、端等任何环境下直接交付运行起来。

无状态服务Serverless

当 BaaS 云服务日趋完善时，Serverless 因为屏蔽了服务器的各种运维复杂度，让开发人员可以将 更多精力用于业务逻辑设计与实现，而逐渐成为云原生主流技术之一。Serverless 计算包含以下特征：

全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施 的开发、运维、安全、高可用等工作；

通用性，结合云 BaaS API 的能力，能够支撑云上所有重要类型的应用；

自动的弹性伸缩，让用户无需为资源使用提前进行容量规划；

按量计费，让企业使用成本得有效降低，无需为闲置资源付费。

服务网格Service Mesh

Service Mesh 是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流 量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。这个解耦意味着开发者无需关注 微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。换句话说，因为大量非功能 性从业务进程剥离到另外进程中，Service Mesh 以无侵入的方式实现了应用轻量化。

Service Mesh的典型架构：

Service A 调用 Service B 的所有请求，都被其下的 Proxy（在 Envoy 中是 Sidecar） 截获， 代理 Service A 完成到 Service B 的服务发现、熔断、限流等策略，而这些策略的总控是在 Control Plane 上配置。

行业现状：Service Mesh 目前在市场仍处于早期采用 (Early adoption) 阶段。除 Istio 以外，Google 与 AWS 分别推出了各自的云服务 Traffic Director、 App Mesh。这两个 Service Mesh 产品与 Istio 虽有所不同，但与 Istio 同样地采纳了 Envoy 作为数据平面。此外，阿里云、腾讯云、华为云也 都推出了 Service Mesh 产品，同样采用 Envoy 技术作为数据面并在此基础上提供了应用发布、流量管控、APM 等能力。
DevOps

DevOps 就是为了提高软件研发效率，快速应对变化，持续交付价值的的一系列理念和实践，其基本思想就是 持续部署（CD)，让软件的构建、测试、发布能够更加快捷可靠，以尽量缩短系统变更从提交到最后安全部署到生产 系统的时间。要实现持续部署（CD)，就必须对业务进行端到端分析，把所有相关部门的操作统一考虑进行优化，利用所可用的技术和方法，用一种理念来整合资源。DevOps 理念从提出到现在，已经深刻影响了软件开发过程。DevOps 提倡打破开发、测试和运维之间的壁垒，利用技术手段实现各个软件开发环节的自动化甚至智能化，被证实对提高软件生产质量、安全，缩短软件发布周期等都有非常明显的促进作用，也推动了 IT 技术的发展。

DevOps四大原则：

文化（Culture）---要实施 DevOps，就首先要让开发和运维人员认识到他们的目标是一致的，只是工作岗位不同，需要共担责任。这就是 DevOps 需要首先在文化层面解 决的问题。只有解决了认知问题，才能打破不同团队之间的鸿沟，实现流程自动化，把大家的工作融合成一体。

自动化（Automation）---DevOps 的持续集成的目标就是小步快跑，快速迭代，频繁发布。实施 DevOps，首先就要分析已有的软件开发流程，尽量利用各种工具和平台，实现开发和发布过程的自动化。经过多年发展，业界已经有一套比较成熟的工具链可以参考和使用，不过具体落地还需因地制宜。

度量（Measurement）---通过数据可以对每个活动和流程进行度量和分析，找到工作中存在的瓶颈和漏洞以及对于危急情况的及时报警等。通过分析，可以对团队工作和系统进行调整，让效率改进形成闭环。度量首先要解决数据准确性、完整性和及时性问题，其次要建立正确的分析指标。DevOps 过程考核的标准应该鼓励团队更加注重工具的建设，自动化的加速和各个环节优化，这样才能最大可能发挥度量的作用。

共享（Sharing）--- 要实现真正的协作，还需要团队在知识层面达成一致。通过共享知识，让团队共同进步：可见度 visibility：让每个人可以了解团队其它人的工作。这样可以知道是否某一项工作会影响另一部分。通过相互反馈，让问题尽早暴露。透明性 transparency：让每个人都明白工作的共同目标，知道为什么要干什么。缺乏透明性就会导致工作安排失调。知识的传递 transfer of knowledge ：知识的传递是为了解决两个问题，一个是为了避免某个人成为单点，从而导致一个人的休假或离职，就导致工作不能完成。另一个是提高团队的集体能力，团队的集体能力要高于个人的能力。

云原生未来发展趋势

趋势一：无处不在的计算催生新一代容器实现

随着互联网的发展到万物智联，5G、AIoT 等新技术的涌现，随处可见的计算需求已经成为现实。针对不同计算场景，容器运行时会有不同需求。KataContainer、Firecracker、gVisor、Unikernel 等新的容器运行时技术层出不穷，分别解决安全隔离性、执行效率和通用性三个不同维度的要求。OCI（Open Container Initiative）标准的出现，使不同技术采用一致的方式进行容器生命周期管理，进一步促进了容器引擎技术的持续创新。其中，我们可以预见以下几个细分方向的未来趋势：

基于 MicroVM 的安全容器占比将逐渐增加，提供更强的安全隔离能力。虚拟化和容器技术的融合，已成为未来重要趋势。在公共云上，阿里云容器服务已经提供了对基于 KataContainer 的阿里云的袋鼠容器引擎支持，可以运行不可信的工作负载，实现安全的多租隔离。

基于软硬一体设计的机密计算容器开始展露头角。比如阿里云安全、系统软件、容器服务团队以及蚂蚁金服可信原生团队共同推出了面向机密计算场景的开源容器运行时技术栈 inclavare-containers ，支持基于 Intel SGX 机密计算技术的机密容器实现，如蚂蚁金服的 Occlum、开源社区的 Graphene 等 Libary OS。它极大降低了机密计算的技术门槛，简化了可信应用的开发、交付和管理。

WebAssembly作为新一代可移植、轻量化、应用虚拟机，在IoT，边缘计算，区块链等场景会有广泛的应用前景。WASM/WASI 将会成为一个跨平台容器实现技术。近期 Solo.io 推出的 WebAssembly Hub 就将 WASM 应用通过 OCI 镜像标准进行统一管理和分发，从而更好地应用在 Istio 服务网格生态中。

趋势二：云原生操作系统开始浮现

Kubernetes 已经成为云时代的操作系统。对比 Linux 与 Kubernetes 的概念模型，他们都是定义了开放的、 标准化的访问接口；向下封装资源，向上支撑应用。

服务网格的技术发展上数据平面与控制平面间的协议标准化是必然趋势。大体上，Service Mesh 的技术发展围 绕着“事实标准”去展开——共建各云厂商共同采纳的开源软件。从接口规范的角度：Istio 采纳了 Envoy 所实现的 xDS 协议，将该协议当作是数据平面和控制平面间的标准协议；Microsoft 提出了 Service Mesh Interface（SMI）， 致力于让数据平面和控制平面的标准化做更高层次的抽象，以期为 Istio、Linkerd 等 Service Mesh 解决方案在服务观测、流量控制等方面实现最大程度的开源能力复用。UDPA（Universal Data Plane API）是基于 xDS 协议而发展起来，以便根据不同云厂商的特定需求便捷地进行扩展并由 xDS 去承载。

服务注册发现和配置中心的功能主要致力于解决微服务在分布式场景下的服务发现和分布式配置管理两个核心 问题。随着云原生技术的发展，服务发现领域出现了两个趋势，一个是服务发现标准化（Istio），一个是服务下沉 (CoreDNS)；配置管理领域也有两个趋势，一个是标准化（ConfigMap），一个是安全 (Secret)。

趋势三：Serverless 容器技术逐渐成为市场主流

Serverless 和 容 器 技 术 也 开 始 融 合 得 到 了 快 速 的 发 展。通 过 Serverless 容 器， 一 方 面 根 本 性 解 决 Kubernetes 自身复杂性问题，让用户无需受困于 Kubernetes 集群容量规划、安全维护、故障诊断等运维工作；一方面进一步释放云计算能力，将安全、可用性、可伸缩性等需求下沉到基础设施实现。

趋势四：动态、混合、分布式的云环境将成为新常态

上云已是大势所趋，但对于企业客户而言，有些业务出于对数据主权、安全隐私的考量，会采用混合云架构。一些企业为了满足安全合规、成本优化、提升地域覆盖性和避免云厂商锁定等需求，会选择多个云厂商。混合云 / 多云 架构已成为企业上云新常态。Gartner 指出，" 到 2021，超过 75% 的大中型组织将采用多云或者混合 IT 战略。"

阿里云容器服务 ACK 去年 9 月份发布了混合云 2.0 架构，提供了完备的混合云 Kubernetes 管理能力。

零售云基于云原生体系建设和挑战

零售云是云原生应用实践的良好土壤

CTO 鲁肃提过：阿里经济体是云原生技术发展的最好土壤。而零售云是阿里经济体重要的一个分支，同时是阿里业务中台对外输出建设2B生态的重要战略方向，所以零售云无疑是云原生应用发展实践的极好土壤。当前，在这半年来实践和应用了云原生技术构建了产品-零售云研发运营平台（即云上星环）。

服务化能力：商业能力API，商业能力二次开发SDK
弹性能力：站点PaaS部署发布规划建设中
自动化水平：一键拉起环境，一键部署平台应用
可观测性：一键日志查询和监控运维

零售云基于云原生的技术架构：

零售云基于云原生技术体系之上的分层架构：

零售云DevOps实践

研发运营平台是零售云的重要的研发、监控和运维一体化平台，为零售云业务系统研发提供完整的 DevOps 解决方案。

零售云基于云原生的接下来规划和挑战

个人观点，我们需要基于阿里巴巴云原生架构设计方法论：

一、组织视角

组织上需要从技术、业务和产品体系建设规划好阵型，进行很好的排兵布阵，需要更多的各领域的优秀人才加入建设，建议组织上重点需要内部各领域专有人才定向培养，内部同学有可持续发展通道才能留住人才、用好人才，用人做事在零售云组织体系上尤其重要，而不是做事用人，否则项目就会把整个组织拖垮。

二、企业和业务视角

从 ISV 和客户视角去看零售云该怎么构建产品和快速交付，而云原生技术体系将可以帮助快速构建 2B 生态的产品和技术体系。云原生技术体系基本可以使用阿里云的云产品和技术基础实施，面对不能满足的场景需要考虑自建还是共建方式，我的理解是零售云是业务和产品为导向的， 2B 交付有很多个性化的诉求，阿里云的云原生体系更多的是从通用角度考虑，对于个性化和差异化需求，零售云需要进行补充和扩展云原生技术/产品体系建设，诸如商业能力客户侧部署发布不能依赖阿里云云效，服务 SLA 的标准差异化等。

三、云原生技术架构视角

零售云当前已经基于阿里云 Kubernetes(ACK) 构建了零售云中台飞鹤版本，零售云中台基线版本在建设中。面向明年20家客户交付，后年 100 家客户交付，我们需要构建通用的技术底座和产品基线，以通用的技术底座和产品基线进行快速复制分支交付和版本管理，满足独立部署交付和 SaaS 交付两种模式。当前构建独立部署交付模式，务必需要考虑 SaaS 交付的产品和技术体系，在适当时机需要开始 PaaS 平台的建设。

容器我们需要坚定的使用 Kubernetes（ACK），结合零售行业的特性，Serverless 不是强需求， ASK 短期可以不用。容器建设上需要考虑多租户容器逻辑和物理隔离，多租户容器运行时管理等。

微服务结合零售云现状，我们采用了 Dubbo 框架，建议可以走向微服务第三代架构，加强 SideCar 的规划和建设，诸如多租户数据隔离、权重路由、灰度路由、流量重放、服务伪装、流量打标、流量调度、计量管理、计费管理都将是需要重点建设方向，可以架构设计上保证可扩展能力建设，这些能力根据我们前方项目打仗来适度调整优先级。

OAM 方面可以结合阿里云的进展情况以及零售云近三年项目交付的场景来看是否需要引入，我们的技术架构是可以支持可扩展这些基础能力的。

服务网格 ServiceMesh 跟微服务架构联系起来，即 SideCar 的规划和建设(需要看看阿里云的 SideCar 是否满足零售云需求），lstio 可以解决开发人员和运维人员所面临的从单体应用向分布式微服务架构转变的挑战，部署交付是一个难点和挑战，Istio 为可扩展性而设计，可以满足不同的部署需求。

DevOps 是我们建设的一个重点，研发平台、产品中心、支撑平台（SideCar可以放在这里建设）和站点 PaaS ，以及通用的 PaaS 交付平台建设在中长期的意义非常关键，这个产品体系当前还是初步规划阶段，还需要验证和实践，建议需要更全面和更深度的探索后进一步完善我们的产品体系，避免产品的重复和来回废弃折腾建设。商业能力是零售云对外交付的输出产物，商业能力建设和商业能力研发平台建设是重心。当零售云中台的开发和版本演进变成一个常规化的easy事，商业能力对外交付变成快速可持续迭代的状态，那么我们的产品建设就初成形态了。

低代码开发也是一个重要方向，期望能够低成本交付以及客户低成本开发运维，低代码开发是非常关键，类似 Salesforce 的 Ligthnig 产品的建设，我们需要从多维度去建设，客户基于商业能力二次开发需要低代码开发， Maybe 基于元数据驱动建设零售云产品体系是好的选择，这个方向需要探索和结合场景实践，低代码开发需要根据场景选择产品，有些场景适合使用纪元，有些场景适合使用 Astore ，有些场景适合使用类似斑马产品，有些场景适合使用宜搭 Pro/ 宜搭，我们需要有一个底座，需要和云原生的技术体系结合，然后更好更多的整合产品进来形成一个场景系列解决方案。低代码开发的思考，我将在另外一篇文章中进行总结和思考。

 

原文链接
本文为阿里云原创内容，未经允许不得转载。