从DevOps到Cloud Native，应用上云姿式全解锁

本文由网易云 发布

做者：林帆

序文

伴随着IaaS、PaaS等云端基础设施技术的成熟，“应用上云”成为许多企业软件部门的心头大事。经过把传统软件系统搬到云上，一方面可让业务方得到更多的资源灵活性，另外一方面也能够缓解运营方的成本压力，让硬件资源再也不成为阻碍流量和业务增加的障碍。上云这件看起来轻松的事，其实倒是一项系统性的工程。只有到真正作起来时候才会发现一地鸡毛的问题，且不说技术方面引入的变化，组织部门隔阂、开发流程陈旧、配套工具落后、人员意识保守...随时冒出来情况，足以让这个许多人最初觉得只是改改架构从新部署的工做变得复杂度远超预期。

特别是在早几年时候，“云原生应用”的概念比较模糊，应用上云到底要作哪些事情并无过权威明确的定义。虽然有Google、Facebook和许多国内外互联网企业总结出的案例，但都不具备普适性，一些规模不大的企业照搬照抄效仿，试图一步到位，结果落得邯郸学步的下场。从这个角度来看，网易云出品的《云原生应用架构实践》的确是一本可让人眼前一亮的书，它针对互联网应用前期拼灵活、中期拼增加、后期拼稳定的特色，明确的指出了处于不一样规模和时期的企业，实施上云策略应该彻底不一样，并针对三种典型的发展阶段阐述了企业应该采用的实践和转型途径。

图片来自互联网

从DevOps到Cloud Native

运用“云原生应用”架构的一条很重要原则是：最大化云对业务的价值提高。提到这个大概很容易令人联想到另外一个如今一样很火的词“DevOps”。

云计算的普及将昂贵的基础设施资源变成自来水那样即取即得、“称量”计费的同时，也带来了交付协助模式的改变。计算资源变为人人均可以经过API和自助服务轻易得到，开发团队得到了极大的自主性，运维团队的工做也变得加聚焦和高效。在一些成熟的互联网企业中的开发与运维边界开始变得再也不那么清晰。在这样的环境下，比利时咨询师Patrick Debois受到Flickr公司实践的启发，于2009年提出了DevOps理念。要早于Heroku创始人Adam Wiggins于2012年提出的The Twelve-Factor App宣言，而这个宣言提倡的实践后来造成了Cloud Native架构的基础。

能够说，DevOps和Cloud Native都是在云基础设施的背景里诞生的。二者所提倡的思想也有许多类似性，例如，DevOps从端到端交付效率的角度着手，提倡全局优化，减小跨团队协做摩擦，提倡全功能团队的组织结构，促使了微服务实践的出现。而微服务的架构形式偏偏也是Cloud Native实践中所提倡的一种可以充分发挥云端基础设施能力的架构模式。相似的例子还有提倡服务能力API化、交付流程自动化和可视化等等。

从更高的层次来看。DevOps关注在流程和协作方面的改进，顺便引入了一些技术工具手段；而Cloud Native本来关注的就是架构的设计和对云基础设施的利用，但也涉及到了流程和工具。因此，与其撇清二者的关系，不如将Cloud Native看做是DevOps在架构领域的延伸。

初创企业的云原生架构

许多初创企业选择采用云平台来发布本身的应用，并不是是因为这些云提供很好的扩展性、开放性，或是丰富的功能，而仅仅是出于平台的具备精确计费和稳定、可靠、易用等“高性价比”的特质。处于这个阶段的企业一般只须要不多的服务器实例，以及简单好用的架构，无需划分组件，所以也不存在集成的烦恼。

在这样的企业中使用复杂的交付工具和流程无异于用牛刀杀鸡。我曾在一个短暂的小型项目当中犯过这样的经验性错误，那是一个十分简单的Web服务，出于习惯，我煞有其事地为项目设计了自动化的发布流水线：构建、打包、发布测试环境、发布线上环境。全部东西部署在一个云主机上，用容器隔离，测试环境和线上环境只是用了不一样的端口，一切运转良好。直到有一天服务器修改了密码，运行在容器里的Jenkins服务没法链接上主机端口，不停打印错误日志，很快把整个主机磁盘所有写满。好在问题发生在工做时间，被及时发现，没有致使什么损失。这件事对我启发并不是是使用流水线不对，而是咱们把注意力放在了作一堆自动化的东西，却没有利用云平台把最该作的事先作好，好比说监控。

云端架构对于初创企业的最大价值在于它能简化运维，为小项目添置专职的运维人员是一件奢侈的事，但已经疲于奔命的开发人员显然不肯意抽出太多时间来打理线上环境的平常杂事。此时若能用好云平台提供的服务器监控、数据库备份、服务健康检查等能力，等同于将应用和云进行了充分的互动，也就是Cloud Native设计的体现。

