二月初春，在西子湖畔的细雨中，我拜访了蚂蚁金服中间件团队，和 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 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。

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

一直想有个 Linux 中国的 APP，因为种种条件限制而没有达成这个目标。

微信小程序出来之后，也考虑过是否可以用微信小程序来实现一个 Linux 中国的 APP。但是在这个小程序内应该实现什么功能呢？经过几番考虑，可能也是因为最近比较喜欢极简风格，因此就做了一个（真的）极简的 Linux 中国小程序。

好吧，以上是给我自己找的理由，实在是因为这个小程序里面不知道该放些什么功能才是大家需要的，所以这个小程序只有 3 个页面：一闪而过的封面、显示文章题图及标题的翻页列表，以及一个显示文章内容的 web-view。

打开这个小程序，封面闪过之后，就是这样的列表：

向左滑动，就是下一篇。

点击这个页面，会切换显示模式，以横屏模式显示题图。再次点击切换回来。横屏模式下长按图片，可以保存该图片（需要授权才行）。之所以做这样的功能，是因为我们的每篇文章，都会尽力去选择一张漂亮的题图，不能辜负这种对读者的心意。:D

什么，你说如何访问文章？哦，是我忘记啦——在竖屏模式下，长按即可访问。

此外，要是遇到喜欢的文章，可以方便的分享出去：

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

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

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

PuTTY 是 Windows 上使用最广泛的 SSH 客户端之一，它也有 Linux 版本。日前，得益于欧盟资助的 HackerOne 平台，PuTTY 发布了 0.71 版本，主要是修复了大量的安全缺陷。这个版本距其上个版本 0.70 的发布已近两年。

PuTTY 是一个自由开源且支持包括 SSH、Telnet 和 Rlogin 在内的多种协议的 GUI 客户端。

根据其变更日志，这个新版本的主要变更有：

• 由欧盟资助的漏洞赏金计划发现的漏洞的安全修复：

  • 在 RSA 密钥交换过程中可由远程触发内容覆写，它发生在主机密钥校验之前
  • 循环利用用于加密算法的随机数的潜在风险
  • 在 Windows 上，通过与可执行文件位于同一目录中的恶意帮助文件进行劫持
  • 在Unix上，任何类型的服务器到客户端转发过程中的可远程触发的缓冲区溢出
  • 可以通过写入终端触发的多个拒绝服务攻击
• 其它安全增强：重写加密代码以消除缓存和定时侧信道
• 用户界面更改以防止来自恶意服务器的虚假身份验证提示
• 首次提供了基于 ARM 的 Windows 版的预构建二进制
• 最常见的加密算法的硬件加速版本：AES、SHA-256、SHA-1
• GTK PuTTY 现在支持非 X11 显示（如 Wayland）和高分辨率配置
• 现在，只要打开PuTTY窗口，就可以使用预先输入：在身份验证完成之前键入的键击将被缓冲而不是被删除
• 支持 GSSAPI 密钥交换：这是旧版 GSSAPI 身份验证系统的替代方案，可以在长时间会话期间更新转发的 Kerberos 凭据
• 用于剪贴板处理的更多用户界面选择
• 新的终端功能：支持 REP 转义序列（修复 ncurses 屏幕重绘失败）、真彩色和 SGR 2 暗淡文本
• 按 Ctrl + Shift + PgUp 或 Ctrl + Shift + PgDn 现在可以直接到达终端回滚的顶部或底部

如果要下载使用 PuTTY，请从其官网下载，以避免使用了被恶意篡改的版本：

• Windows 32 位：putty-0.71-installer.msi
• Windows 64 位：putty-64bit-0.71-installer.msi
• Unix 源代码：putty-0.71.tar.gz

此外，也可以单独下载 putty 和 pscp 等的二进制执行文件：

• putty.exe（32 位、64 位）
• pscp.exe（32 位、64 位）

一个月前，我们发布了一个小程序“Linux”，可以用来快速查找 Linux 中的命令常用语法。这个小程序中我们收录了上千条 Linux 命令（严格地说，几乎包含了 Unix/BSD 乃至于 OSX 等的全部命令）。该小程序的数据来源于国外的一个著名开源项目：tldr.sh，其项目托管于 GitHub。

这个小程序在推出前并没有特别周密的产品设计，我们在推出后，对这个产品进行了频繁的打磨和改进。几乎每天都会发布新的更新版本。甚至连小程序的 Logo 都换了两次。现在是这个：

这一个月来，这个小程序得到了大家的踊跃支持，很多命令都得到了大家的翻译贡献。应该说，这个小程序寄托着我们的一个实验性想法：我们希望提供一种众包式的机制，可以使大家可以利用碎片式时间来为开源文档提供碎片式的翻译。大家可能知道，我们的翻译组 LCTT 采用了和一些国际化翻译平台及其它一些开源翻译组织不同的模式，我们通常要求一个译者完成全篇文章的翻译，而非按段落切分，这样可以保证全文的质量和用语稳定。但是，这种模式在我们试图翻译 man 手册时遇到了困难——这可能是文章类和手册类的内容性质不同所造成的。

