网易云冯常健:节省超千万成本,轻舟微服务是如何做到的?

网易云社区2019-03-22 11:52

数字化创新浪潮之下,微服务架构已经被越来越多的企业采用。本文通过网易云轻舟微服务核心研发人员的实践总结,解读如何建设微服务基础设施,以便更好地利用微服务技术来支撑业务实现跃进式的发展。在本篇中,网易云架构师、轻舟微服务技术负责人冯常健结合网易云实践总结了微服务的沿革、价值、落地挑战和解决思路,并分享了网易云打造轻舟微服务的核心经验,以及未来的技术路线。

(网易云架构师、轻舟微服务技术负责人冯常健)
冯常健认为,微服务化是分布式架构发展的高级阶段,是目前满足大规模业务、高速迭代、高可用率等需求的最优方案。他介绍,网易云轻舟微服务平台的成功研发,为网易公司完善各个业务中台打下了基础,产品研发效率提升100%,部署效率提升280%;也成功应用于物流、制造、银行、证券等行业,帮助客户快速实现微服务化以提高生产力,包括一年节省超过千万元的研发运维成本。


网易云是如何做到的?冯常健表示,实施微服务涉及分布式架构的多种挑战,技术门槛高,众多开源组件可以满足企业建设微服务基础设施的基本需求,但开源组件学习成本高,配置复杂,且应用侵入性大,网易云以基于开源、无侵入、易用性为设计原则,基于多年技术积累,将复杂的微服务技术封装为通用平台,帮助业务团队快速、低成本地实现架构微服务化,并提供一整套工具链,包括服务治理、DevOps、AIOps、自动化测试等,保障微服务业务系统顺畅运行。

轻舟微服务诞生:稳定性、扩展性和开发效率的召唤

2012年,冯常健加入网易杭州研究院,开始了云计算研发的工作。初期他主要参与和负责云管平台、云消息队列、自动化部署平台等云服务设计与开发,目前这些云服务在电商、音乐、教育、传媒等部门都有广泛应用。通过这些项目,他对云计算的整个技术栈,以及如何设计一个云服务有了深刻认识,也逐渐形成了设计分布式系统时的思考习惯: 首先会从可用性、稳定性、性能、扩展性等非功能特性入手设计或者review架构的合理性。


从2015年开始,伴随着Docker和Kubernetes的流行和项目需要,冯常健开始转向容器技术的应用研究,之前的自动化部署平台核心在于解决应用构建与部署问题,而在资源编排、服务编排、服务故障自愈等在DevOps实践中同样重要的问题则较少涉及,而容器技术可以补齐自动化部署平台缺少的这些能力,通过容器技术提供的弹性伸缩、服务编排、错误恢复等能力,结合IaaS提供的资源可编排能力,实现无服务器(Serverless)形态的容器平台。


容器技术的普及,推动了微服务架构在网易内部的广泛应用。爆发式增长的网易业务,遇到低耦合、易扩展的微服务,可谓干柴烈火,容器平台则是火上加油。微服务通过业务拆分、进程独立部署、轻量化的通信方式等手段解决了单体架构中存在的可用性、稳定性和扩展性差等难题,并使得团队有更多的技术栈可以尝试,减少团队沟通成本,提升开发效率,加快迭代速度。而容器的镜像和编排等能力,则成为了微服务细粒度分拆与优雅协作的神器。


在两年多的容器和微服务实践中,网易云验证了基于Kubernetes的容器平台在微服务架构的部署调度、集群容错、故障恢复等方面的彪悍实力,也发现了平台还有一些亟待优化的问题,比如服务注册发现、流量负载均衡、服务熔断降级、配置管理等,虽然Kubernetes对这些问题也有相应的解决方案,但在生产环境落地时,一些客户比较担心这些方案的性能、稳定性和可运维性。引入基于Spring Cloud的微服务治理框架,是否能更好地解决服务运行时治理等问题?


于是,冯常健和他的团队在2017年开始了轻舟微服务框架组件的研发,希望新的微服务框架可以和容器平台以及云计算部门研发的DevOps、APM、自动化测试等组件形成互补,形成端到端的轻舟微服务平台,更好地支持微服务落地。

在网易公司内部,轻舟微服务帮助完善了各个业务中台的建设,产品迭代最高提速100倍,人力运维成本节省80%,单节点20,000个服务实例同时在线及水平扩展的支持,让电商大促扩容更加顺畅。而对于企业客户,轻舟微服务也意味着数字化创新的核心平台之一,某客户直接采用轻舟微服务,大幅提升按需扩容响应速度,上线部署时间缩短80%,研发周期缩短40%,并省去交付沟通、协调等成本,成本节省折合货币效应超过千万元。如果自己研发这个平台,至少需要投入30人团队,耗费半年时间。但该公司认为,更重要的是基于轻舟微服务能够灵活地进行业务调整,此前需要半年才能上线新业务,现在只需要一个月。

微服务技术挑战:本质是分布式架构的挑战

