云原生时代下的12要素

简介: 现在各大企业都开始上云,上云有很多好处,其中之一就是有助于数字化转型。企业一旦上云,能大大提升数据搜集能力,计算能力调度及业务应用的整体能力,企业可以更容易的基于云化架构去做更多的场景落地。但上云并不意味着是真正的云原生(Cloud Native)。怎样才是真正的云原生呢?本文主要通过介绍云原生时代下应用需要遵循的12要素加以说明。

在学习K8S的时候,提到了一个概念,云原生,什么是云原生呢?英文介绍如下:

  1. Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments, such as public, private and hybrid clouds.
  2. Containers, service meshes, microservices, immutable infrastructure, and declarative API exemplify this approach.
  3. These techniques enable loosely coupled systems that are resilient manageable ,and observable.
  4. Combined with robust automation, they allow engineers to make high impact changes frequently and predictably with minimal toil.

  上面一大堆英文,提到了应用在云上的弹性伸缩,有助于实现云原生的方法,便于管理监控和观察,自动化部署。看着是不是稍微有点晕?下面使用中文介绍针对云原生应用开发的最佳实践原则,12-Factor。
  12-Factor 全称叫 TheTwelve-Factor App,由Heroku创始人AdamWiggins首次提出并开源。它定义了一个优雅的互联网应用在设计过程中,需要遵循的一些基本原则。

1.基准代码:一份基准代码(Codebase),多份部署(deploy)。
  基准代码和应用之间总是保持一一对应的关系,一份代码可以部署在开发环境、测试环境、预发环境及产线环境。
  多个应用共享一份基准代码是有悖于12-Factor原则的。解决方案如下:
 将共享的代码拆分为独立的类库,然后使用依赖管理策略去加载它们。所有部署的基准代码相同,但每份部署可以使用其不同的版本。比如,开发人员可能有一些提交还没有同步至预发布环境;预发布环境也有一些提交没有同步至生产环境。但它们都共享一份基准代码,我们就认为它们只是相同应用的不同部署而已。

2.依赖——显式声明依赖关系(dependency)
 12-Factor规则下的应用程序不会隐式依赖系统级的类库。它一定通过依赖清单,确切地声明所有依赖项。大多数编程语言都会提供一个打包系统,比如java使用maven,应用依赖了哪些第三方库,要显示地定义在POM文件里。

3.配置:在环境中存储配置
 配置要和代码完全分离,环境变量可以非常方便地在不同的部署间做修改,却不动一行代码。
 配置主要包括数据库信息,缓存信息,第三方服务证书,每份部署特有的配置,如域名等信息。
 判断一个应用是否正确地将配置排除在代码之外,一个简单的方法,看该应用的基准代码是否可以立刻开源,而不用担心会暴露任何敏感的信息。

4.后端服务:把后端服务当作附加资源(backing services)
 后端服务是指程序运行所需要的通过网络调用的各种服务,如数据库,消息系统及缓存系统。
 12-Factor应用的任意部署,都应该可以在不进行任何代码改动的情况下,进行后端服务的切换,比如将本地MySQL数据库换成第三方服务(例如阿里云的 RDS)。另外,部署可以按需加载或卸载资源。例如,如果应用的数据库服务由于硬件问题出现异常,管理员可以从最近的备份中恢复一个数据库,卸载当前的数据库,然后加载新的数据库 。整个过程都不需要修改代码。

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.管理进程:后台管理任务当作一次性进程运行
 一次性管理进程主要指一些管理或维护应用的一次性任务,比如,运行数据迁移,运行一些提交到代码仓库的一次性脚本等。它们应该和正常的常驻进程使用同样的环境。这些管理进程和任何其他的进程一样使用相同的代码和配置,基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布,从而避免同步问题。
 以上了解了12-Factor应用原则。在学习K8S的过程中,个人认为K8S结合service mesh很好的满足了上面的每条原则。设计K8S和service mesh的人很伟大,提出12原则的AdamWiggins很伟大。

参考文档:
https://blog.csdn.net/weiwoyonzhe/article/details/88611362
https://blog.csdn.net/wufaliang003/article/details/79533345

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
机器学习/深度学习 自然语言处理 Cloud Native
探索在云原生环境中构建的大数据驱动的智能应用程序的成功案例,并分析它们的关键要素。
大数据索引: Google使用大数据索引来构建其搜索引擎,并实时处理全球各种语言的文本数据。 云原生基础设施: Google Cloud提供了强大的云原生基础设施,支持大规模数据存储和处理。 自然语言处理: Google使用自然语言处理技术来理解和索引文本数据,从而提供高质量的搜索结果。 实时搜索: Google的
270 0
|
运维 监控 Cloud Native
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 6:全链路技术风险防控
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 6:全链路技术风险防控
253 0
|
设计模式 开发框架 运维
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 1:平台工程 & 不可变基础设施
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 1:平台工程 & 不可变基础设施
399 0
|
弹性计算 Cloud Native 双11
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 2:弹性混合云
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 2:弹性混合云
753 0
|
资源调度 运维 监控
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 3:资源混合部署
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 3:资源混合部署
128 0
|
负载均衡 监控 Cloud Native
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 4:多技术栈异构集成
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 4:多技术栈异构集成
141 0
|
机器学习/深度学习 编解码 供应链
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 5:基础架构连续性(公专一体)
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 5:基础架构连续性(公专一体)
140 0
|
Cloud Native 安全 数据安全/隐私保护
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 7:云原生安全可信
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 7:云原生安全可信
124 0
|
消息中间件 缓存 Cloud Native
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 8:金融级一致性
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 8:金融级一致性
195 0
|
运维 Cloud Native 容灾
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 9:单元化多地多活
《生来创新-金融级云原生》——2 金融级云原生的“新标准和新蓝图”——2.2 定义金融云原生的10大新要素——要素 9:单元化多地多活
239 0