分类 穿山甲专访 下的文章

导读:本文介绍了开源项目 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 是一个需要大量人力来适配各种网站的规则的项目,可以参与的地方很多,参与门槛不高,又能获得非常积极的反馈。

  1. 可以参与的地方很多:每个 RSS 路由都对应一个脚本,可以让很多人参与进来。
  2. 参与门槛不高:脚本的编写难度不高,RSSHub 还有非常详细的开发文档,进一步降低了开发门槛,然后采用了统一代码规范,严格的自动化测试来避免出现问题。
  3. 积极的反馈:可以很方便地自己动手制作自己想要的 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 编排一切》的文章,讲的就是这个事情,它不光可以用来编排容器,可以做各种各样的事情。我很赞同这个观点。”

陈恺在云原生技术实践峰会 2019 上演讲

灵雀云是从 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 中国社区推出的面向开源界、互联网技术圈的重要领军人物的系列采访,将为大家介绍中国开源领域中一些积极推动开源,谙熟开源思想的技术人,并辨析其思考、挖掘其动因,揭示其背后所发生的事情,为关注开源、有志于开源的企业和技术人标出一条路径。

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