您现在的位置是：首页 >其他 >RPC、HTTP、DSF、Dubbo，每个都眼熟，就是不知道有什么联系？网站首页其他

一、HTTP 和 RPC

首先，http 与 rpc 有什么区别这个问题不太严谨，因为这俩就不是一个层级的东西。

HTTP

这个大家太熟悉了吧？日常接触最多的恐怕就是各种http协议的接口了。

没错，http它是一个协议。

其他在这里就不打算铺开了，以前整理过一些内容，有需要的可以跳转翻翻看：

• 一、http介绍、TCP/IP 协议族
• 二、IP，TCP 和 DNS、三次握手
• 三、HTTP 协议基础、四次挥手
• 四、HTTP 缺点
• 五、HTTPS 中的加密、证书介绍，不一直使用 HTTPS 的原因

RPC

RPC 是一种技术的代名词，全称是远程过程调用。

远程？那是不是也有本地过程调用？

没错，举个例子说明一下：

• 本地过程调用：你的电脑上启动了一个服务A，运行程序的时候服务A里的各种方法的互相调用，就是本地了。
• 远程过程调用：而隔壁小王也启动了一个服务B，他还说他里面提供了一个功能非常劲爆的方法，你也想去调用，这就是远程了。

而至于你怎么调用到小王服务器里的方法，那就是个实现方式的问题了。你为了简单，直接走http协议也行。如果觉得http满足不了需求，那么也可以基于tcp自定义一个协议。

远程调用过程

远程调用过程大概就是下图所示：

二、DSF

在工作中我发现公司有不少应用的名字是 DSF 打头的，DSF（Distributed Service Framework）其实就是指分布式服务框架。

简单介绍 2 个点：为什么要用到分布式、这套DSF的包含的内容。

为什么要用到分布式

为什么要用到分布式服务？换个方式问那就是：分布式解决了什么问题。

首先，分布式架构是由单体架构演进而来，我司的业务系统也不例外。业务早期为了降低开发成本，实现快速上线，通常使用单体架构，所有的业务模块都在同一个应用里。

随着业务规模的扩张，单体应用的缺点就暴露出来，比如：

• 系统耦合性高，当后面增加的功能越来越多，代码量巨增的时候，之前某个主程脑海中划分好的模块边界可能越来越模糊，导致调用关系混乱。
• 改一赠二出现越来越多，经常存在开发修改了某个功能，而导致其他的功能有问题。
• 某个功能有问题，整个一起回滚。
• 语言单一，不能根据场景选择更合适的语言。比如其中有个模块系统主要是大数据分析，用 python 自然更加合适，因为它有丰富的类库。
• 系统不易于拓展部署，比如系统中有一个功能流量很大，顶不住了就要加机器，那么在新机器上还是部署整个应用，不能单独的部署这个大流量的服务，会造成一定的资源浪费。 。。。

为了解决这些问题，于是把之前的业务进行垂直拆分成多个系统。系统与系统之间通过网络交互来完成各项业务处理，每个系统互相独立，可以单独部署。这种多个组件合作对外提供服务的形式，就是分布式了。

但是分布式同样也有它的缺点：

• 从之前的单应用调用，现在变成了多个应用直接的交互，调用链路变长，带来了网络开销，同时也给定位问题增加了难度。
• 为了让你的应用更可靠，还有考虑其他的异常情况，比如调用失败、因某些问题导致的高频调用，对此还得做些 限流、熔断之类的措施。
• 出现问题，可能会涉及多个服务的回滚，互相之间会有影响。
• 环境变复杂了，增加了测试的复杂度。 。。。

简单来说，分布式帮我们克服了单体带来的瓶颈，但是为了分布式服务的稳定性，我们需要考虑更多的东西。

DSF包含的内容

那么一套分布式服务平台都有哪些内容，这里简单列举一下（以我司自研为例）：

• 服务注册：服务提供方上传契约信息，契约中包含服务组信息、服务信息、API信息等。
• 服务发现：服务消费方寻址，基于某种粒度可以找到需要。
• 服务调用：自定义超时时间、失败重试次数等，支持同步、异步调用等。
• 负载均衡：比如支持轮询策略。
• 网关：还可以通过网关对外提供一些rest api调用。
• 健康检查：对服务提供方实例进行健康检查。
• 服务拓扑：应用调用的上下游链路拓扑图。
• 服务监控：展示服务运行状态、调用指标等。
• 报警：当某个服务的实例异常数超过阈值，触发报警。
• 限流：用于保护系统。
• web前台：方便查看各种信息，各种常用功能的入口。 ...

三、Dubbo

对于分布式服务框架，如果有自研能力的话，可以结合公司业务实际情况进行高度定制化。如果初期不具备这样的条件，很多公司会选择成熟的开源框架直接使用，dubbo 就是这样的框架。

Dubbo 是阿里巴巴 2011年开源的一个基于 Java 的 RPC 框架，它实现了面向接口的代理 RPC 调用，并且可以配合 ZooKeeper 等组件实现服务注册和发现功能，并且拥有负载均衡、容错机制等。

dubbo 架构

这是官方文档的架构图，描述了 Dubbo 微服务组件与各个中心的交互过程。

• Registry 注册中心：协调 Consumer 与 Provider 之间的地址注册与发现。
• ConfigCenter 配置中心：存储 Dubbo 启动阶段的全局配置，保证配置的跨环境共享与全局一致性；负责服务治理规则（路由规则、动态配置等）的存储与推送。
• Metadata 元数据中心：接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）；作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展。

以上三个中心并不是运行 Dubbo 的必要条件，用户完全可以根据自身业务情况决定只启用其中一个或多个，以达到简化部署的目的。通常情况下，所有用户都会以独立的注册中心 开始 Dubbo 服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。

所以，如果想快速实现一个分布式服务框架，就可以基于dubbo的方案来进行开发，既可以拿来就用，后续也可以进行二次开发。