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