其他分享
首页 > 其他分享> > 轻舟已过万重山:专访网易云陈谔

轻舟已过万重山:专访网易云陈谔

作者:互联网

从炎热的夏日中走入到钱塘江畔清凉的网易云会客室,我见到了陈谔,开始这次“轻舟”之行。

说实话,初次近距离见到陈谔时,心中有点愕然,作为网易杭研的元老之一、网易云基础服务的领头人,我竟然从他身上感到一点点腼腆和技术人员的质朴。联想到之前网易云这边作为背景信息给出的个人介绍,这样的一位领军人物,居然自谦自己“对分布式系统设计开发、云计算平台系统架构有一定的经验和理解”,我不禁有些恍然。

我接触和采访过很多开源和互联网公司的技术领袖,陈谔应该是我见过的最温和而又不失自信的人之一,他的脸上总是浮现着内敛的笑容,让我们在谈话的一开始,就有了一个良好的氛围。

受访者(左):网易云陈谔,采访者(右):老王

网易云:千锤百炼终成型

和很多互联网公司推出的云服务一样,网易云也是一个脱胎于内部实践的云服务。网易杭州研究院作为整个网易公司的技术攻坚力量和创新业务孵化团队,随着网易业务和规模的不断的变化,杭州研究院面临着非常大的压力去做好基础设施的相关工作。

随着移动互联网的到来,原本可以很好应对博客、游戏等业务的 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 中国社区

标签:容器,网易,服务,Kubernetes,轻舟,陈谔,万重山
来源: https://blog.csdn.net/chene_ce/article/details/122720472