蚂蚁金服的 SOFAStack 作为一个成功地将企业私有项目转化为开源核心模式的知名案例，我们之前对背后的思考和推动力做过专题分析，但是具体这件事是如何在蚂蚁金服内部发生的、是如何实操的，有很多读者向我们表示非常感兴趣，而我觉得这也是其它技术公司所正在探索和思考的方向。

因此，上个月底，老王在参加上海举办的 KubeCon 2019 时，遇到了蚂蚁金服 SOFA 团队的余淮，他目前在蚂蚁金服中间件团队服务与框架组具体负责开发框架与 SOFAStack 的开源工作。于是，参会之余，我和余淮就 SOFA 开源的实操方面进行了深入的沟通，现将谈话所得整理给大家。

SOFA 与开源

2018 年，SOFAStack 开始开源之后，处于关注，我曾向蚂蚁金服中间件负责人杨冰了解过为什么要将 SOFA 开源的背后思考，以及 SOFA 发展迭代的历程。

目前，SOFA 的架构已经发展到 SOFA 5 阶段，前任的 SOFA 开源负责人鲁直也向我介绍过 SOFA 5 中重点推进的方向，主要包括 Service Mesh 和 Serverless，以及分布式事务 Seata 的落地等。而在今年上半年他们又开源了分布式事务框架 Seata 和服务注册中心 SOFARegistry。

作为一个成功的开源核心模式的项目，我非常关注 SOFA 开源的实操是如何进行的，是如何进行开源治理的，作为 SOFA 团队的老朋友，我们话题就直接从 SOFA 的开源治理聊起。

以 SOFA 为例：公司内部软件的开源流程

余淮说，从 2015 年开始，蚂蚁金服开启了金融科技对外输出的战略，SOFAStack 也走出了蚂蚁金服，甚至跨越了国界，被更多金融机构与合作伙伴所使用，如天弘基金、信美互信、南京银行、PayTM、DANA 钱包等。

在与合作伙伴以及客户的沟通、合作过程中，他们发现了 SOFAStack 的理念和能力也正是很多金融行业的企业所需要的。在蚂蚁金融科技对外输出的过程中，内部已经对 SOFAStack 进行了一定程度的代码重构，例如历史兼容逻辑的剥离等，但是并未能达到直接开源的标准。

关于开源，其内部一直有开源的讨论，到 2017 年双十一结束后正式决定开源。经过了一系列的准备，2018 年 4 月，完成了对 SOFA 项目的满足了开源改造的标准后，SOFAStack 马上宣布正式开源框架中部分重要组件。

SOFA 团队给开源定的策略叫「 开源核心 （ Open Core ） 」，顾名思义就是要将接口层以及核心实现都开源，以可扩展化的方式来层层构建 SOFAStack 的能力，保证 SOFAStack 的内部版本和开源的版本采用的是同一个内核。为此 SOFAStack 做了大量的改造和重构工作。

在开源的具体考量上，余淮表示，SOFAStack 的开源改造基本上有三条原则，分别是高可扩展性、对内兼容历史版本、对外兼容业界标准。

以 SOFARPC 重构为例，大概经历了这样的过程：

1. 首先需要将 SOFARPC 进行了一次核心接口和模型抽象，然后增加了扩展点机制和事件总线机制，所有的对内、对外实现都基于这些核心接口和模型去扩展，并且保证这些扩展能力都是平等的、可选的；
2. 接着将核心的处理逻辑实现迁移到这套接口和模型上来，保证 RPC 能力完整可用；
3. 然后需要将 RPC 里一些对接内部系统的、兼容历史逻辑的代码做成内部扩展，并进行全量测试验证，确保和已有线上的历史方案的兼容，发布上线；
4. 最后会调研业界的一些开源标准方案和实现，并对其进行兼容，例如 SOFARPC 不仅对接自己的 SOFARegistry 的实现，还兼容了 Zookeeper、Etcd、Nacos 等业界优秀的注册中心方案。

虽然上面重构过程听上去没那么复杂，但是在实际过程中还是非常考验团队的技术能力的，特别是在抽象核心接口和模型的时候，为了做到既兼容内部又兼容外部，这需要进行大量的调研工作，才能做好这层较为通用抽象。其次在对内逻辑兼容的时候，由于内部的历史负担还是比较重的，为了能让重构的代码安全上线，团队也做了很多事情。

还是举 SOFARPC 的例子，蚂蚁内部的服务路由过程比开源是要复杂很多的，特别是配合蚂蚁特有的单元化部署以及异地多活的能力，有时候需要多层路由才能找到目标地址。为了验证重构后逻辑的正确性，除了在开源代码里有单元测试用例外，SOFA 团队在内部也构建了一套非常完善的集成框架，专门用来测试已有逻辑的兼容性及正确性。

基于开源核心这套思想建设 SOFAStack 以后，其实对开发人员的工作量来不会变少，反而可能是增多的。这是因为在写代码的同时，需要更多的考虑内部外部的使用情况，对代码质量也提出了更高的要求，开发流程会变得更加复杂。

例如，内部新增一个特性，在以前可能直接修改代码经过测试就发布上线了，但现在的话会去思考这其中哪些能力是通用的，把这些能力抽象一下放到开源版本里去，然后开源版测试后发布，这个时候内部版本在基于这个开源版进行扩展，再经过测试后发布上线。

虽然开发人员工作变多了，但是这样的话可以让 SOFAStack 的核心代码被更多的开发者评审，在更多的系统中运行，在更多的场景下进行验证，对 SOFAStack 的品质保证有非常大的帮助。

此外在开源进度上，余淮表示， SOFAStack 并不追求开源全部内部的组件，而是会根据产品的特性和开源准备的情况有选择的开源。

例如 SOFAStack 下的分库、分表组件，因为产品特性和 OB 等内部结合紧密就暂时不会开源。金融级分布式架构下未开源部分能力，SOFAStack 会和与业界其它优秀的开源项目做集成，保证整个金融级分布式架构功能的完整性和多样性。

所以对于 SOFAStack 来说，并不只有自己开源的产品，而更多关注的是，和整个社区里所有开源优秀的产品一起，打造一套快速构建金融级分布式架构的套件。

开源项目的管理

开源一个项目，作为背后推动的公司事实上要付出相当多的人力和资金成本，同时，也不可避免的会涉及到审批流程。随着蚂蚁金服越来越多领域的项目开源，包括 SOFAStack、AI、区块链等，蚂蚁金服内部出台了相应的严格的审核机制，包括技术、合规、法务、安全等部门进行审核，同时还会考察项目开源对公司的意义，以及是否对社区有价值，在审核通过之后项目就会正式开源与大家见面了。

蚂蚁金服对于开源文化是十分友好的，其内部的代码也大多都是公开在内网的 GitLab 仓库，经常会有业务团队对 SOFAStack 提交一些合并请求（拉取请求）来帮助项目的发展。

