微服务架构技术经过几年的发展，已经是百花齐放，各领风骚。SpringCloud、Dubbo、自研RPC、Service Mesh…… 大家对微服务架构下的技术、架构、功能模块似乎总有说不尽的话题。大部分团队在自身业务服务规模大到一定程度时开始引入微服务架构，而在技术选型上则大有百家争鸣的感觉：

Spring体系下倾向以Spring Cloud作为框架主体；

Dubbo是国内技术团队选型RPC通用框架的主要选择；

对于技术实力较强技术积淀较多的公司或团队，自研RPC+治理能力带来的可定制性也成为主流选择；

Service Mesh（服务网格）概念在2017年的崛起引发了“下一代微服务框架”的关注热潮。

我们在开发轻舟微服务框架之前也有些疑惑：究竟怎样的选型和架构最合适？如何避免重复造轮子？

设计理念

根据网易云服务网易集团内部业务和外部客户的经验，我们首先梳理了微服务框架的设计理念。我们认为，“最好”的选型与架构需求是这样的：

对业务无侵入：业务开发者应该无需关注和学习治理相关的技术，治理逻辑不应侵入业务代码。

功能完备：提供完备的治理功能全家桶，包括服务注册/发现，降级，限流，容错，负载均衡，分流等。

快速接入：业务系统可以快速接入框架和平台，同时通过平台实时配置治理策略。

安全稳定：提供统一的认证、鉴权机制，同时保障业务系统稳定运行。

跨平台性：如果能跨不同语言和平台，那自然是极好的。

隔离性：多租户、多项目隔离，具备大平台多业务隔离能力。

微服务生态亲和性：符合微服务技术和架构趋势，同时具备长远的扩展性。

开发愿景

轻舟微服务框架的最大愿景，就是可以让业务系统开发者无需关注和学习治理相关技术、无需修改业务系统代码就可以快速引入服务治理能力。

以SpringCloud体系为例。传统开发模式下，如果业务开发需要引入微服务架构，就需要学习SpringCloud全家桶内的相关内容：

需要服务注册/发现？请学习Eureka；

需要熔断器、线程隔离？请学习Hystrix；

需要负载均衡？请学习Ribbon；

需要API网关？请学习Zuul；

需要配置中心？请学习Config、Bus；

……

如果使用传统的方式，可能一家企业的若干团队的众多相关开发人员都需要学习和熟悉Spring Cloud，至少是学习其中的部分组件，而且原生Spring Cloud组件在某些场景下缺乏灵活性，甚至存在一些BUG。除了掌握组件用法，甚至需要掌握核心源码以避免一些被动引入的坑。

所以，前文提及过的避免重复造轮子何其重要！

技术选型

从上面分析可以看出，比起各家各自为战重复造轮子，我们更希望的是一个更通用、侵入性更低、能力更全面的微服务框架。自研RPC虽然能更贴近一些公司或团队的需求，但一般自研RPC往往带有公司或团队长期的技术背景，比较难作为通用技术选型，所以率先pass。

Spring Cloud作为开源届大佬Spring旗下微服务框架的代表作，天生强大的同时还天生要强的引入了Netflix较完备的微服务治理工具集，诸如Eureka、Ribbon、Hystrix、Config、Archaius、Zuul。依托较早脱颖而出的SpringBoot，Spring在微服务圈依旧拥有众多拥簇。

SpringCloud全家桶

Dubbo作为一款标杆型的RPC框架，依托大厂场景成为国内公司RPC框架的重要选择。从小到大到开放到停止维护再到恢复开放更新，Dubbo发展历经风雨又让开发者日久弥新。前期重RPC轻治理丧失了一些追求完整解决方案的粉丝，后来重新焕发生机引入了较多治理特性，也可以作为通用框架备选。

Service Mesh自问世起就备受关注，它提出的无侵入、去中心、高可运维型和扩展性架构十分迷人。Istio作为宇宙级大厂Google、IBM等的联合作品，2017年的横空出世让人感觉到微服务全新时代到来的气息。其依托于Kubernetes平台，虽然前期版本问题不少，其架构和技术的先进性还是微服务架构追随者看到了来自远方的曙光。

Istio架构

关于这几个框架横向对比和详细介绍的文章较多，本文不做详述。从通用微服务框架角度，满足架构、功能、扩展性是技术选型的核心要素。网易云轻舟微服务团队在开始进行微服务基础框架选型时，对各个框架发展状况的最终思考如下：

Spring Cloud在Java体系微服务成熟度较高，功能全家桶能力较全，加之Spring的天生优势，成为我们微服务框架落地的首选；

Dubbo初期治理能力的欠缺；

Service Mesh理念超前，但由于框架处于较早期阶段，尚存在一定问题（平台绑定Kubernetes、性能问题等），不太容易在传统业务直接落地。

当然，Service Mesh在架构和技术上的超前性同样让我们持续关注，落地的架构和技术选型也参考其理念，并决定在后续版本逐步打通。

架构

网易云轻舟微服务框架整体架构V1.0

网易云轻舟微服务框架简称NSF，NSF 1.0版本的架构，以常见的微服务集群为主要场景，主体包括代理（nsf-agent）、服务控制中心（nsf-server）、注册中心（nsf-registry），以及认证鉴权中心（Auth）、通用配置中心（Config）、监控中心（Monitor）、知识库（knowledge）等通用组件。

NSF功能主体以nsf-agent为载体，其以代码无侵入的java agent方式随应用进程启动，配合简单的配置文件完成服务的注册、发现，并对治理的目标进行方法级与服务级增强，使之具备熔断、线程隔离、降级、限流、容错等治理能力，以及负载均衡、路由、参数分流等流量控制能力。

nsf-server、nsf-registry为支撑nsf-agent能力提供了服务元信息管理、策略管理与分发、注册信息同步与实时下发等平台级能力。

Auth、Config、Monitor、Knowledge则作为微服务平台通用组件提供诸如服务认证与鉴权、服务配置、服务监控、服务基础信息能力。

这种架构最大的特点整体抽象agent，无需侵入业务服务代码，同时提供平台能力统一管理微服务信息、治理策略、配置等，降低微服务集群运维成本。而平台本身也是微服务架构，也通过注册中心、治理组件等保证自身微服务的稳定运行。

互联互通社区

互联互通社区专注于IT互联网交流与学习，关注公众号：互联互通社区，每日获取最新报告并附带专题内容辅助学习。方案打造与宣讲、架构设计与执行、技术攻坚与培训、数据中台等技术咨询与服务合作请+微信：hulianhutongshequ