从 RPC 到服务化结构规划

现在互联网体系都是微服务化，那么就需求 RPC 调用，因而本文梳理了从 RPC 根本结构协议到整个服务化结构体系建造中所包含的知识点，要点在于 RPC 结构 和 服务办理才能的梳理，本文定位于一个科普性质的文章，在于让大家了解一个全貌。

这篇文章首发在我微信大众号【后端体系和架构】中，点击这儿能够去往大众号查看原文链接，假如对你有协助，欢迎前往重视，愈加便利快捷的接收最新优质文章

一、RPC 根本结构

1-1、RPC 根本结构

理解 RPC

RPC 的概念便是长途进程调用。咱们本地的函数调用，便是 A 办法调 B 办法，然后得到调用欧冠成果，RPC 便是让你像本地函数调用一样进行跨服务之间的函数调用。互联网发展到现在，咱们都在讲微服务，服务都拆分为微服务了，那么相关依靠的调用，就会变成跨服务之间的调用，而他们之间的通讯方法便是依靠 RPC。

RPC 根底结构（RPC 协议）

Nelson 的论文 Implementing Remote Procedure Calls 告知咱们， RPC 协议包含 5 个部分：

  1. Client
  2. Client-stub
  3. RPCRuntime
  4. Server-stub
  5. Server

从 RPC 到服务化框架设计

当 Client 建议一个长途调用时，它实践上是调用本地的 Stub。本地 stub 担任将调用的接口、办法和参数，经过约定的协议规范进行编码，并经过本地的 RPCRuntime 进行传输，然后将数据包发送到网络上传输出去。当 Server 端的 RPCRuntime 收到恳求后，交给 Server-Stub 进行解码，然后调用 Server 端的函数或许办法，履行完毕就开端回来成果，Server-Stub 将回来成果编码后，发送给 Client，Client 端的 RPCRuntime 收到成果，发给 Client-Stub 解码得到成果，回来给 Client。

这儿边分了三个层次:

  • 关于客户端和服务端，都和本来本地调用一样，只需求重视自身的事务逻辑。
  • 关于 Stub 层，处理双方约定好的语法、语义、封装、解封装。
  • 关于 RPCRuntime，首要处理高功能的传输，以及网络的错误和反常。

1-2、RPC 结构的要点

从 RPC 根底结构中，咱们总结出 RPC 结构的要点，包含 4 部分，如下：

1-2-1、数据序列化

序列化便是将数据结构或目标转换成二进制的进程，也便是编码的进程，序列化后数据才便利进行网络传输；反序列化便是在序列化进程中所生成的二进制转换成数据结构或许目标的进程，将二进制转换为目标后事务才好进行后续的逻辑处理。

常见的序列化协议如下：

  • ProtoBuf（IDL）
  • JSON
  • XML
  • Hessian2 （JAVA 系）

常见的 RPC 结构如 gRPC、Thrift、Dubbo、RPCX 、Motan 等会支撑上述协议中的大部分，尤其是 ProtoBuf 和 JSON 。现在从功能上和运用广泛度上来看，现在一般引荐运用 ProtoBuf，当然许多自研的结构里边他们也会自己完成他们自己的序列化协议。

1-2-2、网络传输（网络通讯）

在数据被序列化为二进制后就能够行网络传输了，网络传输便是咱们的数据怎么传输到对方服务器上，现在来说，常见的通讯传输方法包含 ：TCP、UDP、HTTP(HTTP2.0)、QUIC 协议，TCP 是大部分结构都会默许支撑的，额外这儿要说明一下，RPCX 支撑 QUIC 而 gRPC 支撑 HTTP2.0。

QUIC（Quick UDP Internet Connection）是谷歌制定的一种互联网传输层协议，它依据UDP传输层协议，一同兼具TCP、TLS、HTTP/2等协议的可靠性与安全性，能够有效削减衔接与传输推迟，更好地应对当时传输层与应用层的应战。QUIC在应用程序层面就能完成不同的拥塞控制算法，不需求操作体系和内核支撑，这比较于传统的TCP协议，具有了更好的改造灵敏性，十分适合在TCP协议优化遇到瓶颈的事务。

1-2-3、RPC 调用方法

