.NET Core微服务之路:(纯干货)基于gRPC服务发现与服务治理的方案

  • 时间:
  • 浏览:0
  • 来源:uu快3倍率_uu快3网游_单双计划

  不同之处是将LB和服务发现功能从线程池内移出来,变成主机上的有有一个 独立线程池。主机上的有有一个 肯能多个服务要访问目标服务时,大伙都通过同一主机上的独立LB线程池做服务发现和负载均衡。该方案也是某种分布式方案如此单点大问題,有有一个 LB线程池挂了只影响该主机上的服务调用方,服务调用方和LB之间是线程池内调用性能好,共同该方案还复杂化了服务调用方,不如此为不同语言开发客户库,LB的升级不如此服务调用方改代码。

Netty等例如框架集成;

  2、服务消费方、提供方之间增加了一级,有一定性能开销。

支持多种语言(都可不可以 把proto文件看做IDL文件);

基于HTTP/2

  该方案是针对第二种方案的缺乏而提出的某种折中方案,原理和第二种方案基本例如。

  2、客户端实例化负载均衡策略,肯能解析返回的地址是负载均衡器地址,则客户端将使用grpclb策略,怎么让客户端使用服务配置请求的负载均衡策略。

默认不具备动态社会形态(都可不可以 通过动态定义生成消息类型肯能动态编译支持);

尚未提供“服务发现”、“负载均衡”机制;

