云原生12 要素和云原生15要素

Posted 2021-04-03 乒乓咨询

前言

什么是云原生应用（Cloud Native Application）？云原生应用不只是将应用打包成Docker镜像，然后部署到到Kubernetes容器云上运行。

作为云计算领导者，Heroku整理了著名的云原生12要素（The Twelve-Factor App)。

之后，同样作为云计算领导者，Pivotal (已被VMWare收购）重新整理了Beyond the 12 factor App。

本文对照Beyond the 12 factor App 来浅谈一下我对云原生应用的个人主观理解，以及如何更好地构建云原生应用。

• Beyond the 12 factor App （云原生15要素）

• 1. 一份基准代码，一个应用（One Codebase, One Application）

• 2. API优先（API First）

• 3. 依赖管理（Dependency Management)

• 4. 设计、构建、发布和运行（Design, Build, Release, Run）

• 5. 配置、凭证和代码（Configuration, Credentials and Code）

• 6. 日志（Logs）

• 7. 易处理（Disposability)

• 8. 后端服务（Backing Services）

• 9. 环境一致性（Environment Parity)

• 10. 管理进程（Adminstrative Process）

• 11. 端口绑定（Port Binding）

• 12. 无状态进程（Stateless Processes)

• 13. 并发（Concurrency)

• 14. 遥测（Telemetry)

• 15. 认证和鉴权（Authentication and Authorization）

  
  

Beyond the 12 factor App （云原生15要素）

1. 一份基准代码，一个应用（One Codebase, One Application）

Heroku版本：一份基准代码，多份部署

理解：

1. 代码要进行版本管理；

2. 最好的版本管理工具是Git；

3. 一份基准代码可以是一个代码仓库（code repository），也可以一组代码仓库（code repository group)；

工具：Git代码托管工具，比如GitLab、GitHub等。

2. API优先（API First）

Heroku版本：无

理解：

1. 基于API来在系统的不同层次进行解耦；
2. 前后端分离，前后端通过API来交互，通常是基于HTTP(S) 的REST API，数据格式一般为JSON；
3. 系统的服务之间也通过API来交互，通常是基于TCP的RPC调用；
4. 服务内部不同层级也通过API来交互，通常是代码级别的方法或函数调用；

工具：API测试工具（Postman，SwaggerUI等）、API性能测试工具（JMeter等）、API文档管理（Yapi等）。

3. 依赖管理（Dependency Management)

Heroku版本：显式声明依赖关系

理解：

1. 一个构建好的二进制程序包应该包含它所需要的全部依赖，可以独立运行，比如一个包含了全部依赖的Spring Boot的all-in-one的可独立运行的jar包，又比如一个包含了全部依赖可独立运行的Docker镜像；
2. 使用依赖管理工具和制品仓库；
3. 显式声明依赖的版本，不使用缺省版本号；
4. 注意循环依赖问题。

工具：依赖管理工具，比如Maven、Gradle、npm；制品仓库，比如Nexus、Harbor。

微服务间依赖原则：

1. 按用途从上到下将服务划分为组合服务、业务服务和基础服务，上层服务可以依赖下层服务，下层服务不可以依赖上层服务；

2. 组合服务和业务服务都可以对外提供服务，基础服务不能对外提供服务；

3. 业务服务之间可以相互依赖，但是不能存在“循环依赖”（A依赖于B，B又依赖于A），出现“循环依赖”时由组合服务进行服务组合（组合服务C依赖于服务A，同时C还依赖于B）。

4. 设计、构建、发布和运行（Design, Build, Release, Run）

Heroku版本：严格分离构建和运行

理解：

1. 采用持续集成（CI）和持续交付（CD）实践；
2. 采用CI/CD Pipeline来自动化构建、自动化测试和自动化部署；

工具：CI Server：Jenkins、GitLab-CI、Drone等；自动化部署：Ansible等；

5. 配置、凭证和代码（Configuration, Credentials and Code）

