作为云原生的核心产品，Kubernetes 提供的编排和管理功能，能轻松完成大规模容器部署，但 Kubernetes 自身的复杂性也导致众多企业一直徘徊于容器服务之外。据调查，只有不足 10% 的用户表示使用 Kubernetes 时没有遇到阻碍。

在 2019 年的一个关于容器技术的一个调查数据中，有 40% 的受访者表示计划采用容器。然而，据 UCloud 产品经理张鹏波透露说，在他们接触的用户当中，曾经在两年前表示有兴趣迁移到容器的用户，两年过去了，这些用户很多依旧“计划采用”容器服务。

这让我好奇其中发生了什么。让我们一起来探寻一下其中的症结，以及是否可以将复杂的 Kubernetes变得不复杂。

Kubernetes 复杂吗？

自从 2017 年，Kubernetes 在容器编排三强争霸赛中胜出后，就成为了容器编排领域的事实标准，极大的助推了容器技术在业界的发展。作为企业级的容器服务编排系统，Kubernetes 从技术上是现在、乃至未来的主流。

容器拥有很多优点，包括不可变环境、轻量级、快速启动等优势；而容器编排系统又在此基础上更进一步，提供了更加强大的功能，包括自动部署、快速扩容、故障自愈等等。

然而，在这一系列令人神往的优势和功能背后，Kubernetes 也相应的引入了更多的复杂性。这些复杂性体现在多个方面，比如说：

• 首先是 Kubernetes 架构，本质上，Kubernetes 是用来管理分布式系统的平台。而一说到分布式，复杂性是不可避免的，管理分布式系统的平台自然也不例外。
• 另外是容器支持的网络，Kubernetes 支持的网络类型很多。很多用户对于 Kubernetes 的网络非常疑惑或者说很纠结，当业务要迁移到 Kubernetes 时，选择什么类型的网络是一个难以抉择的问题。特别是在业务迁移上去之后又遇到一些问题的话，排查起来会非常麻烦，这给用户带来很大负担。
• 最后还有就是各种各样 Kubernetes 组件的配置，这些都是用户将业务迁移到 Kubernetes 的障碍。

有什么解决方案吗？

如上所述，并不是每个用户都能尝到桃子的美味的，还有很多渴望迁移到容器环境的用户被拒之门外。

在这种情况下，全球各家云服务商，都纷纷推出自己的容器编排服务，在 Kubernetes上构建了自己的 Kubernetes发行版或定制产品。

而作为中国第一家公有云科创板上市公司，UCloud 利用在 UK8S 产品的技术沉淀，推出新的容器管理服务产品 Cube：两步即可部署容器化应用；采用无服务器形态，不需要再维护底层基础设施；按秒后付费，无需预留资源；降低企业部署云原生产品的学习和技术门槛。

为什么要推出 Cube？

在容器和 Kubernetes 如火如荼发展的同时，UCloud 发现，在他们的 UK8S 上线大概两年多的时间里，之前曾经想把业务迁到 Kubernetes 的用户。在两年后的今天，他们还是说这个话，说我很想上 Kubernetes，还需要你们来做技术交流。

UCloud 产品经理张鹏波说：

这让我们一度很困惑，我们一开始也做了一些尝试，比如说做了很多线下的培训、线上的交流，尝试去推动用户把他们的业务迁移到 UK8S 里面来。但是发现这个过程非常缓慢，我们没有办法控制和推动用户的迁移流程。很多公司的业务在快速发展，运维和研发是没有办法做架构上的调整的。

发现沟通、培训这条路实际上是走不通之后的。后来我们想，能不能换一条路，能不能基于 Kubernetes提供这样一个产品：这个产品只具有 Kubernetes 好处，掩盖了 Kubernetes 的复杂性，只提供类似于自动部署、快速扩容这样的特性，而用户不需要关心底层的 Kubernetes 架构，不需要再操心 Kubernetes 的网络了，也不需要去学习 Kubernetes 的各种 API 了。

Cube 的设计思路

沿着这个思路，UCloud 形成了自己的 Cube 产品。它的设计是从以下几个方面考虑的：

首先，Kubernetes 里面哪些功能是会经常会用到的，比如 Deployment 控制多副本容器组的管理， Job 控制任务型容器组，Service 做服务发现，PVC可以用来抽象使用块存储以及文件存储。这是 Kubernetes 最核心的一些功能。UCloud 在设计 Cube 的时候，希望将这些功能全部保留。这意味着整个 Cube 是基于 Kubernetes 来实现的。把这些复杂性全部屏蔽掉，用户不需要维护 Kubernetes 集群，不需要操心 Kubernetes 网络方案，而是由 Cube 提供一个最优网络方案，把容器的网络和虚拟机的网络扁平化。

其次，把业务迁移到 Kubernetes 的时候，把单体业务变成分布式业务、微服务的时候，用户一定需要考虑容器日志的统一收集、统一管理的问题。在 Cube 里面自动完成了日志的采集工作，集成了日志管理工作。另外，对容器环境的监控也是同样的道理，统一在 Cube 中完成。

当把这些产品全部集成到 Cube 里以后，Cube 是一个什么样的产品形态呢？

首先保证 Kubernetes 最核心的功能，用户能够在 Cube 里面创建 Kubernetes 常用的对象；另外 Cube 的产品形态应该是无服务器的形式；最后，Cube 引入了轻量级的虚拟化技术，实现了容器组与容器组之间虚拟机级别的隔离，这样好处是什么呢？

我们都知道容器的运行是共享使用宿主机的内核的，存在一定的安全风险，Cube 为每一个容器组实现了一层虚拟机的封装，可以使用户安全的运行容器；同时 UCloud 容器团队针对虚拟机的启动进行了深入优化，虚拟机启动速度最快只需要 125 毫秒。

Cube 的功能亮点

快速迁移

让我们横向对比一下，用户使用 Kubernetes 和 Cube 的流程上会有哪些区别。

左边是 Kubernetes，用户要把业务迁移到 Kubernetes，大概要经过这几个步骤：

• 第一个步骤学习 Kubernetes，不仅仅是一个人，也可能不仅仅是一个团队，这个过程可能需要三个月到一年。
• 搭建集群，考虑集群的参数配置、集群的维护工作。
• 然后是做业务镜像。
• 之后还要考虑了解 Kubernetes的 API 以及 Kubernetes 应用。
• 最后才部署应用。

从 UCloud 观察到的情况来看，如果是对 Kubernetes非常熟悉的用户，这个过程可能要一两个月；但是如果对 Kubernetes 不熟悉，需要半年乃至一年。

使用 Cube 的话，就不再需要学习复杂的 Kubernetes知识了，和创建虚拟机一样在 Cube 里面创建一个应用，全部都是图形化的方式。所以，Cube 整个流程只有两步：

• 制作镜像。
• 在 Cube 的界面上直接部署应用就好了。

UCloud 产品经理张鹏波说，“我们有几个用户知道了 Cube 公测，公测以后第一天进行了解，第二天就把自己部署的业务迁移到 Cube 上来了，一天的时间就可以完成业务迁移的工作。”

成本降低

另外在成本方面，我们知道 Kubernetes 是一个大型的分布式集群，除了工作节点以外，还有管理节点。管理节点只是用来管理 Kubernetes 支持的应用，这部分开销实际上从企业角度来看是浪费的。对业务没有起到正向的作用，所以 Kubernetes 成本会比较高。

而对于 Cube，因为只需要为容器实例来付费，容器用了多少资源就付多少钱，不再考虑管理节点的开销、资源预留的问题。

更多的便利性

此外，还有一些其他针对 Kubernetes 自身的一些的改进。在 Cube 整个研发过程中，引入了一些亮点。

第一个是镜像预热，我们知道容器的启动速度其实很快的，基本一秒钟就能拉起来容器实例。但是这是热启动的情况，就是说工作节点上有这个镜像时，拉起来速度是很快的。而在冷启动的情况下，如果虚拟机上没有对应的镜像时，并且镜像非常大时，这个过程就非常缓慢了。我们遇到过最大的镜像有 20G 以上，容器的启动的时间就要花费几分钟。这样，容器本来说快速启动的优势就没有了，比虚拟机还慢了。所以，UCloud 在研发 Cube 的时候，使用了镜像预热的技术，把容器镜像变成 MBD 设备，在容器启动的时候，把它纳入到启动容器的节点上去，省去了镜像拉起的时间，让容器冷启动的时间从以前需要十几分钟变成现在只要几秒钟就拉起来了。

