tag: RPC

随着近几年分布式、微服务架构的火热，RPC 在开发工作中使用的越来越多，也变的越来越重要。 作为一个学生，在学校接触到的大多都是 SSM 这类单体应用，但实习后发现，基本是接触不到从 0 到 1 的项目的，更多的是在为整个大系统的某个小模块添砖加瓦。因此，模块与模块之间的通信就变得异常重要。 集群、微服务、分布式 《道德经》是老子的宇宙生成论，其中“一生二，二生三”广为流传，对于一个软件系统来说，笔者认为这句话也同样适用。所谓一，便是系统的业务需求，无论何人，其编写的每行代码最后都是为了服务业务，或是实现业务功能，或是提升业务性能，最终目的均无法逃离业务。一般意义上，一个公司的业务系统发展脉络基本都是类似的：从单个应用到多个应用，从本地调用到远程调用，随着业务规模的发展，需要对远程服务进行高效的资源管理。于是分布式、集群、微服务等**“银弹”**便应运而生。 在欧洲民间传说的影响下，银弹往往被描绘成具有驱魔功效的武器。 后来也被比喻为具有极端有效性的解决方法。不过佛瑞德·布鲁克斯所发表一篇关于软件工程的论文中提到在软件工程领域是没有银弹的，复杂的软件工程问题无法靠简单的答案来解决 为了分散业务能力，出现了“微服务”；为了分散机器压力，出现了“集群”和“分布式”。那这三者有何关联？我们以一张图来说明： 某大型系统下有众多功能，如订单、视频、物流等，项目初期可能是写在一个大的工程里，部署在一台机子上，后来业务发展了，每个子功能都变得相当复杂，用 IDE 打开这个项目都要花好久，为了方便开发，开发团队将每个功能分开，并起名为“服务”。每个服务可以操作自己的数据库、缓存等，也可以在本机与其他服务通信（这时项目仍然部署在一台机子上）。再后来，一个 DB、Redis 已经没办法满足这个服务的需求，所以又将单个 DB 扩展成 DB 集群，单个 Redis 扩展成 Redis 集群以此来分担机器的压力。再后来，这些服务所在服务器的性能被压榨的一滴也没有了，没办法，只能将这些服务一个个的分在不同的机器上，这就是**“分布式”**。 由此可见，集群，是在多台机器上部署相同的程序，对于集群内部而言，每台机器是一个不同的节点。但对于集群外部（调用方）而言，集群就是一个整体，操作起来就和操作单个数据库、单个 Redis 没有任何区别。对于整个项目来说，如果集群中某个节点挂了，整个集群仍然可以正常工作，这是一种纵向的扩展。 而分布式，是指在多台机器上部署不同的模块。这些模块原本可以放在一台机器上，这叫中心化，一旦这台机器崩溃，上面所有的服务就会崩溃，整个项目也就崩溃了。因此我们可以将系统横向拆分成多个服务后部署到不同的服务器上，如果一台机器崩溃，虽然这台机器上的服务也会崩溃，但不至于导致整个系统发生崩溃，这叫去中心化。 所以随着业务的发展，微服务、集群、分布式这些名词的出现是很有必要的。 RPC 的三个问题 上面我们用了一定篇幅解释了微服务、集群、分布式这些比较火的名词，接下来我们回到本文的主角——RPC。 RPC（Remote Procedure Call），即远程过程调用。不同于本地调用，函数与函数之间同属于同一块内存空间，如需调用某个函数，只需要找到所在内存地址即可。远程调用，通俗地说，便是有两台服务器 A，B，一个应用部署在 A 服务器上，想要调用 B 服务器上应用提供的函数/方法，需要通过网络来表达调用的语义和传达调用的数据。 知道了 RPC 是什么，以及为什么需要 RPC 后，接下来我们就要看看如何实现 RPC 了。文末我会给出一个简单的用 Java 实现 RPC 的 demo，这里先从一个有趣例子出发给出需要解决的三个问题：Call ID 映射、序列化和反序列化、网络传输。 从一个有趣的例子出发 笔者之前写过一篇《从找对象到多线程》，文中以找对象这个例子出发，介绍了线程，这次就让我们开一个线程来看一下远程调用 RPC 吧。 笔者的好友在一个男生如云的工科学校，机缘巧合下，喜欢上一个隔壁学校的妹子，终于有一天他决定告白。所以，第一步就是要知道那个女生所在的学校、年级、班级、姓名等相关信息，确定到那个人，这个过程就是Call ID 映射。由于疫情的原因，虽然各自都开学了，但都被学校强制封闭性管理，无法直接见面，因此，男生就想着用**情书的方式表达自己的爱慕之意，这个过程就是序列化**。男生想着，只要女生收到情书后便能**理解自己的爱慕之情，就会和自己在一起了，这就是反序列化**。剩下的就是如何将情书**送过去了。可选的方式有很多，比如找快递小哥送、发微信、发邮件之类的，只要能将信息传送过去就可以。这个过程就是网络传输**。 Call ID 映射 不知道上面的例子有没有很好的解释Call ID 映射、序列化和反序列化、网络传输是什么东西。将上述例子类比到项目中，我们就能很好的理解为什么需要解决这些问题了。...