gRPC如何节省您的开发时间 _gRPC

文章插图

此时，您应该已经听说过" gRPC"（标题中至少一次）。在本文中，我将着重介绍采用gRPC作为微服务之间的通信介质的好处。
首先，我将尝试简要介绍一下架构演变的历史。其次，我将重点介绍使用REST（作为媒介）和可能出现的问题。第三， gRPC启动。最后，我将以我的开发工作流程为例。
架构发展简史本节将列出并讨论每种体系结构的优缺点（着重于基于Web的应用程序）
整体式一切都在一个包中。
优点：
【gRPC如何节省您的开发时间】· 容易上手
· 单一代码库可满足所有需求
缺点：
· 难以扩展（部分）
· 加载服务器（服务器端渲染）
· 不良的用户体验（加载时间长）
· 难以扩展的开发团队

文章插图
Monolith architecture

文章插图
Inside monolith architecture

Monolith v2（前端-后端）前端逻辑和后端逻辑之间的清晰分隔。后端仍然庞大。
优点：
· 可以将团队分为前端和后端
· 更好的用户体验（客户端的前端逻辑（应用程序））
缺点：
· [仍然]难以扩展（部分）
· [仍然]难以扩展的开发团队

文章插图
Frontend-Backend architecture

微服务每一件事物一项服务（包）。使用网络在每个软件包之间进行通信。
优点：
· 可扩展的组件
· 可扩展团队
· 灵活的语言选择（如果使用标准通讯方式）
· 独立部署/修复每个软件包
缺点：
· 介绍网络问题（通信之间的等待时间）
· 服务之间进行通信所需的文档，协议
· 如果使用共享数据库，则难以识别错误

文章插图
Micro-service architecture with shared database

文章插图
Micro-service architecture with standalone database per service

REST（作为媒介）和可能出现的问题REST（基于HTTP的JSON）由于易于使用，是当前服务之间通信的最流行方式。使用REST使您可以灵活地为每种服务使用任何语言。

文章插图
Typical REST call
但是，灵活性会带来一些陷阱。开发人员之间需要非常严格的协议。下面的草图展示了一个非常常见的场景，通常在开发过程中发生。

文章插图
Developer A want Developer B to make a service

文章插图
Bad request

文章插图
Expectation vs Actual

问题：
· 依靠人类的同意
· 依赖文档（需要维护/更新）
· 从协议到协议（这两种服务）都需要大量的"格式化，解析"
· 大多数开发时间都花在了协议和格式化上，而不是业务逻辑上
gRPC启动gRPC是可以在任何环境中运行的现代开源高性能RPC框架。
什么是RPC？ RPC代表远程过程调用。它是一种协议，一个程序可用于从网络上另一台计算机上的程序请求服务，而无需了解网络的详细信息。

文章插图
Remote Procedure Call

以REST为媒介的RPC使用服务创建者提供的RPC客户端/库将确保调用服务时的正确性。如果我们要使用RPC和REST作为媒介，则开发人员B必须编写客户端代码供开发人员A使用。如果两个开发人员都使用不同的选择语言，那么这对开发人员B来说是一个主要问题，因为他需要用他不习惯的另一种语言来编写PRC客户。而且，如果不同的服务也需要使用服务B ，则开发人员B将不得不花费大量时间来使用不同的语言来制作RPC客户端，并且必须对其进行维护。