网络传输只是数据传输十分根底的一方面，从事务上来看，咱们建议一次 RPC 调用，那么还需求 RPC 的调用方法，包含如下三大类：

  • 同步 RPC：最常用的服务调用方法，建议调用恳求后同步等候成果，符合咱们开发的一向认知和习惯。开发简略、简略保护、简略理解。

  • 异步 RPC：客户端建议服务调用之后，不同步等候呼应，而是注册监听器或许回调函数，待接收到呼应之后建议异步回调，驱动事务流程持续履行，完成起来相对杂乱，可是高并发场景下功能会更好。

  • 并行 RPC：并行服务调用，一次 I/O 操作，能够建议批量调用，这个并行的批量恳求一般是经过协程来完成，然后同步等候呼应；

    • 这儿需求留意，这个 并行 RPC 和 stream 流式调用是有区别的，流式是说，批量发送恳求后，能够不必等一切的音讯全收到后才开端呼应，而是接收到第一条音讯的时分就能够及时的呼应。

1-2-4、服务办理

RPC 协议只是界说了 Client 与 Server 之间的点对点调用流程，包含 stub、通讯协议、RPC 音讯解析等部分。可是在实践应用中，长途进程调用的时分还需求考虑服务的路由、负载均衡、高可用等问题，而保证服务之间的调用就需求进行服务办理，服务办理根本就包含：服务注册和发现、限流、降级、熔断、重试、失利处理、负载均衡等各种服务办理战略。

到这儿，RPC 结构的要点的 4 大部分就介绍完毕了，现在再来看看，常见的 RPC 结构：

1-3、常见 RPC 结构

RPC 结构便是在 RPC 协议的根底上，来完善一些倾向事务实践应用的功用，从而满意不同场景的事务诉求。综合来看，现在业界的 RPC 结构大致有两种不同的偏重方向，一种倾向于服务办理型，一种倾向于跨言语调用型。

1-3-1、服务办理型 RPC 结构

业界比较知名的服务办理型的 RPC 结构有 Dubbo、DubboX、Motan、RPCX 等。

  • Dubbo 是阿里开源的分布式服务结构，能够完成高功能 RPC 调用，并且供给了丰富的办理功用，是十分优秀的 RPC 结构。

    • 序列化 Protobuf 、JsonRPC、Hessian2
    • 兼容协议： gRPC、Thrift
    • Triple 协议是 Dubbo3 的主力协议，完好兼容gRPC over HTTP/2

  • DubboX 是依据 Dubbo 结构开发的 RPC 结构，支撑 REST 风格长途调用，并添加了一些新的 feature。

  • Motan 是微博开源的一套轻量级、便利运用的 Java 言语的 RPC 结构

    • 认运用对java更友爱的hessian2进行序列化。
    • 通讯协议支撑 Motan、http、tcp(默许 TCP)。

  • RPCX: 一个用Go完成的类似Dubbo的分布式RPC结构

    • 支撑多种编解码协议，如Gob、Json、MessagePack、gencode、ProtoBuf等
    • 支撑常见的服务办理战略
    • 支撑TCP，HTTP，QUIC和KCP

服务办理型 RPC 结构的特点是功用丰富，供给高功能的长途调用以及服务发现、服务办理等功用；常用于微服务化的事务体系中，关于特定言语的项目能够十分友爱的透明化接入，是当时业界的干流。但缺陷是言语耦合度较高，跨言语支撑难度较大。

1-3-2、跨言语调用型 RPC 结构

业界比较知名的跨言语调用型的 RPC 结构有 ：

  • gRPC 是 Google开发的高功能、通用的开源RPC结构。

    • 支撑 ProtoBuf
    • 依据 HTTP2
    • 支撑多中言语
    • 业界许多依据 gRPC 来开发自己的 RPC 结构（美图、华为）

  • Thrift 是 Apache 的一个跨言语的高功能的服务结构，也得到了广泛的应用。

  • Hprose 是一款先进的轻量级、跨言语、跨渠道、无侵入式、高功能动态长途目标调用引擎库

跨言语调用型 RPC 结构的要点是重视于服务的跨言语调用，能够支撑咱们常见的大部分的言语进行言语无关的调用，十分适合于为不同言语供给通用长途服务的场景，但这类结构没有服务发现、服务办理等机制，运用这些结构的时分需求咱们自己来完成服务发现、服务办理等相关战略。

那么，跨言语调用指的是啥意思呢，详细是：客户端和服务端能够在各种环境中运行和相互通讯，并且能够用结构支撑的任何言语编写（参阅 gRPC 官网中的一张图如下，比方 C++ 的服务能够调用 Ruby 的服务：）

从 RPC 到服务化框架设计

1-3-3、常见 RPC 结构比照

从 RPC 到服务化框架设计