同时，蚂蚁金服的工程师也普遍地拥抱开源，开源能够帮助项目产生更多、更好的想法，同时也可以吸收来自社区的贡献，让项目本身能够做的更好，这是大家所喜闻乐见的。

SOFA 的社区治理

开源项目并不是开放源代码就是终点，事实上，这只是开始，之后持续不断的开源治理才是开源之路。而如何将一个开源项目从最开始的由开源项目背后的公司主导转变为社区性项目，这是一个值得思考和探索的课题。

基于目前的开源模式和社区建设力度，SOFA 团队也在尽可能去吸引外部的贡献者。不过 SOFAStack 项目由于大量应用在蚂蚁金服及不少企业线上环境，所以目前对于开发者技术能力以及代码质量要求相对较高，因此，这项任务还需要较多的工作。

目前 SOFA 社区已经涌现了不少积极的开发者和贡献者，解决了社区提出的一些重要需求。这其中一些功能组件的完成，贡献者提供了相当重要的代码基础，而 SOFA 社区成员也积极参与到功能的完善和规范化工作中，甚至有的拉取请求要经过十几个来回才能被合并入功能分支。

余淮同时也谈到，下一步会引入更友好的流程和工具，让更多的开发者能够更容易地加入到 SOFAStack 社区的开发和贡献当中，为 SOFAStack 的共同发展做出包括贡献代码、文档完善和推广宣传等各个方面的贡献。

在社区团队方面，SOFAStack 也设计了诸如 贡献者 （ Contributor ） 、 提交者 （ Committer ） 、 委员会成员 （ PMC ） 等多个层面的贡献者认证机制，以让各个层级的热情、精力不同的人能够加入到项目的贡献中。

SOFAStack 开源至今社区已经有 120 多位贡献者共建社区，也有十来位外部提交者通过其贡献的代码获得社区的认可，并进一步取得对社区发展的影响力。谈及这一点，余淮表示，为了保证代码质量，来自社区的代码贡献往往需要 SOFAStack 社区已有成员和贡献者许多次的往复修改和完善才能进入到代码主干，但是通过这些互动，才能真正遴选出来社区的中坚分子，也进一步将项目融入到社区中。

在社区建设方面，除了在 Github 上、钉钉微信群的一些交流外，SOFAStack 社区还会有丰富的线上线下的活动。每周类似周报形式的 SOFA Weekly，帮助大家了解社区的最新资讯和项目进展；社区共建的 SOFALab 源码解析实验室，和社区同学一起学习和解析源码，整理成册，帮助大家更好的学习项目；每月若干次的 SOFAChannel 直播，可以在线和讲师进行沟通交流。与此同时，SOFAStack 也会定期在全国各地举行线下的 SOFAMeetup 活动，大家一起面对面交流，目前已经在全国五个城市举办了 7 场，共有一千多人到现场；也会举办 Workshop 和 CodeLab 等实践类的活动，像本次的 KubeCon 就有一场 Workshop，手把手带着大家一起实践 SOFAStack。

在社区合作方面，社区里有很多优秀的开发者和开源项目，SOFA 团队也经常和社区互相学习、分享、交流技术，目前SOFAStack 已经和很多开源社群建立了良好的关系，包括国内 ServiceMesher，K8S 中国，ShardingSephere，SkyWalking，Ant Design，EggJS 等，也包括国外的 light4j 等。

此外，余淮还谈到，SOFAStack 在今年还会结合实际业务方面和开源社区做更多的能力整合提升，他举例说到 SOFAStack 今年会和做 Spring Cloud 更深入的集成和增强，例如 Spring Cloud 还是文件级别的配置更新，配合 SOFAStack可以做到更细粒度的配置更新等。

总结

要说我对哪个国内开源项目研究的最深入，那非 SOFAStack 莫属。自从 SOFAStack 开源以来，我先后和杨冰、鲁直从 SOFA 开源的思想、战略层面进行过深入沟通，而这次，我希望可以从战术上，从实操层面分享他们在 SOFA 开源方面的经验给广大的开源社区和开源企业。

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

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

在国内的云服务市场当中，青云QingCloud 一直是一个积极活跃的身影，但是我却从来没有和他们直接接触过，而在上个月刚刚结束的 KubeCon 2019 上，我见到了江湖人称“四爷”的青云QingCloud 容器平台负责人周小四。自以为尚不算健谈的我，跟人聊起技术来，居然聊得非常投机。期间，我和四爷聊起了 KubeSphere 容器平台，也对青云QingCloud 的容器战略有了一些管中窥豹的了解。我想将这些谈话整理出来分享给大家，希望可以通过我的侧写让大家也认识一下这位“四爷”和他的团队打造的 KubeSphere。

谈话自然是从我所不了解的青云QingCloud 开始的。

天然的企业服务提供者

说起青云QingCloud，自然不能放过其背后的历史，这段与众不同的历史，造就了这家与众不同的云计算企业。

谈起云计算，大家会想起国内公有云市场占有率较高的一些互联网公司旗下的云服务商，这些公司的云计算业务最初大多是从内部的云计算技术能力转化出来的，将其在内部打造的云计算能力开放给公众，从而形成了我们所熟悉的多个云计算平台。

青云QingCloud 从一开始就走上了和绝大多数云计算创业企业不同的道路——自研云计算架构。

“与这些云计算公司不同，青云QingCloud 从 2012 年公司创立的那一刻开始，就是一个立足于为企业服务的云计算企业，其三位创始人均有多年在 IBM 工作的深厚背景，使得他们对于企业级用户的市场和用户的需求更加敏感，也能更加准确把握企业用户的需求和痛点。”四爷介绍说，“并且，青云QingCloud 的创始人均是资深的技术研发出身，对于技术方向的发展更加敏感，也正是如此，青云从一开始就走上了和绝大多数云计算创业企业不同的道路——自研云计算架构。”说到这里，四爷眼中洋溢着自信的眼神，作为一个同样从事了多年技术工作的老兵，我对这种技术驱动型的公司更加感兴趣了。

私有云成就下的青云

从 2012 年开始，青云QingCloud 便开始进行自研底层云计算架构的研究。自研架构所需要付出的技术成本，使得青云的公有云服务上线花费了一年半的时间，但是，付出总有回报，在自研架构上的投入，使得青云QingCloud更加灵活和富有创造力，可以更加专心地为企业提供更优质的服务。

而同时期一些使用 OpenStack 作为基础设施的云计算企业，却受制于社区的发展速度，不得不在底层基础设施的优化上花费大量的精力。说到这里，四爷表示，“这为青云争取到了宝贵的时间！”

到了 2014 年，青云QingCloud 已经取得了长足的发展。这个时候他们意识到，在当时的环境下只做公有云服务是“一条腿走路”，无法获得长时间的可持续发展，而私有云服务能够更好的发挥青云QingCloud 在企业服务的能力和经验。因此，青云开始正式进军私有云市场，并在次年年初，成功拿下中国银行、招商银行等的私有云业务。