在冯常健看来,上述成果的实现,得益于对架构本质的把握,而实现微服务的挑战,本质上还是分布式架构带来的挑战。一旦实施微服务架构,团队会面临服务注册、服务发现,服务流量的负载均衡,分布式系统的集群容错、系统的可用性和可扩展性,服务数量多了之后的配置管理、部署调度,还有如何进行日志和监控的统一管理、如何进行服务调用跟踪等等。这些挑战,每一项都需要引入大量的基础技术平台和框架组件来解决。


当然,每一项挑战也都有不少开源解决方案。从实施微服务的技术团队角度来看,团队可能喜欢一开始就引进很多新技术,设计出一套能满足未来3到5年的架构出来,但从业务的角度来看,其实不是每一个阶段都有必要引入这些技术实现或解决方案,在人力有限的情况下,如果团队把太多精力倾斜在微服务架构建设方面,忽视了承载更多价值的业务研发,这就是本末倒置,最终可能会导致项目的失败。


冯常健解释说,业界常见的开源解决方案,比如对于Java技术栈,有Dubbo和Spring Cloud框架,都很强大,但它们的学习曲线比较陡峭,而负责每个微服务的往往是相对比较小的团队,如果其中大部分人再把时间都放在新技术、新框架的学习上,团队就没时间投入到业务开发。以Spring Cloud为例,如果每个团队上来都要学习几十个组件,而且学完了也不一定能用好它们,对开源组件掌控程度不够反而会给业务带来一些不稳定的因素,这对于企业而言也是很大的成本。所以,不能为了做微服务而做微服务,而是要根据业务匹配度来选择技术。

轻舟微服务框架设计:基于三大原则

对于网易云而言,容器平台和DevOps工具链已经就绪,APM也有基础,解决上述问题,核心便是微服务框架的研发,而作为云计算技术提供商的网易云,却必须考虑产品能力的全面性。那么,网易云又是如何思考和实践的呢?冯常健介绍,团队在微服务框架设计上定义了三大原则。


首先是基于开源技术栈,整个架构基于Spring Cloud,兼容Dubbo,以插件化的方式实现服务注册发现、服务治理、负载均衡、流量控制等。基于来源、兼容开源,可以最大程度地降低客户了解产品、使用产品的成本。


其次是无侵入性,实现了微服务治理框架和用户业务的松耦合,好处是用户只需要关注业务,服务治理框架的引入和升级不会带来业务改造的成本。插件化的方式,有利于实现这一点,并且对服务性能的影响可以忽略。


第三是易用性,实现图形化的统一控制中心,通过一个平台化界面涵盖完整的实时的服务治理能力,将用户从繁琐的配置中解放出来,允许用户通过图形化界面解决原本需要编写代码、编写配置才能解决的问题。


这些设计要求在技术实现上存在很大的技术挑战。例如无侵入性的实现,轻舟微服务主要采用Javaagent字节码增强技术,将服务治理逻辑以独立Jar包的方式提供加载。为支持更大的并发,轻舟微服务后端采用全分布式架构,能支持单节点20,000个服务实例同时在线,支持水平扩展,并提供99.99%以上的可用性。


目前,在微服务框架模块上,轻舟微服务已经实现了服务注册发现、负载均衡、集群容错、服务熔断降级、流量控制、动态配置管理、统一监控大盘等能力,覆盖了微服务的治理到问题的定位和排查。


性能优化对轻舟微服务框架而言也是重要的工作。例如,对Spring Cloud社区的服务发现组件Eureka做了源码级的定制和参数优化,实现了单节点10,000个服务实例的注册能力。同时,还引入异步化框架,比如Servlet 3.0、异步HttpClient、Disruptor等技术,使得轻舟微服务的请求转发能力达到单节点30,000以上TPS,并且延迟控制在5毫秒以内。


正是这些优化工作,让轻舟微服务能够承担重任,满足了网易内部和网易云客户的业务需求,实现了微服务的价值。

轻舟微服务的未来:融合Service Mesh

当前社区热议的下一代微服务架构Service Mesh,也是网易云轻舟微服务在未来微服务框架方面的工作重点。冯常健认为,Service Mesh提供的通信方式,更安全、快速和可靠,控制面与数据面的设计,使得微服务治理功能与业务解耦更加彻底。


目前开源Service Mesh架构实现中,控制面有Google主导的Istio,数据面有Envoy、Linkerd等,都是已经或者即将进入CNCF(云原生计算基金会)的开源组件,轻舟微服务框架秉承基于开源、兼容开源的思想,通过集成开源技术能力去帮助用户更好落地微服务。


轻舟微服务目前在Service Mesh方向的工作有两方面,一方面是基于Envoy做优化和改进,提供高性能的微服务通信网络,形成自己的数据面组件,可无缝对接轻舟微服务控制平台。另一方面,Istio目前的发布版本是基于Kubernetes实现的,无法脱离Kubernetes容器平台运行,而轻舟微服务框架定位是底层基础设施平台无关的,它不关心服务是运行在容器里面,还是直接运行在虚拟机、物理机上。因此,轻舟微服务框架集成Istio会是一个工作重点。

点击了解网易云轻舟微服务,获取方案