另外，因为 Kubernetes 是由谷歌开源的一项方案，很多理念和大部分企业更加超前一点。所以，在这种设计理念下，Kubernetes 每一个容器在重启以后，容器的 IP 就会变化。而我们知道很多传统的应用设计上是依赖于固定 IP 的，IP 一旦变化整个应用就会出现一些问题。很多用户都希望让容器重启后 IP 保持不变。这对于特别是有状态的服务尤为重要。所以，在 Cube 里面使用了 UCloud 的 EIP 功能，能够让用户容器重启时其 IP 保持不变。

最后，Cube 要兼容原有的运维习惯。传统上，虚拟机和 IDC 里面的物理机在使用体验上是没有什么差别的。有些用户之前业务部署在虚拟机，经常需要在出现问题的时候，直接登录到虚拟机里面去排错，查看一些日志。所以，为了兼容用户以前使用虚拟机的习惯，在 Cube 里面的容器也提供了登录功能，让用户在业务出现问题的时候，能够登录到容器里去快速排查问题。

结语

说实话，关于 Kubernetes 和各种发行版，我们也看过和研究过不少产品了，但是更多的是叶公好龙，没有将自己的应用迁移到 Kubernetes上的想法。一方面对着 Kubernetes 的各种先进特性馋涎欲滴，另外一方面却担心没有足够的精力面对全新的技术变化带来的挑战。

不过，今天看到 UCloud 的 Cube 产品，我决定要去亲自试试这个桃子的味道了。

一段时间以来，IoT 屡屡被各大云厂商提及，不出意外的，作为中国科创板云计算第一股的 UCloud，也在 IoT 领域发力已久，而如今，更是有了新的突破。

上周 UCloud 在上海举办了 2020 年的 ThinkInCloud 2020 大会，很荣幸，我代表 Linux 中国被邀请前往参会。在这次参会过程中，我发现 UCloud 新发布的物联网产品有了一些不同的进展，期间得以和 UCloud 物联网产品负责人钱波先生坐下来畅聊了一番 IoT 及 UCloud 在这方面的新成绩。

钱波，具有多年互联网产品研发经验，当我们聊起 UCloud 此次发布的 IoT 产品矩阵，他饶有兴致地谈起了UCloud在物联网领域所致力的产品与技术方向。作为 UCloud 的产品研发总监、IoT 产品线负责人，长久以来的相关从业经验让他言谈之间，就平添了一番信任感。

宝剑锋从磨砺出

2018 年伊始， UCloud 决定将物联网 IoT 作为一个新的增长点，开始投入人力和物力研发新产品；到 2019 年，UCloud 第一个物联网产品 UIoT Core 发布；再到如今的 UCloud 物联网产品家族正式结束公测，对外开放服务。其中经历的种种，让钱波激情澎湃。对于钱波来说，UCloud 的各种物联网产品，就如同他的孩子一样，从最早的只有基础的设备联网能力功能，到如今云边端的一揽子产品解决方案，UCloud 的物联网产品在一天天长大，一天天变得更加的适用。

钱波说：“物联网想要做好，云、边、端都要做好，一个做的不好，这个物联网就是瘸腿的。”

谈及对物联网的认识，钱波说：“物联网想要做好，云、边、端都要做好，一个做的不好，这个物联网就是瘸腿的。”他补充到，其实一直以来，产业互联网就有自己固有的问题：

• 行业内做上层业务的居多，缺乏广连接高并发的技术经验，导致设备连接多，并发一高平台就挂，结果设备的数据就丢失了；
• 行业内的设备类型很多，导致协议繁杂，无法统一，解决方案实现成本很高；
• 同时，物联网开发涉及到云、硬件、软件等，整个研发链路长，耦合深，企业无法很好的解决项目管理中遇见的种种问题，如架构代码复用；
• 此外，还有一个老大难，就是设备分散严重，老旧设备的改造成本极高。

这些问题，都是产业互联网一直以来的痛点。为了解决这些个痛点，在他的带领下，UCloud IoT 产品团队推出了一系列产品，来解决产业互联网的痛点。

让产业互联网上云不再困难。

为了提供能够承载更高压力的云服务，钱波团队基于 UCloud 的各项公有云能力，为产业互联网提供了 UIoT Core，背靠 UCloud 丰富的云计算资源，为产业互联网提供功能强大、负载能力强的云端物联网底座。

为了解决设备协议繁杂的问题，他们在推出的 UIoT Edge 中提供了业界使用最为广泛的 Modbus 协议的支持，让主流的设备都可以轻松地完成设备的接入，对于一些分散的行业协议，还提供了协议驱动的开源框架，帮助设备快速实现协议并接入。另外，UCloud还将陆续推出DLT645、OPCUA等设备驱动，覆盖更多的产业。

对于研发链路长的问题，UCloud 将整个物联网涉及到的所有资源都基于 UCloud 本身的各项能力来实现。你可以在 UIoT Core 中轻松的调用来自 UCloud 公有云的各项能力，从而让整个流程中涉及到的各项资源更具备一致性。开发者可以轻松的调试各个环节，减少中间服务商的存在。

至于老旧设备的改造问题，UCloud 创新性的提供了一套 UIoT Edge Runtime ，借助设备驱动，帮助产业互联网无侵入地接入设备和实现强大的功能。

为了让开发者们可以更好的基于 UIoT Core 开发产品，他们还调研了国内的开发者在嵌入式操作系统方面的投入，和国内的 RT-Thread 达成了合作，共同推出了 UIoT SDK For RTT，让RT-Thread 开发者可以在 10 分钟内，就完成产品的上云和接入。

借助这些能力，钱波和他的团队让产业互联网上云不再困难。

梅花香自苦寒来

时间的磨砺带来的是 UCloud IoT 产品线的不断壮大。和传统的 IoT 云服务提供商不同，UCloud 提供了很多极具特色又能够帮助到产业互联网企业的重要功能，比如可以解决老旧设备接入的开放协议驱动、可以解决 IoT 设备状态留存的设备影子、可以自由流转数据的规则引擎等等，云端serverless风格的数据解析，一系列的功能都表现出了其产品研发团队强大的实力。而在一些其他物联网服务提供的通用能力中，UCloud也是做得有声有色，如设备生命周期管理、物模型、日志监控等，应有尽有。

整个 UCloud IoT 产品中，令我最为惊艳的是其 UIoT Edge 产品。UIoT Edge 产品所具备的特性，让 UCloud IoT 产品和使用了这些 IoT 产品的场景更具备想象的空间。

在我看来，UIoT Edge 提供的 Modbus 和开放协议，让存量的物联网设备可以更好的接入到 UCloud IoT 体系中，这让产业互联网能以一个较低的成本接入到其中，而不至于完全重新开发。这让产业互联网的接入成为了一个可能，毕竟产业互联网的各种设备其实造价很高，如果要求产业互联网必须完全开发才能使用的话，成本未免太高。开放协议驱动的支持，则让任何产品都可以根据自己的实际需求来完成接入，如果设备不支持 Modbus，就可以直接通过自行编写驱动来完成接入，成本总体来说低于重新打造一批设备。

AIoT，这使得 UIoT Edge 拥有了更大的想象力。

而另一个更好的地方是 UIoT Edge 提供的函数计算环境，这个计算环境为 IoT 设备提供了一个新的可能： AIoT。有了函数计算环境，你可以用来做一些小计算量的边缘数据处理，但同样也可以用来执行一些机器学习的模型计算，从而实现在边缘设备上的计算，从而落地 AIoT，这使得 UIoT Edge 拥有了更大的想象力。

而提到 UIoT Edge 的各项能力，钱波也给我分享了几个案例：

UCloud 的合作伙伴一应科技，拥有多年的物业楼宇系统提供商经验，借助于 UCloud 的 UIoT Core 和 UIoT Edge 产品，将过去的数家厂商设备和云服务整合到了一起。将其底层的边缘设备，比如电气火灾、消防水压、电力监控、人脸识别、视频等，都整合到了一套基于 UIoT物联网中台，并借助于 UCloud 强大的公有云能力，与其应用层的楼宇应用、工单调度、通行应用等整合在了一起。大大的提升了管理的效率，减少了整个环节过程中对不同厂商云的依赖，提升稳定性。而这些，都得益于 UCloud 对于 Modbus、DLT645等协议的支持。

UCloud的合作伙伴晟能科技，长期从事电力能量源领域的解决方案研发，借助于UIoT产品，通过装有UIoT Edge的白盒ARM网关，实现了智能电力表计数据的实时采集与数据上云，扩宽了其项目覆盖能力。

而 AIoT 方面，UCloud 也有客户基于 UIoT和UAI实现了在边缘设备运行视觉检测程序，通过神经网络来判断药片是否符合标准，问题药片的识别和准确性都远超传统方案。