二、通用的服务化结构规划

咱们一般讲的微服务结构包含了 RPC 结构，微服务体系中最重要的便是 RPC 结构，并且是一般是倾向服务办理的 RPC 结构。微服务需求供给的中心才能包含：微服务架构中通讯的根底协议RPC、服务发现与注册、负载均衡、容错、熔断、限流、降级、权限、全链路日志盯梢。

2-1、微服务结构的中心才能（服务办理战略）

2-1-1、服务注册与发现

微服务后，服务很多添加，因而咱们必定要能够有一个合适的方案能够发现对方的一切服务，业界比较常见的服务发现的组件如 zookeeper、etcd、consul 等，根本原理便是先将自己的服务列表到注册中心注册，然后再供给服务发现才能。

服务发现机制有服务端发现和客户端发现两种完成方法:

  • 服务端发现形式(server-side):能够经过 DNS 或许带 VIP 的负载均衡完成。

    • 长处是对客户端无侵入性，客户端只需求简略的向负载均衡或许服务域名建议恳求，无需关系服务发现的详细细节，也不必引进服务发现的逻辑
    • 缺陷是不灵敏，不便利异化处理；并且一同需求引进一个统一的负载均衡器。

  • 客户端发现形式(client-side):需求客户端到服务注册中心查询服务地址列表，然后再决议经过哪个地址恳求服务。

    • 灵敏性更高，能够依据客户端的诉求进行满意自身事务的负载均衡，可是客户端需求引进服务发现的逻辑，一同依靠服务注册中心
    • 常见服务注册组件包含：zookeeper、Etcd、Consul。java 系的一般挑选 zookeeper ，而 Golang 的一般挑选 consul 或 etcd ，这个也便是各自挑选对应的言语。etcd 比较而言，是用的较多的，K8s 体系里边也依据是 etcd。

2-1-2、服务路由 & 负载均衡

服务路由和服务发现严密相关，服务路由一般不会规划成一个独立运行的体系，一般状况下是和服务发现放在一同完成的。在服务路由中，最要害的才能便是负载均衡。咱们一般常见的负载均衡算法有：随机路由、轮询路由、hash、权重、最小压力路由、最小衔接数路由、就近路由等。

从业界来看，负载均衡的完成方案一般能够分为三类:

  • 服务端负载均衡:

    • 负载均衡器在一台单独的主机上，能够采用软负载，如 Nginx，LVS 等，也能够采用硬负载，如 F5等
    • 完成简略，存在单点问题，一切的流量都需求经过负载均衡器，假如负载均衡器存在问题，则直接导致服务不能正常供给服务；中间经过负载均衡器做代理，功能也有必定损耗。

  • 客户端负载均衡

    • 处理了服务端负载的单点问题，每个客户端都完成了自己的负载功用，负载才能和客户端进程在一同
    • 负载均衡要求每个客户端自己完成，假如不同的技能栈，每个客户端则需求运用不同的言语完成自己的负载才能。
    • 现在业界干流的 微服务结构都是采用 客户端负载均衡方案

  • 客户端主机独立负载均衡

    • 服务发现和负载的才能从客户端进程移出，客户端进程和负载均衡进程是2个独立的进程，在同一个主机上。也便是 SideCar 形式
    • 没有单点问题，假如一个主机的负载均衡器出问题，只影响一个节点调用，不影响其他的节点，负载均衡器自身负载也较小，功能损耗较低

2-1-3、服务容错

负载均衡和容错是服务高可用的重要手段。服务容错的规划有个根本原则，便是“Design for Failure”。常见的服务容错战略如恳求重试、限流、降级、熔断、阻隔

超时与重试

超时机制算是一种最常见的服务容错形式了，咱们建议的任何恳求调用，都不或许无限等候，对方服务或许由于各种原因导致恳求不能及时呼应，因而超时机制是最根底并且是必须的。超时或许有网络超时、也或许是对方服务反常等多种状况。

重试一般和超时形式结合运用，适用于关于下流服务的数据强依靠的场景，经过重试来确保数据的可靠性或一致性，不强依靠的场景不建议运用。在对方服务超时之后，能够依据状况进行重试(对方服务回来反常就不要重试了)。可是必定留意，重试不能盲目重试，在重试的规划中，咱们一般都会引进，Exponential Backoff 的战略，也便是 “指数级退避”，每一次重试所需求的 sleep 时刻都会指数添加，不然或许会导致拖累到整个体系。

服务限流

