灵雀云CTO陈恺：从“鸿沟理论”看云原生，哪些技术能够跨越鸿沟？

摘要：早在年针对高科技行业和高科技企业生命周期的特点，提出了著名的鸿沟理论。今天我们尝试以鸿沟理论为基础来分析云原生领域颠覆性的创新技术。回过头来看，灵雀云从早期全力投入技术栈，是最早进行产品化的厂商。

历史进入2019年，放眼望去，今天的整个技术大环境和生态都发生了很大的变化。在己亥猪年春节刚刚过去的早春时节，我们来梳理和展望一下整个云原生技术趋势的发展，是一件很有意义的事情，这其中有些变化在不可避免地影响着我们身处其中的每一家企业。

如果说云原生在2017年还仅仅是冒出了一些苗头，那么2018可以说是普及之年，云原生变成了一个成熟的、被普遍接受的理念。灵雀云作为云原生理念的拥趸，也不断顺应这种趋势，聚焦云原生的核心场景，围绕容器平台、DevOps和微服务黄金三角进行产品的研发和业务场景的落地。

早在1991年Jeffery Moore针对高科技行业和高科技企业生命周期的特点，提出了著名的“鸿沟理论”。这个理论基于“创新传播学”，将创新性技术和产品的生命周期分为五个阶段：创新者（Innovator）、早期使用者（Early adopters）、早期大众（Early majority）、晚期大众（Late majority）、落后者（Laggard）。

在Early adopters和Early majority之间有个巨大的鸿沟（Chasm），每个新技术都会经历鸿沟，大多数失败的产品也都是在鸿沟里结束了其整个生命周期，能否顺利跨越“鸿沟”，决定了创新性技术的成败。今天我们尝试以鸿沟理论为基础来分析云原生领域颠覆性的创新技术。

“Kubernetes is Boring”，边缘创新有亮点

Kubernetes在2017年底成为容器编排事实标准，之后以其为核心的生态持续爆发，在传播周期上可以说已经跨过鸿沟了，进入Early majority早期大众阶段，开始占领潜力巨大的主流市场。

根据CNCF在2018年8月进行的第六次测量容器管理市场的温度，83%的受访者更喜欢Kubernetes的容器管理工具，58％的受访者在生产中使用Kubernetes，42％的受访者正在进行评估以备将来使用，40％的企业（员工规模在5000 ）正在使用Kubernetes。Kubernetes在开发人员中已经变得非常流行。

回过头来看，灵雀云从早期全力投入Kubernetes技术栈，是最早进行Kubernetes产品化的厂商。我们并未满足于把Kubernetes当作一个容器编排工具来使用，而是将它定位成构建上层平台的核心框架，通过合理运用Kubernetes本身的扩展机制、架构模式与API规范，构建出一系列“Kubernetes原生”的产品体系。这样做不仅真正发挥出Kubernetes作为云计算核心框架的最大优势，也可以与以Kubernetes为核心的云原生生态无缝集成。

进入主流市场的Kubernetes开始变得“Boring”，这很正常，甚至是一个好的现象。核心项目的创新速度会减慢，最新的版本中主要关注点聚焦在稳定性、可扩展性这些方面，尽可能把代码从主库往外推，让它的主库变得干净，其他功能通过一些扩展机制来做，同时开始关注安全性。

Kubernetes项目本身已经过了现象级创新爆发的阶段，但由Kubernetes独特的架构属性催生出的周边生态的二次创新仍然在高速发展，例如诸多与Kubernetes集成或者基于Kubernetes框架开发的上层服务与平台。这个话题我们下次讨论，今天还是主要关注与Kubernetes项目关联最紧密的创新亮点：

早期容器化workload大多聚焦在无状态服务，跑的最多的是Nginx，而对有状态应用避讳不谈。现在Kubernetes进入主流市场，显然需要对“现实中的应用”，包括有状态服务提供良好的支持。2019年，对于复杂应用的管理以及Kubernetes本身的自动化运维将会更多的表现为Operator。