这些案例的分享，也证实了我对于 UIoT Edge 这个产品的看法 —— 前途无量。

另外，在采访中钱波也透露，近期UCloud将推出几款装有UIoT Edge软件的EdgeBox，同时加大行业设备协议接入的研发投入，使聚焦应用侧的开发客户真正做到数据采集的开箱即用；UCloud还将基于公有云的UIoT产品，推出可私有部署的IoT产品，覆盖更多领域，让客户有更多选择。

总结

UCloud 的 IoT 产品矩阵组合拳打得很好，UIoT Core 解决基础底座能力，让设备可以有一个稳定的基础做更多的事情； UIoT Edge 则为产业互联网提供了更多的可能，让 UCloud 的产品可以服务更多的企业，产生更大的价值。对于苦于产业割裂的企业来说， UCloud 的产品，会是一个不错的选择。

似乎每一家互联网公司都有一种属于自己的气质，我接触过很多知名互联网公司的技术专家，其中有一家公司技术专家给了非常深的印象，那就是 UCloud。在和 UCloud 技术专家的沟通中，我深深感受到这是一支极为自信、动手能力很强的技术团队。

近期，我在UCloud上海办公室采访了 UCloud 虚拟网络负责人徐亮，就如同我采访过的很多一线技术领军人物一样，徐亮给我带来的直接印象就是执着、朴实和认真。

说到自己擅长的网络技术领域，徐亮神采飞扬

在和他的谈话中，我听到了不少 UCloud 有趣的研发故事，让我对 UCloud 技术团队的动手能力有了更深的认识。尤其是， 当UCloud 所倡行的“客户为先”、“客户的需求就是我们的下一个产品”等理念从一个专注于前沿技术的技术领军人物的谈吐中汩汩冒出时，印象更深刻了。

转化：实验室技术能力 ➡️➡️➡️ 生产能力

我为什么认为 UCloud 的技术团队是一支动手能力极强，这得从他们的 25G 智能网卡项目说起。

众所周知，如何将实验室形成的技术能力转化成生产能力，需要很好的工程能力，25G 智能网卡从实验室到生产环境恰恰体现了这样的工程能力。

“去年我们将 25G 智能网卡产品投入到生产环境，实际上，UCloud 从 2016 年就开始跟踪这项技术。这期间我们测试了很多厂商的智能网卡，有的智能网卡的性能相当不错。但是阻碍我们将其投入生产环境的一个重要原因是，它和公有云所要求的热迁移的能力不兼容。所以，虽然这些智能网卡的性能很好，但是没有办法应用到公有云环境。”徐亮介绍道。

其实，业界一些公有云厂商很早就在借助这些智能网卡做加速，但是在处理热迁移的时候做不到用户的无感迁移，必须要用户手动修改虚机里面网络的配置。这虽然能够达到目的，但是对用户并不友好。对此，UCloud 秉持一向的态度：“我们一定要做到用户没有额外的负担，这样对用户来说才是最佳的方案，才是成熟的、用户友好的方案。”

据徐亮回忆，情况在 2017 年底出现了一个转机。彼时，Linux 内核社区开始讨论智能网卡如何能够无感的支持热迁移，UCloud 技术团队第一时间进行了深入的技术追踪和研究。从社区开始讨论和开发，最后到 2018 年 5 月份时该功能趋于稳定，才被接受到 Linux 的内核主线里。

“在发现该功能已经基本成熟后，我们马上就把这个补丁应用回 UCloud 的定制内核当中，跟智能网卡厂商一起研究，很快就在实验室完成了该产品。”徐亮接着谈到，“然后我们就开始在线上做公测。这个时候就非常体现我们的工程能力。”

在徐亮的团队将智能网卡投入生产环境时，虽然也发生了一些问题，但是就算在连固件都升级过两次的情况下、对用户的业务并没有产生太大的影响，我想这就是 UCloud 技术团队的工程能力一个重要体现——“我的固件都升级了，而用户业务不受影响。”

驱动：客户为先 ➡️➡️➡️ 工程能力

在我采访的 UCloud 技术人员中，徐亮并不是第一个提到“客户为先”、“客户的需求就是我们下一个产品”等理念的，在与 UCloud 技术副总裁杨镭、私有云和容器产品线负责人叶理灯等人的采访沟通中他们都曾提及这一贯彻于 UCloud 所有技术、产品研发中的理念。他们对于“客户为先”以及在产品的研发、技术专研中的践行，让我深信他们从骨子里认可这样一个价值观。可以说，“用户为先”的理念驱动着其工程能力的形成。

谈到他们的经典网络升级至 VPC 2.0 项目，也许你会理解我说的。

以“客户为先”为出发点

据我了解，UCloud 应该是全球唯一一家把经典网络升级到 VPC 2.0 网络的公有云厂商。在我和多位 UCloud 技术人员的接触中，这个项目被多次提及，它的实施可谓是历经周折，遇到的困难很多。

“我们的出发点是‘客户是不是有这个诉求？这件事情对客户来说是不是有好处？’如果是的话，那我们为什么不做呢？“。当问及项目出发点时，徐亮谈到。显然，如果能够透明的将经典网络升级至 VPC 网络，对于用户来说无疑是有诉求和好处，不需要自行迁移或是同时维护两个架构。但，UCloud 一开始低估了这个项目的难度。

徐亮说，“为什么这么难？因为一个默认的前提条件出现了变化——我们以前假设用户的 IP 是唯一的，这不光体现在网络产品上，还包括数据库产品、存储产品等，都会假设用户的 IP 是唯一的——在之前的经典网络时，该前提条件似乎是显而易见的。但在我们要升级到 VPC 2.0 时，我们突然发现这个 IP 变得不再唯一，由于不同的租户网络是完全隔离的，IP 完全是可以重复的。”

因此，这个项目不再是一个纯粹的网络项目，意味着 UCloud 平台上的所有产品都需要升级，都要支持这个重要变化，所以在工程上存在非常多的协调工作。这是一件非常、非常难的事，是一个涉及到全公司协调的能力。

“客户为先”驱动产品创新

VPC 2.0 项目过程中，徐亮团队还推出了许多创新产品，如 IPv6 地址转换。

公有云里面会有一些公共服务，比如说，像镜像服务、DNS 服务等，所有的客户都可能会访问这些公共服务，而有些客户的 IP 是彼此重叠的，只是 VPC 不同而已。传统上都是采用 NAT 的方式去做的，因为地址是相同的，肯定需要通过 NAT 翻译成不同的地址，然后再去访问公共服务。

但是，NAT 方式有两个问题，一个是公共服务在获取原地址时变得很复杂，它要用 TOA 或其它手段才能够提取出原地址。另外是这是一个有状态的网关，可扩展性会存在一定的问题，有状态的部分容易成为瓶颈，维护状态代价很大。

UCloud 在这方面做了一个创新——徐亮的团队把用户的地址和用户的 VPC 这两个部分信息组合起来，形成一个 128 位的 IPv6 地址，把用户的 IPv4 的请求无状态地转换成了 IPv6 请求，然后发送给这些公共服务。徐亮说，“我们这个无状态转换的思路，是非常创新的。对用户来说，得到的性能很好，同时不需要为此额外增加成本。”

就这样在“用户为先”的驱动下，UCloud 技术团队一点一点的完成了经典网络到 VPC 网络的升级，历时三年。

“我们的初衷就是从客户为先的角度出发，用我们的技术给客户带去价值，在这个基础上我们就认为这件事情值得就去做。”

自省：关于工程能力的三句话

关于对工程能力的理解，徐亮谈到了几句话： “先于客户发现问题”、 “先扛住再优化”、“这件事情能不能做到24小时止血”、“一周之内能不能拿出一个中期解决方案？”… 让我印象深刻，这也是 UCloud 技术团队的实践路线。

“先于客户发现问题”

据徐亮介绍，其团队做可编程交换机的过程中遇到一个非常隐晦的交换机芯片编译器的 BUG，它会发生哈希冲突，从而导致行为不可预期，但是这个问题在实验室是没办法复现出来。历时一个月时间，UCloud 通过在工程上引入全量测试的环节，提前发现了问题。

这件事情之后，徐亮的团队开发了一个新系统，对所有用户虚机点对点通信的信息进行统计，在做变更时就会针对通信过的场景做全量验证。通过这种方式来发现一些因为软件架构变化导致的问题，能够“先于客户发现问题”，在对客户业务没有产生影响的情况下去解决它。

“先扛住再优化”

