数字化企业云平台的Cloud Native12原则

转载本文需注明出处：EAII企业架构创新研究院（微信号：eaworld），违者必究。如需加入云计算架构设计群或联系作者交流请添加微信号：elaineyuan928。

Uber、滴滴、小米、红领、Airbnb等软件服务给我们日常生活带来革命性的颠覆，互联网给我们带来生活极大的便利。未来会有更多的传统企业以互联网思维模式进行业务创新，在实现自身数字化转型的同时，为我们带来更优的生活体验。所有的这一切需要强大的IT能力支撑，需要企业IT的精益运营，让软件的生产、交付、获取、升级、遥测是简单的。

在以云计算、容器技术（以Docker为代表）、微服务架构、DevOps等相关概念和实施的成熟发展，支撑企业IT敏捷、快速、协作的交付应用成为可能，在软件行业同样需要软件交付的自动化生产线，交付出个性化、可定制的软件。

最近有幸参加公司新一代云平台的研发（数字化企业云平台The Platform）工作，深度体验到新的技术变革带来的软件交付变革的便捷性。通过企业云平台能够支撑秒级服务无缝切换、分钟级的应用交付（从代码到交付出一套可访问环境）。对于企业云平台，在版本研发中同样采用了微服务架构、容器、DevOps生产线的技术支撑能力，20分钟（后续小伙伴已经有了优化，提升到12分钟内可以搞定）时间内可以从源代码，经历编译、打包、配置、部署、启动等系列操作交付出两套可访问环境，一套部署在公有云上，一套部署在公司内部私有云。

目前整个平台有十六大领域系统（参加下图红色部分）支撑，部署节点30余个，开发环境、测试环境、预发环境在私有云上发布；生产环境在阿里云（仅使用阿里云上的虚拟机）上交付。

数字化企业云平台支撑云原生应用的快速交付，同时在平台自身建设过程中（所有的微服务建设过程中）严格遵守了12-Factor原则（HeroKu提出的12原则，原文可以访问：http://12factor.net/zh_cn/），12-Factor原则提供了未来云原生应用建设的方法论，是开发Cloud
Native App的理想实践标准，并特别关注于应用程序如何保持良性成长，开发者之间如何进行有效的代码协作，避免软件污染，无缝交付云上云下。

正确的理解12-Factory原则非常关键：我们的理解是，12-Factor本质是站在运维的角度，给开发提出的要求，未来更多的应该由平台提供12-Factor能力支撑，让工程师更关注在业务应用的交付；把复杂的、重复的、无价值的事情交给DevOps+平台来做，彻底让软件工程师从码农变为知识创造者。

平台建设过程中我们对12-Factor了大量落地工作，在此分享给大家，如有更好的落地实践也欢迎讨论。本次会和大家分享12要素宣言的前6个原则，后续为大家分享后6个原则。

原则一：基准代码（一份基准代码，多分部署）

    我们的实践：

          1、每个微服务对应一个Git库

          2、每个发布版本为一个Codebase（发布后会对该发布版本的代码打一个Release Branch）

          3、使用TBD（Trunk Based Development）版本管理模式 （TBD是基于主干的开发模式，详细可以参见“宋会计”的博客：http://blog.csdn.net/xn_sung/article/details/51427075，更多版本开发模式可以参考：http://www.alwaysagileconsulting.com/articles/version-control-strategies/）

          4、模块间不允许代码依赖（必须依赖三方库、或者二方库）

原则二：依赖（显式声明依赖关系）

    我们的实践：

          1、所有依赖必须显式声明

          2、微服务之间的依赖（Rest API）纳入依赖管理

          3、反模式：禁止使用反射依赖注入

          4、Native Lib的依赖需要纳入管理（不仅开发期的依赖需要严格管理，对于运行期依赖的服务组件需要打包在一个可执行的环境中）

原则三：配置（在环境中存储配置）

     我们的实践：

          1、配置针对环境的配置，即“环境配置”，不涉及业务配置

          2、环境配置与代码严格分离

          3、环境配置不能做热更新（遵循“不可变基础设施”原则），如要变更只能重新部署（谁让微服务现在能秒级交付那）

          4、环境配置项要细化到最小粒度，不要做“套餐”模式的配置

          5、配置与部署环境关联（提供不同环境的部署包、在编译打包后通过注入的方式形成不同环境的可部署包）

原则四：后端服务（把后端服务当做附加资源）

     我们的实践：

          1、不要在应用内部嵌入后端资源（如自带嵌入式数据库）

          2、留出扩展点以方便后端资源的快速更换

          3、在技术和成本允许的情况下尽量使用云服务能力，并通过留出扩展点以降低耦合

原则五：构建、发布、运行（严格分离构建和运行）

     我们的实践：

          1、构建、发布、运行三个阶段要严格分离

          2、不要直接更改运行环境（如直接对运行环境中的应用打补丁、直接修改运行环境中的配置文件操作，需要严格禁止）

          3、编译产物、配置和运行环境（镜像）需要纳入版本管理

          4、建立发布失败后的回退机制

原则六：进程（以一个或多个无状态进程运行应用）

     我们的实践：

          1、应用容器内不允许保存状态数据（所有微服务均是无状态的，便于后续的扩展、伸缩、漂移等能力）

          2、应用容器之间不允许直接共享数据（通过后端服务来提供）

          3、需要提供Session集中管理（托管在Redis中）

          4、不允许使用粘滞Session

          5、提供缓存服务保存Session状态信息

本文对12要素宣言的实践，先为大家分享前六个，之后会继续为大家分享后六个在数字化企业云平台上的实践结合。

近期EAII研究院（微信号：eaworld）会发布作者刘相“数字化企业云平台的Cloud Native12原则（下）”，敬请关注。

关于作者：

刘相

EAII-企业架构创新研究院 专家委员

计算机应用技术硕士，现任普元软件产品部副总兼SOA产品线总经理。十年IT行业经验，专注于企业软件平台，在SOA、分布式计算、企业架构设计等领域。先后主导公司EOS7、Portal、云PAAS平台、云流程平台、BPM等系列产品的开发和设计工作。著有国内首本解析SpringBatch的中文原创图书《SpringBatch批处理框架》。个人爱好：阅读，慢跑。

关于EAII

EAII（Enterprise Architecture Innovation Institute）企业架构创新研究院，致力于软件架构创新与实践，加速企业数字化转型。

eaworld项目（微信号：eaworld，长按二维码关注）

eaworld是EAII的官方微信账号。