Operator是基于Kubernetes扩展机制，将运维知识编写成“面向应用的Kubernetes原生控制器“，从而将一个应用的整体状态作为API对象通过Kubernetes进行自动化管理。这个应用通常来说是比较复杂的有状态应用，如MySQL数据库、Redis集群、Prometheus等等。现在基本上常见的有状态应用都有自己相对应的Operator，这是一种更为有效的管理分布式应用的方式。

其次是应用跨集群部署与管理。早期社区里有Federation联邦集群的方案。我们不少大金融客户都有跨集群部署、管理业务的需求。当时深入研究Federation v1之后，觉得这个方案复杂度高，观点性强，对于我们实际的需求灵活度不足而又不够成熟。所以我们最终选择自研跨集群部署。后来出现的Federation v2在设计方向上有不小改观，是我们持续关注的项目。

早期采用容器技术的用户都会尽可能兼容企业原有的IT基础设施，比如底层物理机，保留物理机之上的虚拟层，虚拟机之上再跑容器。当然，面向资源管理的硬件虚拟化和面向应用的容器化本质上没有冲突。随着Kubernetes的普及并且在应用上超越了容器编排的范畴，后Kubernetes时代如何搭建管理基础设施是值得思考的。我们也观察到一些有意思的趋势，比如在Kubernetes上同时管理容器和虚拟机（所谓的“容器原生虚拟化”），或是使用Kubernetes来管理OpenStack。

总之，Kubernetes在云计算领域成为既定标准，会越来越多的往下管理所有种类的基础设施，往上管理所有种类的应用。这类标准的形成对于技术社区有很大的益处，会大大降低围绕Kubernetes技术投入的风险。因此，我们会看到越来越多的周边技术向它靠拢，在Kubernetes之上催化出一个庞大的云原生技术生态。

DevOps独辟蹊径：

开放式DevOps工具链集成与编排

DevOps理念、方法论和实践已经走到了Early Majority早期大众阶段，是已被实践证实的高效开发运维方法。做容器的厂商都经历过用容器搞CI/CD，灵雀云也不例外，CI/CD是容易发挥容器优势的显而易见的使用场景。在去年，我们做了重大的产品升级，将原来的CI/CD功能模块扩展为完整的DevOps产品—Alauda DevOps平台，覆盖应用全生命周期。

DevOps包含好几层概念，首先是组织文化的转变，然后涉及到一系列最佳实践，最终这些最佳实践需要用工具去落地。我们在帮助很多大型企业客户落地DevOps的过程中发现：
在DevOps的整个流程里涉及到很多类别的工具，每一个类别都会有大量的选择；2. 每个客户的工具选型多少会有些不同，并不存在一个固定的、完全标准的工具组合；3. 随着时间的推移工具选择会发生变化，多数客户意识到目前使用中的工具在未来很可能会被替代。

基于这些观察，Alauda DevOps的定位并不是要提供一个新的DevOps产品，去取代客户已有的工具选型。相反，我们致力于打造一个开放式的DevOps工具链集成与编排平台。

这个平台可以灵活的兼容客户的工具选型，通过集成将各类工具串联起来，形成一套工具链，通过编排让DevOps工具链与容器平台联动，形成一个完整系统。同时，不断结合自身的经验，提炼DevOps落地的最佳实践，平台将这些最佳实践自动化，作为服务进行输出。这个思路在和客户的交流以及实际落地过程中不断获得认可。

值得一提的是，我们对于DevOps工具链的编排也是基于Kubernetes来实现的。Kubernetes不仅是出色的容器编排工具，扩展之后也很适合编排DevOps工具。换句话说，我们开发了一套“Kubernetes原生的DevOps平台”。

微服务：落地需要一套完整的基础设施