发现问题第一时间不是去分析根本原因是什么，而要考虑怎样降低对客户的影响，这就是 UCloud 团队常说的“先扛住再优化”。比如说，智能网卡出现故障了，不会先修复智能网卡，肯定是先把用户的业务切走，让用户的业务正常，然后再想办法解决智能网卡的问题。

“这件事情能不能做 24 小时止血”

一旦发生故障就会做复盘，这时候UCloud技术团队最常说的一句话就是“这件事情能不能做24小时止血”。故障对客户是有影响的，我们要在24小时之内先推出一个方案，这个的方案能够让客户降低损失。不光是出现问题的客户，甚至是其他没有出现问题的客户，我们也要在24小时之内拿出一个方案，让这些问题不会影响到客户。

然后，再问‘一周之内能不能拿出一个中期解决方案？’，最后再考虑长期解决方案，长期方案有的时候就真的很长，比如说体系架构设计的不合理、需要进行重构。

结语

在和包括徐亮在内的多位 UCloud 技术领头人在深入沟通后，深切感受到这是一支极为自信、工程能力极强的技术团队，他们敢于尝试新技术，同时其工程能力能在给用户提高价值的同时，保证不出现问题，我相信这是 UCloud 技术团队自信的底气。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。

前段时间，笔者参加了 UCloud 在京举办的 TIC 2019 大会，适逢 UCloud 实验室负责人叶理灯的演讲结束，就容器计算方面和他进行了短暂沟通。叶理灯是国内在云计算方面有深入研究和实践的资深专家，我觉得他的一些观点和看法值得分享给大家了解。

叶理灯，UCloud实验室负责人

叶理灯，UCloud 实验室负责人。现负责 UCloud 创新产品研发，专注面向企业的云计算产品的研发及运营。叶理灯拥有 10 年以上丰富的互联网研发经验，先后任职于腾讯、盛大云等互联网公司，从事海量分布式后台系统研发及运营工作。

定制违背了 K8S 初衷，提供原生 K8S 产品

记者：在官方的 K8S 发行版之上，各方云厂商提供 K8S 服务时都有一些自己的定制和调整，今天大会上提及的 UCloud 的 K8S 发行版 UK8S 主要做了哪些定制，有什么特色呢？

叶理灯：如果说定制 K8S 的话，其实是违背了 K8S 的初衷。我们并没有定制 K8S，我们是基于公有云给用户提供了原生的 K8S 产品。在公有云上提供原生的 K8S，其实要做很多的工作，例如与公有云的计算、网络和存储的整合，给用户提供一个开箱即用的原生K8S集群等等。

我为什么说不应该定制呢？因为大家知道 PaaS 发展到今天，一直存在的一个问题就是供应商绑定的问题。而 K8S 之所以那么有生命力，之所以迅速流行，是因为它提供了一个开源的标准，让用户使用 K8S PaaS 平台，可以避免厂商绑定。也就是说你的服务在某个服务商的 K8S 上运行，可以无缝的迁移到另外一个服务商。

作为云厂商其实最重要的工作是，基于我们自身云平台的体系，提供原生的 K8S 给用户使用，帮助他们减少在集群管理和资源整合方面的工作和投入。例如，我们网络能力、存储能力和计算能力的整合，就是让用户享受到原生K8S的好处，同时避免了很多运维的负担。

公有云的 K8S 处在底层 IaaS 和上层应用之间，一方面向下整合IaaS能力，一方面向上托管客户的应用。在整合 IaaS 方面，不改变 K8S原生特性，因为 K8S 本身架构足够开放，例如在我们实现的网络插件，是基于我们 IaaS 的 VPC 网络，让 pod 可以和我们托管区和物理云区域打通，这是我们 IaaS 能力在 K8S 产品上的体现，算是我们的特色之一，但这是在 K8S 体系支持下的插件方式实现的，不影响我们提供原生 K8S；在应用层面，厂商也可以基于 K8S 提供一些周边的功能以帮助用户提高效率，但它和提供一个一致的 K8S 环境不矛盾。

另外一方面，如果说定制的概念是指基于 K8S 本身开发体系所提供的插件机制去做二次开发，那每家厂商都要定制，因为 K8S 本身不是一个产品级就绪的环境，需要使用者去适配网络和存储还有计算，因为每个公有云厂商基于自己的 IaaS 去提供 K8S 产品，必然要去开发插件。

综上，向用户应该提供原生的、标准的 K8S 产品，但底层应该基于自身 IaaS 平台去定制，本质还是为了提高用户使用 K8S 的效率，让用户开箱即用。

K8S 落地挑战：改造成本和人才问题

记者：你觉得目前国内云厂商提供的 K8S 集群编排服务在推广方面目前欠缺的是什么？是什么阻碍了客户进一步去使用这些容器集群服务？

叶理灯：K8S 以容器技术为核心、以容器镜像为打包标准的特点，意味着如果要迁移到这个体系下，客户需要将软件做容器化打包和微服务改造，这个是有成本的。K8S 的特点决定它是运维和研发之间的桥梁，这样就要求公司的研发过程需要跟着改造。我们看到很多公司的运维人员有动力去推动，而研发人员则没有动力，因为它改变了研发的习惯和流程，增加了负担；当然也有的公司是研发希望用 K8S 管理应用，而需要运维跟着变。这样导致迁移到 K8S 的工作较重，但一旦这个阶段过去了，迁移后的效率和成本优势就体现出来了。

因此，这是个新技术落地的问题，涉及到用户教育和习惯的改变，这个需要社区和商业公司一起完成。而且每家公司的技术路线和文化不一样，上 K8S 的路径也不一样，所以没有一个放之四海皆准的最佳实践，但随着容器和微服务逐渐落地，K8S 作为事实标准，会逐步普及。

除了改造业务的成本，另外一方面是 K8S 人才比较缺乏，不同用户的情况不一样，有些用户的运维人员本来就很少，不可能专门抽出一两个人去做 K8S，以及用户又担心它出问题谁来帮我解决？其实，应该是云厂商再往前走一步，除了帮用户构建一个 K8S 平台，还要帮助解决很多技术上的问题。 UCloud 现在就是这么做的，一个用户进来，我们会拉一个群，他们所有技术问题我们帮他们解决。在落地方面，在人才和 K8S 本身对用户架构改造方面，我们可以多做点工作，帮助客户培养K8S的运维人员和为用户制定架构迁移的方案。但我相信随着技术的发展和普及，越来越多人懂 K8S。

最后，K8S 本身也在发展，K8S 刚推出的时候是为了让大家重新面向应用来运维，但是大部分用户用 K8S 同时管理集群里的节点和应用，就会同时有两个负担。我觉得目标应该是用户直接拿一个容器就可以跑起来，而不用知道它的节点在哪里，即 Serverless 形态。一旦这种技术更加成熟，对容器技术的落地也有很大的推动作用。另一方面，Serverless 形态也给用户节省了大量的成本，按需付费，免去用户的运维成本。我觉得 K8S 的落地已经是个趋势了，是不可避免的，但是 K8S 本身是要往前进步，它的革命还没有完成。

容器与 Serverless：覆盖场景不同，非替换关系

记者：你觉得现在目前 Serverless 的发展对于容器这种创新技术的迭代升级有什么影响？是不是可以让容器更加的轻量化？

叶理灯：不完全是这样，其实 Serverless 刚出现的时候是针对计算的。计算分很多层次，有物理机、虚拟机、容器和 Serverless。Serverless 刚出来的时候，它等同于 FaaS，有一个对标的产品叫 Lambda。

Serverless 出现的动力是，由于云计算的发展，带来了如对象存储等很多丰富的中间件，Serverless 概念的提出是希望应用开发者可以不用写后端逻辑，直接把逻辑写在客户端，组合云上的一些服务来完成业务逻辑，这样就没有管理后端资源的负担了。但是后来发现很多时候还是需要后端代码的，所以就演变成如果有后端代码，就拆成函数，托管在 FaaS 服务中，这样的话，你依然是不用管理服务器的，你用的还是一个个服务，没有服务器管理负担。

这个概念在不断进步，2017 年的时候 AWS 提出了一个新的概念，重新定义了什么叫 Serverless，只要一个服务具备了四方面特性：免运维、按需付费、高可用和自动扩容，这个服务就是个 Serverless 的服务。所以 Serverless 这个概念可以对应 FaaS，也可以代表一种架构，也可以代表一种服务的形态，例如 Aurora Serverless 就是把一个数据库的服务变成 Serverless 的。

