分布式服务框架一般是相对传统单体架构而言的。
在业务的早期，为了快速上线和试错，一般都会选用单体架构来构建业务，所有的业务组件都在同一个应用内部。但随着业务的发展，用户量和业务规模越来越大，单体应用的性能会遇到瓶颈，同时用户需求也会越来越多，各个组件耦合在一起会导致研发效率的下降，无法应对快速变更的用户需求。这个时候就需要考虑分布式服务化的架构。
服务化架构需要把原来的单体应用进行服务化的拆分，一般先按照业务领域进行纵向拆分，比如电商平台可以拆分为用户中心、订单中心、支付中心等，再按照通用共享维度进行横向拆分，比如订单中心可以继续拆分为订单基础服务、订单聚合服务、订单应用服务等。服务进行合理的拆分和整合后，就可以独立地进行扩缩容，解决性能瓶颈，同时也可以独立的进行迭代演进，解决研发效率问题。
服务化的架构一般要求选用一套服务化的技术框架，来解决服务之间的互相发现以及服务治理等问题（比如限流、降级、熔断、分流等）。开源框架里面大家用的比较多的有Spring Cloud和Dubbo这两种。SpringCloud提供了服务化框架所需要的一整套工具套件，包括服务注册发现Netflix Eureka、服务调用Ribbo和Feign、服务治理Netflix Hystrix、服务配置SpringCloud Config、服务网关Netflix Zuul和SpringCloud Gateway等。Dubbo也提供了类似的一套解决方案，在国内用户也比较多。
但是开源框架的使用成本仍然比较高，主要体现在两个方面。首先是开源框架对业务的侵入性比较大，框架代码与业务代码耦合比较紧密，导致升级运维复杂度高。其次是开源框架缺少体系化的解决方案，经常面临不同方案的组合和选择，无论是基于SpringCloud还是Dubbo，构建一整套的微服务解决方案仍然需要投入很多的精力去做方案的选型和不同方案的整合。
这里可以参考下网易轻舟微服务解决方案，不仅提供了业务无侵入的接入方式，同时提供了一整套开箱即用的微服务套件。业务可以通过agent一键接入到框架，即可完成服务注册和发现、服务治理、流量染色、服务配置、认证和鉴权等一系列配套能力。值得一提的是该框架同时支持SpringCloud、Dubbo和gRPC等不同协议和框架的一键接入。架构如下：
参考：https://www.zhihu.com/question/19699884/answer/1183012719