Heroku版本：在环境中存储配置

理解：

1. 代码和配置分离；

2. 在不同环境使用不同的配置；

3. 妥善保管凭证信息，不允许将凭证信息保存到代码中；

4. 使用服务配置中心来管理配置。

工具：服务配置中心，比如Etcd、Nacos、Appolo等；

6. 日志（Logs）

Heroku版本：把日志当作事件流

理解：

1. 日志直接输出到标准输出（stdout或stderr），而不是写入到日志文件；
2. 由统一的日志采集系统来存储、分析和处理日志；

工具：ELK或EFK。

7. 易处理（Disposability)

Heroku版本：快速启动和优雅终止可最大化健壮性

理解：

1. 服务需要可以被快速启动和快速终止；
2. 这就要求服务要足够小，启动过程要足够简单；
3. 把服务打包成一个独立的单元（比如容器）来部署。

工具：容器技术，比如Spring Boot自带了Web容器，Docker容器等。

8. 后端服务（Backing Services）

Heroku版本：把后端服务当作附加资源

理解：

1. 把后端用到的中间件和资源都当成服务，而不是实体，比如：
• 数据库服务：可能是mysql数据库服务实例，或者其它关系型数据库服务实例
• 缓存服务：可能是Redis服务实例；
• 消息队列服务：可能是Kafka服务实例；
• 对象存储服务：可能是阿里云的OSS对象存储，也可能是AWS的S3；
• 邮件服务：可能是Mailgun的SMTP服务；
• 认证授权服务：可能是第三方的OAuth认证授权服务；

9. 环境一致性（Environment Parity)

Heroku版本：尽可能的保持开发，预发布，线上环境相同

理解：

1. 保持开发、测试、预发布和生产环境的部署架构、程序版本和时钟一致；
2. 基础设施即代码（Infrastructure as Code）

工具：虚拟化管理平台，比如VMSphere；基础架构管理工具，比如Terraform。

10. 管理进程（Adminstrative Process）

Heroku版本：后台管理任务当作一次性进程运行

理解：

1. 区分一次性任务和常规任务；
2. 常规任务可以作成定时任务。

工具：任务调度工具，比如xxl-jobs，Spring Quartz。

11. 端口绑定（Port Binding）

Heroku版本：通过端口绑定提供服务

理解：

1. 服务启动时动态绑定随机端口，不写死服务的端口；
2. 通过动态路由来实现服务寻址。

工具：微服务的服务注册中心、Kubernetes的服务路由。

12. 无状态进程（Stateless Processes)

Heroku版本：以一个或多个无状态进程运行应用

理解：

1. 服务本身是无状态的，但是应用是有状态的；
2. 应用的状态存储在文件存储服务、数据库存储服务、缓存服务和消息队列服务中；
3. 无状态服务易于横向扩展。

13. 并发（Concurrency)

Heroku版本：通过进程模型进行扩展。

理解：

1. 横向扩展（简单地增加服务实例和计算节点）就可以提升系统的并发处理能力。

14. 遥测（Telemetry)

Heroku版本：无

理解：

1. 容器云和服务的监控和告警；
2. 服务健康检查（探针）；
3. 服务调用链路跟踪；
4. 服务故障隔离（熔断）、服务降级（限流）和故障自动恢复。

工具：监控，比如Prometheus、Grafana；微服务框架提供的服务熔断、限流和链路跟踪工具。

15. 认证和鉴权（Authentication and Authorization）

Heroku版本：无

理解：

1. 系统的认证和鉴权；
2. 保证系统安全性，防止未授权访问，防止水平越权；
3. RBAC权限控制模型。

工具：OAuth2，OpenID，SSO（单点登录）；Java生态中的Spring Security、Shiro。

参见：

• Cookies vs. Tokens: The Definitive Guide
• jwt.io

小结

本文结合云原生12要素和云原生15要素，浅谈了对构建云原生应用的理解，包括对应的工具，以供参考。