容器和 Serverless 的区别在于，Serverless 是无容器的，除了不关注服务器，也看不到容器。两者是面向不同场景的，并不是互相替代的关系。FaaS 的特点，接收一个请求拉起一个函数执行，函数是无状态的，它的执行地点也不固定，这意味着延时相对于常驻进程要高，对一些延时敏感的地方它是不合适的，但是有些场景是非常合适的。我举个例子，在 IoT 场景中，有几十万的设备，为了节省电源，它们大部分时候处于睡眠状态，如果用传统的架构去为这几十万设备服务的话，肯定要考虑并发连接的时候，应该有多少计算资源去服务，这很浪费成本。所以最好的方式，来一个请求就拉一个函数服务一下，这就很节省成本。

这是按需的，但它不是完整的替换，相当于说 IT 领域里面不同的场景其实是使用不同的服务。我们推出这个服务的原因，背后的动力还是成本和效率，在某个场景上用某个解决方案它的成本更低、效率更高，而不是说新的东西会替换老的，因为不同场景需求是不一样的。K8S 接受的用户比 FaaS 的用户更多，因为 K8S 的面更广，它覆盖的场景更多，但是它不是替换的。

记者：目前，国内客户对 Serverless 和 PaaS 的接受和普及程度是怎么样的？

叶理灯：我觉得在国内还是处于起步和用户教育阶段。2014 年 Lambda 推出的时候，它的渗透率是 72%，什么原因呢？有 72% 的人用的 Lambda，我们有个 Serverless 产品叫 UGC，腾讯有 FaaS，阿里也有 PaaS，目前都不算是渗透率很高。

原因有几个。第一、国内用户对新技术接受程度是比较低的，可能是习惯问题，国内的IT的发展水平跟国外也有差距，有 5、6 年差距；其次，对国内用户来说，把一个架构改成 Serverless 架构，其实成本是很高，而且改造的收益和规模相关；最后， FaaS 本身不是一个独立能起作用的产品，你会看到 Lambda 推出时，不是个独立的产品，它是体系的副产品，例如其他产品要开放事件源，通过事件去触发 Lambda 函数执行。只有产品体系开放足够多的事件源，FaaS 才能渗透到整个平台里面去，才能覆盖更多场景。

我们国内的厂商还没有做到这一点。AWS 刚推出 FaaS 时，它主要是 S3 上的图片处理，不是每个用户都有这个场景，因此渗透率不高。随着 API 网关方式调用，和体系开放事件源越来越丰富，覆盖场景越来越多，我相信 FaaS 会逐步落地。

在现场的演讲中，提及了一个叫 USQL 的产品，就是 Serverless 方式的大数据分析工具，StepFlow 用 Serverless 的方式编排你的程序，这些都是 Serverless 的服务。

未来，虚拟化容器值得关注

记者：目前 UK8S 的主要发展方向有什么路线图吗？UK8S 是否已经开源？

叶理灯：有的，例如说我们让 K8S 管理更多的资源、异构的资源，还有物理机、GPU 资源，希望用户可以通过 K8S 对这些资源进行统一地管理。另外，再往业务层面走会提供一些微服务的基础设施，通过产品化，一方面减轻用户的资源负担，另一方面减轻应用层的架构负担，从而尽量减轻用户迁移到 K8S 的负担。

目前 UK8S 插件还属于正在整理开源的阶段，还没有正式的发布，但我们已经小范围的开放了代码，把我们的插件代码分发给到很多用户，但公开的开源，我们希望做的更加规范一点再进行，因为我们的插件还在不断的迭代中，有一天我们觉得达到一定程度的稳定了，我们就会进行公开开源。

记者：你认为未来 K8S 以及容器的技术方向上比较值得重点关注的技术点是什么？

叶理灯：虚拟化容器。未来的方向我们相信是 Serverless，这个也是云计算应该做的，持续地为了用户提高效率和降低成本。刚才我也说了，现在用户使用 K8S 还是有资源管理的负担的，不是完全的面向应用来运维，所以需要解决这个问题，让计算节点对用户透明。用户通过 Docker 镜像和配置文件就可以把一个应用跑起来，而不用去管资源问题。这需要我们去提供一个海量的集群去跑客户的应用，这就存在一个问题，多个客户的应用可能跑在一个节点上，考虑 Docker 本身的隔离问题，我们需要类似虚拟化容器的计算方式去做隔离，同时又希望拥有 Docker 本身轻量级快速启动的效率，现在看来，虚拟化容器是比较符合这个需求的。

尾声

通过和叶理灯的交谈，梳理了我对云计算、容器技术和 Serverless 等方面的一些认识，作为一个几年来亲自践行云计算发展，并有深入探讨和研究的专家，他的观点和认识或许值得从业云计算行业的技术人员参考。

你问我相信什么样的事情？我们相信云计算是长远的。

去年，作为《穿山甲专访》系列采访之一，我们曾经给大家分享过 UCloud 技术副总裁杨镭先生的访谈。那是我和杨镭先生的第一次见面，虽然采访时间不长，但是他务实严谨的风格，也给我留下了深刻的印象。因此，这次又特意预约了他的时间，专程去上海和他深入地聊了一些过去七年 UCloud 的技术价值观理念，并与这位从一线运维跌打滚爬出身的技术领袖的所思所想产生了深切的共鸣。

作为采访者，我也是一位做了二十多年互联网技术工作的老兵，虽然在私交上我和杨镭并不算熟悉，但是随着在互联网、技术和开源方面话题的展开，我们很快就聊得十分投机。

【图：现场采访图】

第一章 一位技术人员的成长史

话题是先从杨镭先生的技术背景和从业经历展开的。

老王：是否可以请先介绍一下你之前的技术背景和你的从业方面的情况？

杨镭：我结合 UCloud 整个技术发展的情况和我自己的情况跟你讲一下。

我的背景是这样的，我 2006 年加入盛大在线，刚入职时我是从最一线的运维人员开始做的，大概两年多以后逐渐地开始参加一些研发的工作，做一些运维的平台系统开发工作。

我跟老季（UCloud CEO 季昕华）是大概 2008 年认识的，他当时在管盛大在线。盛大在线提供运维平台来支撑各个游戏部门的业务，包括像盛大创新院的服务器，其实背后都是由盛大在线提供运维的。在之后做盛大云时，我们承接了非常多的业务部门的运维工作，而当时我就是在做平台技术方面的工作。

那时包括 OpenStack 才刚刚出现，AWS在国内刚被知晓，而我们那时候自己最早做虚拟化都是通过 VMWare 来做的。我们一直在关注云计算的发展。在 2011 年底，老季出来创业时，问我有没有兴趣出来，我就出来了。

我们当时认为，运维应该走到一线去产生业务价值，而云计算正好是可以让做运维、做技术的人能做产品的一个技术。云计算说白了是把以前运维的东西放在台前了，可以去赚钱了。

?从一封未发出的邮件说起…

杨镭：当时我离开盛大的时候，写了一封邮件，但邮件我没发出去，一直存在我的草稿箱里，现在还在。其实我对盛大也是挺有感情的，整个平台都是我们一手搭建的，做了很多很多的事情，还是很辛苦的。

那封信大概的意思是说，云计算真的能解决很多问题，它能让服务器弹性地、不用关机去升级内存和 CPU……还有很多充满想象力的事情，其实这也是 UCloud 的初衷，是我们出来创业的初心，包括老季在内，其实也是这样的，在那个时候我们每次出问题，他都知道，可能是哪个机房的网线插反了，或者哪个服务器配置不小心没搞对，就像蝴蝶效应一样引发了严重的后果。

那时候出来，我们就是想把云这个事情做好。

践行新技术，到处吃螃蟹

杨镭：因为我不是从研发出身的，当时 UCloud 创业的时候也不容易，我们当时除了三个创始人之外，还有五个研发技术人员。当时所有的运维、开发、底层的一些工作，这些我都参与过。

一开始我是做网络方面的研发，当时懂网络的人比较少，而我是做运维出身的。那时还没有 SDN 的概念，我们开始做云计算的时候，当时主流的虚拟化技术是 Xen，KVM 刚进入视野。我那时候很关心 Linux 内核方面的技术，我认为 KVM 一定是有发展的，所以就建议围绕KVM而不是Xen做底层虚拟化，我们一开始采用的 KVM 就是这样来的，结果在后面就少走了很多的弯路。

我主要的一个工作是虚拟机创建流程，这跟我自己之前的一些运维知识也比较匹配，在这方面我做的很多工作主要是优化。这里面其实有一个云计算产品的精髓，云计算产品如果要做好有两方面：

一方面技术要做好，它的可拓展性、稳定性要好，这是从研发的架构层面来看；另一个方面，你要真正地懂这个产品。

