导读：本文介绍了开源项目 KubeSphere 背后的故事，以及由它引发的对开源软件发展的思考。从一个开源项目的数据说起作为一家主要关注于开源的技术社区，我们每年都会对以中国贡献者为主的开源项目进行一次分析。而随着云计算的发展，我们对由云计算公司发起和推动的开源项目愈加重视，在研究分析过程中，我们发现了一个开源项目的数据表现亮眼，这引起了我们对这个项目背后团队的兴趣。图 1 KubeSphere Grank 指标图这个项目就是 KubeSphere。和其他同类项目相比，KubeSphere 项目的启动时间不算早，2018 年初才启动。但从启动开始，社区的活跃度就屡创新高。从上面的 Grank 指标图可以看出，其在 2019 年度的整体活跃度（红色线）相当高，并在今年有继续提升的趋势。而其平均活跃度指数 6.89 可以排入 Grank 服务端分类榜的前三十。刚好，这个项目背后的负责人我们也很熟悉，之前曾经在《穿山甲专访》栏目中接受过采访——周小四（人称“四爷”），如果你感兴趣，也可以看看之前的采访文章。如今一年过去了，为了了解现在 KubeSphere 项目有什么新的变化，我又和他约时间，再次聊聊 KubeSphere 的发展和下一步的计划，得到一些新的发现和体悟。KubeSphere：“青云”之路谈起 KubeSphere ，容我先简单介绍一下背景。随着云计算技术的发展，容器编排技术 Kubernetes 已经成为云服务商们的角逐重点。按照 Kubernetes 的理念，它定义的是一套标准、一个生态规范，因此，各个生存于其间的云服务商纷纷基于 Kubernetes 推出了各自的发行版和相关的生态软件。这其中既有 Rancher、OpenShift 这样复杂完备的的企业级平台，也有 minikube、k3s 这样简单易用的实验型工具。而今天我们提到的主角 KubeSphere就是一款开源的企业级 Kubernetes 发行版，与其外延的其它组件组成了一个完备的容器生态体系。事实上，我们可以看到，几乎所有的主流云服务商都开发了 Kubernetes 引擎（KE），比如说 TKE、RKE、AKE 等等，并以此作为其基于容器的云服务基础。当然，这些软件作为开源软件生态的一分子，都或早或晚进行了开源。而作为青云QingCloud QKE 服务的引擎，KubeSphere 也是其中的佼佼者，并且，值得注意的是，KubeSphere 从一开始就选择了开源，并以开源作为其产品迭代发展的模式。相比 Kubernetes 领域的其它厂商，KubeSphere 的进入时机不算早，因此，在这种情况下仍能推动决策立项，应该压力不小。周小四和我说，他们当时深入调研和分析了企业的市场需求，发现在该领域尚存在较大的产品空隙。固然，Kubernetes 为企业级容器应用揭晓了新的篇章，但广泛的企业用户在如何用好 Kubernetes 层面，需要突破较多的技术门槛和业务适配的阻碍。因此，他认为，在该领域仍大有可为，这一建议也得到青云QingCloud 的大力支持。而另外一方面，作为一家国内主流的企业级云服务商，青云QingCloud 也一直在密切跟进 Kubernetes 领域的技术发展和产品形态。所谓磨刀不误砍柴功，正是这一年多提前付出的预研投入，让周小四及其团队在2018 年初开始 KubeSphere 的研发时，就能迅速发布经过了精心设计的 KubeSphere，并于半年后在青云QingCloud IaaS 基础设施之上推出了 QKE——KubeSphere on QingCloud 容器服务。图 2 KubeSphere 路线图倏忽间过去了两年，KubeSphere 也即将迭代到 3.0，对于它发展至今，并取得今天的成绩，周小四认为主要得益于以下原因：天时：站在 Kubernetes 的肩膀上，处于容器技术的大时代；地利：开源为它赋予了成长为参天大树的土壤；人和：来自团队和社区贡献者对容器技术的深刻理解、对用户需求的精准把握和在产品设计上的匠心独运。KubeSphere 的天时扑面而来的云原生时代，是机遇也是挑战。这里，我们看到了 Docker 公司如荧惑一样迅速升起又快速淡去，我们也看到了谷歌力推的 Kubernetes 从天下三分到一统容器编排领域，真正揭开了云原生时代的大幕。并不是每个身处大潮之中的都是弄潮儿。说实话，这些年我看过很多云计算领域的企业或因押错注而不得不更弦易辙，或因产品没有足够的独特优势而泯然众人。对于一家国内主流的企业级云服务商，青云QingCloud 不仅一早看好 Kubernetes，又没有匆匆下场，更在局势渐明时能决然重兵压上，其实我是有些佩服和羡慕的。在和周小四的对话中，他说，在潜心研究了 Kubernetes 生态一年后，青云QingCloud 才正式立项，并由他带队开发运营 KubeSphere 容器平台。谈话间，生性乐观的周小四并没有表现出曾经面对的困难和压力，但是如果易位而处，我能感受到他的那种魄力和信心。KubeSphere 的地利那么，KubeSphere 的地利是什么？是开源。有一个强大而完善的团队，确实可以打造一款好产品，有可能取得一时之胜。但是，时代如汤汤大河，如今开源已经成为数字世界的血脉，触达和营养了各种互联网技术的急速发展。在21世纪的第二个十年间，连微软都已经摇身一变，成为了世界上最大的开源企业之一，可以说，开源已经成为了一种时髦的技术文化，它从一种软件分发和开发模式，变成一种可以以之为脉络的商业模式。但是，开源到底只是一种时髦文化、用来迎合大众和媒体的流行词，还是可以赖之生存和发展的一种机制呢？在这方面，我们看到了企业在开源领域的众生相，略举几例：买椟还珠式开源：有的公司是只是希望贴上开源的标签，并不真正了解开源对公司的实质价值，也无从将开源的好处和公司的发展机制相结合，空耗人力与财力，甚至没能给开源世界带来什么贡献。叶公好龙式开源，有的公司的开源成为了技术部门的 KPI 工具，他们并不真正依赖开源来提升软件质量和改善软件的业务生态，甚至害怕开源伤害到公司以专有代码建立起来的业务护城河；竭泽而渔式开源，还有的公司对待开源则是奉行“拿来主义”，只有索取和利用，而不对开源软件和开源社区做出适当的回哺，甚至倒逼一些开源软件纷纷修改其许可证，避免被吸血。而作为 KubeSphere 项目的负责人，周小四认为青云QingCloud 是真正把开源做为一条切实可行的发展路线的。周小四认为，虽然目前开源领域看起来热闹非凡，但是真正可以称之为成功的、健康的、可复制的开源模式尚寥寥无几，失败者并不鲜见。而青云QingCloud 作为一家主流的企业级云服务商，根植于云技术之上，已经找到了一个切实可行的开源模式。周小四说，“公司（青云QingCloud）给予了强有力的支持，希望 KubeSphere 可以走出一条新的开源模式路线来，真正践行开源的思想和路径。”KubeSphere 的人和说完了天时、地利，让我们再来看看 KubeSphere 成功背后的人和。对于一位资深的技术专家来说，精通云计算技术并能跟上全球云时代的技术浪潮，并不算最难的挑战，难的在于可以站在技术之外看到用户需求、用户体验和产品运营之道。在对话中，周小四和我说，他很幸运，“总是能在对的时候找到对的人”，因此 KubeSphere 的各个细节才处理得很好。这里他专门提到了 KubeSphere “特别易用的前端界面”和“丰富完备的中英文文档”，并特别庆幸每次总能找到最好的伙伴们来做这一切。当然，这些都是建立在精心设计的架构和底层 API 之上的，只是想必这部分是周小四亲自操刀的，但他并没有专门提及。而我想，在这样的一个团队中，有这样的一位领头羊，也是一种幸运吧。图 3 KubeSphere and Friends开源是如何为 KubeSphere 添砖加瓦的缘何开源可以为 KubeSphere 提供助力呢？这是由开源模式本身的优势所决定的。或许有些人直觉上会感到意外，开源本身并不会因代码的公开，导致该软件及软件背后的企业或组织丧失竞争力。事实上，几乎不存在一段极其精妙的代码可以形成长久的优势，更重要的是，在软件的发展过程中的工程能力才是真正的竞争力，这一点，其实和开源与否并无直接的联系。那么既然开源对竞争力并无负面影响，是否有正面的影响呢？有的。首先，无论是什么软件，其必然要满足各种不同场景需求，才能与时俱进，不断发展下去，而该软件的团队和决策者往往并不能照顾到（或遇到）各种场景，也不一定总是能做出最佳选择。但是在开源模式下，由于代码是公开的，总会有层出不穷的用户场景，这些意料之内或之外的场景和需求，极大地刺激了开源软件的生命力。其次，通过开源极大地降低了用户接触门槛，因为用户可以近乎无成本地接触和使用这些开源软件，并在满足场景需求和形成知识领域之后，还会进一步的扩散该软件的传播范围，而这本质上是对用户和市场的争夺。最后，通过开源，软件的参与者就不仅仅是内部团队了。不限于对代码的贡献，任何提出错误反馈、功能需求，甚至寻求帮助的用户，都能加速代码的迭代和发展。一个快速迭代的软件，其活力远不是闭门造车所能比拟的。而在 KubeSphere 中，对于以上几点的践行，实实在在地收获到了成绩。KubeSphere 的开源成绩从 KubeSphere 的 GitHub 仓库的活跃度看，来自青云QingCloud 和社区贡献者的提交、 议题 （ issue ） 都非常活跃。周小四还说，“我们的项目的 星标 （ Star ） 数现在有三千多，有人分析过，星标的质量很高，它们来自于全世界各地。”这意味着，KubeSphere 已经取得了社区的一定认可。而且，社区用户也在主动地自发向更多的人去推荐 KubeSphere，提到这一点，周小四的振奋之情让我感同身受。图 4 KubeSphere 星标增长图从上图的星标增长趋势来看，KubeSphere 的用户关注度在持续地自然增高。在我们对开源项目的评判当中（Grank 模型），有两个重要的维度：项目活跃度：通过项目的提交、拉取请求、贡献者等数据的变化幅度计算得来的一个指标；项目健康度：通过项目的社区化程度来判断项目的健康发展程度。从文章开始部分的图 1 可以看到，KubeSphere 的活跃度能维持在较高水准上。尤其是经过了最近几个月的全球性疫情之后，KubeSphere 的项目活跃度再次取得了新高。如果维持这个发展态势，KubeSphere 的变化将日新月异。社区化而 KubeSphere 项目的健康度，我们可以从图 1中看出，来自社区的代码贡献者的比例并不算很高，这对于一个由企业主导推动的开源项目来说，属于正常水准。但在代码贡献者之外，据周小四称，目前 KubeSphere 的社区活跃度还是很不错的，从社区支持的多个交流平台，如国内用户惯用的论坛、微信群，到国际用户惯用的 Slack、邮件列表等，都有很多活跃的贡献者和用户。而另一方面，KubeSphere 的独立下载量已经达上万次，周小四表示，他的目标是这个数量将来可以进一步提升到十万、百万级别。目前的贡献者除了青云QingCloud，还有来自本来生活、中通、VNG 等海内外多家企业，并且还有不少社区的独立开发者希望能够更多地参与到 KubeSphere 的直接贡献当中。但是从目前看起来，晋升为 KubeSphere 的核心开发成员的外部贡献者占比还不够高，主要还是来自于青云周小四说，他们还在着手丰富 KubeSphere 贡献者生态，主要努力方向在以下两个方面：一方面，在如何降低贡献者的贡献门槛方面，比如文档、代码规范、贡献流程方面不断地改进和完善；另一方面，由于 KubeSphere 本身迭代速度较快，新的功能不断推出、原有功能不断改善，在高歌猛进的同时，一些需要夯实的基础性工作，比如国际化、教程、bug修复和用户需求管理方面继续加大投入更多的人力。周小四说，他希望 KubeSphere 是属于社区的开源项目—— 这一点，从项目本身的 GitHub 仓库放在 KubeSphere 组织下可见初心。对此，周小四也设定了一个评判标准，什么时候 KubeSphere 社区的技术委员会（TOC）里面，除了青云QingCloud 的人员以外，还有其它公司或社区的成员，才叫真正的成功。图 5 KubeSphere 社区组织图对于一个开源项目的发展，周小四有着清晰的认知，从最初的产品设计，到进一步成熟迎来更多用户，再到社区成员参与贡献并走到更高的社区决策层面，都标志开源社区的开放性和健康发展。图 6 GitHub 数据生态化作为云原生领域的生态软件，KubeSphere 坚持完全开源和开放的迭代思路，联合多个企业与开源社区，共同打造了以 KubeSphere 容器平台为核心的开源项目。除了集成主流的开源组件如 Jenkins、Istio、Prometheus 等，还围绕 KubeSphere 开源了 Porter、OpenPitrix、KubeKey、Kube-events、Fluent-bit Operator、Notification Manager、CSI 插件等 80 余个开源项目，甚至 Porter——面向裸金属环境的 Kubernetes 开源负载均衡器这样优秀的子项目已经进入了 CNCF 云原生全景图。国际化但是，KubeSphere 并没有满足于当前的发展，而是更积极地谋求国际化发展。周小四说，得益于该项目在发展之初就以国际化为目标，其文档、社区交流，除了立足于中国本土的中文环境之外，国际化是在创立之初就从头贯彻的。甚至，他还专门招聘有国际化社区运营经验的人员来负责全球社区建设和运营。然而这些努力并没有白费，他发现最近几个月以来，KubeSphere 的国外下载量已经超过了国内的下载量，其贡献者中也不乏来自于中国以外各个国家和地区的技术爱好者和用户。甚至还有国外的公司主动联系他们，希望共同合作建立欧洲市场和社区，并提供相关的本地化工作。周小四说，对于 KubeSphere 来说，开源的属性为其带来了天然的全球化属性，但让 KubeSphere 真正的成为一个全球化项目，正是他寄予期望的目标之一。结语有人说，一叶而知秋，我们讲开源讲了这么多年，也从心里认可和推行开源思想，但是只有我们真正在具体的项目中践行开源的理念，我也希望读者可以从这样一个具体的项目中，观察和吸收到开源模式的精粹，我觉得，是时候在你的下一个，不，现在手里的这个项目开始，落地开源思维了。你说呢？“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。
拥有一个很萌的头像的 DIYgod 是一个当前任职于 B 站的年轻开发者，他是在 GitHub 拥有一万星标（本文发表时）的 RSSHub 的创始人，也是 APlayer（4.4k 星标）、DPlayer （8k 星标）等开源项目的创始人。在我所认识的开源开发者当中，DIYgod 是一个很优秀的开源社区贡献者，所以今天我们邀请到了 DIYgod 来参加我们的穿山甲专访。DIYgod 很有 B 站风格的头像问：您可以先自我介绍一下么？DIYgod：Hi，大家好，我是 DIYgod，一名爱好开源的 JavaScript 开发者 —— 写代码是热爱，写到世界充满爱。我的梦想是成为一名可以养活自己的自由职业者。问：目前你已经是自由职业状态，还是说仍然在企业工作呢？DIYgod：现在在哔哩哔哩（B 站）做前端。问：能否向读者介绍一下你的开源项目 RSSHub 呢？DIYgod：RSSHub 是一个用来生成 RSS 订阅源的工具，它可以给任何奇奇怪怪的内容生成 RSS 订阅源，实现万物皆可 RSS。RSSHub 正在借助于开源社区的力量快速发展中，目前已适配了数百家网站的上千项内容。使用时只需要简单的编辑下地址即可获得需要的订阅源。问：对于目前的很多人来说，RSS 已经鲜为人知，现在很多新生代的互联网用户已经不再使用 RSS，他们可能更习惯于使用信息流应用。你当初因为什么原因选择做了 RSSHub ，是有什么契机么？DIYgod：我本身是一个 RSS 重度用户，之前关注了几个有意思的微博博主，但经常打开微博去刷更新太麻烦了，就写了个简单的 Node.JS 脚本生成 RSS 加到自己的订阅里，后来又写了哔哩哔哩的 RSS、网易云音乐的 RSS，越来越多，最后就干脆把它们合成了一个项目，取名 RSSHub。 问：说起来，你其实是将微博的信息流推送的形式，借助于自己的编程能力，转化为 RSS 的被动拉取的形态。那对于 RSS 和 现在的信息流应用，你有什么看法么？DIYgod：信息流应用基本都有自己的一套推荐算法，受益于此，可以获得更轻松愉快的阅读体验；但另一方面来看，用户丧失了内容选择的主动权，看到的不一定是自己真正想看的，稍不注意也会消耗自己大量的时间，阅读效率更低。RSS 可以选择自己真正想看的内容，阅读效率更高，但这也导致使用门槛比信息流应用高了很多。信息流应用的另一个问题是它无法集中地收取信息，时不时地打开微博、Twitter、YouTube、哔哩哔哩，去翻看我关注的人有没有更新，实在是一件痛苦的事。最后是 RSS 可以做到没有遗漏地收取信息，而信息流应用很容易遗漏。问：可以看出来，你是一个重度的 RSS 用户，不仅仅是用户，更是为 RSS 生态添砖加瓦。你自己平时都是怎么样应用 RSS 的呢？DIYgod：大家都知道 RSS 是一种用来做消息聚合的格式规范，有着更高的阅读效率、更好的阅读体验、可以掌握主动权等等优点，但它的用途一直被大家低估，除了最常用的在 RSS 阅读器里使用，还可以通过 BT 客户端实现自动的 BT 下载用来追美剧或动漫、通过播客客户端订阅和收听播客、通过 IFTTT 与各种各样的东西联动等等。我平时除了常规的使用 RSS 阅读器订阅，还会在群晖的 BT 客户端里订阅美剧的 RSS，这样美剧更新后 BT 客户端就会自动把最新一集下载到硬盘里，晚上下班回家打开电视就可以直接看了。此外是自动下载我的 B 站投币视频，整个流程是“投币操作 -> RSS 更新 -> IFTTT 触发 Webhook -> 服务器下载”，实现方法在我的博客里有介绍：https://diygod.me/download-webhook 。然后还有我的 Telegram 频道： https://t.me/awesomeDIYgod ，它通过 IFTTT 监听了很多 RSS 更新，有 DIYgod 的博客更新、DIYgod 的 PSN 奖杯、DIYgod 的 Twitter 更新、DIYgod 喜欢的网易云音乐、DIYgod 的 bilibili 投币视频等等，几乎包括了我的全部动态。问：说起来集中在一个地方收取信息，你怎么看曾经的“即刻”应用，即刻应用也可以关注特定的人、微博之类的，在一个地方查看所有的信息。DIYgod：我非常喜欢“即刻”，在“即刻”倒闭之前也一直在使用它，早期很像一个 RSS 阅读器，甚至真的可以订阅 RSS，但后来这些功能越来越淡化直至去掉了，取而代之的都是 UGC 内容了。 问: RSSHub 里有非常多的“路由”，包括社交媒体、新媒体、论坛等。除了我们一般意义上的信息流转化 RSS 以外，RSSHub 还有非常多有意思的 Feed，比如高校教务处通知的 RSS Feed，就你自己而言，你最喜欢 RSSHub 中的哪一个条目？ DIYgod：那当然是 “RSSHub 有新路由啦”。问：那么，除了 RSSHub，你还会使用哪些 RSS 生态中的工具呢？DIYgod：除了 RSS 阅读器和支持 RSS 的 BT 客户端，还有 IFTTT 和 Tiny Tiny RSS 及其插件。问：RSSHub 是一个基于 MIT 许可证开源的项目，你自己当初是怎么走上开源的“不归路”的呢？DIYgod：刚学前端的时候，为了练手写了几个很简单的小项目，然后把它们传到了 GitHub 上想着找工作时候可以用到，没想到真的有人会去用自己写的东西，收获了第一个 提案 （ issue ） ，第一个星标，第一个拉取请求，就这样发现了其中的乐趣，打开了新世界的大门。问：RSSHub 是中国的个人开发者开源的项目中首屈一指的项目，获得了非常多的星标 ，也有很多贡献者，对于开源，你有什么想要告诉大家的么？或者说，在你看来，想要做好开源，最重要的是什么？ DIYgod：希望大家没尝试过的都尝试一下，收获第一个星标，第一个拉取请求的快乐无法描述，不仅可以帮到别人，也可以快速地提升自己；最重要的是兴趣，开源项目需要投入大量的业余时间去更新维护，用爱发电，然后是持之以恒，挖一个坑很容易，但后续的更新维护也很重要。问：RSSHub 项目的社区化非常的高，有 300 多位贡献者，很多社区开源项目都难以获得这么多的社区贡献者，你是如何让这些来自全国的开发者相互协同的呢？DIYgod：我觉得这更多的是跟项目性质有关系，RSSHub 是一个需要大量人力来适配各种网站的规则的项目，可以参与的地方很多，参与门槛不高，又能获得非常积极的反馈。可以参与的地方很多：每个 RSS 路由都对应一个脚本，可以让很多人参与进来。参与门槛不高：脚本的编写难度不高，RSSHub 还有非常详细的开发文档，进一步降低了开发门槛，然后采用了统一代码规范，严格的自动化测试来避免出现问题。积极的反馈：可以很方便地自己动手制作自己想要的 RSS 源并分享给很多人用，同时在文档对应的 RSS 源也标记了路由作者的名字。问：现在有一个机会，你可以推荐一个东西给大家，你会推荐什么？可以是软件、可以是网络服务、可以是硬件，Everything is Ok.DIYgod：PS4 和 Switch — “No Game No Life”；跟 RSS 相关的再推荐一下“快知 APP”。问：大家在哪里可以找到你呢？DIYgod：GitHub：@DIYgod；Twitter：@DIYgod；博客：diygod.me；Telegram频道：@awesomeDIYgod关于穿山甲专访“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。如果你希望加入到穿山甲计划专访中，请访问 https://jinshuju.net/f/9X8gvG ，填写报名表。
似乎每一家互联网公司都有一种属于自己的气质，我接触过很多知名互联网公司的技术专家，其中有一家公司技术专家给了非常深的印象，那就是 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 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。
酌一杯云之酒，以开源佐之 ——专访灵雀云陈恺
在云原生技术实践峰会召开前夕，匆匆奔赴北京的我，见到了刚刚从美国飞回来，却毫无时差之扰的陈恺——灵雀云的 CTO。虽然我早就和灵雀云有了联系，也有好几位朋友在灵雀云任职，不过作为国内新锐云原生厂商灵雀云的创始人之一的陈恺，我之前并没有直接接触过。虽然我们是初次相识，但是在聊到了开源，聊到云技术，我们以云做老酒，以开源为佐酒菜，很快就俨然如同老友般进入了旁若无人的状态——旁边的朋友被我们暂时性忽视了，虽然这张合影就是她帮我们照的。 :D滥觞始于云计算。缘起陈恺和左玥等人在创立灵雀云之前，他们都曾在微软 Azure 从事云计算领域的专业研究。回忆起那时候，陈恺说，那时他们也在想象云里面的应用应该长什么样子，设计最早版本的“云服务模型”、“云服务运行时”，而现在回过头看，其实云计算的发展已经千差万别。2013 年 Docker 出现以后，左玥和陈恺他们第一时间就意识到容器技术会很有影响力，它重新了定义云技术之后发展的路径，这恍然在他们面前掀开了一个新的时代，于是灵雀云诞生了。云技术领域发展演变的非常快，事实上，在云计算早期并不能预见到如今的云计算格局。“早期我们尝试过很多东西，总的想法是觉得容器就像是一种轻量级虚拟机，一种新的虚拟化技术。就像虚拟机需要虚拟机平台去作为它的管理平台一样，容器也需要一个容器云平台，所以我们早期想做的就是容器云平台，这一点一直没变，现在也是在做企业级的容器平台。”陈恺说，“我们最早的技术选型是 Mesos 技术栈，经历了几次大的改变，包括从 Mesos 转到支持当时的三种主流的调度系统，然后开始倾向于Kubernetes，到最后全面转向 Kubernetes，以及最近在架构上和 Kubernetes全面对齐，把我们的平台做成一个 Kubernetes 原生的平台，技术上一直在做升级。”云原生吞噬一切，Kubernetes 编排一切不知不觉之间，云原生已经吞噬了整个世界，如今，云原生已经是技术界最时髦的词汇之一。而应运而生并推动了这一切发生的云原生计算基金会（CNCF）也在不同的时期、不同的场所，对云原生做了不同角度的解读。那么作为一家很早就涉入云计算领域的新锐力量，陈恺对云原生的理解是什么呢？陈恺说，“CNCF 旗下涵盖这么多云计算的技术、产品和服务，所以它对‘云原生’的定义必然会比较宽泛，但的确，‘云原生’不是一个特定的技术或者一种方法，很难把它精确的定义，也不应该把它和具体的技术对等，比如说把它直接跟 Kubernetes 挂钩，跟 Kubernetes 没关系就不是云原生？跟 Kubernetes 有关系就叫云原生？这两者都是不对的。”他接着补充说，“我对云原生定义的观点也是比较宽泛的，（云原生）就是让应用能够最大化的释放云计算生产力的一系列的思维方式、最佳实践和技术体系，这里的关键词是让应用去释放云计算最大的生产力。这是关键。所有的云原生我觉得都是首先应该围绕应用的。什么叫‘云原生’？主要是以应用为中心的。‘原生’这个名字看起来起的不是很好，听上去似乎是只有在云上生出来的才叫‘云原生’，或者只有在公有云上才叫‘云原生’，并不是。关键不是说你在哪里跑你的应用，而是你是不是能够释放云的生产力——广义的云的生产力。”在容器编排市场尚三分天下的时候，很多容器服务商都同时支持三种主流的编排系统，当时有一些观点认为这种三分格局会持续比较久，然而 Kubernetes 迅速崛起，很快就一家独大地统治了容器编排市场。陈恺说，“我觉得当时 Kubernetes 可以很快的从编排之争当中胜出，并没有那么让人吃惊。为什么我们比较早的时候就开始往 Kubernetes 发力？其实第一个触发的点比较偶然。那时经常会有人问起三种容器编排系统各自的优势是什么？我们做了一些研究，业界有一些对比，当时我印象比较深的是一个细节，我觉得这才是关键——有一项对比的是基于这三种技术有哪些商业版？基于 Docker Swarm 的有一个商业版 Docker EE；Mesos 有一个商业版 MesosPhere；基于 Kubernetes 有好多商业版——这是本质的区别。这一点对它们的社区的发展速度和后续影响很广，因为它是开放式的治理。Kubernetes 虽然是谷歌发明的，但是它是开放式治理，背后有很多商业版。如果从开源软件本身社区发展角度看，很关键一点是上面有多少商业版，商业版越多说明从开源软件里面可以获利的公司越多，这样就有了正向的良性循环，会有更多资源投进来，社区里面参与的人就会更多，最后的发展会更好，生态会很繁荣。当时从这一点我们就觉得这个生态肯定会赢。”Kubernetes 一统容器编排市场的今天，业界一些专家对此有所忧虑，担心这种垄断会形成市场压制。从长期来看，如果 Kubernetes 的发展会形成类似 Android 一样的巨头化，那么作为下游厂商，灵雀云是如何看待和应对这种发展变化的呢？陈恺说，“回到垄断这个问题，如果是商业软件的话会有垄断这个问题，如果是开源软件的话，它的治理模式有可能是封闭式的，也有可能是开放式的，而 Kubernetes 是一个开放式的治理模式，会有一些厂商有更大的影响力，但不是被一家完全控制，所以我觉得从这个角度来说，谈不上垄断，更多的是一个标准。它可能更多像 Linux 而不像是 Android。从标准的角度来说，肯定是利大于弊，而且是远大于弊。因为有了标准，大家都围绕着标准做投入，风险就大大降低，可以放心去投入，也就会有越来越多的技术厂商会向它靠拢。”灵雀云的 Kubernetes 生态灵雀云在围绕 Kubernetes 生态方面也做了自己的发行版，他们是如何在符合 Kubernetes 标准的基础上形成差异化的服务和产品的呢？“Kubernetes 发行版首先必须是跟 Kubernetes 兼容的。在 Kubernetes 上可以增加各种各样的能力，但它本身的第一属性一定是一个真正的 Kubernetes。如果为了做差异性，把它做得不像 Kubernetes，不兼容会是个很大的问题。”陈恺说，“我们走的比这个更深一步，我们的 ACP 2.0 是把整个平台都做成 Kubernetes 原生的，因为 Kubernetes 本质上是声明式 API 加上基于控制器模型的架构设计范式，容器编排相当于它的一个副产品，是它基于这个架构的一种应用，当然也可以把这种架构应用到对任意资源的编排。前一段时间有一篇很多人转发的《Kubernetes 编排一切》的文章，讲的就是这个事情，它不光可以用来编排容器，可以做各种各样的事情。我很赞同这个观点。”灵雀云是从 2017 年底的时候决定这样做的，当时的做法是一些新的产品开始在新的架构上做一些实践，比如 DevOps 平台、基于 Istio 的 Service Mesh 等产品，完全基于新的架构来做。今年年初，灵雀云认为所有方面都成熟了：第一，方向肯定没问题，Kubernetes 编排一切；第二，对如何基于 Kubernetes 的架构构建上层产品有了更多的经验和体会。灵雀云于是把以前产品上的所有功能都逐渐迁移到 Kubernetes 原生架构上，重新融合到统一的架构里面，这就是 ACP 2.0。在此之上灵雀云还做了一些差异化。灵雀云在这里的技术栈分为三层：最底层的产品是一个 Kubernetes 发行版，Kubernetes 是一个开源的技术，并不是一个平台，大多数企业做不到直接把它当一个平台用。灵雀云的做法是将 Kubernetes 技术变成一个企业就绪的 Kubernetes 发行版。再往上是 ACP 层，定位是云原生应用赋能平台。包含有三个子产品：容器平台、DevOps 平台和基于 Istio 的 Service Mesh 产品。容器平台和发行版最接近，但对发行版进行了大量扩展，比如在发行版之上增加了多集群管理和企业级多租户。ACP 把单一的 Kubernetes 集群变成企业平台级的产品，经过了三年多 100+ 企业客户生产环境的考验，而且考虑到更多开发者的场景。DevOps 也基于 Kubernetes 原生，用 Kubernetes 去编排所有的工具，定位是一个开放式 DevOps 工具链集成和编排的平台。在此之上还有一层是灵雀云新的 ACE 3.0，它的定位是一个企业级的 PaaS 平台，或者用现在更时髦的说法，可以称之为企业技术中台，集成了更多企业需要的其他服务，比如第三方的中间件、开发框架等。它是个完整的技术中台，以容器平台为底座，以云原生黄金三角为核心，其他服务在上面做成一个个插件。这部分主要是和生态合作伙伴合作，国内外的一些最优秀的 PaaS 类服务都可以放在里面，为企业提供完整的解决方案。云原生之于微服务和 DevOps我们知道微服务、DevOps 等模式在云原生概念发展起来之前就已经存在，但是随着云原生的发展，似乎给它们注入了更多的活力。陈恺认为云原生显著地推动了 DevOps、微服务的发展，对于这一现象他还专门用了一个词汇来形容：后 Kubernetes。这是在容器和 Kubernetes 出现之后开始对 DevOps 侧的微服务反过来的助推。他认为，微服务架构的本质是用运维复杂度为代价去换取敏捷性。企业至少要考虑两件事：第一是否真的有这么高的敏捷性需求，值得用那么大的运维代价去替换，第二，假设你有着敏捷性需求，那么多出来的复杂度怎么办？早期微服务落地会很痛苦，因为大家没有准备好怎么去应付这个复杂度，而且会低估它。这复杂度是未知的，用未知的复杂度去替代已知的复杂度，这通常都是不好的，所以才会有各种各样的治理框架出来。其实它需要底下有一个好的基础设施来支撑它。容器和微服务天生一对，容器 Kubernetes 的出现，对微服务有非常明显地推动。Kubernetes 作为底层的应用管理平台非常合适，而且很多微服务里面要考虑的与业务无关的能力也可以慢慢推到 Kubernetes 里面去。而进一步，Service Mesh 等其上的技术栈就重新定义了微服务技术栈，微服务治理方式发生了变化，反过来作用到微服务上，形成了新的最佳实践。因此，要做微服务应该先容器化，才能解决运维复杂度的问题，容器化的服务应该跑在 Kubernetes 之上；如果进一步做服务治理，应该往 Service Mesh 方向走，Service Mesh 是基于 Kubernetes 平台的微服务治理的最佳实践。云原生之于 DevOps 也是如此。早期大家很多的精力在持续集成上面，比如 Jenkins 最初是作为 CI 工具出现的，而有了容器和 Kubernetes 之后，持续集成变得简化了，最终生成 Docker 镜像就好。重心开始转到部署，转到 CD 上。而且，现在的 DevOps 实践或 CI/CD 通常会把 Kubernetes 作为最重要的部署目标。也就是说CI会围绕容器镜像，CD 会围绕 Kubernetes。这是容器和 Kubernetes 带给 DevOps 的影响，基础设施越强大，对 DevOps、微服务就越有帮助。以 Kubernetes 为核心的基础设施变成新的标准，DevOps 和微服务的一些最佳实践都会围绕它去改变。源于开源，茁壮于开源云计算构筑在开源之上，灵雀云的基础设施和服务也构建在开源之上，那么灵雀云是如何拥抱开源和贡献开源的？陈恺说，“有几个开源社区跟我们是非常相关的，最早的时候是 Docker 社区，现在 Kubernetes 则是跟我们关系最大的开源社区。我们核心的产品是容器、DevOps 和微服务三部分。Jenkins、Istio 等相关开源项目是我们的重点，我们非常重视在开源社区的投入。我们的许多工程师会参与其中，对社区进行贡献，也会开源一些项目，我们在一步一步持续地做这件事情。我们首先会选择一些偏底层的技术或者机制，选择那些有足够亮点，真的被需要的项目和技术开源出来。”目前灵雀云已经开源了的项目，包括基于 OVN 的网络插件 Kube-OVN，它是把 OVN 的网络和 Kubernetes 所集成的网络插件。现在该项目在国内外都受到关注，也有来自外部贡献者参与。另外一个开源的项目叫 Captain，是一个基于 Helm v3 标准的 Kubernetes 控制器，对 Helm 应用分发进行改进。后续灵雀云还计划将更完整的东西放出来，比如灵雀云的 Kubernetes 发行版，供社区用户用来管理自己的 Kubernetes 平台，可以达到和使用灵雀云产品接近的体验。另外灵雀云也计划将其 ACP 释放社区版或者开源版本出来。陈恺说，“我们很乐意把它开源出来，因为这是一个标准的产品，我们让它较早期的接触更多用户，也能得到更多反馈，甚至吸收一些外部的贡献者参与进来。”尾声我采访过很多技术领袖和技术专家，不过陈恺的这场采访让我有一点不同的感受。一场对话下来，陈恺给我的感觉如同多年的老友一样言无不尽，而他对于我提到的每个话题，都非常认真、仔细的做了阐述，让人感到浓浓的专业技术风格。我想，这就是陈恺的技术初心，也是灵雀云一直以来的风格吧。“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。
从炎热的夏日中走入到钱塘江畔清凉的网易云会客室，我见到了陈谔，开始这次“轻舟”之行。说实话，初次近距离见到陈谔时，心中有点愕然，作为网易杭研的元老之一、网易云基础服务的领头人，我竟然从他身上感到一点点腼腆和技术人员的质朴。联想到之前网易云这边作为背景信息给出的个人介绍，这样的一位领军人物，居然自谦自己“对分布式系统设计开发、云计算平台系统架构有一定的经验和理解”，我不禁有些恍然。我接触和采访过很多开源和互联网公司的技术领袖，陈谔应该是我见过的最温和而又不失自信的人之一，他的脸上总是浮现着内敛的笑容，让我们在谈话的一开始，就有了一个良好的氛围。受访者（左）：网易云陈谔，采访者（右）：老王网易云：千锤百炼终成型和很多互联网公司推出的云服务一样，网易云也是一个脱胎于内部实践的云服务。网易杭州研究院作为整个网易公司的技术攻坚力量和创新业务孵化团队，随着网易业务和规模的不断的变化，杭州研究院面临着非常大的压力去做好基础设施的相关工作。随着移动互联网的到来，原本可以很好应对博客、游戏等业务的 IT 基础设施逐渐变得捉襟见肘，原本的资源调度能力无法处理好随着新业务和新模式的快速增长和迭代而产生的需求和复杂度。IT 基础设施成为了当时网易发展业务的新瓶颈。为了能够更好的服务网易内部的业务， 2012 年，网易杭州研究院组建了专门的云平台产品部，来建设网易内部使用的云计算平台，以应对移动互联网到来而产生的更加复杂应用带来的基础设施需求。随着网易云产品对内提供服务，规模上的问题被逐渐解决，但是，产品的研发模式也在不断的迭代，网易内部开始不断地实践微服务架构。在这个过程中，陈谔感觉到，现有的 IaaS 产品和 PaaS 产品已经渐渐无法支撑来自微服务架构的复杂度，但在那时，云原生理念和技术尚未成熟的时代，对于微服务的探索只能独立践行。网易云针对性的提供了 CI/CD、分布式架构链路跟踪、服务治理的工具，帮助用户更好的去实践微服务。到了 2015 年 7 月，随着 CNCF 的成立，这时陈谔发现，网易云的很多产品和服务，和 CNCF 的理念是一致的或相似的，于是，网易云决定将自己的探索和成果更好地结合社区的发展，向社区贡献自己的努力，也吸纳来自社区的营养，将网易云的发展和开源社区的路线结合起来。也正因为拥抱社区，网易云很早就走上了 Kubernetes + Docker 的发展路线。谈起对于 Docker 和 Kubernetes 的选择，陈谔表示，网易云选择 Docker 和 Kubernetes 并不是偶然之下的决定。实际上，早在 Docker 出现之前，网易云已经开始使用 LXC 技术来进行更细粒度的资源分配，实现了类似的容器技术栈，在此过程中，陈谔及其团队亲历了 LXC 技术在实施的过程中各种问题和技术缺陷带来的困扰。而 Docker 的横空出世使得整个云计算领域眼前一亮。虽然网易云自建的技术栈已经可以满足当时及近期业务的需求，但作为具有技术远瞻力的技术负责人，陈谔知道，相比于得到业界普遍看好的 Docker，自研的专属技术栈的生态环境狭窄，技术人员的培养成本也居高不下。而另外一方面，Docker 的镜像机制、分层文件系统机制，也使得之前在 LXC 技术栈里面斩荆披棘的网易云似乎看到容器技术发展的堂皇大道，使用 Docker 也就变得顺理成章。因此，网易云十分自然的就完成了从 LXC 向 Docker 的转移。我问及 Kubernetes 的选择，陈谔笑了笑，他提到，网易云对于 Kubernetes 的支持是非常早的，在早期 Kubernetes、Swarm、Mesos 尚三足鼎立的时候，网易云就坚定的投入了 Kubernetes 生态。这一点和网易云过去在微服务、容器编排方面的实践是密不可分的。Kubernetes 解决了网易云在过去运维过程中遇到的诸多问题：如何进行弹性伸缩、如何进行服务调度、如何使用配置来进行控制。Kubernetes 所提供的配置能力，特别适合于需要解决微服务架构编排问题的网易云。对于网易云来说，他们并不是一个刻意追求新奇的团队，相比于新兴的技术，网易云更在乎什么能够解决问题。显然，对于微服务架构支持最好的 Kubernetes 成为最终之选。企业云：只为解决客户问题网易云和很多云计算公司不同，没有将目光全部投放在公有云上，而是专注于为企业提供业务云化的解决方案。网易云也和容器云厂商的定位不同，容器是网易云的产品，更是网易云的工具，因此网易云虽然很早就应用了 Docker、Kubernetes 等技术，但是并没有突出这些看起来非常时髦的技术名词，而是根据企业需求，更多的将这些作为服务于上层的微服务产品的基础。通过结合容器的网络方案、存储方案等云原生技术积累，网易云希望更好的服务自己的客户。陈谔说，网易云之所以选择了企业云的路线，更多是因为网易云发现自身更适合于在云原生领域深耕细作。与其在公有云的红海中去竞争，不如在云原生领域去深入挖掘，提升技术和竞争力。这样，就将竞争从 IaaS 层面，提升到了基于云原生体系的 PaaS 层面，避开了红海的竞争。同时，这种基于 Kubernetes 标准化的 PaaS 服务，其生命力也远超普通的 IaaS 产品，Kubernetes 的设计使得它能够消除厂商锁定，基于其实现的 PaaS 服务可以运行在任何一家 Kubernetes 服务商的云产品上。陈谔还提到，作为一个面向企业提供解决方案的服务商，网易云和其他的容器云不同的是，更多是希望去靠近企业的 IT 的技术的认知，不会给企业造成过多的认知负担和业务侵入性。在业务落地时，能够根据企业的需要来不断的完成落地，而不是从一开始就要求企业去实践容器等，造成更大的负担。如果不是企业的需求要做容器化的话，不会第一时间要求用户完成容器化的迁移。但陈谔也发现，当用户真正去实施微服务框架的时候，往往会考虑实施和部署容器化，这时，网易云早已准备好的容器平台就可以很好的完成这部分的工作。对于不希望进行容器化的企业，陈谔提到，网易云针对于这些异构的环境，也提供了不同的解决方案，诸如支持裸金属集群和虚拟机环境的 服务网格 （ Service Mesh ） 等能力，可以帮助那些不打算做容器化的企业完成自己的工作。网易云希望自己的产品能够基于客户的 IT 策略来考虑，而不是将网易内部的实践生搬硬套到客户的业务中去。DevOps 认知：陈谔的 DevOps 观在谈到网易云内部的 DevOps 实践时，陈谔提到，在网易云内部其实很早就开始进行了 DevOps 实践。从 2014 年开始，网易云内部就开始推行服务化的组织架构和协作方式。在网易云内部，所有的工作都是接口先行，在网易云看到的每一个界面，都是先有接口，后有界面的。每一个接口背后都对应着网易云的一个服务以及对应的研发团队。这样从一开始，网易云就不设立专门的应用运维团队来负责业务的发布和上线，而是由各服务团队自行完成业务的发布和上线。除了 IaaS 层面基础设施的运维有专门的 SRE 团队来负责以外，各服务的运维都由各自团队自行来负责，这使得对应的团队必须自行解决运维需求。而且，为了更好的协作，网易云内部的所有的 API ，都会放在一个统一的 API 网关中，所有的用户都可以借助 API 来完成自己想要的操作，而无需进行 Web 界面的操作。我们还谈到了 DevOps 和容器化的关系，在过去的一段时间里，宣传上总是将二者联系起来。在陈谔看来，容器化和 DevOps 的关系实际上是相辅相成的。在他看来，之所以 DevOps 会出现，核心是随着企业业务的不断服务化拆分、微服务架构的实施，中心化的运维成为瓶颈，这使得企业不得不去提升运维的能力，去招募更多的运维。但是基于企业成本的考虑，运维人员的数量终归是有限的，因此有一些开发人员不得不兼任运维工作。但是，开发人员在运维方面的思路、关注点、风险意识上和传统运维人员存在一定差异，基于这样的考虑，需要一批工具来辅助开发人员进行运维工作，规范开发人员可以做的事情。在这样的一个大背景下，容器技术应运而生了。他相信，即使没有 Docker 公司搞出了容器化，也会有其他的公司来做出类似的产品，不同的只不过是各家的方案的优劣罢了。轻舟微服务：帮助企业更好落地微服务此次会见陈谔是在网易云创峰会上，而此次大会浓墨重彩介绍的产品之一就是网易轻舟微服务。轻舟微服务是网易云在完成了基础设施的 Docker、Kubernetes 等改造完成后，基于对业界的分析和研究后提出来的。出于标准化技术栈的考虑，网易云最终启动了轻舟微服务的项目，将现有的技术栈，打造成一个个独立的标准化技术产品。到了 2018 年，在完成了对所有技术栈的标准化以后，将轻舟微服务发布了出来。陈谔认为，异构系统整合，包括兼容、通信和系统间事务一致性，和多供应商建设，包括多团队协作、软件资产沉淀，是目前企业在建设在线业务中台过程中遇到的最大障碍，而网易轻舟微服务新品的发布，正是要通过服务网格、分布式事务框架 GTXS、全新 API 网关与原有轻舟产品的整合，完成全栈化在线中台技术体系升级，帮助企业完成业务架构的进化，支撑业务快速创新。网易云陈谔和老王陈谔介绍，轻舟服务网格是基于 Istio 和 CNCF 的 Envoy 等主流开源技术构建，可以实现 Java、Python、NodeJS、Golang 和 PHP 等不同技术栈的兼容和通信，能够与网易已有微服务框架 NSF 统一管控、互相发现、互相调用，并且支持容器、虚拟机和裸机部署，将异构系统的支持实现到了业界领先的程度。在陈谔看来，轻舟微服务的推出，是网易云内部的微服务能力的对外输出，是网易云内部技术能力的输出体系，针对企业客户，提供了一整套的技术方案，以及对应的咨询服务和最佳实践的指导，帮助先前没有足够能力独力完成微服务化的企业，完成企业产品和服务的微服务化。很多企业的 独石应用 （ Monolithic applications ） 随着企业的发展和产品的变迁，都面临新的挑战，而微服务化改造是企业所寄予众望的一条发展路径。但或因为微服务的技术储备不足，或因为既有业务的历史包袱过重，企业自行开发微服务体系不但耗时周期过长，而且可能因经验不足而走了弯路，因此，网易云在推出了轻舟微服务以后，赢得了不少企业用户的关注。在实际的使用过程中，轻舟的部署也帮助企业大幅度提升了新业务接入的效率和版本发布的效率。举个例子来说，如果同时有数十个微服务的不同版本在开发，在传统的模式下，就需要提供数十个测试环境来完成测试，但在轻舟下，就可以基于无侵入的流量染色功能重用一套测试环境，仅将测试流量路由至特定版本微服务，降低了环境的成本。后记由于我离开了中国电信好几年了，近些年我对企业级产品和服务接触并不太多。而这次的采访，使得我对于一直以来缺少了解的网易云和其产品有了更深刻的认识。显然，网易云在这场云计算大潮中，找到了企业界真正的痛点，关注到了众多企业的真实需求，这种深耕的思路，一方面让网易云支撑起来网易云音乐、网易考拉等明星产品，另外一方面也使得网易云在企业上云和 IT 现代化方面不断攻城略地，取得不菲的成果，这值得云计算领域的细分厂商学习。“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。
京东云郭理靖：我对云服务的一些看法
本期人物介绍：郭理靖，京东云产品研发部高级总监、产品委员会主席，专注于公有云服务、Docker、API 与数据开放平台、数据库服务等领域。擅长数据库、分布式存储系统、高可用服务架构等技术。在任职期间，郭理靖研发上线了 MySQL、SQL Server、MongoDB、PostgerSQL、MariaDB、Percona、JDW（数据仓库）、DRDS（分布式数据库服务）、时序数据库、TiDB、BDS（区块链 BI 数据分析服务）等多款京东云产品 。京东云不仅是国内第一家支持 MySQL 8.0 的云厂商，也是国内第一家支持 MariaDB 的云厂商，而区块链 BI 数据分析服务也是可以代表全球区块链先进技术的创新产品，聚合了业界知名项目的核心数据，目前 BDS 已经对外开源。前言盛夏，在一家幽静的咖啡馆，我见到了匆匆赶来的郭理靖。我们深入谈了关于云计算、关于数据库方面的一些话题。我将这些谈话中的精彩内容整理出来，以飨读者。与京东云共同成长的人在谈话中，我了解到，郭理靖在京东的工作历程是伴随着京东云的发展一路走过来的。从 2006 年到现在，郭理靖一直专注于云计算领域。从 2013 年京东云作为内部的基础设施云服务开始，他亲历了京东云从内部自用到正式商用的多个阶段的发展。作为核心人员之一，郭理靖又在其中扮演了什么样的角色呢？“其实我有两层角色，”郭理靖说到，“第一层，我负责数据库相关的服务，包括 RDS、数据仓库，现在京东云还推出了时序数据库、分布式数据库等，把京东技术体系内部的各种数据库的技术拿出来。另外，我还在京东云产品委员会，负责对京东云产品进行中长期规划， 评审产品开发可行性与必要性，规范产品上线流程，跟踪竞品动态与对标，统一产品培训资料，推进内、外部培训认证机制，精心打造京东云产品。”谈到这里，我发现一个现象，根据我的了解，包括京东云在内的很多公有云服务商的产品负责人都是出身于一线技术岗位。之前也有人跟我说，“为什么云服务行业是技术人员来担任产品经理，这是因为云计算服务就是技术性的产品，不懂技术的没法制定和设计这样的产品出来。”郭理靖表示：“这种说法是比较有道理的，因为整个云计算的产品主要是给技术人员使用，要求产品经理有很强的技术功底、技术视野以及技术敏感度，不是技术背景出身的产品经理，难于理解用户诉求，很多细节没法把握。比如做时序数据库，到底是做成什么样的时序数据库，提供什么样的功能，只有做过技术支撑的产品经理，才能理解要什么样的产品和什么样的用户体验。”从私有云到公有云最初，京东云只是作为内部基础设施服务，那时候京东云的人手也比较少，最初采用的技术是 OpenStack 技术栈，从 2014 年开始全部转向了 Docker 容器技术。那个时候，京东已经把统一监控、部署、代码管理、日志服务这些技术部分都已经建设完备了，但是还缺乏一个核心的运行环境，而其时崛起的容器技术正好填补了这个空白。这个技术体系一直发展到现在。到 2016 年， 京东云平台经历内部历练和打磨后，已经有了大规模的对外开放的技术基础了。在基础架构细节梳理的比较清晰、底层的基础设施服务和中间件服务都逐渐成熟、内部的使用和运营非常顺畅之后，当时决定，可以对外做公有云了。当然，做公有云和私有云的难度不是一个量级的，私有云很多事情都是在掌控范围之内，而做公有云要改造的东西特别多的。这包括网络管控、存储结构改造等几大的难点。 然而，京东云以后来者居上的节奏，从决定要对外开放，到真正的对外开往，仅用了几个月的时间，在 2016 年的 4 月 1 号正式对外开放公有云服务。在京东云的公有云服务上线之后，逐渐往上增加各种产品和服务。产品从 20 多款已丰富至现在的 220 多款。云计算从最初一个概念的提出，到后来发展为公有云、私有云、混合云等不同的形态，关于到底哪种云服务形态才是未来，人们也有不同的看法。不过从当前阶段看起来，主流的认识是，在认可公有云的基础上，企业希望有一种“私有化”的公有云服务。那么如何看待公有云、私有云以及接下来的发展呢？郭理靖说：“这个事情我们分两方面看，一方面就是看现状，另外一方面看接下去的发展。”“当前的云服务的现状是公有云、私有云、混合云并存，而且这个阶段可能会比较长。……京东也在做私有云服务，……我们称之为 JDStack 专有云，专业服务中大型企业以及政务云 。JDStack 既能把京东云所有的能力集成起来，而又提供灵活选配的功能，除了核心的几个组件，如 SDN、RDS 等必需的产品之外，其他产品都可以选配，用户可以将京东云的能力复制一份带回家，这个产品目前的市场前景也非常好。”，同样，对于混合云，“我们可以提供的 VPN 以及专线接入，打通用户的私有云与我们的公有云，我们有完整的混合云方案，京东云的很多客户也是采用混合云的模式。”至于公有云，就更不用说了。这三种模式我们都有，主要是使用于不同场景……就目前来看，公有云市场最大，而私有云的销售份额要比混合云大。”“你刚才讲到公有云上的私有云，确实有些用户希望在公有云里面划分一些独占的资源池，它的所有 VPS，RDS 都分配到那个资源池里面去，这种客户独享资源池的模式我们也是完全支持的。”郭理靖接着补充到，“存在这样的需求我觉得主要还是在于，政策法规上对于数据安全上面的规定。在金融、保险等领域，对数据保存的位置与管理都是有特殊要求的，使用这个解决方案，不仅能够满足合规的要求，而且能复用公有云统一的技术栈、管理服务，不用担心升级运维等基础设施性的问题。”Docker 出现以后，随着 Kubernetes 编排系统的进一步普及和标准化，用户逐渐摆脱了被厂商绑定的情况，目前京东云在容器服务方面的进展是怎么样的？“其实在云端提供容器服务的最大难点是资源隔离，在这方面我们做的还比较出色。我们应该是国内厂商中比较早做容器服务的。现在 Docker 是用 cgroup 进行隔离的，但会造成 Docker 容器之间的逃逸，导致同一台物理机上的 Docker 容器可以读取另一个 Docker 容器的数据。这在私有云上这不是太大的问题，但在公共云上是不可接受的，所以我们开发了原生容器服务，利用虚拟化去承载容器镜像。用传统的虚拟化技术进行隔离，同时兼容所有 Docker 的镜像，在启动速度方面，丝毫不逊色于 Docker，甚至在不少场景还会更快。同时原生容器还可以无缝衔接我们现有的 SDN 和云硬盘等底层服务，在公有云产品线里是属于与云主机平级的‘一等公民’，这会比在虚拟机里运行 Docker 要好很多。”专注于数据库除了云计算方面，郭理靖也植根于数据库领域。“京东云的关系型数据库（RDS）覆盖面还是比较广的，支持的数据库类型也比较多，除此之外我们还有自己的 DTS 服务，可以做数据迁移服务。”他说，“京东云非常重视数据库，数据库研发团队也非常精悍。我们对新技术的敏感度及理解一直走在前面。例如，京东云是国内首发支持 MySQL8.0 的云厂商，同时也是第一家支持云数据库 MariaDB 服务的云厂商，我们也在积极进行云原生数据库的研发工作。新的数据库，新的服务模式关于京东云自研的新数据库服务，我表示很好奇，因为一个全新的数据库的研发难度显然要远远大于将已有的开源产品进行适配、优化后提供给客户使用。郭理靖说，“因为 MySQL 在单一实例上自身存在容量限制，并不能发挥云端的优势：按需付费。比如购买云厂商的 RDS，企业实际购买的数据库服务的 QPS 是受限的，如果买更高性能则可能很多时候是浪费的。这就没有把云服务的资源和能力完全发挥出来：随着用户的体量越来越大，对容量的需求相对更大，应该在访问高峰时能够满足服务要求，在访问低峰时足够便宜，按照实际用量来收费。这样的数据库产品很值得设计研发。”京东云对未来这样一个按需付费的数据库期望达到：“第一、兼容SQL 标准；第二、按需付费、按性能付费，小规格的存储也能享受高性能，存储和运算深度分离；第三、性能非常好。”开源开放作为开源社区，我们自然也关注京东云的开源。郭理靖说，“参与开源社区活动我们是非常积极的。我们不但是云原生基金会（CNCF）的会员，也加入了 Enterprise Ethereum Alliance（EEA），我们对开源这件事持很开放的态度。”“在过去的几年中我们的工作压力比较大，更多的精力是投放在产品的打磨上，先要达到一定的产品丰富程度才能去做到精益求精，才能在对外开源，才能在开源社区上去贡献更大的力量”，郭理靖补充道。当然，开源从来不仅仅是一种意愿，而是代表着背后很多的工作投入的。开源这件事需要必要的时间和投入，京东云事业部对此也是持开放的态度，希望可以通过开源进行技术和品牌侧的建设。从这一点看，我觉得中国的技术公司已经有这样的思想和氛围了。“要做一个完整的开源项目还是存在一些挑战，比如京东云的很多项目相互依赖比较多，要做开源的话首先要进行整理和切割，否则开源出去也无法独立运作，就没有开源的意义了。举个例子，如果要开发一个中间件，那必须把原先和用户、计费、管理、监控相关的东西全部切割出来，这个任务代价是很大的。”郭理靖说，“目前我们的 BDS 项目已经完成代码的整理，已经对外开源了。BDS 是京东云打造一个行业标准的区块链的 BI + 数据搜索服务。区块链项目的底层区块存储结构各不相同，需要对不同的项目的数据进行解析与整理，基于此，京东云开源了区块链数据服务 (BDS)，以望让更多的开发者与社区可以参与其中，接入更多公有链、联盟链、私有链等区块链项目。区块链数据服务将以区块链数据搜索引擎形式聚合所有区块链相关的内容，最大化区块链上可信数据价值，方便社区能在 BDS 上进行区块链数据的一站式查询。。”“技术开源也能从另一个纬度考验我们的技术能力，进而驱动我们不断打磨技术和产品”。作为京东集团技术能力对外输出的重要出口，京东云商用三年以来，正在逐渐演化为京东技术的“开源”代表，对内整合 AI、区块链等硬核技术，对外不断携手上下游伙伴扩张生态，京东云希望让各种技术通过云端整合相互促进，业务侧对外赋能可以像积木一般拆分重组，实现“即插即用”的模块化方式，为社区、为生态带来普惠价值。结语和郭理靖的谈话匆匆过去了一个小时，通过和一位直接负责云产品的技术负责人的深入沟通，让我对京东云丰富的云产品背后所掩盖的宏大的技术背景有所了解，也对云计算的发展有了更多的切实体悟。“穿山甲专访”栏目是 Linux 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。
大公司开源怎么做？SOFAStack 给出一个很好的例子
蚂蚁金服的 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 重构为例，大概经历了这样的过程：首先需要将 SOFARPC 进行了一次核心接口和模型抽象，然后增加了扩展点机制和事件总线机制，所有的对内、对外实现都基于这些核心接口和模型去扩展，并且保证这些扩展能力都是平等的、可选的；接着将核心的处理逻辑实现迁移到这套接口和模型上来，保证 RPC 能力完整可用；然后需要将 RPC 里一些对接内部系统的、兼容历史逻辑的代码做成内部扩展，并进行全量测试验证，确保和已有线上的历史方案的兼容，发布上线；最后会调研业界的一些开源标准方案和实现，并对其进行兼容，例如 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 的主要原因有以下几点：Kubernetes 背后由 Google 支持：显然 Google 支持的 Kubernetes 会拥有更多的资源来发展，它也拥有更加强大的生命力。Kubernetes 是 Google 在内部基础设施的容器编排方面的经验升华：Kubernetes 的应用场景是容器编排，这种大规模容器的实践经验十分难得。而 Google 作为互联网领域的巨鳄，所拥有的经验和技术积累具有无可比拟的优势。相比之下，初创企业 Docker 公司在海量的可伸缩服务上的经验就稍显孱弱。而且 Docker 公司本身的开发力量显然有限，在容器技术日新月异的快节奏发展之下，仅仅是 Docker 引擎本身的开发和维护就已经有些不堪负荷，所以对他们在 Docker Swarm 上发展自然不如 Kubernetes 那么快。Kubernetes 的社区更加活跃：得益于 Google、Red Hat 等企业的开源社区基础，Kubernetes 从一开始就是整个社区目光的焦点，大量的开发者活跃在 Kubernetes 及其周边项目上，活跃的社区为企业培养了足够的储备人才，这一点是 Docker Swarm 和 Mesos 都无法比拟的。容器时代已经与以虚机为基础的云计算时代有着本质的区别，以前人们关注的是功能、性能、安全等问题，创建一个虚机每个厂商可以用不同的 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 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访，将为大家介绍中国开源领域中一些积极推动开源，谙熟开源思想的技术人，并辨析其思考、挖掘其动因，揭示其背后所发生的事情，为关注开源、有志于开源的企业和技术人标出一条路径。取名为“穿山甲”寓意有二：取穿山甲挖掘、深入之意来象征技术进步和表征技术领袖的作用；穿山甲是珍稀保护动物，宣传公益。
专访安全容器 Kata 项目创始人王旭：开源是一件向死而生的事情
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 等方面的一些认识，作为一个几年来亲自践行云计算发展，并有深入探讨和研究的专家，他的观点和认识或许值得从业云计算行业的技术人员参考。