数字化创新浪潮之下，微服务架构已经被越来越多的企业采用。本文通过网易云轻舟微服务核心研发人员的实践总结，解读如何建设微服务基础设施，以便更好地利用微服务技术来支撑业务实现跃进式的发展。在本篇中，网易云架构师、轻舟微服务技术负责人冯常健结合网易云实践总结了微服务的沿革、价值、落地挑战和解决思路，并分享了网易云打造轻舟微服务的核心经验，以及未来的技术路线。
（网易云架构师、轻舟微服务技术负责人冯常健）
冯常健认为，微服务化是分布式架构发展的高级阶段，是目前满足大规模业务、高速迭代、高可用率等需求的最优方案。他介绍，网易云轻舟微服务平台的成功研发，为网易公司完善各个业务中台打下了基础，产品研发效率提升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会是一个工作重点。
相关文章：
【推荐】 浅谈 kubernetes service 那些事（上篇）
【推荐】 直播平台杜绝违规内容之道