限流和降级用来确保中心服务的安稳性；限流是指约束每个服务的最大访问量、降级是指高峰期对非中心的体系进行降级从而确保中心服务的可用性

限流的完成方法：

  • 计数器方法（最简略）

  • 行列算法

    • 常规行列：FIFO
    • 优先级行列
    • 带权重行列

  • 漏斗(漏桶)算法 Leaky Bucket

  • 令牌桶算法 Token Bucket

  • 依据呼应时刻的动态限流

    • 参阅 TCP 协议中算法：TCP 运用 RTT 来勘探网络的延时和功能，从而设定相应的“滑动窗口”的大小

分布式限流和单机限流：

  • 单机限流：单机限流参阅上面的完成方法能够发现有多种限流算法可供挑选，可是业界咱们最常用的是漏桶算法及令牌桶算法。假如要对线上并发总数进行严厉限定的话，漏桶算法或许会更合适一些。

  • 分布式限流（集群限流）：集群限流的状况要更杂乱一些，一般是中心化的规划。

    • 简略的完成能够依据 Redis 来做，可是方案的缺陷清楚明了，每取一次令牌都会进行一次网络开支，而网络开支最少是毫秒级，所以这种方案支撑的并发量是十分有限的。

    • 别的一个简略的完成思路是先在各个微服务节点上完成一个计数器，对单位时刻片内的调用进行计数，单个节点的计数量定期推送汇总，然后由中心化的统计服务来计算这个时刻片的总调用量，集群限流分析器会拿到这个总调用量，并和预先界说的限流阈值进行比对，计算出一个限流份额，这个限流份额会经过服务注册中心下发到各个服务节点上，服务节点依据限流份额会各自算出当时节点对应的终究限流阈值，最终使用单机限流进行流控。

    • 分布式限流业界常用的结构包含 Hystrix、resilience4j

容错降级

容错降级能够分为三大类，从小到大依次是：

  • 接口降级：最小的降级类别。对非中心接口，在需求降级的时分，能够直接回来空或许反常，以削减高峰期这些非中心接口对资源如 CPU、内存、磁盘、网络的占用和耗费

  • 功用降级：对非中心功用，在需求降级的时分，能够直接履行本地逻辑，不做跨服务、跨网络访问；也可设置降级开关，一键封闭指定功用，保全全体安稳；还能够经过熔断机制完成。

  • 服务降级：对非中心服务，能够经过服务办理结构依据错误率或许呼应时刻主动触发降级战略；还能够经过断路器完成

熔断

熔断规划来源于日常生活中的电路体系，在电路体系中存在一种熔断器（Circuit Breaker），它的作用便是在电流过大时主动切断电路。熔断器一般要完成三个状况：闭合、断开和半开，分别对应于正常、毛病和毛病后检测毛病是否已被修正的场景。

  • 闭合： 正常状况，后台会对调用失利次数进行积累，抵达必定阈值或份额时则主动发动熔断机制。

  • 断开： 一旦对服务的调用失利次数到达必定阈值时，熔断器就会翻开，这时分对服务的调用将直接回来一个预订的错误，而不履行真正的网络调用。一同，熔断器需求设置一个固定的时刻距离，当处理恳求到达这个时刻距离时会进入半熔断状况。

  • 半开： 在半开状况下，熔断器会对经过它的部分恳求进行处理，假如对这些恳求的成功处理数量到达必定份额则以为服务已康复正常，就会封闭熔断器，反之就会翻开熔断器。

熔断规划的一般思路是，在恳求失利 N 次后在 X 时刻内不再恳求，进行熔断；然后再在 X 时刻后康复 M% 的恳求，假如 M% 的恳求都成功则康复正常，封闭熔断，不然再熔断 Y 时刻，依此循环。

在熔断的规划中，依据 Netflix 的开源组件 hystrix的规划，最重要的是三个模块：熔断恳求判断算法、熔断康复机制、熔断报警：

  • 熔断恳求判断机制算法：依据事前设置的在固定时刻内失利的份额来计算。

  • 熔断康复：关于被熔断的恳求，每隔 X 时刻允许部分恳求经过，若恳求都成功则康复正常。

  • 熔断报警：关于熔断的恳求打反常日志和监控，反常恳求超越某些设定则报警

阻隔

阻隔，也便是 Bulkheads 隔板的意思，这个术语是用在造船上的，也便是船舱里防漏水的隔板。

