网站建设部网,玉环建设规划局网站,网站总体设计怎么写,免费线上培训平台分布式微服务治理的核心在于: 微服务和分布式(微服务框架)微服务的最优技术实现目前是: SpringBoot(RPC 框架)分布式的最优技术实现目前是: Thrift,Motan,Dubbo,Spring Cloud(Netflix OSS),Finagle,gRPCRPC 是什么RPC 的全称是 Remote Procedure Call #xff0c;是一种进程间…分布式微服务治理的核心在于: 微服务和分布式(微服务框架)微服务的最优技术实现目前是: SpringBoot(RPC 框架)分布式的最优技术实现目前是: Thrift,Motan,Dubbo,Spring Cloud(Netflix OSS),Finagle,gRPCRPC 是什么RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。它允许进程调用另一个地址空间的过程或函数而不用进程员显式编码这个远程调用的细节进程员无论是调用本地的还是远程的本质上编写的调用代码基本相同。说两台服务器 A、B一个应用部署在 A 服务器上想要调用 B 服务器上应用提供的函数/方法由于不在一个内存空间不能直接调用需要通过网络来表达调用的语义和传达调用的数据。Remote Procedure Call翻译过来应该是 “远程进程调用”目前业内通用的翻译是 “远程过程调用”但是 “过程” 这个词很容易造成误解翻译成 “进程” 更好理解 RPC 的意义。RPC 协议说了什么一般所谓的 XX 协议就是个文档类似于我们的需求文档只说了要做什么但是具体怎么做是由各大开源大佬做的。一般情况下都会实现核心功能不同的开源在细节上实现都会不一样这个需要注意RPC 这个概念术语在上世纪 80 年代由 Bruce Jay Nelson 提出的在 Nelson 的论文 “Implementing Remote Procedure Calls” 中他提到了几个RPC的特点简单RPC 概念的语义十分清晰和简单这样建立分布式计算就更容易。高效过程调用看起来十分简单而且高效。通用在单机计算中过程往往是不同算法部分间最重要的通信机制。除此之外这位大佬还给出了实现 RPC 框架的详细架构图结合上图Nelson 的论文中指出实现 RPC 的进程包括 5 个部分UserUser-stubRPCRuntimeServer-stubServerUser 是调用方User-stub 负责将调用的接口、方法和参数通过约定的协议规范进行编码RPCRuntime 负责将本地数据传输到远端的 RPCRuntimeServer-stub 负责根据约定的协议规范进行解码Server 是被调用方所以这架构图的意思是当 user 想发起一个远程调用时它实际是通过本地调用 User-stub。并通过本地的 RPCRuntime 传输 。远端 RPCRuntime 实例收到请求后交给 Server-stub 进行解码后发起本地端调用调用结果再返回给 User 端。实现 RPC 协议需要什么看完协议内容跟着就得实现这个协议啦这时候你是不是发现了问题的严重性自己一点思路都没有序列化协议和传输协议所以我们需要再理解一下 RPC 协议根据 Nelson 的论文知道我们要做的两件事将调用的接口、方法和参数通过约定的协议规范进行编码/解码(User-stub/Server-stub)将本地数据传输到远端 (RPCRuntime)上述两点其实是实现 RPC 协议的两大要素序列化协议和传输协议。本地与远程调用的对比因为 RPC 本质上是进程间通信而 “本地调用和远程调用的对比” 实际上就是 “进程内通信和进程间通信的对比”。通过两者的对比我们才能理解到序列化协议和传输协议的作用如下图理解单点式 RPC 框架和分布式 RPC 框架的区别最基本的 RPC 框架就是单点式的因为 A 服务直接调用 B 服务不经过第三方这种是最简单的。但是必须是 A 和 B 同时部署一套A1 只能调用 B1A2 只能调用 B2。假设现在 B 服务出现了性能瓶颈部署多台 B 服务的同时也只能部署多台 A 服务很浪费资源。所以需要一台 A 服务对多台 B 服务利用第三方服务 (注册中心) 找到其他 B 服务而不是写死 B 服务的地址。这种 RPC 才是分布式RPC也是业内主流。单点式 RPC 框架(自己玩自己)分布式 RPC 框架 (自己玩自己还能玩别人)实现分布式 RPC 框架需要什么单点 RPC 框架只需要序列化协议传输协议但是我们要做分布式的啊所以需要序列化协议传输协议服务注册发现中心实际上在生产环境中我们需要实时监控服务的调用情况所以需要一个微服务管理中心甚至是一个自动化运维的管理中心所以需要序列化协议传输协议服务注册发现中心服务监控管理中心在文章的第二节我们看到大佬论文中对 RPC 的总结其中一个很重要的一点“通用”。对的30 年前的初衷更大的是需要解决异构系统的服务调用问题序列化协议和传输协议必须是通用的才是好的 RPC 框架你总不能只能 Java 用然后 C# 用不了Scala 用不了Go 用不了吧。比如某个服务的并发需求高需要用 GO 来解决因为以前用的 Java 性能低下。然后你的 RPC 框架不支持 GO完蛋啦中间的一个服务是 GO 写的上层服务是 Java 来调用的不支持跨语言的 RPCGo 语言写的新服务完全用不了那还玩个鸡儿。所以我们需要序列化协议传输协议服务注册发现中心服务监控管理中心能跨语言调用(无关语言)对的能实现上述五点的才是一个合格的 RPC 框架但还不是优秀因为我们还要考虑下性能。说下业内流行的 RPC 框架和性能问题先打个底目前流行的 RPC 框架大多都是多管闲事不单单只是 RPC 框架你可以看看 Dubbo 和 SpringCloud 中除了 RPC 还有什么骚功能。可以看看别人的各种 RPC 框架总结http://www.cnblogs.com/moonandstar08/p/6291283.html在网上找到了个图但是没有提到 SpringCloud暂且看看先因为有些不认为是对的我们可以看到各个 RPC 框架使用的序列化协议注册中心管理中心是否跨语言但是传输协议没有提到。性能问题参考这篇博客http://blog.csdn.net/jek123456/article/details/70208049综合来说在性能上 rpcx 是首选但是考虑到框架的生态其实还是推荐 Dubbo 或者 SpringCloud 的因为除了性能成本也是很重要的无论是学习成本还是研发成本。感谢
