从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等多家业内媒体发表有许多相关领域文章。
网易云为您提供容器服务，欢迎点击免费试用。
相关文章：
【推荐】 MongoDB账号管理及实践
【推荐】 搜索实时个性化模型——基于FTRL和个性化推荐的搜索排序优化
【推荐】 appium封装显示等待Wait类和ExpectedCondition接口