图片来自互联网

成长期企业的云原生架构

当企业的业务模式获得验证，愈来愈多的访问流量和用户数据既是产品经理们渴望看到的业绩，也是项目开发团队面临的巨大的考验和挑战。这个阶段的服务复杂度到了必定规模，拆分组件是必然选择，跨团队的集成开始出现。同时为了抗住更大的并发访问压力，服务的横向扩展性成为十分重要的事情。此外，服务的安全性也逐渐须要提上日程。

前面提到的十二要素（The Twelve-Factor App）原则如今开始发挥做用，这一阶段是云基础设施最能体现价值的阶段，也是在网络上充斥的大量介绍Cloud Native实践文章所假设的业务规模状态。为了协调和可视化团队之间的交付进度，一般须要引入持续集成和持续交付实践。面对众口难调的用户群体，灰度发布和A/B测试是一般会采用的局部试错手段。监控依然是必不可少的主题，更全面、更准确及时的故障事件通知是保障服务规模化的关键。服务数目愈来愈多，日志的管理也是要被提到台面上的事情，经过分析业务的日志，还能对用户行为和系统潜在问题进行更早的预测。天天迟早波荡起伏的流量每每也须要大规模的服务扩缩容。同时，更多的数据库、更多的消息中间件也带来了更多的平常管理工做。这些林林总总的问题，若是要让项目团队本身重头设计解决方案，不知要作到猴年马月。

处于成长期的企业，充分发挥云所带来的平台优点，意味着调用一个API就能实现服务器存储容量的变动，一个CPU过载的告警就可以马上触发新节点的建立、初始化和集群的扩容，零维护工做量的高效消息队列，零管理成本的多副本高可用数据库。一方面将应用设计成可以充分利用云端集成设施能力、具有水平扩展条件、可以编排部署的服务组；另外一方面尽可能避免在基础设施能力上重复造轮子，利用云平台简化总体架构的复杂度。这些Cloud Native因素也是许多互联网产品成功的外在保障和内在动力。

稳按期企业的云原生架构

可以真正经受市场的打磨进入稳按期的企业和产品并很少见，一旦积累到足够多的粘性用户，跨过产品增加期的鸿沟，就仿佛驶入了一片代表平静但实则暗流涌动的深海。这些可以存活下来的互联网产品一般都是已经深深植根于Cloud Native实践的，不论他们是否有主动意识到Cloud Native的存在：没有一个庞大到几千人的团队可以不依赖平台和云，或是不采用先进的交付流程实践，彻底听任开发人员重头实现全部基础服务、采用小做坊式的简单粗暴发布流程可以把产品作成功的。

这些企业所面临的问题再也不是如何使用Cloud Native，而是如何更好地利用云的能力将在现有业务领域上的优点从1到100的复制到其余的领域上，以得到更大的成功。所以不断的组织重组、寻找创新的突破口都是司空见惯之事。微服务架构是当下许多进入稳按期的企业正在探索的方向，经过微服务的拆分，特别是基于领域驱动设计这样的先进实践，可以将企业的技术架构与业务架构更好的匹配，为未来可能发生的业务领域扩张提供信心和保障。

在这个阶段，资金充沛的企业会开始考虑自建数据中心，经过前期的一次性投入，从更长远的时间跨度里节约成本。两地三中心、主备或者多活容灾等问题开始提入议程。接下来，在这些数据中心之上构建本身的定制化私有云平台，继续更高级的基于云的交付实践探索。也有些企业依然会选择继续在公有云（易小云：别忘了专属云，本质也是公有云，但私密性、定制性更强）扩张本身的业务，或者将二者结合，造成混合云的架构。这种应用与云高度融合的实践算得上是Cloud Native的一种终极形态。

图片来自互联网

总结

当你们都还在吵吵嚷嚷着要应用上云的时候，有这么一群人，他们静下心来将本身在云端开发的各类实践沉淀下来，汇聚成了《云原生应用架构实践》这本十分精彩Cloud Native枕边书。相信它能陪伴你们的技术成长之路，迈过互联网产品的增加鸿沟，走向Cloud Native的康庄大道。

做者简介：林帆，DevOps和容器技术咨询师，目前就任于ThoughtWorks，从事软件开发运维咨询以及社区推广工做，在容器规模化运维方面有丰富经验。StuQ特约课程讲师，著有《CoreOS实践之路》一书，并在CSDN、InfoQ等多家业内媒体发表有许多相关领域文章。

了解 网易云 ：

网易云官网：www.163yun.com/

新用户大礼包：www.163yun.com/gift

网易云社区：sq.163yun.com/