随着青云QingCloud 的私有云业务的发展一路开疆拓土，他们逐渐建立起来成熟完善的公有云、私有云、托管云、混合云一体化的产品服务体系，后续不断得到越来越多客户的认可，我们耳熟能详的光大银行、泰康保险、中国太平、江苏交通控股、华润创业、本钢集团、国航、四川航空、好未来、VIPKID 等，都是青云的客户。

在云业务一片向好的环境下，容器时代正在悄悄的来临了。

容器时代来临，KubeSphere 应运而生

容器时代的到来，让各家云服务商都开始积极布局容器服务，而在青云QingCloud，容器服务的负责人便是我们今天谈话的主角周小四——圈内亲切的称其为“四爷”。

从 Docker 开始

在当时，开源社区内的主流容器方案，一种是一出现就迅速风靡技术世界的 Docker 技术，另一个则是同样源自 CGroup 技术的 LXC。那个时候，看起来 LXC 的目标更远大，但是在对这两种技术方向进行分析后，最终四爷选择了 Docker 的方案。

我们也曾经在容器技术初现萌芽时，对出现的各种容器技术做过跟踪，因此，我也好奇为什么四爷会在 Docker 技术初生时就押注 Docker，因为这不仅仅是社区爱好，这个决策肯定会影响到公司的技术方向和时间差优势。

四爷对此的解释说，“2013 年才提出的 Docker 虽然很年轻，但是作为一个新的容器化解决方案，它所提出的解决方案适合这个面向应用、快速迭代、微服务正在兴起的大趋势，符合并适合现行的软件开发模式发展，可以让技术把更多的精力放在如何构建一个更好的应用上。”而 LXC 则延续了重型虚拟机时代的思路，将更多的精力放在了如何更好的隔离宿主环境与容器内的环境上。这很重要，但是已经不再适合如今快节奏、快迭代的开发环境了，因此，他认为 Docker 一定会是最终的胜利者，决定选择 Docker 作为青云QingCloud 容器服务平台的底层设施。

虽然现在回过头看，Docker 容器技术在初期确实存在容器逃逸的安全问题，如今也有专注于提高隔离性的安全容器技术的出现，但是在当时，这种折中确实极大地激发了 DevOps 和相关生态的迅速发展。而正当其时，能敏锐地发现这一点，并果断下注，我认为这离不开一位技术领袖的远瞻。

在选择了容器技术方向之后，四爷的下一个挑战就来了。Docker 最初主要是一个容器引擎，其外围的生态尚不完善，尤其是对于企业大规模应用所需要的容器编排才刚刚开始获得发展。业界也推出几种不同的容器编排技术方案，这包括 Docker 推出的 Swarm、Google 推出的 Kubernetes，以及 Apache Mesos，那么作为面对企业提供服务的青云QingCloud，该如何选择呢？

押注 Kubernetes

现在看起来，当初四爷选择 Kubernetes 作为技术方向似乎是在技术人直觉之下做的选择。但是，这背后是经过了深思熟虑和足够的技术远见之下的选择。

四爷告诉我，他选择 Kubernetes 的主要原因有以下几点：

1. Kubernetes 背后由 Google 支持：显然 Google 支持的 Kubernetes 会拥有更多的资源来发展，它也拥有更加强大的生命力。
2. Kubernetes 是 Google 在内部基础设施的容器编排方面的经验升华：Kubernetes 的应用场景是容器编排，这种大规模容器的实践经验十分难得。而 Google 作为互联网领域的巨鳄，所拥有的经验和技术积累具有无可比拟的优势。相比之下，初创企业 Docker 公司在海量的可伸缩服务上的经验就稍显孱弱。而且 Docker 公司本身的开发力量显然有限，在容器技术日新月异的快节奏发展之下，仅仅是 Docker 引擎本身的开发和维护就已经有些不堪负荷，所以对他们在 Docker Swarm 上发展自然不如 Kubernetes 那么快。
3. Kubernetes 的社区更加活跃：得益于 Google、Red Hat 等企业的开源社区基础，Kubernetes 从一开始就是整个社区目光的焦点，大量的开发者活跃在 Kubernetes 及其周边项目上，活跃的社区为企业培养了足够的储备人才，这一点是 Docker Swarm 和 Mesos 都无法比拟的。
4. 容器时代已经与以虚机为基础的云计算时代有着本质的区别，以前人们关注的是功能、性能、安全等问题，创建一个虚机每个厂商可以用不同的 API 提供，用户要的是资源，不会太在意这些差异性，因此自研的云平台有存在的市场空间。但容器时代是面向应用的，用户更关注的是开放、标准等问题。简单来说，如果大家都用 Java 语言，你去采用一个只能使用汇编语言的平台，这个平台基本上很难有市场。容器编排系统一样，用 YAML 或 JSON 定义的声明式接口就是标准，大家害怕的就是选错标准。所以当大家都选择 Kubernetes 的时候，实际上选择的是标准。

经过权衡，四爷及其团队最终选择了 Kubernetes 作为青云QingCloud容器平台的编排工具。而随着对 Kubernetes 的不断的深入研究，更是让他相信，Kubernetes 会成为最终的胜利者。

他补充道：“Kubernetes 的一个主要关注是规范化，应用可以随意的在不同的基础设施间迁移，从而避免了供应商锁定。这会使得越来越多的人主动尝试使用 Kubernetes，此长彼消之下，Kubernetes 会成为最终的赢家。”

KubeSphere 的诞生

确定了 Kubernetes 方向后，四爷开始对各个 Kubernetes 产品进行了调研。通过不断试用、体验后，他敏锐的发现，现有市场上大多数厂商都没有认真做产品，要么是为了尽快抢占市场、在市场上发布尚不完善的产品，要么就是厂商的防御性产品。

“他们是以做项目的心态在做产品，没有精细化地打磨产品，更多的是功能的堆砌。”周小四解释到。

“就好像考试做题，一共十道题，每道题 10 分。他们可以做八道题，但是因为做得不好，每道题都只能得五分。而我们即使只做了 6 道题，但是每道题都是 10 分。最后的总分还是我们高，企业还是会选择我们。”四爷举了一个例子来说明“做项目”和“做产品”的不同。

在他看来，也正是这些企业以“做项目”的心态来做容器产品，才给了 KubeSphere 弯道超车的机会，以满分的心态，做出更好的产品。

从 2017 年 6 月开始，周小四便开始调研和思考如何设计 KubeSphere 的原型。2018 年 4 月，KubeSphere 项目正式立项，经过了三个月的苦干，终于在同年 6 月正式发布了 KubeSphere 的社区版，并邀请了部分用户进行内测。

精细化打磨的 KubeSphere 得到了用户的很多好评。而这一切并没有让 KubeSphere 团队止步，他们又进行了 5 个月的研发迭代，继而在 2018 年的 12 月发布了 KubeSphere 高级版，并进入了公测期。KubeSphere 团队吸收了在社区版上积累的经验，高级版将更多的精力放在企业用户的专业性、高可用性、易用性需求上。而就在前不久的 4 月发布的 KubeSphere 高级版 2.0 中，融合了更多的企业级特性。

