背景
前几天好几个公众号推送了这样一篇文章: Service Mesh 利器: NGINX 将支持 gRPC, 更有甚者鼓吹 nginx 是第一个支持 grpc 的代理看到这几篇文章的时候, 我总想说点关于国内的互联网发展
这几年国内互联网行业变化飞快先是微服务, 当时国内各大线下交流会议都是各种微服务框架的分享,比如 zookeeper 采坑之类, 微服务的十二要素啊, 服务治理什么的然后接着就是直播行业, 这时线下会议又变成了视频秒开啊, 如何连麦啊, cdn 优化啊等等不仅技术从业者都往这上面冲, 各大投资者也是一个劲地往里砸钱, 都不想错过这个风口到去年, 又有人开始鼓吹直播已死这个时候听到更多的一个词又是 devops, 这个时候, 可能听到的更多就是全链路监控告警, apm 优化, devops 实践等等到了今年, 情况就更夸张了, kubernetes 区块链人工智能, 尤其是区块链, 只要上市公司有一点区块链概念沾边, 估价就蹭蹭蹭地网上涨停, 比如迅雷人人网接下来只怕是公司有一点人工智能的概念, 那也会不得了到今年年末明年年初, 我断定, service mesh 又肯定会成为各大线下会议的主要课题
百花齐放固然是好, 但技术的革新不可能如此的快著名的一万小时理论告诉我们, 如果要精通一门技术, 一年的时间是远远不够的我觉得国内互联网氛围有点浮躁了, 这不好, 尤其是对刚毕业的年轻人
什么是 grpc
gRPC is a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services.
简单点说, grpc 就是谷歌出的 rpc 框架, 数据交换格式基于protobuf, 数据传输基于 http2 谷歌提供了大部分常用语言的 sdk
grpc 代理选择: envoy
我有幸参与了一个 grpc 的项目, 当时版本还是的 0.x 说句题外话, 如果是我负责选型, 我断不会轻易同意将不稳定的第三方软件应用到产品里, 就是非用不可, 也一定要深入了解它才行我踩过太多这样的坑了
当时为了做 grpc 的负载均衡,我特地仔细研究过 grpc 的官方文档, google 的开发人员提到了 nghttpx 和 envoy 这两种代理
nghttpx 是一个基于 nghttp2 的代理, nghttp2 是一个 http2 的库, 前面提到 grpc 本质是基于 http2 的通信, 所以要想做 grpc 的代理, 必须要底层要能支持 http2, 这也是为什么最近发布的 nginx1.13 才支持代理 grpc 的原因, 因为 nginx 老版本并不支持 http2 协议
要想做好 grpc 的负载均衡, 只是支持 http2 协议还不够, 必须要有基本的负载均衡算法, 比如, 我们的应用是根据请求的信息, 调度到不同的服务器上要想实现这样的功能, 就必须基于 python 或其他脚本语言配置
而 envoy 在这一方面就强多了, 它支持多种负载均衡算法: Round robinWeighted least requestring hashMaglevRandomOriginal destination 对于我上面提到的例子, 只需要将请求的字段放如 grpc 的 context 中, 然后配置 envoy 时根据该字段设置好 server 的 ring hash 就行, 几句配置就搞定了
当然, envoy 的强大并不仅仅局限在负载均衡算法多样它还有如下优点:
开源, 基于Modern C++11
支持三层四层七层代理, 支持 http 路由
支持服务发现健康检查
支持 mongodbdynamodb
多种负载均衡算法
动态配置 nginx 并不支持哦
这些功能都是开源免费的, 但nginx 可并不一定,很多进阶功能都需要购买使用 nginx plus
关于健康检查我多说一句, 很多平台的健康检查就是检查某个 http 接口是否有响应, 或是 tcp 连接是否建立, 但这并不代表服务功能正常, 这就跟单独开线程做心跳是一个道理, envoy 支持数据能正常收发层面的健康检查
总结
所以, nginx 注定了并不是 service mesh 的最好选择, 因为 envoy 比它提供了更丰富的功能不过依然可能会有很多公司使用 nginx, 因为 nginx 的运维技术相对成熟, 网上资料大把
googleibm 公司还基于 envoy 弄了一套 service mesh 的框架 Istio, 有空我再介绍介绍 istio
来源: https://juejin.im/entry/5abb700f518825558b3dfd91