数字化企业云平台的Cloud Native12原则
数字化企业云平台的Cloud Native12原则
普元云计算 发表于11个月前
数字化企业云平台的Cloud Native12原则
  • 发表于 11个月前
  • 阅读 9
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云实验室 1小时搭建人工智能应用,让技术更容易入门 免费体验 >>>   

转载本文需注明出处: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的官方微信账号。

共有 人打赏支持
粉丝 2
博文 23
码字总数 18356
×
普元云计算
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: