微服务网关支持grpc（微服务统一网关）

本篇文章给大家谈谈微服务网关支持grpc，以及微服务统一网关对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享微服务网关支持grpc的知识，其中也会对微服务统一网关进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、【微服务】GRPC漫谈
• 2、Grpc原理
• 3、docker构建与运行grpc-gateway项目
• 4、使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 初识 gloo

【微服务】GRPC漫谈

在微服务架构中，可能完成一个请求需要多个服务进行协作，比如一个输出商品详情页的HTTP接口，聚合服务需要查询多个通用服务，如：

为了顺利完成如上所述的协作，微服务架构的多个服务之间需要进行相互通讯，在此场景下我们需要使用RPC（Remote Procedure Call）。

下图比较了RPC和REST：

简单来说：

设计目标：

其他优势：

HTTP2.0简介：分为Headers Frame（对应1.1的header）和DATA Frame（对应1.1的body）两部分
HTTP1.1 相较于 HTTP1.0的提升点：支持长连接（keep-alive）并默认打开，一个TCP请求上可以传送多个HTTP请求和响应，避免握手和挥手造成的延迟。
HTTP2.0 相较于 HTTP1.1的提升点：多路复用+头部压缩

基本概念

多路复用

头部压缩 HPACK
cient和server存储在一个HTTP2.0链接存续期间，共同维护一个header表
每次请求时相同的header数据不用在发送，只要发送差异即可（新增/修改）：比如ua，host，cookie等

PB性能更好 ：消息体积小且序列化较快
消息体积更小：平均约为JSON的1/3，网络传输快

序列化和反序列化快：约为JSON的20倍

1. HTTP1.0、HTTP1.1 和 HTTP2.0 的区别
2. 思考gRPC ：为什么是HTTP/2
3. REST和RPC区别
4. 流行的RPC框架benchmark

Grpc原理

rpc调用原理框架如图:

-支持多语言的rpc框架微服务网关支持grpc，例如Google的grpc微服务网关支持grpc，facebook thrift， 百度的brpc
-支持特定语言的rpc框架， 例如新浪微博的Motan
-支持服务治理微服务化特性框架，其底层仍是rpc框架，例如 阿里的Dubbo
目前业内主要使用基于多语言的 RPC 框架来构建微服务，是一种比较好的技术选择，例如netflix ，API服务编排层和后端微服务之间采用微服务rpc进行通信

-支持C java js
-git地址 https://github.com/grpc/grpc-java
-原理图:
gRPC 的线程模型遵循 Netty 的线程分工原则，即微服务网关支持grpc：协议层消息的接收和编解码由 Netty 的 I/O(NioEventLoop) 线程负责微服务网关支持grpc；后续应用层的处理由应用线程负责，防止由于应用处理耗时而阻塞 Netty 的 I/O 线程
不过正是因为有了分工原则，grpc 之间会做频繁的线程切换，如果在一次grpc调用过程中，做了多次I/O线程到应用线程之间的切换，会导致性能的下降，这也是为什么grpc在一些私有协议支持不太友好的原因

缺点

改进:
优化后BIO线程模型采用了线程池的做法但是后端的应用处理线程仍然采用同步阻塞的模型，阻塞的时间取决对方I/O处理的速度和网络I/O传输的速度

grpc的线程模型主要包含服务端线程模型，客户端线程模型

2.1.1 I/O 通信线程模型
gRPC的做法是服务监听线程和I/O线程分离Reactor多个线程模型 其工作原理如下:

2.1.2 服务调度线程模型

gRPC 客户端线程模型工作原理如下图所示（同步阻塞调用为例)

相比于服务端，客户端的线程模型简单一些，它的工作原理如下微服务网关支持grpc：

grpc 线程模型

docker构建与运行grpc-gateway项目

趁着实习摸鱼（啊不是）之际，简单学习一下曾经很想入门的 docker 。

在上一篇有关 DevOps 的博客中，曾提到：docker 容器的出现，推动了 DevOps 的发展。而 docker 的功劳不仅如此，它的出现可以说是：具有划时代的意义。

很早之前，我就想学习 docker 。但，那时 docker 还未完全支持 Windows 平台，奈何电脑又太差，不敢给 Linux 虚拟机分配太高配置，导致 docker 学习一直被搁置。

如今，docker 已经推出了完美的 Windows 桌面版，而公司电脑配置也完全足够。天时地利人和，此时不学，更待何时。

同时，作为实践，我将用 docker 构建和运行 grpc-gateway 项目。

环境如下：

常用的命令示例：

docker 中很多命令是有相同效果的，比如： docker images == docker image ls 、 docker rmi == docker image rm 、 docker ps -a == docker container ls -a 等，可自行尝试。

Dockerfile 用于构建镜像。镜像既可以通过容器 commit 构建，也可以通过 Dockerfile 构建，但更推荐后者（前者黑盒）。

Dockerfile 常用命令如下：

Dockerfile 编写指南： 一般性的指南和建议

项目地址： https://gitee.com/dounineli/grpcDemo.git

Dockerfile 如下：

利用 Dockerfile 的多阶段构建，减少镜像体积（编译型语言，运行环境不需要复杂的编译环境）。

总共分为三个阶段：

