原创声明

本文首发于微信公众号【程序员黄小斜】

本文作者：黄小斜

转载请务必在文章开头注明出处和作者。

本文思维导图

什么是分布式服务

RPC

　　RPC（Remote Process Call），即远程服务调用，被广泛地应用在很多企业应用中，是早期主要的服务治理方案，其流程较为简单，客户端consumer携带参数发送RPC请求到服务提供方provider，provider根据参数路由到具体函数，方法，并将执行获得的结果返回，至此一次RPC调用完成。

　　

　　随着业务的发展，大数据时代的到来，服务提供方的压力也日益增大，单机应用的处理能力无论在软件，硬件上都受到限制，provider也不可能一直无限扩容，即使扩容，也存在着很多问题，即服务的路由，和Consumer的负载均衡问题。因此，分布式服务架构应运而生，RPC发展到一定阶段思考的变革，成为了分布式服务，云计算的计算机基础。

SOA

　　由于简单的RPC调用已经不能随着时代发展满足需求，因此复杂的业务逻辑对于分布式应用架构体系的需求愈发强烈，业务希望自己的服务是分布式部署的，请求是分流的，对数据的操作是能读写分离的，同时能屏蔽许多复杂需要自己编写的底层服务，借助已有的公共服务，去快速的构建自己的应用，降低人力开发维护的成本和提高应用交付的效率，基因此，基于分布式服务思想的SOA（Service-Oriented Architecture）成了新的受追捧的架构。常见的SOA服务调用流程图如下：　

　　

服务治理方案

　　业界的互联网巨头公司，都有属于自己的分布式服务框架，如阿里巴巴的Dubbo，HSF，腾讯的Tars，京东的JSF，新浪的Motan，都已经是业界非常成熟的解决方案，其中开源的Dubbo和Motan受到了广大开发者的研究对象。

　　纵观这些服务框架，设计的基本思路都如上图，无非涉及provider发布注册，consumer订阅，调用发起，负载均衡，服务分流和监控等模块，并在此基础上增加了很多玩法，形成了各具特色的分布式服务框架设计，下面就Dubbo，JSF，Motan的设计做下简单的介绍。

Dubbo：下图是Dubbo在服务治理方面的架构设计

初始化阶段：部署在Container的Provider启动后向服务中心Registry发布并注册自己的服务，客户端Consumer初始化时即向Registry订阅自己想要的服务，同时Registry对Consumer保持着一个长连接，当订阅的服务新增或减少节点时，会及时通知到客户端更新（此过程是异步进行的，不会影响Consumer的主流程），如此一来，客户端Consumer便有了Provider的所有实时信息，便可以发起服务调用了。

invoke阶段：客户端Consumer从获得的所有Provider列表中通过负载均衡等策略选出最适合调用的服务提供者Provider并发起同步调用。

Monitor阶段：Consumer和Provider通过异步的方式向监控中心上报自己的需要被监控的数据。

　　

JSF

下图是JSF在服务治理方面的架构设计

初始化阶段：Provider启动后向服务注册中心发布注册自己的服务

invoke阶段：与Dubbo不同的是，JSF的注册中心不向Consumer推送Provider实时数据，而是在发起调用时Consumer向注册中心询问并获得对应的Provider，然后组织匹配JSF协议的报文发起调用。

Monitor阶段：Provider定期向监控中心发送性能统计数据，同时Provider还会上报事件给事件中心。

　　

Motan

Motan是有名的轻量级服务框架，代码质量很高，下图是Motan在服务治理方面的架构设计

Motan的服务治理设计与Dubbo十分的相似，都是Provider发布注册，Consumer订阅与接受推送，之后发起调用。

　　

分布式服务框架主要模块名词释义

无论是那种SOA的架构设计，都离不开几个模块的功能，即Provider，Consumer，Registry，Gateway，负载均衡，服务分流，监控等，通过上述所讲，应该对这些功能模块有了初步的认识，下面就这些名词再作下介绍

（1）Provider：服务提供者，无论是业务服务，还是一个系统中公用的SAAS，都属于Provider

（2）Consumer：即发起调用的客户端

（3）Registry：服务注册中心，是分布式服务系统中的一个重要组成模块，管理Provider的Manager，在实际的运行环境中，服务注册中心Registry被动通知或Consumer主动询问，在Provider有节点宕机或新增节点时，客户端也可实时感知到，从而避免了某个Provider被无限调用或是无限闲置

（4）Gateway：网关也是分布式服务框架中不可或缺的部分，每种系统与框架都有自己的一套协议，当异构系统互相调用时，网关的作用即显现出来，Gateway接受各种外部HTTP请求，完成相应的权限校验，报文适配，路由转发到对应的Provider，再将Provider返回的结果传递给异构系统的Consumer，完成异构系统的互相调用

（5）负载均衡，服务分流：Consumer从Registry获得具体的Provider列表后，如何选取合适的Provider，取决与一定的负载均衡算法，常见的算法有轮询法，随机法，源地址哈希，加权轮询，加权随机等

（6）监控：接收来自Consumer和Provider异步上报的性能监控数据，对有风险的节点发出告警

分布式服务和微服务的区别

分布式架构是分布式计算技术的应用和工具，目前成熟的技术包括J2EE, CORBA和.NET(DCOM)，这些技术牵扯的内容非常广，相关的书籍也非常多，也没有涉及这些技术的细节，只是从各种分布式系统平台产生的背景和在软件开发中应用的情况来探讨它们的主要异同。

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

从概念理解，分布式服务架构强调的是服务化以及服务的分散化，微服务则更强调服务的专业化和精细分工；从实践的角度来看，微服务架构通常是分布式服务架构，反之则未必成立。所以，选择微服务通常意味着需要解决分布式架构的各种难题。

区别分布式的方式是根据不同机器不同业务。

将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。区别分布式的方式是根据不同机器不同业务。

微服务更加强调单一职责、轻量级通信(HTTP)、独立性并且进程隔离。

微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。

分布式是否属于微服务？

不一定，如果一个很大应用，拆分成三个应用，但还是很庞大，虽然分布式了，但不是微服务。。微服务核心要素是微小。。

微服务架构是分布式服务架构的子集。

微服务架构通过更细粒度的服务切分，使得整个系统的迭代速度并行程度更高，但是运维的复杂度和性能会随着服务的粒度更细而增加。

微服务重在解耦合，使每个模块都独立。分布式重在资源共享与加快计算机计算速度。

分布式：分散压力。微服务：分散能力。

参考文章

https://blog.csdn.net/zhonglunsheng/article/details/83153451
https://www.sohu.com/a/322537288_120047065
https://www.cnblogs.com/jiyukai/p/9459983.html