比如说云主机，你现在来看很多云计算产品的功能都已经习以为常了，但是 UCloud 一开始做了很多可能现在看起来不同寻常的事情。为什么会做这些事情呢？根本原因在于我们对于运维的理解比较深刻，所以我们敢先做这些功能。比如说当时有一个叫“重装系统”的功能，当时很多云服务商是没有这个功能的——那时候还很早，大约是 2012年的时候——这是我现在回过头来看一开始 UCloud 在那个阶段能冲出来的一个蛮重要的原因。

当时 SDN 也是这样的。在那个时候，很多技术和框架还没有标准的、可以参考的开源实现。比如说做虚拟化，你可以用 KVM 或 Xen 都能做 。因为那个时候我对网络方面一直很感兴趣，我以前主要是做运维，对 IPtables 很熟悉，排查过非常多复杂的现网故障，所以对于IPtables在生产环境中的使用有一定的把握。当时我们就是这样，去 AWS 的 EC2 虚拟机中抓包结合网络上的材料来分析背后的实现方案，然后用最有把握的工具链来实现。我们很快就做了一套自己的 SDN——当时还没有 Open vSwitch，它是 2013 年出来的——而我们当时就很大胆地采用了一个这样的东西。现在你看 UCloud 发布的技术文章、我们把技术实现方式都讲了出去，但是那个时候你只能自己猜和试验。

云计算的问题在于什么呢？它的产品是技术型的，客户用你的产品和服务的时候，你跟客户接触的人员是要懂技术的，尽管我们传统上认为这个事情很多还是商务上、销售上的事情。但是最终你要成就一个优质的客户，因为只有优质的客户，它的业务好，才会更多的买云服务。而优质的客户不光看客户关系的，看的还是你的技术、你的产品和你的人员是不是专业。因为这个原因，所以我后来在整个 UCloud 工作的过程里，不断地在往前走，去做技术支持。那时候我们很重视客户，我去做解决方案架构师，甚至有段时间在事业部参与销售工作，其实是因为被这个问题推着往前走的，包括我现在其实主要的精力也在负责产品以及整体的技术管理这块。

差不多我的技术历程就是这样的，这也是 UCloud 技术这几年发展的一个缩影。

第二章 技术观与价值观

老王：你作为 UCloud 的技术负责人，之前在 TIC 大会上我也听你讲到过 UCloud 的技术价值观的观点，我想了解一下在宏观上、较高层面上你是如何看待云计算技术的发展的，以及这里传达了什么样的价值观？

「能力」——用工程能力解决技术问题

杨镭：接着前面的话题说。尽管在方向上是对的，但是我们还是走了很多小的弯路。我们有一个核心的能力，也是 UCloud 的核心技术能力，就是出现 BUG 或者架构缺陷的时候可以很快地在现网透明地升级解决掉——这实际上是对我们后端的无缝升级能力特别大的挑战。我自己的感受是，一开始讲要这样做时我其实不太相信能做到，但是在第一年，我们就做到了很多这样的事情。

我举个例子，当时我们产品上线以后，做弹性 IP 的实现，一开始很简单，我们搞几台设备，用IPtables实现了弹性IP和内网云主机的映射，放在两台机器上，有故障时候服务自动切换，一切都很美好。但是上线以后就开始发现问题，这两台机器不停地宕机，其实就是出现了 “Kernel Panic”。因为我们一开始只有两台核心网络接入设备，宕机一台就是 50% 的服务不可用，然后客户自然就炸了。但是那时候我们是解决不了这个 “Kernel Panic” 问题的，尽管懂一点内核知识，但是对内核代码层面的问题并不了解，我不知道为什么会发生，虽然我知道肯定是那个方向的问题。

我们搞不定怎么办呢？当时老季和我们 COO 经常在外面和客户解释网络故障的原因，例如中午和客户吃饭，边吃边告诉客户我们出了什么问题，会采取什么样的措施确保不再出现。而在后面，我们做了一件什么事儿呢？我们大概花了 2-3 天的时间，我们把两台集中式的服务器变成分布式的了，因为在物理机上崩溃了之后、服务器就挂了嘛，所以我们把这个服务放到虚拟机里去，每一台物理机上我们放两台。这样比如说到时候这里宕机了，这两台就可以及时切换，而且因为是虚拟机，切换速度很快。我们写了一个自动化地拉起所有服务的脚本。两三天就完成了，就把这个问题救活了。如果当时不解决，可能 UCloud 就挂了。

我们靠这个机制顶了大半年，直到我们的内核负责人来了。最后，发现是什么问题呢？确实是流量带宽控制那里有一个隐藏的 BUG，这个 BUG 其实连 CentOS 都没修复——因为我们用的是 CentOS——它没修复，而我们也搞不定。当时去查找 CentOS 的补丁列表，并没发现有这方面的补丁。到最后是怎么发现的呢？是上游后来发一个修复，但是这个修复 CentOS 一直都没放进来。

你看，这本身是一个非常深入的技术问题，但在创业的时候你不一定能解决，而我们通过架构的优化把它解决掉了，这实际上是 UCloud 从成立第一年开始到现在的一个核心能力。我自己经历过这个事情以后，再遇到什么事情都不怕了。

用架构、用工程能力去解决了一个隐藏很深的技术问题，以成本最小的方法解决问题。

杨镭：这是一种变换的能力。这是整个 UCloud 技术文化所贯穿的一点，先提供一个方案把它解决掉，让我们的服务品质不会降低。而要做到这一点，我觉得最难的是你需要对工程这个事情有深刻的理解。大家都会说工程师很重要、工程能力很重要，但是说实话，就像我开始来到 UCloud 的时候，我也会讲我是工程师，我很自信这一点，但是在我第一年遇到并解决了很多问题以后，我发现自己其实还不太懂。比如说，你看现在最近很火一些知识付费类课程，当我走到那个高度后我跟你说这个事情应该这样，应该那样。但如果你是才进入行业两三年的人，你是听不懂的，你并不知道怎么做，只能知道这句话应该是对的。这句话可能确实是对的，但是在日常工作中，你第一时间是反应不过来的，因为你不会深刻理解这句话。

一开始我们的工程能力就是很强的，因为这个基因来自于创始团队是当时最顶尖的工程团队。云计算天生对稳定的要求特别高，这是非常偏工程化，而这个能力对整个行业的影响是很深远的。

「尝试」——当时胆子真的太大了，走得很前面

杨镭：当时我们遇到的挑战很多，我们一开始第一代用 SDN 白盒交换机的，当时没多想就上了，然后我们遇到了非常多的问题，最早还用过 Open Switch。其实 UCloud 前几年在技术上走的比较靠前，因为我们规模较小，决策更快，而且我们的技术团队胆子也很大，因为对技术团队很自信，对自己的工程能力很自信，所以敢尝试新的技术。比如说在网络层，我们有一套是用的 OVS，还有一套是用白盒交换机，而我们在两套之间还做了无缝地升级。我们的胆子大，所以那时候我们玩的都是新的技术。我还记得我在 2013 年出去做过 SDN 相关的演讲，现在看来当时胆子真的太大了，走得很前面。

那时候大家都知道是趋势，但是到底会怎么发展还没有人敢下定论，就像 Service Mesh 一样，现在绝大多数公司在做研究，在做概念验证，而我们已经在产品环境上跑了，我们走在很前面，有点孤独。

从我自己的角度看，我们那时候技术还是走得很快的。我举一个例子，比如现在有的云服务商要在两个地域之间打通，比如说从北京到香港，一般会告诉你要找第三方的网络供应商帮你打通。而 UCloud 是怎么做的呢？我们在底层有物理专线，用户只要在控制台点一下两边就通了。大概在相当早的时候，我们就提供了两个地域连接打通的功能。现在有的云服务商还需要几天才能为客户打通，而我们只要控制台上点一下，计费之后就通了，两个地域间的虚拟机就全部都互通了。

我记得那时候在这个功能的发布前夕，我们为此做了一整个通宵。在早上 7 点钟的时候，公司有人来上班了，我就在群里发了一条消息，说我们这个搞完了，大家都很激动，虽然现在两个地域之间的云计算服务器连起来是很正常的，但是在那个时候是没有人做的，那时候就感觉很有成就感。

其实好几个 UCloud 早期的研发同事，他们都有类似于跟我一样的事情，只是我当时的领域全部在网络上，而他们的领域在其它的方面。

整个云计算这个事情，它的核心其实是一个技术问题，最终想在这个地方走长远，本质上是要比技术能力的，一不小心就会落后。