生成镜像时，我们只需构建 server 和 gateway 两个运行阶段即可，两个阶段依赖的 builder 阶段镜像会自动构建，并在构建完成后自动删除。分别得到 grpc 服务端和 grpc-gateway 网关镜像：

由于 grpc-gateway 网关需要访问 grpc 服务端，因此：

用 postman 进行接口测试：

不得不说，docker 的出现，让很多事情变得轻而易举。举一个很简单的例子：如果你想在电脑上安装 MySQL ，直接运行 docker 的 MySQL 镜像即可，几行命令搞定，再也不用麻烦地配置环境了。

使用 gloo 在非 kubernetes 环境搭建服务网关指南 - 初识 gloo

原文链接: https://trainyao.github.io/post/gloo/gloo_in_non_kubernetes_env_gateway_01/

本系列文章主要介绍了在非 kubernetes 环境，使用 gloo 搭建服务网关的过程，以及 gloo 的简单的使用指南。

系列文章目录如下:

本系列文章的源码将放在 这里

gloo 是 solo 公司的一个开源产品，它可以看作是 envoy 的一个控制面板。

envoy 是一个功能强大的4层7层代理，它性能较好、可扩展性强，也比较稳定。由于它基于 http2 协议，所以它在7层上支持 rest、grpc 协议的路由功能。它能够被用作服务的边界网关，而且由于比较稳定，且系统资源占用较少，也被用作微服务里的服务边车（比如在 istio 里），与业务服务一起部署。

envoy 的功能如此强大，以致它的配置也比较复杂。gloo 在 envoy 的上层建立了一个控制面板，将自己抽离的一些业务对象（比如下面会提及的 proxy virtualserivce 等）转换成 envoy 的配置并且加以维护。用户只需操作 gloo 抽离的这些对象即可配置网关，而不需要考虑 envoy 的复杂配置。这样的中间层是有好处的，比如后续想要更换代理实现（比如 nginx，或者 mosn ），也可以将 envoy 更换掉，而翻译配置的模块只需改写成从翻译 envoy 的配置为翻译新代理实现即可。

在真实工程环境中，使用 envoy 作为网关或者边车是一个不错的选择。但 envoy 的复杂配置增加了不少使用维护成本，最终你有可能会建立一个类似 gloo 的控制面板，满足工程需求。既然如此何不使用和扩展 gloo 呢？：）

为了与 envoy 交互，gloo 里带有了一个 xds 服务。 xds 是配置 envoy 的协议，如上文所属，gloo 会将内部业务对象翻译成 envoy 的配置，翻译后的配置就是通过 xds 协议与 envoy 交互的。

gateway 是服务的入口，可以看做代理服务里的 listener，具体表现为监听某个端口作为流量的入口，进行4、7层的路由分发。

gateway 对象是用户可以配置的。

virtual service 可以理解成代理提供的虚拟服务，它是一个7层概念。virtual service 对象可以配置 "host" 字段的流量分发，当流量从 gateway 监听的端口进来，带不同的 "host" 字段的流量能被路由到不同的后端服务中，对外看起来就像不同域名提供了不同的服务。
在 gloo 中，virtual service 对象也可以配置不同功能的路由，比如根据 path 路由、根据 header 路由，也可以配置错误注入、熔断等功能，可以说7层功能的配置基本上都在 virtual service 对象上完成。

virtual service 对象也是用户可以配置的。

proxy 对象是 gloo 翻译组件根据 gateway 和 virtual service 对象翻译出来的。被用作 xds 服务读取并翻译成 envoy 配置。

对于 proxy 对象，用户是不需要也不应该配置的。
它的内容实际上等价于 gateway + virtual service 对象的内容。

在架构设计角度上，proxy 对象也可以看作是 gloo 翻译组件和 xds 服务的中间层：翻译组件应该将待翻译的内容（比如 gateway、virtual service等）翻译成 proxy 对象，而 xds 服务以 proxy 对象为标准，翻译 envoy 配置。这意味着，在 gloo 里，gateway、virtual service 这类与用户打交道的配置是可以扩展和替换的，gloo 只要求，扩展替换后与翻译组件合作的结果 = proxy 对象即可。

downstream 可以理解为请求方。

gloo 里没有 downstream 对象。

upstream 可以理解为后端真正提供业务逻辑的服务。

upstream 对象也是无需用户配置的，gloo 内置服务发现组件，通过监听服务注册（如 k8s 内的 service、consul 里的 service）来生成 upstream 对象，供 xds 服务读取并生成 envoy 配置。

（上图来自 gloo 文档 ）

上述架构图基本上能和第二部分讲到的概念对应上：

首先，本系列文章在非 k8s 环境下使用 gloo 主要是基于 gloo 源码下的 install/docker-compose-consul 安装方式来使用，可以看出，是基于 docker-compose + consul 来运行的。
在使用上很多地方其实可以对应到 k8s 环境下的实现。

异同点分下列点讲述：

gloo 文档里的 petstore 例子是能跑通的，上面附上的 项目 也是基于这个 petstore demo 改动的。

本篇是系列文章的第一篇，主要介绍了 gloo 的基本情况和简单跑起了非 k8s 环境下的 gloo，为后续的其他功能介绍做个铺垫。
后续文章就可以更多涉及网关能力的介绍。 关于微服务网关支持grpc和微服务统一网关的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关支持grpc的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务统一网关、微服务网关支持grpc的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。