容器时代的数字化转型方法论

【编者按】谈到数字化转型，大多数文章的表达方式大概都是“在时代从互联网进入产业互联网的背景下，所有行业都应该拥抱云计算、大数据和人工智能……”好像只要开出这三味药名就能药到病除。

谈到容器与微服务，人们习惯围绕着 Docker、Kubernetes、Service Mesh、FaaS、DevOps、Serverless……这些技术和概念在微观层面打转，结果在落地过程中出现很大的组织裂痕，举步维艰。

本文试图从企业业务核心诉求出发，在数字化转型核心逻辑下，帮助企业厘清企业应用开发与运维全面向云原生和微服务架构转型的根本原因，以及转型过程中涉及的各种关键问题、相关概念之间的关系。

文章转载自云头条，作者“青云QingCloud”，经编辑发布，部分有删减，供业内人士参考。

2013年诞生的Docker，让尘封已久的容器技术再一次兴起。围绕编排调度框架的百舸争流，更是将容器推上了风口浪尖。直到Kubernetes 脱颖而出，成为业界公认的容器编排标准，容器似乎代表了未来的一切，业界对容器技术的追捧更是达到了顶点。然而，如同 Gartner 经典的技术成熟曲线所描述的，陡然而起的顶峰也意味着即将迎来的一轮“幻灭低谷”。当技术和生态日益蓬勃与成熟，越来越多的从业人员开始从单纯对技术和理念的追捧，转向对容器落地实践与真实价值的思考。无独有偶，另一份Gartner调研预测到 2020 年将有 50% 的企业会将容器应用于生产环境中。这侧面反映出业界，特别是最终用户群体，对通过容器技术达成真正业务价值的期许。对于完成了高光亮相的容器和Kubernetes， 接下来面临的是走向成熟前的最后一次大考：突破“幻灭低谷”，走入真正的生产实践，创造商业价值。

▌以“微观塑形”的新业务新应用

任何技术走入生产实践的终极目标都是塑造企业创新性竞争力，为业务目标服务。

互联网的出现为企业经营带来巨大改变：全新的业务形态，更为广阔的营销空间，愈发高效的运转效率。面向未来，企业业务将呈现更为彻底的互联网化与数字化：从面向营销、面向人的消费互联网，通过物联智能延伸到面向生产与供应链（物与流程）的产业互联网，同时将更加依赖通过数据挖掘而形成的数据智能进行决策。企业 IT 将面临超大规模、无数触点、极高并发、极快速迭代更新等新的挑战，需要更高的弹性和敏捷性。

数字化转型1.0 阶段，企业更加关注基础设施的敏捷性改造，通过系统基础架构（计算、存储、网络）全面云化实现获取敏捷和弹性的第一波升级。而在云计算基础上，完成对更为贴近实际业务的上层应用的架构转型，将更直接的大幅提升业务敏捷性，云原生理念应运而生。

云原生的最基本属性是分布式的，但以何种粒度和维度实现模块化的切分，业界一直在不断探索。Gartner 提出了一种应用（服务）粒度理论，将应用分成：Macroservice、Miniservice、和 Microservice，从粗到细依次对应不同的应用切分粒度。越细的粒度，将带来越大的自由度和敏捷性。微服务架构就是基于这一理念，将应用进行更细粒度的模块化拆分，并通过服务网格/服务治理技术建立起微服务间的通信网络，从而构建起由独立微小服务组织而成的应用（服务）网络集群。由于每个个体相对而言是轻量化的，可以单独开发与部署，使得整个微服务应用具备了高度的动态化能力，可以不断的快速迭代演化，也因此具有更强的业务敏捷性和弹性。Gartner 基于微服务理念进一步提出了 MASA （Mash App and Service Architecture）应用架构，并预测这种理念将成为未来应用架构的主流趋势。应用开发开始从“宏观造像”逐步走入“微观塑形”。

如同爱因斯坦的相对论为我们打开了量子世界之门，微服务理念开启了应用的“微观世界”。但理论的真正落地，仍然需要一整套庞大的系统工程，包括完整的微服务工具集，与之匹配全新的应用开发与管理流程，以及符合微服务特性的基础设施平台。

新流程

DevOps 不仅仅是技术或者实现技术的工具，更是应用开发的一种组织架构和工作流程。DevOps 通过流程的重构希望实现从开发、测试到最终应用部署发布全流程的贯通与高度自动化，从而实现敏捷开发。而正是这种对高度的动态特性的关注，让 DevOps 方法论与微服务理念找到了共识。

新平台

“轻量化”和“标准化”是容器最显著的特性，而这两个特性也恰恰完美匹配微服务应用开发的需求。轻量化匹配对“微观”资源的需求，而标准化的封装则为组网和标准化通信提供了基础。进入“微观”世界最不可避免的是数量剧增带来的管理复杂性，也因此容器的使用从来不从单体出发，而强调调度编排，这也正是 Kubernetes 有如压舱石一般的价值所在。同时，业界也普遍认可容器是运行DevOps 的最佳平台。

总结下来，企业真正需要的是利用更敏捷灵活的应用交付能力持续锁定创新竞争力，而通过落地微服务完成应用架构升级，则是取得这一目标的关键。完善的容器平台，提供基础设施资源、完整的工具集、流程链及企业级工作平台，为微服务及DevOps 的全面落地提供一站式支持，应该成为所有企业容器建设的共同目标。

广义架构的粘合剂

以上是从纵向的视角探讨容器对单体应用的重构，而以横向的视角，从宏观拓展的角度，亦可观察到容器在多种新兴应用场景中起到的粘合作用。

容器和云 & 虚拟化

一方面，容器和虚拟化是互补关系，这一点越来越为大家所认可。在容器最火热的时候，将容器视为虚拟化替代品的论调也不乏受众。但逐渐，大家在实践中认知到容器与虚拟化各自的专长，也逐步区分开各自的应用场景。两者都是基于分布式的架构理念，但是如之上提及的粒度理论，容器更敏捷更轻量，需要全方位的架构重组，适合短平快的新业务；而虚拟化粒度更粗，灵活不及容器，但单体更强壮，更适合需要长期稳定运行的重载应用。因此在相当长的时间内，虚拟化和容器将以互补的关系在企业的生产环境中长期共存。

另一方面，容器是可以部署在虚拟化之上运行的。特别是在虚拟化大规模普及的背景下，这样的部署方式更贴近用户的使用习惯和真实环境，使用和运维都十分方便灵活，同时虚拟化在隔离性上的优势也将补强容器的安全性。但代价是在一定程度的性能损耗，特别是网络性能。与之相应的，是选择将容器直接部署在物理机上，架构上减少一层，会大幅降低运维复杂度和性能损耗，同时资源利用率也将显著提升，最终获得更优的 TCO （总体拥有成本）。两者各具优势，如何选择则应诉诸于使用场景：更为灵活的虚拟机方案比较适合开发测试环境，而 TCO 和性能更好的物理机方案则更适合长期运行的生产环境。在真实环境中，这两者不是简单的二选一，大多数时候是同时存在互相补充的，在一套完整的云体系中统筹管理运行。

容器和 Serverless & FaaS

通过 Serverless 服务，用户可以直接执行代码来处理负载，从而完全避免了应用运行环境或部署所带来的各