四爷向我介绍说，KubeSphere 容器平台在企业增强特性上主要可总结为四点：

• 极简：向导式图形化的 UI 全方位覆盖调度、管理、运维监控等功能，低学习成本高效使用。
• 安全：基于微服务级别细粒度的多租户权限管理，完美实现资源隔离，保障数据安全性。
• 运维友好：可视化、自动化的统一运维，以及全方位、立体化的秒级频率监控，极大程度降低运维复杂度。
• 兼容企业传统 IT：尊重企业 IT 管理规范，兼容企业既有 IT 管理流程，可平滑整合到现有 IT 体系中。

比如说，在 Kubernetes 社区中，官方仪表盘糟糕的监控功能饱受诟病，为了解决这个问题，KubeSphere 团队为用户提供了更细粒度的权限控制、自定义控制、日志查看等功能，帮助企业更好的解决监控的需求。此外，KubeSphere 还提供了诸如 DevOps、微服务治理等能力，可以帮助企业更加简单的完成 Kubernetes 生态的接入。这些方面的差异性体现在以下几点：

• DevOps：无需Jenkins配置、图形化拖拽编辑、即点即用
• 微服务：治理功能完善、全可视化治理、低成本运维（轻点即用、零 Istio 基础也可以）

在接下来会发布的版本中，四爷透露道，新版会更加适配企业用户的需求，将会为企业用户提供诸如多集群、多租户、多网络、AI平台等企业亟需的特性，还将对 KubeSphere 进行架构层面的改造，让 KubeSphere 支持模块化配置，用户可以根据自己的需要，选择所需的产品模块，从而让 KubeSphere 的架构更加灵活、自如。

KubeSphere 的开源基因

如今是开源的年代，而云计算、容器和 Kubernetes 更在开源中诞生并茁壮成长起来的奇迹花园。作为开源社区，我们也非常关心 KubeSphere 的开源情况。

四爷表示，KubeSphere 项目从一开始，就是抱着开源的想法去做的，项目从初期便开源。他提到，青云QingCloud 做 KubeSphere 一开始就和其他的企业的思路不同。青云有天然的企业服务基因，从一开始 KubeSphere 就是面向企业设计和研发的，企业对于开源产品会更加的信任，而开源模式也能够让 KubeSphere 走得更远。

这种开放的策略，让 KubeSphere 在早期收获了大量用户，也让 KubeSphere 赢得了用户的信赖。

此外，四爷表示，KubeSphere 的开源也是符合用户利益的。实际上，有不少用户在开始使用青云QingCloud 的云服务之前，已经采购了其他的云服务、虚拟化或者物理设备，很难马上迁移到青云上来。开源的 KubeSphere 可以帮助他们在其它基础设施上先用起来。这种开放的策略，让 KubeSphere 在早期收获了大量用户，也让 KubeSphere 赢得了用户的信赖。

当 KubeSphere 根植于青云时

开源的 KubeSphere 与云平台是完全解耦的，这意味着 KubeSphere 可以运行于任何公有云基础设施之上，而当 KubeSphere 根植于青云QingCloud 自身所提供的基础设施时，就出现了 QKE。

周小四说，“QKE 是我们在 KubeSphere 容器平台的基础上，加入了青云的基础设施，以进一步的降低用户的使用成本。”

“从一开始做我们就知道，KubeSphere 的最终形态一定是对接公有云的，也只有公有云才有足够的资源提供给企业进行弹性伸缩。我们在 KubeSphere 的基础之上，对接了青云的高可扩展性网络和高性能存储，帮助企业用户更加简便地使用 Kubernetes 完成应用开发，而无需将大量的精力投放在底层基础设施的运维上。”

进一步的，在 QKE 之上，QKS（QingCloud Kubernetes Service）也会很快推出，QKS 是 QKE 的升级版。“QKS 也在 KubeSphere 之上，提供了不少非常有价值的功能，比如说，相比于其他家的容器服务，QKS 能够根据用量付费，这和其他家以集群来付费的理念是完全不同的。他们的本质上还是购买计算资源，然后在资源内部进行弹性。而 QKS 的底层是一个大的资源池，所有的用户都从这个资源池内调取资源进行计算，使用完成后就可以释放，从而达到真正的‘按量计费’。”

尾声

或许都是技术人吧，两个有共同话题的人聊起来技术就滔滔不绝，聊天中，我问起了“四爷”这个颇为霸气的昵称的来历，据说最初这来自同事们的戏称，周小四在技术问题上非常较真，十分霸气；而在攻关重大技术难关时，又能领着大家迎头挑战，颇有侠气，因此这个昵称在技术部门内不胫而走，最后在整个青云公司内，甚至连客户都这样亲切称呼他。我想，这正是一个技术人对技术的自信、对自己做出来的产品自信，才能自信立于云计算的潮头吧。

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

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

6 月 25 日，我代表 Linux 中国社区团队参加了本次 KubeCon 2019（上海）峰会，期间有幸和安全容器 runV 的创始人王旭做了一番长谈，就云原生技术、安全容器、开源与初创企业等话题进行了深入沟通。现将这些话题整理其精要分享给大家。

互联网技术发展速度之快是所有从业者甚至非从业者都能感受到的。尤记得在世纪之交时，那时候互联网刚刚在中国开始向民用普及，不说支撑大规模的网站访问量的相关技术，就连 Linux、负载均衡甚至都没有被普遍使用。而在二十年之后，云计算已经大行其道，当今的技术人员已经言必称虚拟化、容器和 Serverless，就连刚刚准备入行互联网运维行业的新人们都已经从最初觉得考个 Linux 认证就够了到开始问询 Kubernetes 培训哪家强了。

从一届届 LC3、DockerCon 到 KubeCon，蓬勃发展的云计算与容器化似乎已经称霸了互联网领域。这次我带队参加了 6 月 24 ~ 26 日的 KubeCon 大会，对此感受尤为深刻。事实上，这次在上海举办的 KubeCon 2019 距离上次在同一地点举办的同一会议才仅仅过去半年，但是我们依旧在这次大会上看到了层出不穷的大量新技术、新动态。

云与容器的结合，引爆了这一切。

作为容器领域的资深专家，让我们来看看王旭是如何看待容器和云原生领域当前的发展态势的，以及作为这个领域的一家初创技术企业的创始人，他是如何投身到这个领域的，开源又在其间起到了什么作用。

王旭，安全容器项目 runV 的创始人，现已加入蚂蚁金服。

创立于 2015 年的 runV 项目已于 2017 年和另外一个来自英特尔的 Clear 容器项目合并为 Kata 容器项目，并由 OpenStack 基金会（OSF）进行管理，它与来自谷歌的 gVisor 项目并称为目前两大安全容器技术。

开源与初创

要么就去加强容器，要不就是引入别的安全技术来让它像容器一样。

