发布时间：2020年10月1日-6分钟阅读
你可能会因为这个吸引人的标题而读到这里。哎呀，谁不喜欢提升水平呢？
在这篇文章中，我们将借助gRPC--"一个高性能、开源的通用RPC框架"--他们在自己的网站上明确指出的--来提升我们的进程间通信（IPC）水平（哈！我又说了一遍），特别是给Linux开发者举例。
看完这篇文章后，希望你能相信gRPC是一个超强的同机IPC框架，而不仅仅是像它广为人知的分布式计算或云端微服务。我们甚至还提供了一个通过Unix Domain Sockets（UDS）实现gRPC的例子，帮助你进一步入门。
这听起来是不是很熟悉？
对于那些不熟悉进程间通信的人来说，它是一种允许进程进行通信和管理其共享数据的机制。一些IPC机制包括
- 消息传递（套接字、Unix域套接字、命名管道等）。
- 共享内存
下面是一个消息传递的例子。
如图所示，进程A需要将对象传递给进程B，这个过程需要将每个对象序列化到一个缓冲区，发送、接收、反序列化回来，最后进程B需要对这些对象做一些事情。
如果进程B要返回一个对象给进程A呢? 你猜对了! 这整个过程，不过是倒过来的。
如果上图看起来很熟悉，请问自己。
- 增加一个新的对象类型有多容易？需要几分钟吗？几小时？几天？
- 进程之间的通信安全吗？
- 在另一台机器上部署进程B，并轻松地将我的传输层重新实施为通过套接字的TCP/IP而不是UDS，需要多长时间？
- 引入进程C会有多大的麻烦，因为它期望从进程A得到不同的对象？
- 我是否要自己实现和维护所有这些代码？
如果这些问题中的任何一个让你在座位上动弹不得，你也许可以节省几个小时的开发时间，同时还能顺便改进你的项目架构。
我知道你在想什么......gRPC! 但是等等，RPC是谁？
远程过程调用（RPC）是IPC的一种形式，它使进程能够在其他进程中执行功能，同时在途中来回传递数据。RPC并不是一个新的孩子，它已经存在了很久。它可以用于同一台机器上的进程，也可以用于机器之间的通信。有很多实现RPC的框架和库，支持各种编程语言以不同的方式执行序列化。虽然这些年大多数的实现都是一鸣惊人，但gRPC并不是其中之一。
那么，gRPC有什么特别之处呢？
gRPC的根源在于Google对协议缓冲区的实现，即Protobuf，一种序列化结构化数据的方法。它被设计成比XML更快、更小，而且非常简单；是一种接口描述语言，描述它序列化数据的结构。
gRPC增加了HTTP2传输层，它解决了以前HTTP1.1协议的几个问题。因此，gRPC的性能优于其他基于HTTP1.1协议的替代品。在gRPC的众多功能中，你可以发现双向流、阻塞和非阻塞传输、超时、SSL/TLS认证与加密等。自2015年由Google开源以来，其最常见的用例是微服务式架构。
gRPC中的 "g "竟然不代表 "Google"，也就是该库的原始开发者，但维护者为每个版本都找到了不同的 "g "相关词，这里可以看到。
一些突出的优点包括。
- 消息和服务都是用一个简单的各方同意的定义语言来定义的。这种设计允许一种简单的方式来解耦进程之间的依赖关系。因此，API总是直截了当、不杂乱无章。
- 客户端和服务器的实现可以用10多种不同的语言在本地生成。C#, C++, Dart, Go, Java, Kotlin, Node.js, Objective-C, PHP, Python和Ruby。
- 有一个庞大的社区在开发工具和插件。在这里可以找到一个很棒的gRPC资源列表。
虽然很多人都知道gRPC的HTTP传输，但它也可以用于通过UDS进行传输。
这意味着，如果你是一个有安全意识的开发人员，我相信你是，你将能够通过Unix域套接字配置通信。这赋予你更好的权限控制和安全性，因为Unix文件权限适用。这个狡猾的功能不一定在所有语言中都能实现。我们已经在C++中实现了一个流行的gRPC "Hello World "的例子。你可以在这里找到greeter_client.cc代码，在这里找到greeter_server.cc代码。还可以添加额外的插件，比如SSL/TLS加密，以进一步保护你的连接。
所以，回答我们上面最初的问题。
- 添加新的对象超级简单--只需几分钟就能实现! 只需使用接口定义语言来定义它们。
- 它允许使用SSL/TLS设置最先进的安全性。
- HTTP传输和UDS之间的距离只有几行代码。
- 简单地使用定义语言定义一个新的API，编译，并使用自动生成的客户端和服务器实现--没有比这更简单的了。
- 由于大部分代码已经生成，您只需要维护API。共享对象接口之间的序列化、反序列化和同步都是过去的事情。
我被说服了! 我该如何开始呢？
重构基础设施说起来容易做起来难，但我们从我们的经验中为你收集了一些在提升IPC水平时的技巧。
- 不要一开始就尝试移动树木--种下种子并等待。当开发一个新功能时，看看你如何能解耦它的逻辑。如果你能成功地将它与项目的其他部分解耦，就去设计它的API与你的项目，使用接口描述语言。计划哪个进程包含客户端，而另一个进程包含服务器。
- 看看gRPC是否适合你。在某些情况下，一个简单的send()-recv()或共享内存就可以了。
- 一旦你掌握了它的窍门，慢慢地将已经解耦的进程过渡到使用gRPC进行通信。
- 如果你用C++开发，并且你的测试工具是用C#或Python写的，你会发现gRPC对多语言的支持有多好。这样你就可以充分测试你的流程，而不一定需要重新实现所有的东西。
- 这里有各种情况下产生的错误，还有很多RPC执行状态代码。你会发现它们可以提供很多信息--确保你处理好它们。
在我们分开之前--对未来的道路有什么最后的话要说吗？
gRPC可以适合许多用例，即使不是从一开始就适合。在这篇文章中，我谈到了如何将它作为你的代码中可能有的普通IPC消息传递实现的替代品。已经介绍了一个在UDS上的gRPC的例子，演示了一个基于gRPC的服务器如何通过带有文件描述符的套接字接受连接。
许多项目维护了很多代码，这些代码可以用现代的RPC实现来代替，比如gRPC可以提供更多的功能。它并不适合每一个用例，但它离将你的单体分解成微服务（一种更现代的方法）又近了一步。
如果你对分布式计算感兴趣，你就会知道REST API替代品的存在--但在微服务的世界里，gRPC正引领着潮流。即使你对分布式计算不感兴趣，并希望将你的项目保持在一台机器上--gRPC仍然可以提供很多东西。
我们仍在陆续解耦我们的功能，使用gRPC进行IPC通信，目前还算满意。解耦功能让我们可以单独测试每个功能，实现一个孤立的 "模拟 "客户端与之交互。希望我们的经验也能对您的项目有所帮助。祝你顺利!
通过www.DeepL.com/Translator（免费版）翻译