提起微服务治理，很多人会条件反射般的联想到某些特定的技术，例如Spring Cloud，或者Service Mesh。我们不妨先退后一步，系统考虑下企业微服务架构改造和落地所需要的完整的基础设施。

首先，在微服务应用的底层需要一个应用管理平台，这在今天毋庸置疑是一个基于Kubernetes的容器平台。

微服务本质上是分布式应用，在我们获取敏捷性的同时不可避免的增加了运维和管理的难度。微服务对自动化运维，尤其是可观测性的要求很高。支持微服务架构的基础设施必须具备完善的监控、告警、日志、分布式追踪等能力。

在微服务应用的前方，通常需要一个API网关，来管理对外暴露的API。API治理策略，包括安全、路由、流控、遥测、集成等对于任何应用平台都重要，但在微服务架构下尤为关键。我们需要通过定义、封装对外API来屏蔽应用内微服务组件结构细节，将客户端与微服务解耦，甚至为不同客户端提供个性化的API。

云原生应用的一大准则是应用与状态分离。在微服务架构下，每个微服务组件更是应该完全掌控自己的数据。所以，云原生应用通常依赖外部数据服务（Backing Services），而在微服务架构下，多元化持久性（Polyglot Persistence）是常态，也就是说一个微服务架构的应用会依赖非常多种类的 Backing Services。面向微服务架构的基础设施需要将这些外部服务暴露给微服务应用消费，甚至直接支撑各类Backing Services 的部署和管理。

一个团队之所以采用微服务架构，一定有敏捷性的诉求。所以通常微服务团队也会拥抱DevOps理念。一个完善的面向微服务架构的基础设施需要考虑 DevOps 流程以及工具链的自动化。

最后，我们回到狭义的微服务治理，这里关注的是微服务组件之间的连接与通讯，例如服务注册发现、东西向路由流控、负载均衡、熔断降级、遥测追踪等。现在有个时髦的术语来描述这类功能，就是大家熟悉的Service Mesh。其实早期 Sping Cloud 之类的框架解决的是类似的问题，但在实现的方式上，尤其是mesh 和业务代码的耦合度上，有本质的区别。

当我们考虑一个平台如何支撑微服务架构的时候，需要涵盖上述提及的方方面面，从产品的角度我们会保持一个开放的态度。这其中一部分需要我们自己去做，其他一些可以借助生态合作伙伴的能力去补全完善。

此外，微服务架构也进入到了后Kubernetes时代，早期基本上是微服务作为用例推动容器技术的发展。今天已经反过来了，成为标准的Kubernetes其实在驱动和重新定义微服务的最佳实践。容器和Kubernetes为微服务架构的落地提供了绝佳的客观条件。

Service Mesh： 下一个亟待爆发的现象级技术创新

业界对于Service Mesh的布道已经持续了一段时间，我们今天不再重复基本的概念。当我们把Service Mesh和上一代以Spring Cloud为代表的微服务治理框架以及更早的Service Oriented Architecture (SOA) 作比较的时候，会看到一个有意思的演化。

我们知道，SOA有企业服务总线（ESB）的概念，ESB重且复杂，其实会混杂很多业务逻辑。SOA架构下，ESB最终容易变成架构以及敏捷性的瓶颈。早期推广微服务架构的时候，一个重要的概念就是“Smart Endpoints and Dumb Pipes”，针对的就是SOA下ESB的痛点，从而每个微服务能够独立、自治、松耦合。

但是仔细去想的话，就会发现它其实走到了另一个极端：它把一些基础设施提供的能力放到微服务的业务组件里面了，通常每个组件需要加载一些治理框架提供的库，或是调用特定的API，其实就是在业务组件里内置了基础设施的功能。到了Service Mesh其实又把它们分开了，从架构角度这样也比较合理，应用是纯业务的东西，里面没有任何基础设施，而提供微服务治理的基础设施，要么在Mesh里面，要么由底层的Kubernetes平台来提供，对应用是透明的。