我再举一个例子，我们在 2014 年下半年的时候招了第一个做 DPDK 研发的人，那时候我们知道 DPDK 技术发展前景还不错，所以我们招了这个岗位；而到了 2018 年的下半年，如果哪家有云产品而没有 DPDK 技术，你的产品是完全不具备商业竞争力的，你会卖得很贵，性能非常差，而友商会卖得很便宜，性能又很好，这个就是技术的红利。DPDK 的红利，但是如果你当时不投入的话，到现在可能会来不及。这是看三年的，所以我们现在在做 Serverless 方面的工作，投入是比较大的，但是如果我们不投入，可能三年以后或者四五年以后就出局了。

杨镭：我们还做了很多很有意思的事情。比如，很多用户买了云计算的虚拟机以后由于密码不严格被黑掉了，然后就变成肉鸡对外发大量数据包。这个事情很多云服务商的处理是很简单粗暴的，就是把你机器关掉，但客户其实是很受伤的。而我们当时不是这样做的。我们看，它不是对外发包吗？我们在宿主机上打开 TCP 来抓包，比如说 10 秒钟的包——因为不能长抓，长抓的量太大了——把它放到数据库里，然后我们去分析这个 TCP 包的特征、出入的比例，如果只是出站没有入站的话，那就肯定是被利用攻击了嘛。后来我们发现，所有被反射攻击利用的特征都是这样的。我们发现如果符合这个特征，就把这个虚拟机的网络给处理掉——我们会把它的网络给漂走，叫做隔离区，并没有把机器关掉，不会影响其他人，但是他的虚拟机自己还是可以登进去的。我们把这叫做最优选择，但是这个技术上很复杂。

实际上这不是纯技术的问题，这是一个理念，你要懂技术，还要懂业务，还要懂数据分析，还要设计一套东西把它串起来。

我们觉得自豪的一点不是说这个技术很厉害，而是我们的友商没人这样去做。我们做了好几件类似的事情，我们最终带动了行业的发展，客户在 UCloud 里体会到好处以后，他跑到别的云服务商说，你看 UCloud 这样做的，别的云服务商没办法，就被我们反逼提供这样的功能。而且这种功能不是说我们为了超越谁，而是我们自己想出来的。我们自己的研发人员自己关起门来说，对这种事情还是挺自豪，某种意义上我觉得这其实是种创新。

「价值观」——我们相信云计算是长远的

老王：你刚才介绍了 UCloud 的情况，作为技术人员我也觉得很有心向往之的感觉。你觉得目前而言，你们这个四五百人的技术团队的优势主要是在工程能力上还是在你们团队上的技术文化上？

杨镭：从我这个角度，首先这是我们的精髓、文化或者说是技术文化。在这个问题上我们是不允许所谓的不纯粹的。所以在管理上，其实我们对刚才说的这几件事情，我们是要求很高的，如果你新来一个人你在文化上不认同，这个可能不适合你。

还有一方面，我们对整个技术的价值观就像上次我跟你聊的一样，我们会要求很高。我们除了自己不收集，还会帮用户把隐私保护好，告诉用户不要给我们任何的信息，而多数的公司是反过来的。我们大概会在 1 年多后完成大部分云上数据的加密，包括存量的数据。就像我们在去年的 TIC 大会上说的，这里会坚决投入，而且不是一个小的研发投入。因为说白了用户未必自己诉求那么强，很多时候没这个意识。而我们做这个事情因为有很多存量的云主机，几十万台的规模，我们要透明的、不影响性能、安全地放上去，而且密钥还要定期轮换，不能老是一把密钥，但是要轮换的时候又不能影响性能，所以在工程上是有挑战的和有技术深度的。我们做那么多的事情，说白了这就是价值观问题，我们真的对用户的数据安全非常重视。

树立了一个自己的独特价值观，而且为了这个价值观付出了代价、成本。

杨镭：尽管我们现在人不少了，但是我们产品线也很长，我们这点人也是不够的，我们现在做这个事情都在加班做，说白了时间不够，只能花时间解决这种问题。这种事情说白了是在价值观上，你做不做可能没有区别，但是我们认为真正长远地看这个事情是有意义的。眼前不会有太大的得益和收益，但是从长远的趋势看，从我们的信念看，保护隐私、保护数据安全其实是一个所有人都会走向的共同的目标，只是现在还看不到。

所有的这些事情其实都是归纳到一点，你相信什么样的事情？我们相信云计算是长远的。我们跟客户的合作不是做一锤子买卖，我们甚至于对客户都有要求，我们都要做得很优秀，我们要长远看这件事情值不值得做？当然值得做。为什么要看长远？因为我们对自己还是有信心的。其实你的现在是被过去决定的，你现在是为未来做的，所以我们现在在这个层面上想的事情都是三年、五年以后的。现在这些从大势来看，我们做的这些其实都是因为我们前三年做了一些事情，我们坚持了一些事情，因为做了那些事情，我们活了下来了。现在数据隐私这个事情也好，数据安全这个事情也好，或者是很多 Serverless 产品也好，我们相信在那个时代会更重要，所以我们坚持做这个。

第三章 尾声

老王：做这个专访，一方面我们希望看到真正的技术人现在具体做哪些事情。另外一方面我们希望让大家看到有这样的公司在做具体的事情，这些事情会不会对他们产生触动、启发甚至吸引他们去关注或者参与，这是我们希望能进一步做到的东西。

我觉得今天你婉拒了很多采访的邀约而接受我们的专访，我觉得也很荣幸。一方面我们可以持续性地关注你们这边的技术进展，我们把有些可能在你们看来不值得一提，但是在我们看起来可能非常重要或者更有传播和示范意义事件传播给大家。我觉得今天的采访让我确实地了解到了很多我原来没有想到或者没有观察到的地方。

杨镭：我从一个运维人员走到现在，现在做这个事情我才能发现原来是这样的。我觉得我能理解你，因为大家专业不同，我们正好每天在这里做事情，所以就往这个方面想。我希望这篇采访能让大家知道有些事情怎么做更好，只是我们走在了前面一点，我们是这个行业里的人，我们有经验，我们传播出去，这个我很开心，就 OK 了。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。

UCloud 技术副总裁杨镭首谈 UCloudStack、保护客户隐私、回馈开源社区背后的故事和挑战。

日前，Linux 中国社区的老王参加了 UCloud 用户大会，并有幸和 UCloud 技术副总裁杨镭进行了面谈。以下将我们谈话中一些内容分享给大家。

杨镭，UCloud 技术副总裁。全面负责 UCloud 产品研发和产品运营工作，有超过十年 IT & 互联网行业从业经验，在网络领域拥有丰富的经验和深刻的理解。

为什么专门开发了 UCloudStack？

今天的大会上面您提出一个针对私有云的 UCloudStack，是否可以给我们详细介绍一下为什么在有了生态很成熟的 OpenStack 的情况下，UCloud 还投入了巨大的资源去研发UCloudStack？

杨镭：

我们在 OpenStack 上做的还比较早的，当时我们的认知就是公有云是公有云，而私有云 OpenStack 做的比较好。但实际上，通过不断的时间验证，我们发现 OpenStack 有一个比较大的问题，就是过于复杂。

回到用户对私有云需求来讲，用户实际上关注的还是能不能解决他的需求，而不是说要不要用 OpenStack。所以，我们考虑到，既然已经有了多年的云计算的开发和运维经验，如果从头开始做一个自己的私有云产品，是不是会做的更好？

我们做了 16 个月就做出来了这个产品，在完成核心产品之后，整体的代码量还是很少的。代码量是相对来讲是衡量一个项目复杂性的很好的指标。我们根据自己这么多年来的经验做下来，我们发现这个事情并没有那么的难，而且，现在这个时候，在做这个产品的时候认知就和几年前不太一样，我们会比以前想的成熟很多。我们相信做出来的东西会比 OpenStack 更轻量、更好用，这是我们做这个产品的一个主要的想法。

其实现在真正能自己独立用 OpenStack 产品的公司一般都有一个一定规模研发的团队，至少十个人。但是云计算这个市场的人才竞争还是蛮厉害的，一个公司很难有这样一群比较好的人去做这个事情，所以它的门槛会很高。如果说公司的目标只是为了有一个私有云，那么这样研发投入的必要性是打问号的。这些企业的目标和我们云服务商的目标不一样，它的云只是一个工具，不像我们的云是我们本身的一个产品。所以这时实际上企业往往会考虑说怎么能把这个私有云更好的建起来，很快、很稳定的用起来，在成本上比较合理。所以在我们的这个产品上，我们最重要的一个点确实就是在轻量上。

