分布式服务框架一般是相对传统单体架构而言的。
在业务的早期，为了快速上线和试错，一般都会选用单体架构来构建业务，所有的业务组件都在同一个应用内部。但随着业务的发展，用户量和业务规模越来越大，单体应用的性能会遇到瓶颈，同时用户需求也会越来越多，各个组件耦合在一起会导致研发效率的下降，无法应对快速变更的用户需求。这个时候就需要考虑分布式服务化的架构。
服务化架构需要把原来的单体应用进行服务化的拆分，一般先按照业务领域进行纵向拆分，比如电商平台可以拆分为用户中心、订单中心、支付中心等，再按照通用共享维度进行横向拆分，比如订单中心可以继续拆分为订单基础服务、订单聚合服务、订单应用服务等。服务进行合理的拆分和整合后，就可以独立地进行扩缩容，解决性能瓶颈，同时也可以独立的进行迭代演进，解决研发效率问题。
服务化的架构一般要求选用一套服务化的技术框架，来解决服务之间的互相发现以及服务治理等问题（比如限流、降级、熔断、分流等）。开源框架里面大家用的比较多的有Spring Cloud和Dubbo这两种。SpringCloud提供了服务化框架所需要的一整套工具套件，包括服务注册发现Netflix Eureka、服务调用Ribbo和Feign、服务治理Netflix Hystrix、服务配置SpringCloud Config、服务网关Netflix Zuul和SpringCloud Gateway等。Dubbo也提供了类似的一套解决方案，在国内用户也比较多。
但是开源框架的使用成本仍然比较高，主要体现在两个方面。首先是开源框架对业务的侵入性比较大，框架代码与业务代码耦合比较紧密，导致升级运维复杂度高。其次是开源框架缺少体系化的解决方案，经常面临不同方案的组合和选择，无论是基于SpringCloud还是Dubbo，构建一整套的微服务解决方案仍然需要投入很多的精力去做方案的选型和不同方案的整合。
这里可以参考下网易轻舟微服务解决方案，不仅提供了业务无侵入的接入方式，同时提供了一整套开箱即用的微服务套件。业务可以通过agent一键接入到框架，即可完成服务注册和发现、服务治理、流量染色、服务配置、认证和鉴权等一系列配套能力。值得一提的是该框架同时支持SpringCloud、Dubbo和gRPC等不同协议和框架的一键接入。架构如下：
除了微服务之外，网易轻舟云原生平台提供了一系列围绕微服务的云原生产品，包括容器云、微服务套件、DEVOPS和PaaS中间件等，适用于微服务改造、业务中台、数字化转型、工业互联网、开放平台等多种场景。
主要提供微服务发布,服务治理和服务监控,因为复杂的业务需求,会造成线上服务的混乱,和连接数据库的混乱.
微服务的好处是:
业务解耦,方便扩容,方便系统按模块升级,模块重用,开发新业务简单,开发人员可以专注某一业务,方便代码管理,方便数据库优化
微服务的坏处:(分布式服务框架要解决的问题)
每个系统之间的关系变得非常复杂
随着调用的业务增多,底层的模块需要高可用性和并发
需要分布式Session框架支持
分层后增加测试复杂度
所以一般分布式服务框架都会且不仅限于实现下列功能:
微服务发布(http/rpc)
服务调用代理及客户端软负载
基于Token的安全认证框架
服务治理(服务注册/管理/配置推送等)
服务监控(调用链分析)
测试平台
很多公司都会自己实现一套，我们是自己实现的一套infogen框架不过尚未开源,开源的话可以看看dubbo,当然如果不嫌弃多年未更新和配置复杂的话
就是同一个服务，把数据库的不同部分分开建立到不同的服务器上。以缓解数据库大量数据访问的压力。
很多大公司的业务量比较大，每天的访问量都达到几百万上千万，甚至上亿的访问量，在访问量不是很大的情况下，是可以通过提高单台服务器的配置来满足需求的。但是当单台服务器已经满足不了需求的时候就需要做分布式处理了。毕竟一台服务器的处理能力是有限的。
如果分散到几台甚至几十台几百天电脑上，其优势就显现出来了。
可以去看下阿里的开源框架Dubbo，会有更深的了解。
我们公司现在用的系统采用的是分布式架构，我们目前用天翎的低代码平台，它目前目前采用的是微服务架构，前端采用vue，后端采用spring cloud，并且支持分布式架构。
书籍：
《分布式系统：概念与设计》(Distributed Systems:Concepts and Design)《分布式算法》(DISTRIBUTED ALGORITHMS) Nancy A. Lynch这两本书分别是将分布式系统和分布式算法的，你所要了解的分布式服务的知识能够从这两本书中获得，另外《分布式算法》一书的作者曾经将这本书的前身--其在授课时使用的讲义免费公布过，不过我找不到链接了，有需要的话可以留邮箱。