临近 2015 年，Docker 逐渐被业界主流所接受，互联网技术已经有一个比较明显的发展趋势：第一是云，第二是容器。而云加上容器一定会产生隔离性的需求，这应该说是王旭和他的联合创始人赵鹏做安全容器最早的一个思路：要么就去加强容器，要不就是引入别的安全技术来让它像容器一样。这就是 runV 这个项目想法的起源。

runV 发布的同一个星期，英特尔Clear 容器也发布了。2016 年 8 月份，在西雅图的 LinuxCon 上，王旭和 Clear 团队见面交流，双方在一些细节上面展开合作。在 2017 年 9 月份一个会议上，英特尔软件副总裁、开源技术中心总经理 Imad Sousou 提出项目合并，然后放到基金会里管理。当时大家都觉得这是很好的一个思路。

对于 runV 和 Clear 来说，避免了重复开发以及花费精力在如何说明两者的不同上，同时合并之后可以共同推动发展一个社区，一起去寻找更多的用户。同时，两者合并还有更多的意义。

Kata 容器的意义

Kata 容器最大的意义在于推动了社区的发展。

王旭认为，Kata 容器最大的意义在于推动了社区的发展。在 2018 年之前刚开始做 Kata 容器的时候，王旭他们需要很多的附加进程来模拟 runC 容器的行为，因为 runC 是事实标准，你需要兼容它。但是当 Kata 和谷歌的 gVisor 都出来之后，上游社区就注意到这一点，开始重视，于是推出新的接口，可以语义明确地直接去对话，而不需要再去模拟 runC 的底层行为，把原来的 2N+2 个辅助进程变成了一个进程。另外，既然有了不同的容器运行时，是不是可以在不同的场景下让它们转到不同容器运行时环境上去？于是就有了“ 运行时类 （ runtime class ） ”这样的结构。Kubernetes 社区做了很多这样改进，它们也在逐步变成事实标准。这样，一个小项目的引入推动了包括从用户到上下游的整个社区相关软件的变动。

安全容器也让更多的业务使用容器变得可能。

同时，安全容器也让更多的业务使用容器变得可能。王旭在蚂蚁金服做面向金融的一些服务往云原生方向发展，需要非常严格的安全标准，这正好和 Kata 这些安全容器项目结合在一起。

增强安全性不可避免的会带来一些会性能或易用性的取舍。王旭他们的做法是，在 Kata 里面增加了一个隔离层，减少用户需要考虑的事情。举个 Docker 的例子，Docker 镜像的开发者和管理员往往不是同一个人，对于管理员来说给出的权限越少越安全，但是对于开发者来说的话，尤其开发和调试的过程中，权限的变少会让开发和调试变得非常困难。对于开发者来说，不能完全理解管理员要做的事情，所以你就会见到很多的 Docker 镜像都是要所有权限的，因为它自己也不知道需要什么权限；此外还有一些动态的情况，很难先验地用程序去完全断定它需要的权限，开发者并不太不确定到底使用了哪些能力。在这个情况下我们做的事情就是把能力整体限制到沙盒里面。在沙盒里面是完整的能力，但是实际上沙盒本身访问不到外层的系统能力，这样对应用是无感知的，操作系统就变得更安全了。确实，对于系统来说安全性和便利性是一对矛盾，你很难在同一个层面上把这个问题完全解决掉。

现在有了“运行时类”，可以指定是否需要使用安全容器。Kubernetes 社区给大家提供 了一个机制，用户可以选用或者不用安全容器，它可以是全局的配置，也可以是 pod 级别的配置。对安全性不太关键的，比如说访问一些不太敏感信息的，可以在安全性上折中一点，可以让性能更好一些。

容器的发展

从早期的 Cgroup 开始，到 LXD/LXC 这样的容器技术的出现，再到 Docker 的的诞生，一下子点燃了整个容器技术生态，紧接着在容器编排系统出现后，并发展到现今 Kubernetes 成为了事实标准。容器领域一直在快速发展。王旭的看法又是怎样的呢？

容器领域正在逐渐往上层发展。

他认为，容器领域正在逐渐往上层发展。互联网技术本身一开始是在架构层面、在底层发展，但是从 Docker 开始兴起时，给大家的感受就是减少了对底层环境的考虑，用完整的环境把应用包装起来变成容器，让它可以随地随地运行。不需要操心运行在什么样的操作系统里，把操作系统这一层干掉，或者说把它变成很窄的一层。

以发行版为例。Linux服务器发行版的核心工作有两件：一是怎么把这个系统安装上；另一个是怎么去尽量平滑管理和升级软件系统。所有的事情其实都是在围绕这两件事情。最初出现了 RPM、APT 这些包管理系统，后来是通过 Chef、Puppet、Ansible 这类配置管理系统自动化的大规模部署，再到现在的 Docker、Kubernetes，一它们都是在做软件管理的事情。原来是操作系统在做这件事情，现在是 Kubernetes 在充当操作系统的位置；对云服务来说的话，这就是无服务器模式。2014 年 AWS 在拉斯维加斯的 re:Invent 大会发布 Lambda 的时候，得到业界非常大的关注。从 Lambda 开始，每个云厂商都逐渐有了自己的无服务器服务。所以他觉得未来的发展方向，应该是向这个方向的。

除此之外，像现在中间件、服务网格也都是这样一个目的，尽量的把应用要做的事情剥离出来，和应用无关的事情全都抽象出来放到底层。

对应用开发者和使用者来说，可以不用关心底层是什么架构、怎么伸缩的，只需要知道到我需要什么服务，只要定义应用，定义 Kubernetes 配置，由它统一管理、自动伸缩和调度就好。基础设施这一层会越来越向一些少数的云厂商集中，而大家更多的精力是帮助开发者做事情，集中精力在那些业务、智能等逻辑部分。

金融与云原生

加入蚂蚁金服之后，王旭致力于将安全容器技术落地到金融级云原生的场景下。由于金融领域的特殊性，云原生实践也需要有相应的变化。

要保证安全性，不仅仅满足应用的，也要满足监管的端到端的安全性要求。

王旭举例说，金融行业不仅仅本身对安全有要求，监管对安全也有要求。所以必须要保证安全性，不仅仅满足应用的，也要满足监管的端到端的安全性要求。另一方面，他们认为安全性包括两方面，一个是应用不能破坏沙盒，泄露到外面，同时应用的底层供应商不是自己时，也可以安全的使用。这就是一个双向的安全问题。

一般而言，作为一个云服务商，会假设所有的用户都是坏人，因为所有的用户都可能去窥探基础设施，它们都可能攻击其他用户，攻击宿主机，所以要做隔离。

而金融级的要求是不光是要做这一层的隔离，而是要做更强的隔离。首先是对应用不能盲目信任，即便是内部应用也不能放任，因为内部的也有可能存在局部的破坏，也有可能会有不安全的代码或者没有被完全验证的测试代码，还有可能会有第三方的代码。反过来，应用既然是金融级的应用，它对环境也有安全要求，所以这是整体的要求。