通过这次的实验，我们发现这种模式在对手册类的内容进行翻译还是有效的。因此，我们接下来会推出针对 man 手册的小程序，会同样采用这种众包方式进行翻译。

当然，在某个条目/手册的翻译成熟后，我们会将其推送会上游，以使更多人受惠。

这一个月来，这个小程序得到了八千多人的使用，一百多位贡献者实际参与了翻译贡献，其中贡献最高的“Datura stramonium L.”一个人就提交了 646 条翻译！

下面我来总结一下这一个月来我们的“Linux”小程序的改进要点：

• 除了可以搜索命令名之外，还可以按描述搜索命令
• 贡献排行榜
• 首页随机推荐命令，显示最新更新动态
• 显示风格调整
• 强化贡献者呈现
• 增加了命令的延伸阅读文章
• 增加了中英文切换显示功能

接下来，我们计划进行如下改进：

• 对命令页面中的占位符进行特殊渲染
• 标定某个页面的翻译成熟，可以推送到上游
• 添加评论框，以发表评论和丰富用法示例
• 添加更新提示消息——当你编辑过的消息被再次更新，你可以收到提醒

最后，欢迎大家都来体验一下“Linux”小程序：

之前我们发过一篇《如何在 Ubuntu 和其他 Linux 发行版上安装 Putty》，有一些人对此不以为然，说实话，我原本对在 Linux 上安装 PuTTY 也持可有可无的态度。前两天，我们又发了一篇《在 Linux 中安装并使用 PuTTY》，比上一篇更详细的介绍了在 Linux 上安装使用 PuTTY 的经验。

不出所料，又引来了一些人评论，我本来对此也是哈哈一笑，各人都有各人的看法嘛。但是，看着看着，我就有点看不下去了。

这些人在说什么呢？他们是这样说的：

• 为什么不直接用命令行呢？
• 多此一举
• PuTTY 能做的 Linux 终端都能做，感觉没啥用
• X 疼操作
• 有个疑问：Linux 为什么要装 PuTTY？
• 典型的南辕北辙，画蛇添足，无聊的蛋疼
• 是 OpenSSH 不好用了还是 OpenSSH 不够骚了
• 存粹搞着玩
• ？？？？？？？？
• 我 tm 好想 at 疑惑大赏

更多我就不一一列出来了，以上也不指名道姓了，上述言论归该发言者所有。

在一开始，我就轻轻的回复一句：“为什么不能在 Linux 桌面里面有个 ssh 连接管理器呢？”也有同学说“经常用 Linux 桌面访问多机 SSH 的朋友知道这篇文章的好。”、“几乎是最简洁轻便的 ssh 工具了（其实还支持 telnet 和串口等）”，但是这些很快被淹没在种种无脑的评论当中。

我低估了这些应该是懂一些 Linux 系统管理的人傲慢，也没想到会有这么多的偏见！

是的，我们以前只在 Windows 上见过 PuTTY，而且，我还曾经在偶尔需要 SSH 连接时临时下载使用过 PuTTY，虽然不如 SecureCRT，但是也够用了——谁让之前 Windows 没有内置的 ssh 命令行呢。

是的，我对 PuTTY 还有过一个不好的偏见，因为之前有些坏人给 PuTTY 加壳，放了木马，一些警惕心不够的人因此而中招——虽然这事完全不赖 PuTTY。

难道系统管理员们都是“万般皆下品惟有终端高”吗？作为技术人员，在一个日新月异的时代，无论是作为继承了古典“黑客”传统的 IT 人，还是处于一个一日不学即落后的行业，为什么要故步自封？为什么不能将眼睛从黑窗口挪开看一眼呢？

那么，我来说说，使用 PuTTY 有什么好处！

• 如果你要管理若干服务器呢，难道用 txt 记录 IP 吗？
• 如果想为重要的生产服务器设置不同的终端样式提醒你千万小心呢？
• 如果你要同时管理 Solaris 和 Linux 呢，需要调整键盘映射呢？要知道 Sun Solaris 的删除键和 PC 键盘不同。
• 如果想为不同用户采用不同的验证方案呢？比如 root 采用密钥验证，而普通用户采用 otp 加密码验证。
• 如果你不想每次敲长长的命令行，指定端口号、指定用户名、指定另外的密钥位置呢？
• ……

这些，够不够你放下傲慢来看一看呢？说到底，一个不能公正地看待包括 Windows（及 WSL）、Unix、 Linux 等不同系统的优缺点的人，不能谦虚地保持学习和理性的思维的人，你觉得你适合做技术工作么？

戒骄戒躁，放下傲慢。