微服务网关支持grpc（微服务网关技术选型）

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

本文目录一览：

• 1、【微服务】GRPC漫谈
• 2、Grpc原理
• 3、docker构建与运行grpc-gateway项目
• 4、国信证券Zebra微服务架构简介
• 5、什么是微服务架构？主流的微服务如何实现？

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

-支持C java js
-git地址 https://github.com/grpc/grpc-java
-原理图:
gRPC 的线程模型遵循 Netty 的线程分工原则，即：协议层消息的接收和编解码由 Netty 的 I/O(NioEventLoop) 线程负责；后续应用层的处理由应用线程负责，防止由于应用处理耗时而阻塞 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 线程模型

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 镜像即可，几行命令搞定，再也不用麻烦地配置环境了。

国信证券Zebra微服务架构简介

我们从0到1设计开发了国信微服务架构微服务网关支持grpc，他是一个完整的，从前到后的架构。我们希望逐步分享出来，后续也会将此架构开源。

1、配置依赖最小化微服务网关支持grpc；

2、开发速度最大化；

3、环境部署最简化；   

选用grpc,因为grpc有以下几个优势：

1、多语言支持；

2、社区活跃，生命力强，七月份发布1.5版本；

3、支持ios、Android，支持SSL和自定义鉴权（支持国密），可以简单实现客户端到后台的多路复用、rpc调用；

4、只有通信层依赖于grpc，所以容易替换；

5、grpc使用pb协议，此协议在互联网上广泛使用，生命力强；

6、支持流stream，在流的基础上实现了Server Push，方便做变更通知，不再需要客户端做费力的Long Pull；

方案基于进程内LB方案，结合分布式一致的组件etcd3，进行设计开发，具备以下功能：

1、服务自动注册；

2、服务自动发现；

3、负载均衡；

4、注册中心异常保护；

5、异常通报下发；

6、服务降级；

可视化服务管理平台，展示服务信息，包含功能如下：

1、server展示，包括ip地址、端口号、应用名称、接口名称；

2、api展示，显示proto文件内容；

3、api测试；

4、服务监控展示；

5、服务依赖动态图展示；

api网关基于vert.x实现，后期考虑采用原生netty进行升级：

1、由统一的入口来调用微服务的API；

2、API鉴权；

3、反向代理、数据剪裁、数据聚合；

4、流量控制；

5、监控报警；

6、TCP、HTTP等多协议支持；

基于springboot进行业务开发：

1、权限管理，服务接口授权；

2、服务端流量控制；

3、业务线程池管理；

4、调用端和服务端TCP连接数管理；

5、服务过载快速失败；

6、TCP心跳保活；

7、调用链分析埋点；

8、超时管理；

9、泛化调用；

参考Prometheus搭建监控中心，具有以下功能：

1、服务流量上报；

2、服务访问ip上报；

3、服务平均耗时情况上报；

4、异常上报；

5、日志收集服务；

6、调用链埋点；

对配置信息进行统一管理，可做到一次打包，各个环境都可使用，具有以下功能：

1、资源类配置与业务类配置分离；

2、作用域分离（分为四大作用域：GLOBAL、IDC、SET、NODE）；

3、配置中心异常容错；

什么是微服务架构？主流的微服务如何实现？

简单地说微服务网关支持grpc，微服务架构就是以业务域或业务功能为边界微服务网关支持grpc，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，并且使用轻量级，通用的机制在这组应用间进行通信。
主流的微服务包括微服务网关支持grpc：
1、SpringCloud
Spring Cloud , 来自Spring，具有Spring 社区的强大支撑，还有Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司在几年前就把几乎整个微服务框架栈开源贡献给微服务网关支持grpc了社区，这些框架开源的整套服务架构套件是Spring Cloud的核心。
- Eureka:服务注册发现框架；
- Zuul:服务网关；
- Karyon：服务端框架；
- Ribbon：客户端框架；
- Hystrix：服务容错组件；
- Archaius：服务配置组件；
- Servo：Metrics组件；
- Blitz4j：日志组件；
2、Dubbo
Dobbo是一个分布式服务框架，是阿里开放的微服务化治理框架，致力于提高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分(官网)
- 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式；
- 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；
- 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo 也是采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo的配置即可，Dubbo 基于 Spring 的 Schema 扩展进行加载。当然也支持官方不推荐的 API 调用方式。
3、lstio
lstio 作为用于微服务聚合层管理的新锐项目，是Google、IBM、Lyft（海外共享出行公司、Uber劲敌），首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。
目前首个测试版是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和Cloud Foundry 等其微服务网关支持grpc他环境增加支持。lstio将 流量管理添加到微服务中，并为增值功能（如安全性、监控、路由、连接管理和策略）创造了基础。
- HTTP、gRPC 和 TCP 网络流量自动负载均衡；
- 提供了丰富的路由规则，实现细颗粒度的网络流量行为控制；
- 流量加密、服务件认证，以及强身份声明；
- 全范围（Fleet-wide）的策略执行；
- 深度遥测和报告。 关于微服务网关支持grpc和微服务网关技术选型的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微服务网关支持grpc的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微服务网关技术选型、微服务网关支持grpc的信息别忘了在本站进行查找喔。

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