当前位置： 移动技术网 > IT编程>数据库>Redis > 云原生12 原则和云原生15原则 The Tweleve-Factor App and Beyond the 12 factor App

云原生12 原则和云原生15原则 The Tweleve-Factor App and Beyond the 12 factor App

2020年07月17日  | 移动技术网IT编程  | 我要评论

文章目录

云原生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版本：一份基准代码，多份部署

理解：

  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。

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。

参见：

小结

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

本文地址：https://blog.csdn.net/nklinsirui/article/details/107358079

您可能感兴趣的文章:

如对本文有疑问， 点击进行留言回复！！

相关文章:

验证码：
最近更新的文章
大家感兴趣的文章
移动技术网