技术创业与开源

开源对软件公司来说，是一件向死而生的事情。

在早期以开源技术为核心做创业公司时，王旭认为开源是市场推广的一个很好途径。因为软件是有人买才能赚钱，有人用才有人买，所以你如果不开源，就要一家一家地找人去试用，但是你开源了之后大家就可以免费尝试。不过，开源并不是没有缺点，开源对软件公司来说，是一件向死而生的事情。你把最核心的技术开源了，赌的是别人跟不上你的发展速度；或者说别人相信你才有能力把它做到更好，别人才会用你；或者说你给别人看到的当前版本，让他相信下一个版本他也做不到你这么好，所以才愿意跟着你来走，以至于当他维护不了的时候才会愿意来给你掏钱。这应该说是一个在市场背景下的选择。

反过来说，如果说你现在做了一个基础设施领域的软件特别好用，但是你不开源，这个时候就一定会有人做一个一样的开源替代品。那你就看能不能比它做得好，你能不能拿更多的支持、拿到更多资源。这是很困难的。

所以在这个情况下，你不得不去做这种这种极致的推广手段，就是这种不买先送的这种开源式的市场推广手段。目前来看，纯软件实现的、跟硬件没关系这种项目基本上都是采用了开源或者半开源的方式，就是说至少给你一个开源的演示版或基础版。这种方式，从商业上说是迫不得已的一种推广方式。如果你不做，你的用户们用不到的话，他们会去寻找替代品，也一定会有开源替代品出现。

技术创业还会面临一个挑战，就是当你做出来产品以后，很快会有更大的对手入场，对于初创公司来说，面临的压力是颇大的。王旭面临的情况稍微有些不同。

幸运的是，推出和 runV 类似项目的公司是英特尔，在这件事情上并没有很强的盈利导向，这也是双方最终能够合作的前提。王旭认为尽量避免无用的竞争，而是一起来教育和开拓市场，是更有建设性的做法。

做初创公司，做有价值的东西是最重要的。

经历了开源技术为核心的技术创业之后，王旭对如何做技术创业也有一些自己的看法。他认为，对于初创公司来说，很大程度上来说都在赌别人没有做过的事情，因为你重复别人做的事情，还要比别人做的好，是一件很困难的事情。对于项目来说，取决于你想的是什么东西，你的项目想得越多，想出来和别人有什么不同，别人怎么需要你的项目，其实它就越有价值。

做初创公司，做有价值的东西是最重要的，而不是说做一个很好看的架构，最重要的还是要有价值，大家才会用。此外，还要考虑相关的项目，就是你要和谁一起配合工作，你的用户群是谁，你的用户需要去引用的已有项目是哪些，怎么和它们共存，因为完全从零开始造轮子不太可能，你会用到很多已有的成果。

新做一个项目，要考虑很多相关的东西、上下游的东西，各种的兼容性、支持性，要在生态里面去找到你自己的位置。除此之外，还要明白什么是项目最重要的指标，比如开始做 runV 的时候，第一个考虑事情就是安全容器的启动时间，并且不间断的去关注和优化。

最后，做开源项目也并不是说把代码开源出来就行了，还要注重社区的建设。

作为一个开源项目来说，它的社区是非常重要的，有社区才是开源项目。

王旭认为，作为一个开源项目来说，它的社区是非常重要的，有社区才是开源项目，没有社区的项目只是拿出代码给大家看看而已，那样不会有人真的严肃的去使用你的代码。

无论是在 runV 的时期，还是后面 Kata 容器的时期，社区都是王旭和团队非常注重的一环，有很多在早期关注和参与的开发者和组织，到现在王旭也和他们保持着很好的关系。

结语

作为国内少数的基础设施方面的开源软件初创项目的领军人物之一，王旭无疑在这个领域的技术和商业方面拥有独到的经验和感悟，这些思考可以给更多在前沿领域的技术人员和开源初创项目一些启示。

“穿山甲专访”栏目是 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 等方面的一些认识，作为一个几年来亲自践行云计算发展，并有深入探讨和研究的专家，他的观点和认识或许值得从业云计算行业的技术人员参考。

二月初春，在西子湖畔的细雨中，我拜访了蚂蚁金服中间件团队，和 SOFA 技术负责人鲁直做了一次深入交谈，更妙的是，鲁直也是负责 SOFA 开源事务推进的人，而这样一个切实践行开放核心模式的开源项目，也正是我非常感兴趣的。

两个技术人的谈话，自然是朴实而直白的，话题主要围绕着 SOFA 和开源主题展开，希望也能一样引起同是技术人的你的共鸣。

人物介绍

受访者：鲁直，蚂蚁金服 SOFA 开源负责人。

采访者：老王，开源布道人，有 20 年互联网从业经历的技术老兵。

虽然我和鲁直在微信上已经联系很久了，但这还是第一次见面。交谈中，我了解到鲁直是 2009 年加入阿里巴巴工作，已经有十年了。刚开始是在 1688.COM 做业务系统，对中间件技术非常感兴趣，也会经常研究各种中间件的实现和功能。后来在 2013年时，为了更深入地学习研究中间件框架，转到了蚂蚁金服中间件团队，从那个时候开始就一直在做 SOFA。

目前鲁直在 SOFA 的团队主要负责的工作包括几个部分。其中一个主要部分就是 SOFA 开源相关的工作。SOFA 的产品体系非常广，包括已经对外开源的部分、内部整个微服务体系，以及 SOFA 框架等等——而这些开源相关的工作主要是由鲁直负责推动的。

当然，作为技术负责人，鲁直既要带技术团队也要做技术工作。谈及这一点，鲁直说：

“我觉得做技术管理，跟普通的管理不太一样，因为技术管理最重要的一个点是除了管理之外，还要保持一定的技术判断力和敏锐度。对一些新技术，包括团队中遇到一些重大的技术问题，你都要有一些方向性的判断。虽然最后不一定是你具体解决的，但是在整个团队的技术攻坚和技术选型上，要一起确立方向。”

我以前也做过十余年的技术管理，我很能够感受这种情况，重大问题技术负责人更要迎难而上。

SOFA 5 落子 Service Mesh

就我了解的情况，现在 SOFA 已经发展到了 SOFA5 了。在 SOFA4 阶段，主要的任务是将开源体系捋清楚了，然后开始按步骤地开源；到现在发展到了 SOFA5。我想知道从 SOFA4 发展到 SOFA5，是什么让蚂蚁金服中间件团队判断 SOFA4 的阶段性目标已经达成，可以迈进到新的 SOFA5 阶段了呢？

“从整个业界趋势上来讲，SOFA4 的架构相对来说还是偏传统一些，更多是对我们之前的技术框架的整理和梳理。在这个阶段，SOFA 的代码经过了非常多的优化和重构，才达到了对外开源的要求，从而 SOFA 走上了开源核心的模式，逐步分阶段的将各个部分进行了开源。”鲁直讲到，“但是，从我们对业界的整体判断上来说，未来无疑是云的时代，所以说要考虑怎么让所有的业务系统能够提供云的能力，比如说 Serverless。”

