12要素原则是一种构建可扩展、高性能、高健壮性应用的方法论或原则。12要素原则天然地适用于微服务,并且随着微服务的发展,这些原则也变得越来越流行。前文 (构建云原生应用的十二要素原则上)已经介绍前六条要素,本文接着介绍剩下的6个要素。
端口绑定:通过端口绑定提供服务
12要素应用是完整的自包含的应用,如一个Web应用不需要在运行环境中注入Web服务器而直接可以运行。Web应用通过绑定端口对外提供HTTP协议的服务,并且监听该端口获取从外部来的请求。
简单地说,应用应该是完整运行的实体,而不需要将他们部署在运行着Web服务器的环境中就可以运行。
微服务的情况下,SpringBoot应用就是一个例子。SpringBoot默认包含切入的tomat、jetty或undertow服务器。
并发:通过无状态进程进行水平扩展
考虑到扩展性,12要素原则建议放弃传统地运行一个单一系统的方式,把应用分割为多个进程/实例来运行。各进程中仍然可以使用线程来改进对请求处理的并发性。
本质上,12要素原则主张使用水平扩展的方式对应用进行扩展,而非传统的垂直扩展。
微服务的情况下,通过微服务容器化,应用可以实现按需水平扩展。
易处置性:通过快速启动和优雅关闭来最大化健壮性
12要素应用的进程应该可以随时被启动和停止。当进程被启动或停止时,不应当影响应用的状态。
进程在结束时系统需要确保处于正确的状态,因此进程应当考虑优雅停止的设计。
当进程增加或者减少时,系统状态不应当受影响。
由于种种原因,系统可能会异常终止。系统应当确保这种情况发生时,其影响最小,并且系统的有效状态应该被保存。
微服务的情况下,通过使用容器来封装微服务,应用在最大程度上遵守易处置性原则。Docker容器可以被快速启动或关闭。通过把请求、状态、会话数据保存在队列或后端服务中,可以确保即使应用容器意外终止的情况下,请求还可以被无缝地处理。
环境等价: 尽可能地保持开发、测试及生产环境的一致性
12要素原则建议尽可能地减少开发与生产环境的差异,从而避免由于特定环境原因产生的Bug。
开发人员应当尽量避免开发环境与生产环境中使用不同的后端服务。
微服务的情况下,采用容器化封装,原生地保持了开发与生产环境的一致性。
日志:把日志作为事件流处理
日志对于在生产环境中调查问题或理解用户行为等方面至关重要。日志为运行中的应用提供了可见性。
12要素应用原则强调日志产生与日志处理分离。应用中在被写为标准输出,执行环境负责日志的收集、存储、整理与归档。
微服务架构中,可观测性是基本要求。它可以通过APM工具(如ELK、Newrelic等)或日志汇聚工具(如Splunk等)来实现。
使用本原则后,在调查问题时只需要到你的工具看板去搜索相关的内容。
管理进程:后台管理进程也作为一次性进程来运行
在应用部署的过程的过程中,有一些一次性的进程需要执行,如数据迁移、特定环境初始化等。12要素原则建议将这些管理性任务作为应用代码的一部分保存在代码库中。这样做,可以让后台管理进程也遵循与代码相同的流程与原则。
确保这些一次性脚本的执行是自动化的,从而我们不必担心在发布之前它有没有被执行。
12要素原则也建议使用执行环境中的内嵌工具在生产环境的服务器上运行这些脚本。
微服务的情况下,容器化机制可以利用任务来运行这些一次性脚本,并且在运行完一次后自动关闭。
通过遵循上述的12原则,相信我们可以构建出可扩展可移植自动部署与运行的云原生应用。