免费注册


云原生时代下应用需要遵循的12要素

2020-12-29 人浏览

  云原生时代下应用需要遵循的12要素:
  
  1.基准代码:一份基准代码(Codebase),多份部署(deploy)。
  
  基准代码和应用之间总是保持一一对应的关系,一份代码可以部署在开发环境、测试环境、预发环境及产线环境。
  
  多个应用共享一份基准代码是有悖于12-Factor原则的。解决方案如下:
  
  将共享的代码拆分为独立的类库,然后使用依赖管理策略去加载它们。所有部署的基准代码相同,但每份部署可以使用其不同的版本。比如,开发人员可能有一些提交还没有同步至预发布环境;预发布环境也有一些提交没有同步至生产环境。但它们都共享一份基准代码,我们就认为它们只是相同应用的不同部署而已。
  
  2.依赖——显式声明依赖关系(dependency)
  
  12-Factor规则下的应用程序不会隐式依赖系统级的类库。它一定通过依赖清单,确切地声明所有依赖项。大多数编程语言都会提供一个打包系统,比如java使用maven,应用依赖了哪些第三方库,要显示地定义在POM文件里。
  
  3.配置:在环境中存储配置
  
  配置要和代码完全分离,环境变量可以非常方便地在不同的部署间做修改,却不动一行代码。
  
  配置主要包括数据库信息,缓存信息,第三方服务证书,每份部署特有的配置,如域名等信息。
  
  判断一个应用是否正确地将配置排除在代码之外,一个简单的方法,看该应用的基准代码是否可以立刻开源,而不用担心会暴露任何敏感的信息。

云原生


  
  4.后端服务:把后端服务当作附加资源(backing services)
  
  后端服务是指程序运行所需要的通过网络调用的各种服务,如数据库,消息系统及缓存系统。
  
  12-Factor应用的任意部署,都应该可以在不进行任何代码改动的情况下,进行后端服务的切换,比如将本地MySQL数据库换成第三方服务。另外,部署可以按需加载或卸载资源。例如,如果应用的数据库服务由于硬件问题出现异常,管理员可以从最近的备份中恢复一个数据库,卸载当前的数据库,然后加载新的数据库 。整个过程都不需要修改代码。
  
  5.构建->发布->运行:严格分离构建和运行
  
  基准代码 转化为一份部署(非开发环境)需要以下三个阶段:
  
  (1)构建阶段,将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码,获取和打包依赖项,编译成二进制文件和资源文件。
  
  (2)发布阶段,将构建的结果和当前部署所需配置相结合,并能够立刻在运行环境中投入使用。
  
  (3)运行阶段(“运行时”),针对选定的发布版本,在执行环境中启动一系列应用程序进程。
  
  每一个发布版本必须对应一个唯一的发布 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.管理进程:后台管理任务当作一次性进程运行
  
  一次性管理进程主要指一些管理或维护应用的一次性任务,比如,运行数据迁移,运行一些提交到代码仓库的一次性脚本等。它们应该和正常的常驻进程使用同样的环境。这些管理进程和任何其他的进程一样使用相同的代码和配置,基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布,从而避免同步问题。
  
  责任编辑:浪潮云原生,原创不易,转载是必须以链接形式注明作者和原始出处及本声明

上一篇: 云原生已成为新的技术浪潮
下一篇: 为什么软件最终都会变得很复杂?

相关文章