在服务化结构的阻隔规划中，咱们同样是采用类似的技能来让咱们的毛病得到阻隔。因而这儿的要点便是需求咱们对体系进行别离。一般来说，有两种方法，一种是以服务的类型来做别离，一种是以用户来做别离。

  • 以服务的品种来做别离的方法：比方一个交际 APP，服务类型包含账号体系、聊天体系，那么能够经过不同体系来做阻隔

  • 以用户来做别离的方法：比方经过战略来完成不同的用户访问到不同的实例

2-1-4、集群容错

在分布式场景下，咱们的服务在集群中的都是有冗余的，一个是为容错，一个是为了高并发，针对很多服务实例的状况下，因而就有了集群容错的规划。集群容错是微服务集群高可用的保证，它有许多战略可供挑选，包含：

  • 快速失利（Failfast）：快速失利，只建议一次调用，失利当即报错。一般用于非幂等性的写操作，比方新增记载。

  • 失利搬运（Failover）：失利主动切换，当呈现失利，重试集群其它服务实例 。一般用于读操作，但重试会带来更长推迟。一般都会设置重试次数。

  • 失利重试（Failback）:失利主动康复，后台记载失利恳求，定时重发。一般用于音讯告诉操作。

  • 聚合调用（Forking）:并行调用多个服务器，只要一个成功即回来。一般用于实时性要求较高的读操作，但需求浪费更多服务资源。一般会设置最大并行数。

  • 广播调用（Broadcast）:广播调用一切供给者，逐一调用，恣意一台报错则报错。一般用于告诉一切供给者更新缓存或日志等本地资源信息。

2-2、微服务结构的根底才能

服务监控和告警

开源代表作： Prometheus + Grafana，遵从 OpenMetrics 规范，根本数据格式分为 Gauge、Count、Summary、Histogram

分布式服务 Tracing 盯梢体系

现在有两种协议规范：

  • OpenTracing ：链路盯梢范畴的规范，现在业界体系支撑最多的规范，开源代表作：

    • jaeger
    • zipkin

  • OpenTelemetry： 可观测性范畴的规范，对Trace，Metrics，Log统一支撑的唯一规范。OpenTelemetry 由 OpenTracing 和 OpenCensus 合并而成，和 OpenTracing 是一个互补的形状。

    • 天机阁

装备中心

装备中心用来办理很多微服务之间的事务装备，并且是中心化的统一装备中心来进行办理。

长途日志

长途日志组件的代表作是 ELK 体系：Elasticsearch, Logstash, Kibana。

在微服务架构中，一个客户端恳求的接入，往往涉及到后端一系列服务的调用，如何将这些恳求串联起来？业界常用的方案是采用大局流水号【traceID】串联起来。经过大局流水号【traceID】，从日志里边能够拉出整条调用链路。

这儿关于全体链路又和 分布式服务 Tracing 盯梢体系 相关起来，Tracing 能够知道全体链路的恳求质量，长途日志+ traceID 能够知道全体链路的日志概况。

2-3、微服务结构依托的主动化运维才能

微服务结构建造 ok 之后，那么很多服务怎么运维，这就依托主动化运维才能，包含如下几个方面：

  • 主动化测验

  • 主动化部署

  • 生命周期办理

业界现在一般采用容器渠道，微服务结构 + K8s 容器渠道 是当今互联网事务的黄金规范

2-4、小结：自己建立一个服务化结构的思路

自己建立一个服务化结构的思路:

  • 首先，要确定好根本的 RPC 通讯协议，一般会挑选开源方案，要点重视：

    • 功用需求的满意度
    • 多言语的支撑
    • 功能和安稳性
    • 社区活跃度、成熟度

  • 其次，依据开源的 RPC 结构来建立而不是彻底从 0 开端。可选的结构包含

    • Dubbo
    • Motan
    • gRPC
    • Thrift
    • 关于方案的比照，这儿不再陈述，网上能够搜索得到，想要表达的是，每个公司的状况不一样，开发人员的才能和言语也不一样，因而方案选型需求依据自身状况而定，没有最好，只要最合适！

  • 最终，Go 言语方面，gRPC 是业界公认的比较好的 RPC 结构，依据 gRPC + 一些服务办理战略能够完成一个服务化结构。这些服务办理的战略，许多也都能够用一些开源的组件。

最终

  • 这篇文章首发在我微信大众号【后端体系和架构】中，点击这儿能够去往大众号查看原文链接，假如对你有协助，欢迎前往重视，愈加便利快捷的接收最新优质文章

  • 本文正在参加「金石方案 . 瓜分6万现金大奖」