灵雀云 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) 就是一个“云原生机器学习平台”，目标是从云平台的角度，用云原生的思路去落地机器学习工程化的最佳实践。