谈谈我对零售云在云原生总结与思考

零售云是阿里三朵业务云：零售云、金融云和政务云之一，将开辟阿里在电商、零售行业的新蓝海，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」 代表架构设计的关键视角ÿ