云原生12 原则和云原生15原则 The Tweleve-Factor App and Beyond the 12 factor App
文章目录
- 云原生12 原则和云原生15原则 The Twelve-Factor App and 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）
- 小结
云原生12 原则和云原生15原则 The Twelve-Factor App and Beyond the 12 factor App
前言
什么是云原生应用（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）
Heroku版本：一份基准代码，多份部署
理解：
-
代码要进行版本管理；
-
最好的版本管理工具是Git；
-
一份基准代码可以是一个代码仓库（code repository），也可以一组代码仓库（code repository group)；
工具：Git代码托管工具，比如GitLab、GitHub等。
2. API优先（API First）
Heroku版本：无
理解：
- 基于API来在系统的不同层次进行解耦；
- 前后端分离，前后端通过API来交互，通常是基于HTTP(S) 的REST API，数据格式一般为JSON；
- 系统的服务之间也通过API来交互，通常是基于TCP的RPC调用；
- 服务内部不同层级也通过API来交互，通常是代码级别的方法或函数调用；
工具：API测试工具（Postman，SwaggerUI等）、API性能测试工具（JMeter等）、API文档管理（Yapi等）。
3. 依赖管理（Dependency Management)
Heroku版本：显式声明依赖关系
理解：
- 一个构建好的二进制程序包应该包含它所需要的全部依赖，可以独立运行，比如一个包含了全部依赖的Spring Boot的all-in-one的可独立运行的jar包，又比如一个包含了全部依赖可独立运行的Docker镜像；
- 使用依赖管理工具和制品仓库；
- 显式声明依赖的版本，不使用缺省版本号；
- 注意循环依赖问题。
工具：依赖管理工具，比如Maven、Gradle、npm；制品仓库，比如Nexus、Harbor。
4. 设计、构建、发布和运行（Design, Build, Release, Run）
Heroku版本：严格分离构建和运行
理解：
- 采用持续集成（CI）和持续交付（CD）实践；
- 采用CI/CD Pipeline来自动化构建、自动化测试和自动化部署；
工具：CI Server：Jenkins、GitLab-CI、Drone等；自动化部署：Ansible等；
5. 配置、凭证和代码（Configuration, Credentials and Code）
Heroku版本：在环境中存储配置
理解：
-
代码和配置分离；
-
在不同环境使用不同的配置；
-
妥善保管凭证信息，不允许将凭证信息保存到代码中；
-
使用服务配置中心来管理配置。
工具：服务配置中心，比如Etcd、Nacos、Appolo等；
6. 日志（Logs）
Heroku版本：把日志当作事件流
理解：
- 日志直接输出到标准输出（stdout或stderr），而不是写入到日志文件；
- 由统一的日志采集系统来存储、分析和处理日志；
工具：ELK或EFK。
7. 易处理（Disposability)
Heroku版本：快速启动和优雅终止可最大化健壮性
理解：
- 服务需要可以被快速启动和快速终止；
- 这就要求服务要足够小，启动过程要足够简单；
- 把服务打包成一个独立的单元（比如容器）来部署。
工具：容器技术，比如Spring Boot自带了Web容器，Docker容器等。
8. 后端服务（Backing Services）
Heroku版本：把后端服务当作附加资源
理解：
- 把后端用到的中间件和资源都当成服务，而不是实体，比如：
- 数据库服务：可能是MySQL数据库服务实例，或者其它关系型数据库服务实例
- 缓存服务：可能是Redis服务实例；
- 消息队列服务：可能是Kafka服务实例；
- 对象存储服务：可能是阿里云的OSS对象存储，也可能是AWS的S3；
- 邮件服务：可能是Mailgun的SMTP服务；
- 认证授权服务：可能是第三方的OAuth认证授权服务；
9. 环境一致性（Environment Parity)
Heroku版本：尽可能的保持开发，预发布，线上环境相同
理解：
- 保持开发、测试、预发布和生产环境的部署架构、程序版本和时钟一致；
- 基础设施即代码（Infrastructure as Code）
工具：虚拟化管理平台，比如VMSphere；基础架构管理工具，比如Terraform。
10. 管理进程（Adminstrative Process）
Heroku版本：后台管理任务当作一次性进程运行
理解：
- 区分一次性任务和常规任务；
- 常规任务可以作成定时任务。
工具：任务调度工具，比如xxl-jobs，Spring Quartz。
11. 端口绑定（Port Binding）
Heroku版本：通过端口绑定提供服务
理解：
- 服务启动时动态绑定随机端口，不写死服务的端口；
- 通过动态路由来实现服务寻址。
工具：微服务的服务注册中心、Kubernetes的服务路由。
12. 无状态进程（Stateless Processes)
Heroku版本：以一个或多个无状态进程运行应用
理解：
- 服务本身是无状态的，但是应用是有状态的；
- 应用的状态存储在文件存储服务、数据库存储服务、缓存服务和消息队列服务中；
- 无状态服务易于横向扩展。
13. 并发（Concurrency)
Heroku版本：通过进程模型进行扩展。
理解：
- 横向扩展（简单地增加服务实例和计算节点）就可以提升系统的并发处理能力。
14. 遥测（Telemetry)
Heroku版本：无
理解：
- 容器云和服务的监控和告警；
- 服务健康检查（探针）；
- 服务调用链路跟踪；
- 服务故障隔离（熔断）、服务降级（限流）和故障自动恢复。
工具：监控，比如Prometheus、Grafana；微服务框架提供的服务熔断、限流和链路跟踪工具。
15. 认证和鉴权（Authentication and Authorization）
Heroku版本：无
理解：
- 系统的认证和鉴权；
- 保证系统安全性，防止未授权访问，防止水平越权；
- RBAC权限控制模型。
工具：OAuth2，OpenID，SSO（单点登录）；Java生态中的Spring Security、Shiro。
参见：
小结
本文结合云原生12原则和云原生15原则，浅谈了对构建云原生应用的理解，包括对应的工具，以供参考。
本文地址：https://blog.csdn.net/nklinsirui/article/details/107358079