多语言支持(C, C++, Python, PHP, Nodejs, C#, Objective-C、Golang、Java)

  至于选折 那个版本,跨平台的需求不大得话,都可不可以 用版本二、大得话都可不可以 选折 一肯能三。(本文后续选折 二为例)

优点:

  HTTP/2 提供了连接多路复用、双向流、服务器推送、请求优先级、首部压缩等机制。都可不可以 节省速率、降低TCP链接次数、节省CPU,帮助移动设备延长电池寿命等。gRPC 的协议设计上使用了HTTP2 现有的语义,请求和响应的数据使用HTTP Body 发送,例如的控制信息则用Header 表示。

  gRPC is a modern, open source, high-performance remote procedure call (RPC) framework that can run anywhere. It enables client and server applications to communicate transparently, and makes it easier to build connected systems.

  1、单点大问題,所有服务调用流量都经过LB,当服务数量和调用量大的也不,LB容易成为瓶颈,且一旦LB地处故障影响整个系统;

  gRPC 一结速由 google 开发,是一款语言中立、平台中立、开源的远程过程调用(RPC)系统。

  2、另外生产环境中,后续肯能要对客户库进行升级,势必要求服务调用方修改代码并重新发布,升级较复杂化。

缺点:

  gRPC使用ProtoBuf来定义服务,ProtoBuf是由Google开发的某种数据序列化协议(例如于XML、JSON、hessian)。ProtoBuf都可不可以 将数据进行序列化,并广泛应用在数据存储、通信协议等方面。压缩和速率高,语法简单,表达力强。

IDL使用ProtoBuf

  针对第有有一个 方案的缺乏,此方案将LB的功能集成到服务消费方线程池里,也被称为软负载肯能客户端负载方案。服务提供方启动时,首先将服务地址注册到服务注册表,共同定期报心跳到服务注册表以表明服务的存活情况,为宜健康检查,服务消费方要访问某个服务时,它通过内置的LB组件向服务注册表查询,共同缓存并定期刷新目标服务地址列表,怎么让以某种负载均衡策略选折 有有一个 目标服务地址,最后向目标服务发起请求。LB和服务发现能力被分散到每有有一个 服务消费者的线程池结构,共同服务消费方和服务提供方之间是直接调用,如此额外开销,性能比较好。该方案主要大问題:

  gRPC开源组件官方并未直接提供服务注册与发现的功能实现,但其设计文档已提供实现的思路,并在不同语言的gRPC代码API中已提供了命名解析和负载均衡接口供扩展。 

  RPC协议性能要高的多,例如Protobuf、Thrift、Kyro等,(肯能算上序列化)吞吐量为宜能达到http的二倍(甚至更高)。响应时间也更为出色。千万暂且小看这点性能损耗,公认的,微服务做的比较好的,例如,netflix、阿里,有有一个 都传出过为了提升性能而合并服务。肯能是交付型的项目,性能更为重要,肯能你卖给客户往往靠的也不性能上微弱的优势。

protobuf二进制消息,性能好/速率高(空间和时间速率都很不错);

  1、开发成本,该方案将服务调用方集成到客户端的线程池里头,肯能有多种不同的语言栈,就要配合开发多种不同的客户端,有一定的研发和维护成本;

序列化反序列化直接对应线程池中的数据类,不如此解析后在进行映射(XML,JSON全是例如辦法 );

  在服务消费者和服务提供者之间有有一个 独立的LB,通常是专门的硬件设备如 F5,肯能基于软件如 LVS,HAproxy等实现。LB上有所有服务的地址映射表,通常由运维配置注册,当服务消费方调用某个目标服务时,它向LB发起请求,由LB以某种策略,比如轮询(Round-Robin)做负载均衡后将请求转发到目标服务。LB一般具备健康检查能力,能自动摘除不健康的服务实例。 该方案主要大问題:

肯能基于HTTP2,绝大部多数HTTP Server、Nginx都尚不支持,即Nginx如此将GRPC请求作为HTTP请求来负载均衡,也不作为普通的TCP请求。(nginx1.9版本已支持);

  该方案主要大问題:部署较复杂化,环节多,出错调试排查大问題不方便。

RESTful : 严格意义上说接口很规范,操作对象即为资源,对资源的某种操作(post、get、put、delete),常见的http api都都可不可以 称为Rest接口。

PB具有有有一个 版本:

  4、当有rpc请求时,负载均衡策略决定那个子通道即grpc服务器将接收请求,当可用服务器为空时客户端的请求将被阻塞。

  http相对更规范,更标准,更通用,无论哪种语言都支持http协议。肯能你是对外开放API,例如开放平台,结构的编程语言多种多样,你无法拒绝对次责语言的支持,相应的,肯能采用http,无疑在你实现SDK也不,支持了所有语言,什么都,现在开源里边件,基本最先支持的多少协议都蕴藏RESTful。

Protobuf二进制可读性差(貌似提供了Text_Fromat功能,没用过);

其基本实现原理:

  1、服务启动后gRPC客户端向命名服务器发出名称解析请求,名称将解析为有有一个 或多个IP地址,每个IP地址标示它是服务器地址还是负载均衡器地址,以及标示要使用那个客户端负载均衡策略或服务配置。

  gRPC是某种都可不可以 在任何地方运行的现代、开源、高性能远程过程调用(RPC)框架,它使客户端和服务端应用线程池透明地通信,并使构建连接的系统更容易。

  目前gRPC主流分布式方案有如此几种: etcd, zookeeper, consul.

GRPC尚未提供连接池,如此自行实现;

  3、负载均衡策略为每个服务器地址创建有有一个 子通道(channel)。

  在gRPC里客户端应用都可不可以 像调用本地对象一样直接调用另一台不同的机器上服务端应用的辦法 ,使得您都可不可以 更容易地创建分布式应用和服务。与例如 RPC 系统例如,gRPC 也是基于以下理念:定义有有一个 服务,指定其都可不可以 被远程调用的辦法 (蕴藏参数和返回类型)。在服务端实现例如接口,并运行有有一个 gRPC 服务器来正确处理客户端调用。在客户端拥有有一个 存根都可不可以 像服务端一样的辦法 。

  网站系统随着不断的发展,如此复杂化,架构的变迁也会从MVC—>SOA—>微服务,从简单到复杂化,从集中到分布,服务化框架的引入是SOA—>微服务过程必如此正确处理的大问題。面对服务的增多,服务分布的部署,服务与服务之间相互的调用,不得不使用服务化框架去正确处理,著名的dubbo和spring cloud也不有有一个 产生的。

支持向前兼容(新加字段采用默认值)和向后兼容(忽略新加字段),复杂化升级;

proto文件生成目标代码,简单易用;

  gRPC支持多种语言,并都可不可以 基于语言自动生成客户端和服务端功能库。目前已提供了C版本grpc、Java版本grpc-java 和 Go版本grpc-go,其它语言的版本正在积极开发中,其中,grpc支持C、C++、Node.js、Python、Ruby、Objective-C、PHP和C#等语言,grpc-java肯能支持Android开发。