接着这个话题，鲁直讲了他对云计算的理解：“一方面云计算肯定要为整个业务的发展提供更加方便的基础资源，可以不用去关心底层的基础设施。Serverless 字面的意思就是说‘无服务器’——我不用关心服务器怎么来的，不用关心基础设施，只要关心业务代码就可以了。那反过来对于云服务商来说，经过了这一层抽象，其资源利用率会更高，可以有更多的利润空间，这是一个双赢的局面。对于用户来讲，这种好处是实实在在的，可以更少关注基础设施，只关心代码就可以了。”

“我们希望在 SOFA5 的方向上，在这个新的迭代中，去让业务——包括让未来我们开源出来各种功能、各样服务模式——都更多地去关心自己的业务代码，而不用再过多地关心基础设施。”鲁直说。

在 SOFA5 中，一个重要的方向就是 Service Mesh 这个方向，这将是 SOFA5 中非常重要的特性。鲁直强调了其对 Service Mesh 技术的看好：“我认为 Service Mesh 是迈向未来往前走的非常关键的一步，让业务不用再关心基础设施。通过 Service Mesh，我们可以将很多技术能力直接放到基础设施里面，而业务可以不用感知到这一层。原来可能需要花几个小时或者更多的时间解决的基础设施问题，现在可以通过 Service Mesh 解决掉。”

“目前我们我们已经在生产环境中应用了 Service Mesh。我们在这方面有非常大的决心，我们希望能够在今年，在更大的范围中去落地 Service Mesh。当前这个阶段更聚焦在这种技术的内部落地上，希望用好了，再给社区做更多的贡献。”

Service Mesh 这个词最早是由开发 Linkerd 的 Buoyant 公司于 2016 年提出的，随着 Linkerd 的传入，Service Mesh 也进入国内技术社区的视野。Service Mesh 也被翻译为“服务网格”。Linkerd 则是业界第一个 Service Mesh。

Service Mesh 是一个基础设施层，用于处理服务间通信，负责实现请求的可靠传递。在实践中，服务网格通常实现为轻量级网络代理，通常与应用程序部署在一起，但是对应用程序透明。

Service Mesh 的部署模型，有两种情况：

• 对于一个简单请求，作为请求发起者的客户端应用实例，会首先用简单方式将请求发送到本地的 Service Mesh 实例。这是两个独立进程，它们之间是远程调用。Service Mesh 会完成完整的服务间调用流程，如服务发现负载均衡，最后将请求发送给目标服务。这就是 Sidecar，它在原有的客户端和服务端之间加多了一个代理。
• 多个服务调用的情况，Service Mesh 出现在所有的服务的下面，这一层被称之为服务间通讯专用基础设施层。Service Mesh 会接管整个网络，把所有的请求在服务之间做转发。在这种情况下，上面的服务不再负责传递请求的具体逻辑，只负责完成业务处理。服务间通讯的环节就从应用里面剥离出来，呈现出一个抽象层。

如果有大量的服务，Sidecar 之间的连接就会形成一个网络，这个就是服务网格名字的由来。

“我们将以 Service Mesh 为跳板再往前走。”鲁直表示，“Serverless 更多的还是应该聚焦在其字面本身，其含义就是‘无服务器’，后面的技术都是为了让无服务器承载具体的业务。”

Serverless 这个概念虽然提出来已经有几年了，目前 AWS 在 Serverless 和 FaaS 方面处于比较前沿的位置，但是在国内，Serverless、FaaS 这些技术的发展还是相对比较滞后。

鲁直指出，“我觉得 Serverless 想要成功，还是要从覆盖业务的整个广度上打开，否则可能还是停留在 FaaS 上，那场景就比较受限。”

Service Mesh 将是微服务的下一个时代，关于它还在持续进行理论研究和实践探索。

鲁直说：“坦白来讲，我觉得 istio 的理念非常好，但是在整个工程设计上，如果放到蚂蚁金服这样体量较大的环境里面，可能跑起来还需要做一些工作。我们希望今年 Service Mesh 在蚂蚁金服有了更大规模落地之后，可以把我们在 Service Mesh 方面的一些实践经验用到产品环境的工程中去实践，然后贡献出去。目前更多的一些工作，是将整个体系上进一步完善，铺到更多业务上，然后将这些经验反哺到整个 Service Mesh 的设计上，让它走的更远。”

也就是说，蚂蚁金服在 Service Mesh 上跟 istio 的技术路线是一致的，但是会从工程的角度更多地推动它的发展。

我们希望能够在我们进行了生产验证之后，再慎重地推送给开源社区。这也是蚂蚁做开源贡献的一贯理念。

鲁直：“我们希望能够在我们进行了生产验证之后，再慎重地推送给开源社区。这也是蚂蚁做开源贡献的一贯理念——我们希望一个东西经过了内部一段时间的成熟之后，再去开源。经过了大规模的内部验证之后，它的稳定性上有了一定的保障，就贡献给外部社区使用，再去拓展更多一些使用场景，包括完善和解决一些之前没有遇到一些问题。”

合力 Seata 分布式事务框架

2007 开始，蚂蚁金服自主研发了分布式事务中间件 XTS，在内部广泛应用并解决金融核心场景下的跨数据库、跨服务数据一致性问题，最终以 DTX 的云产品化展现并对外开放。而与此同时，阿里巴巴中间件团队发布 TXC，为集团内应用提供分布式事务服务，经过多年的技术沉淀，于 2016 年产品化改造为 GTS，通过阿里云解决方案在众多外部客户中落地实施。

2019 年 1 月，基于技术积累，阿里巴巴中间件团队发起了开源项目 Fescar，蚂蚁金服也开源了自己的分布式事务框架，并与 Fescar 合并一起共建分布式事务解决方案。这个发展既在情理之中，也在意料之外，我确实好奇这期间发生了什么，是如何和 SOFA 中间件团队的发展结合的，他们下一步会有什么计划？

鲁直说：“分布式事务是蚂蚁金服在 2007 年做的创新，是基于 TCC 原理，我们在内部实现了这个模式。TCC 理论相对还是比较简单的，但是它要落地，需要花费比较长的工程实现上的打磨才行。分布式事务这个技术在蚂蚁金服已经走过了 12 年的时间了。在蚂蚁金服最核心一些业务上，包括支付、交易、账务等等系统都在使用这套分布式事务框架解决和孵化的。”

在分布式事务这一块领域上，在业界来看目前相对来说比较空白，还没有非常好的分布式事务框架。说起来合并的初衷，鲁直表示，“既然阿里巴巴和蚂蚁金服都在这个方向做了一些开源的工作，所以我们把这两个部分的努力结合起来，取长补短，以适用于更多的分布式事务业务场景，蚂蚁金服加入 Seata 社区共建，在 Seata 0.4.0 版本中加入了 TCC 模式，为大家提供一个更加宽泛的分布式事务的解决方案。”

