多进程中的RPC
RPC是什么
RPC（Remote Procedure Call Protocol）远程过程调用协议。
RPC通俗描述：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。
RPC正式描述：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
常见的RPC框架：
谷歌的gRPC，百度的bRPC，阿里开源的Dubbo / 当当网扩展的Dubbox、Spring Cloud、Thrift、Hessian、CXF、Motan
示例：Thrift
Thrift是一种可伸缩的跨语言服务的RPC软件框架，它结合了功能强大的软件堆栈的代码生成引擎，以建设服务，高效、无缝地在多种语言间结合使用。2007年由facebook贡献到apache基金，是apache下的顶级项目，具备如下特点：
- 支持多语言：C、C++ 、C# 、D 、Delphi 、Erlang 、Go 、Haxe 、Haskell 、Java 、JavaScript、node.js 、OCaml 、Perl 、PHP 、Python 、Ruby 、SmallTalk
- 消息定义文件支持注释，数据结构与传输表现的分离，支持多种消息格式
多进程中的RPC
参与多进程项目后，经常听说RPC，觉得很高大上，好像很难的样子。经过一番学习后，发现其实在开发移动app项目的时候经常使用这个东西，举个例子大家就明白了：比如移动app中进行登陆验证的时候，移动端会收集用户名和密码，然后打包成一个request，发送给某个网址，后台接到用户名密码后，调用相应函数处理，并返回给客户端结果；客户端接收这个网址的response，解析数据后，就知道了用户权限是否合法。这个过程就是一个RPC过程，是不是从一脸懵逼到恍然大悟。
RPC
RPC（远程过程调用），广义上讲，只要调用过程不在一个进程中，都称为远程调用；windows将RPC做了细分，发生在一台机器上的跨进程调用称为LPC，意为本地过程调用；发生在网络上的跨进程调用，称为RPC。RPC在分布式中应用比较多
跨进程交互方式
RESTful、Webservice、Http、基于数据库做数据交换、基于消息队列做数据交换、RPC
跨进程交互形式分类
直接交互：比如访问http请求，调用方需要提供方立即提供结果，提供方的运算效率影响着调用方的执行效率，实时性高。
非直接交互：基于数据库的交互方式属于典型的非直接交互，调用方将消息数据存储到数据库中，提供方可以在任意时候取出数据并执行操作，再将结果存储到数据库中，调用方再从数据库中取出结果，这个调用过程实时性差。
RPC架构
服务提供方：定义并提供服务，将服务注册到注册中心中
服务调用方：调用远程服务
服务中心：服务注册与发现
调用流程
- 客户端（服务调用方）调用存根里的方法
- 待传输的对象数据序列化成二进制数据
- 网络传输到服务端（服务提供端）
- 二进制数据反序列化出对象
- 利用反射调用服务的方法
- 返回方法的返回值
- 将返回值序列化成二进制数据
- 网络传输给客户端（服务调用方）
- 反序列化二进制数据
- 返回结果给调用方的调用函数
重点实现
调用方传入：接口类名称、方法名及参数类型、实参数据
注册中心传入：接口类名称、接口类实现的对象（默认将接口类中所有的公开方法一次性注册到注册中心中去，每个方法都会被封装成一个注册项）
服务查找：根据接口类名称、方法名及参数类型去注册中心寻找实现对象（由于接口可能存在多个实现类，因此查找结果可能存在多个符合项），进而反射调用对象的相应方法。
Dubbo分布式服务框架入门
Dubbo是什么，它有什么用。
使用场景：比如我想开发一个网上商城项目，这个网上商城呢，比较复杂，分为pc端web管理后台，微信端销售公众号，那么我们分成四个项目，pc端网站，微信端网站，还有一个后台服务项目，接口服务项目。
对数据库的操作的相关接口放到接口服务项目，这些接口的实现放在后台服务项目，pc端网站和微信端网站都依赖接口服务项目，调用后台数据库数据。在这种场景下就是应该使用Dubbo这种分布式服务框架了。当然这只是Dubbo的一个最浅显的功能。
有些猿友可能会问到了，为什么搞那么多各项目啊，不是自找麻烦麽。当你一个项目越来越复杂的时候，是必须要怎么干的，至于为什么，慢慢会有体会。
1.1、Dubbo是什么？
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架
其核心部分包含:
1）远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
2）集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
3）自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
1.2. Dubbo能做什么？
1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
1.3. dubbo的架构
dubbo架构图如下所示：
节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
对于这些角色来说，其他都还好，Monitor可能猿友们前期使用会把它忽略，但是后期会发现它的作用十分明显哦，如服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？为了解决这个问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。
调用关系说明：
0 服务容器负责启动，加载，运行服务提供者。
1 服务提供者在启动时，向注册中心注册自己提供的服务。
2 服务消费者在启动时，向注册中心订阅自己所需的服务。
3 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
1.4. dubbo使用方法
Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。如果不想使用Spring配置，而希望通过API的方式进行调用（不推荐）
Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。
服务未来的趋势
谈到服务，可能大家很多听说过SOA、MSA等服务的概念名词，近几年MSA炒的比较火，其实每一个概念的背后都在解决不同的问题。此类名词的最大特点就是一解释就懂，一问就不知，一讨论就打架（no more agree）
两者说到底都是对外提供接口的一种架构设计方式。我倒觉得微服务其实就是随着互联网的发展，复杂的平台、业务的出现，导致SOA架构向更细粒度、更通用化程度发展，就成了所谓的微服务了。以这种说法做为根据，我觉得SOA与微服务的区别在于如下几个方面：
- 微服务相比于SOA更加精细 ，微服务更多的以独立的进程的方式存在，互相之间并无影响；
- 微服务提供的接口方式更加通用化 ，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制；
- 微服务更倾向于分布式去中心化的部署方式 ，在互联网业务场景下更适合；
微服务与SOA有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。在围绕着服务的概念创建架构这一方面，微服务提供了一种更清晰、定义更良好的方式。微服务的原则与敏捷软件开发思想是高度一致的，而它与SOA原则的演化的目标也是相同的，则减少传统的企业服务总线开发的高复杂性。两者之间最关键的区别在于， 微服务专注于以自治的方式产生价值。 但是两种架构背后的意图是不同的： SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。
| 功能 | SOA | 微服务 |
|---|---|---|
| 组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
| 耦合 | 通常松耦合 | 总是松耦合 |
| 公司架构 | 任何类型 | 小型、专注于功能交叉的团队 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目标 | 确保应用能够交互操作 | 执行新功能，快速拓展开发团队 |
微服务并不是一种新思想的方法。它更像是一种思想的精炼，一种SOA的演进，并且更好地利用了先进的技术以解决问题，例如容器与自动化等。所以对于我们去选择服务技术框架时，并不是非黑即白，而是针对SOA、MSA两种架构设计同时要考虑到兼容性， 对于现有平台情况架构设计，退则守SOA，进则攻MSA，阶段性选择适合的。
参考推荐：
RPC框架原理到选型：gRPC、Thrift、Dubbo、Spring Cloud
版权所有: 本文系米扑博客原创、转载、摘录，或修订后发表，最后更新于 2022-03-02 05:58:04
侵权处理: 本个人博客，不盈利，若侵犯了您的作品权，请联系博主删除，莫恶意，索钱财，感谢！
转载注明: 多进程中的RPC （米扑博客）
研究这么高深的东西了？