假如你对 OpenStack 需要做一些改动，是牵一发而动全身的，为了做某个功能可能要改造底层的东西，这个时候整个过程在研发上来讲就太“重”了，所以我们如果从零开始做，其实我们的底层就是可控的。我们在第一次推出的时候，我们总的代码量才八九万行，而 OpenStack 所有项目代码量加起来有几千万行，这之间的复杂性灵活性是完全不能比拟的，这是它的一个轻的主要原因。

另外一个，因为我们做这个产品的目的性会比做一个开源的社区项目更明确一点，比如说我们做产品的路线很不一样。当我们的核心产品完成以后，我们做的一个比较大的改变是和传统的网络打通，我们 UCloudStack 部署完了以后和传统的网络做很大的打通，这点和开源社区项目的目标不一样，它要让这个东西更加通用。这在产品的改变选择的路径差别特别大。这个时候看用户要什么，往往用户要的东西更贴近它想要的，这里面也是一个很大差异点。

今天本来想放一段视频，那段视频是当时在富士康的办公园区里面拍的，当时是下午四点钟进入机房到晚上十点种整个私有云的交付就完成了。而且当中大概有 2-3 个小时是因为机房的一些问题影响了整个的进度，如果看到那个视频就会真正感觉到它很轻，但一般而言 OpenStack 部署起来时间会更长，比如说好几天的时间，它的底层太复杂了。

我们一直认同的一点是说，开源软件比较适合做一个组件，比如说一个数据库、一个操作系统、一个很垂直的部分。但是云实际上不是一个垂直的组件，而是很多组件组成在一起的一个体系。如果你去用开源软件做组件的方式去做云，这其实不是特别的理想。

为什么将客户隐私保护拔高到这样的高度？

今天上午大会上您提到一个隐私的产品，禁止一些 API 采集用户数据，来保护用户的隐私，这方面能够详细谈谈吗？

杨镭：

这个我需要澄清一下，我们说的是禁止我们的云平台收集我们客户的信息，而不是说我们禁止了客户收集他的用户信息。因为我们是给企业提供服务的，企业本身给他的终端用户提供服务，我们控制的是我们和企业之间数据的隐私问题。比如说它的使用习惯是什么，或者它业务的模型是什么，我们在控制这个。

因为我们自己是做云服务的，我们的技术工程师在管理我们云业务的时候，实际上是有可能看到用户的数据。比如说你是一个电商公司，假设你的数据库如果没有进行加密，技术人员是可以看到这个数据的。目前来讲绝大多数的厂商，靠的还是流程和制度，靠的不是技术手段保护。什么叫技术手段，就是说我想看却看不到，因为是加密的。你只有拿到相应的解密密钥才能去看。我们说的数据保护更多的是这方面。

再比如说我们的云主机最终跑在 SSD 硬盘上，如果你去机房里把硬盘直接拔插走，而没有加密的话，一定是能读到里面的数据。从长远来看，这是不能出任何问题的，哪怕是一两次。像某互联网公司出了几次乘客的安全事件以后，事情影响就非常恶劣。回到做云服务，我们的责任一样重大。我们如果只是一家公司，也许我有的只是很特定的一些数据，但是作为做云服务的公司，我们上面的客户不是我们能决定的，要看客户自己做什么业务，所以我们上面有几十万，甚至几百万的数据，这是一个非常长远、需要很认真对待的事情。所以我们把这一点放到了一个很高的、甚至于到我们企业文化和价值观的角度。

作为一个工程师来讲，首先我们要有价值观，这是第一点，但是也要从技术上保证，所以我们未来会在这方面投入很多的技术研发工作，来实现比如说我们自己的技术工程师没有任何可能能看到我们客户数据。这里面实际上是有很多的技术工作要做的。

在我们刚刚做云的前两年，那时候如果去对数据做加密，就会严重影响到性能。这个时候你很难两者兼得，但是随着这几年的技术的演进，很多的加密算法被逐渐的优化以后，基本能做到做了加密也不怎么会影响性能。所以现在这个时代，是一个非常好的时机，是一个你应该要去做这件事的时机。

整个这个事情大概我们是这样看的。除了数据的加密，包括用户有时候会输入给我们很多数据，他在做一些操作需要提供身份信息，比如说现在网络安全法要求用户使用要做实名认证，也就是说他的身份证会上传到我们这儿，这些数据其实是一个很隐私的数据。这件信息的泄露是一次都不能发生的，所以我们如果回到最根本的来说，我们怎么样尊重我们的用户？这个事情其实比一些产品功能更重要。

我们不希望出了事故以后我们再做一些补救的工作，那时候即使你是真的去做，你的用户也已经受到了很大的伤害。

另外一个层面，我今天没有提到，因为云计算的公司，我们特别需要最顶尖的技术人才，我们这么多年来在吸引最顶尖的人才上我们逐渐意识到靠的不是钱、待遇，或者是一些职位。最优秀的顶尖技术人才，看的是你公司的理念和价值观，比如说谷歌、苹果他们有非常多的几十年的行业人才在里面，为什么？他们做的工作就是数据安全性、隐私就这方面的工作。所以我们也是在商业的进化过程中，我们发现要做一家几十年的公司，不是靠一两年的财报，而是靠这些背后的东西，这是我们很真实的一个自己成长的过程。

对开源社区的回馈

我们非常关注 UCloud 在采用开源软件方面的情况，云服务商的很多基础设施都是基于开源软件的。目前UCloud在开源方面对上游社区的贡献情况怎么样？

杨镭：

我们目前在开源方面目前做的工作还不多。但是为什么不多？不是我们不想做，而是因为我们处在一个技术竞争特别激烈的行业里面，你的产品实际上卖的都是技术。我们的技术人员这么多年来其实一直不太够用，所以我们绝大多数的精力是在做我们自己不得不做的事情，比如说今天说的网络架构的透明升级，这个事情实际上把我们的核心人员的精力全部消耗掉了。为了这些升级，我们要跟客户沟通好这个事情让客户放心我们才能做，这也是为什么我们会做 29 个月的原因，其中有 9 个月是跟客户沟通的过程中。我们的人并不是很多，我们对自己产品的要求还是蛮高的，在这两个因素影响下，我们也很难拆出精力来更多的主动回馈社区。

但是这一点上我们想法是很明确的，只要我们现在有精力就会回馈社区。比如说这次做的 25G 的网卡，这个解决了一个核心障碍，我们把这个东西交给上游，但是从整个公司来讲这块投的人员和精力还不是很多。像我们开源的命令行工具，我们和 Hashicorp 做的整合，这些我们全部开源了，但是这些还远远不够。其实开源，也是想让用户知道你的代码到底怎么写的，只是说这里面是一个精力问题，不是意愿问题。

我们在 2013 年做了一个内核模块，是可以把 SSD 盘加速 100 多倍，由于一些原因，我们的代码是针对某些特定场景的。同时在代码的规范上也做了一点牺牲，如果要开源，相当于要额外增加 30% 的工作量。但是我们现在一直在想，就像今天举的例子，把很多东西开源，尽量的变成工具化，而不是放在 UCloud 的内部一个产品，只是我们精力不太够。

最近 Redis、Kafka、ES 这样的软件都在许可件上改了自己原来的开源许可证，针对云服务商提出了特别的条款。比如说云服务商用 Redis给客户提供服务，但是很少对 Redis 进行社区回馈，所以云服务商需要额外采购商业许可证，您怎么看这个事情，UCloud 怎么面对这个情况？

杨镭：

目前来看，我觉得确实云服务商对社区的回馈是偏少的，所以说我觉得 Kafka 和 Redis 在这个事情上他们是有一定的道理。但这个事情也不能单方面的看待，因为实际上云厂商在推出 Kafka、Redis、ES 产品时，其实也帮这些开源软件做了很多的推广。Redis 比较简单，Kafka 或者是 ES，其实还是一个蛮复杂的软件。云厂商将这些组件加入平台后，把最复杂的地方把简化了，用户甚至连性能维护都不用考虑，另一个维度来看相当于推广了 Kafka。我认为云厂商或者是以此谋利的厂商，他应该做足够的回馈，不管你是以钱的方式，还是以研发的方式，我觉得是应该回馈的。

和杨镭的沟通当中，我们还谈到了许多其他问题，这里限于篇幅就不展开叙述了。从上面的谈话当中，我们能感受到 UCloud 做为一家新兴发展起来的初创公司，无论是在技术还是企业价值观方面，逐渐形成了自己独有的优势。其实作为 UCloud 多年的老朋友，这次参加这个大会，让我意外的是，原来我对他们的了解还所知甚少；也为他们在隐私保护、技术研发等方面默默做的工作而吃惊。希望这些技术人可以秉持初心，真正做出一个好用、值得用的产品来。

“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。

取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。