Istio的出现促使业界对于Service Mesh的架构有了新的共识：控制平面（Control Plane）与数据平面（Data Plane）解耦。通过独立的控制平面可以对Mesh获得全局性的可观测性（Observability）和可控制性（Controllability），让Service Mesh有机会上升到平台的高度。相对于需要在业务代码层面使用的上一代微服务治理框架，这点对于希望提供面向微服务架构基础设施的厂商，或是企业内部需要赋能业务团队的平台部门都具有相当大的吸引力。

在Data Plane，Envoy的领导者地位毫无争议。Envoy使用C 开发，在资源使用效率和性能上（尤其是长尾性能差异）相较早期主要竞争对手Linkerd有明显优势。Envoy提供基于filter chain的扩展机制，从Kubernetes的成功当中我们已经学习到，可扩展性对于大规模采用十分关键。

Envoy定义了一套“通用数据平面API”（Universal Data Plane API），也就是它的xDS协议。不仅确保了Envoy本身的动态可配置性，更重要的是为Service Mesh中Control Plane和Data Plane解耦提供了一个标准的接口。由于主流Control Plane（例如Istio）对Envoy以及xDS的采纳，xDS成为Service Mesh Data Plane API的事实标准，Envoy也成为无可争议的Data Plane领导者。

在Control Plane，Istio是最具光环的明星级项目。它正在引领Service Mesh创造出一个全新的市场，不过从传播周期看现在还没有跨过技术鸿沟，处于Early adopters阶段。

过去一年中，Istio项目在技术上的表现并不完全令人满意，主要体现在对其复杂度的诟病，以及稳定性和性能的质疑。1.0版本的推出并没有完全令人信服。不过，这些似乎并不影响Istio在社区获得的巨大成功。在开源领域，并不存在对Istio有实质性威胁的竞品。可能在经历了Kubernetes之后，以及Istio早期迅猛的发展和在社区中巨大的影响力之下，很少有开源项目愿意在Control Plane和Istio正面交锋。

长远来讲，Data Plane会慢慢变成commodity，尤其在有了Universal Data Plane API之后。我们有理由相信成熟稳健的Envoy会保持领先，但最终多数用户会越来越少去关心具体的Data Plane技术。这个情境似曾相识，和当初Docker与Kubernetes的关系有点类似。

下个阶段Service Mesh的赋能和创新会更多聚焦在Control Plane。AWS在Data Plane选择成熟的Envoy，而自己开发App Mesh的Control Plane，就很容易理解。灵雀云已经在ACE/ACP两条产品线中集成了Istio，提供企业就绪的Service Mesh。

云原生为机器学习输出工程化最佳实践

云原生的理念与相关技术对于应用开发与交付的巨大价值已经被普遍接受。但云原生不仅仅可以作用在普通的应用开发上。站在容器平台的角度看，机器学习毫无疑问是一类极为重要新兴工作负载。在未来，可能所有的公司都会是AI公司，所有的应用都会是智能应用，使用算法、模型就像今天应用会依赖数据库一样普遍。

如果我们分析数据科学家的工作流，会发现和传统应用开发有很多相似的挑战。如何方便的获取实验环境；如何让实验可重复；如何将数据处理、特征提取、模型训练、模型验证、模型发布这些步骤自动化，并且可重复；如何让研究和生产环境保持一致；如何在生产环境做模型变更、AB测试、灰度发布；如何在生产环境运维模型服务；如何将模型服务化，等等。

在软件工程领域，云原生的理念、方法论和最佳实践已经为类似问题找到了良好的解决方案。这些方案其实非常适合应用在机器学习场景。换句话说，我们需要“云原生机器学习”。这仍然是一个相对早期的概念，从鸿沟理论的周期来看，云原生机器学习大致还处在Innovators创新者尝鲜的阶段。我们去年发布的Alauda Machine Learning (AML) 就是一个“云原生机器学习平台”，目标是从云平台的角度，用云原生的思路去落地机器学习工程化的最佳实践。