首先,http 与 rpc 有什么区别这个问题不太严谨,因为这俩就不是一个层级的东西。
HTTP
这个大家太熟悉了吧?日常接触最多的恐怕就是各种http协议的接口了。
没错,http它是一个协议。
其他在这里就不打算铺开了,以前整理过一些内容,有需要的可以跳转翻翻看:
RPC
RPC 是一种技术的代名词,全称是远程过程调用。
远程?那是不是也有本地过程调用?
没错,举个例子说明一下:
而至于你怎么调用到小王服务器里的方法,那就是个实现方式的问题了。你为了简单,直接走http协议也行。如果觉得http满足不了需求,那么也可以基于tcp自定义一个协议。
远程调用过程
远程调用过程大概就是下图所示:
在工作中我发现公司有不少应用的名字是 DSF 打头的,DSF(Distributed Service Framework)其实就是指分布式服务框架。
简单介绍 2 个点:为什么要用到分布式、这套DSF的包含的内容。
为什么要用到分布式
为什么要用到分布式服务?换个方式问那就是:分布式解决了什么问题。
首先,分布式架构是由单体架构演进而来,我司的业务系统也不例外。业务早期为了降低开发成本,实现快速上线,通常使用单体架构,所有的业务模块都在同一个应用里。
随着业务规模的扩张,单体应用的缺点就暴露出来,比如:
为了解决这些问题,于是把之前的业务进行垂直拆分成多个系统。系统与系统之间通过网络交互来完成各项业务处理,每个系统互相独立,可以单独部署。这种多个组件合作对外提供服务的形式,就是分布式了。
但是分布式同样也有它的缺点:
简单来说,分布式帮我们克服了单体带来的瓶颈,但是为了分布式服务的稳定性,我们需要考虑更多的东西。
DSF包含的内容
那么一套分布式服务平台都有哪些内容,这里简单列举一下(以我司自研为例):
对于分布式服务框架,如果有自研能力的话,可以结合公司业务实际情况进行高度定制化。如果初期不具备这样的条件,很多公司会选择成熟的开源框架直接使用,dubbo 就是这样的框架。
Dubbo 是阿里巴巴 2011年开源的一个基于 Java 的 RPC 框架,它实现了面向接口的代理 RPC 调用,并且可以配合 ZooKeeper 等组件实现服务注册和发现功能,并且拥有负载均衡、容错机制等。
dubbo 架构
这是官方文档的架构图,描述了 Dubbo 微服务组件与各个中心的交互过程。
以上三个中心并不是运行 Dubbo 的必要条件,用户完全可以根据自身业务情况决定只启用其中一个或多个,以达到简化部署的目的。通常情况下,所有用户都会以独立的注册中心 开始 Dubbo 服务开发,而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。
所以,如果想快速实现一个分布式服务框架,就可以基于dubbo的方案来进行开发,既可以拿来就用,后续也可以进行二次开发。
最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!?