具体来说，“阿里巴巴的 Seata 提供是 AT 模式，对业务来说，不用有太多感知，但是它覆盖的场景有限，如果可以接受这样的情况，用 AT 模式更好。而蚂蚁金服因为有更强的金融方面的要求，就需要采用 TCC 模式，业务接入成本更高，但是它能做到非常好的分布式执行。未来还会提供像 XA 这样的模式，去适应更宽泛业务场景，这在这一块上，蚂蚁金服和阿里巴巴会结合在一起提供一个融合的框架。”

Seata 为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。而 Seata 的愿景是让分布式事务的使用像本地事务的使用一样简单和高效，希望可以让 Seata 适用于所有的分布式事务场景。

如何做开源

作为开源核心模式的项目，我希望了解蚂蚁金服中间件的开源一般会做哪些工作，是否有比较完善的流程和规则？

“首先，最基础的肯定是代码，并提供对应的示例，然后我们会提供贡献者指南这样的指引文档，因为本质上我们希望打造成一个开源社区，社区的参与度对我们来说是非常重要的东西，有人会上来提 issue，也有人来解答，有人提功能需求，有人提 PR 等等”，鲁直说。

Linux 中国曾经开发过一个用于测算开源项目活跃度的一个模型，我们认为从过去感性地看一个开源项目是不是活跃，已经开始逐渐进步到通过理性数据评估了，但是这需要排除一些数据作弊的情况，就像之前很多人会用项目的星标数来评估项目的活跃度，这当然很粗糙。我们今年还会继续配合 2019 年度的开源年报，而提供数据支持，到时候我们肯定会给 SOFA 相关的项目做一个考察。希望可以切实地反映出来 SOFA 在开源方面的工作。

从之前的脉络上看，到了 SOFA5，还会继续沿袭开放核心的模式，即：核心部分开源，与本地业务强关联，但是跟核心不是强关联的部分不开源。

从蚂蚁金服自身的实践来看，他们已经切实地践行了开源核心模式。

而对于开源核心模式，有人唱衰，也有人说好，各种观点都有。但从蚂蚁金服自身的实践来看，他们已经切实地践行了开源核心模式，这是我在国内第一个深入了解过的真实落地的开源核心模式项目。

说到开源模式，鲁直表示：“做开源，我觉得首先肯定要做一个心理准备，就是说你要有一个核心部分，再在这个基础上做扩展，在维护的成本上肯定有一定的上升，但是你要接受这样的成本——我觉得这种成本是可以接受的。……项目本身要设计好，具备一定分拆的可能性。如果不具备分拆可能性，那没法做了。像微内核这样的设计方式就会比较适合——就是开源一个核心模块，然后再去扩展，各种模块是可插拔的。”

而对于开源工作是如何做的，鲁直说：“我们没有专门做开源的人，也没有专门做内部代码的人，我们是把这两部分放在一起，既做开源又做内部代码，因为这样一个好处是，既熟悉外部的代码，又熟悉内部的代码，这个边界自己可以把握比较好。我们更多是制定一些规则。比如说跟业务层强相关的部分，你开源出去也没人用；如果说跟业务不相关的，你为什么不开源？因为你开源的这个产品想要做得更好，这些能力开源出去其实没有太大问题，所以一般我们的标准就是看是不是跟内部系统相关，是不是跟业务强相关，如果不相关就可以开源。”

谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻。

谈话中，鲁直反问的“你为什么不开源？”这句话让我印象深刻，这其实代表了他们开源的初心，但是从商业者从公司的角度来说，开源有没有给公司带来真正的好处？这不仅仅是情怀的问题，我相信每一个热爱开源的人，其实存在开源情怀或者是更理想化的想法，但是从另一方面来说，无论是从公司的机制上，还是公司的业绩上，开源还是要有实实在在的收益，能够推动公司业务发展才行。作为一个开源项目的负责人，他是怎么感受到开源的好处呢？

对这个问题，显然他有过成熟的思考：

“最直接的好处就是更长效。从眼前看，你的名声出去了招聘是不是也容易找到更合适的人？这是最短期的收益。长期的好处，开源社区里面大家分享了非常多的观点，从实践来看，也是这样。比如说你在一家公司里面去做的话，公司的业务场景是有限的，虽然说蚂蚁金服覆盖了各种各样的业务，金融方面的基本上全覆盖了。但是其他的行业不一定都有，他们遇到这个问题，我们可能并不会遇到，但这些问题可能是未来能够遇到的，如果把一个项目以开源的方式运作，就意味着说，更大的用例场景更容易发现 bug，用的人越多，越有可能会触发这个bug，那对于就是有了进一步完善的可能。

另外，有了这样的一个社区化的发展，有更多人参与进来之后，这个项目可以更快往前发展，而不是只有你自己在。在一家公司里边，团队的人员数量肯定是有限的，而有这么多人来参与，那对于这个项目的往前演进来说有非常大的好处，反过来对公司也会带来更多好处——无论是潜在的还是直接的。

最后，如果你的产品有商业化的支持，比如说其他系统的支撑，也能够更好提供商业化的支持。”

SOFA 开源以来，就我目前了解到的情况，大概已经有 30 家左右的企业用户在使用这套开源框架——就是直接拿开源的部分去用了。当然这主要是国内的用户，那么在国外影响力没有像国内这么大的原因在哪儿呢？是因为我们的项目不够国际化呢，还是知道这个框架的人不够多呢？

鲁直说：“我觉得可能是两方面的原因。一方面，我们的确在国际化方面做的并不是很多，在今年我们会去尝试做更多的国际化工作。另外一方面，更多的是文化方面的差异，大家的思维方式可能不太一样。当然我们会尝试走一下国际化的路线，因为开源本来就是不分国界的。”

进一步，SOFA 在社区治理这方面，“我们希望能够采用和参考 Apache 基金会的方式，这是一个很完善的治理模式，我们会尝试采用这样的方式去社区治理。这对于国际化产品是有很多好处的，它更多强调的是一种治理模式，是不是以社区的方式在运作，是不是在尊重整个社区等等。”鲁直表示，“我们会考虑跟 Apache 基金会、CNCF 进行直接接触，如果合适的话，我们会捐献项目给基金会。如果只是一家商业公司而没有基金会的支持，大家也会有更多的顾虑。把项目捐献给基金会，给大家更多的信心，通过基金会的托管，让更多一些参与方参与，而不只是有蚂蚁金服，大家也会有更大的信心参与进来。”

最后，鲁直希望致语开源社区，“其实蚂蚁金服开源的东西，也不只是 SOFA 中间件框架，未来会开源更多的东西，包括 AI 方面的一些技术，也希望整个社区能够多关注蚂蚁金服在开源上面未来的举措。”

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

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

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

去年，作为《穿山甲专访》系列采访之一，我们曾经给大家分享过 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 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。

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