K8s+gRPC云原生微服务开发与治理实战
//xia仔k：zxit666.com自从 2011 年 Dubbo 开源之后，被大量中小公司采用，不断是国内最受欢送的 RPC 框架。2014 年，由于阿里内部组织架构调整，Dubbo 暂停维护了一段时间，之后随着 Spring Cloud 的面世，两个体系在交融中一同助推了微效劳的炽热。
不过这世界变化快，自从以 docker 为代表的的容器技术和以 K8s 为代表的容器编排技术登上舞台之后，云原生时期到来了。在云原生时期，不可变的根底设备给原有的中间件带来了不可变的中间件根底设备：gRPC 统一了底层通讯层；protobuf 统一了序列化协议；以 envoy + istio 为代表的 service mesh 逐步统一了效劳的控制面与数据面。
dubbogo 的自然任务是：Bridging the gap between Java and Go。坚持 Go 应用与 Java 应用互联互通的同时，借助 Go 言语（事实上的第一云原生言语）的优势拥抱云原生时期。dubbogo 社区 2020 年勠力打造三支箭：
曾经发布的对齐 dubbo 2.7 的 dubbogo v1.5 版本； 近期将要发布的 sidecar 形态的 dubbo-go-proxy 项目； 以及处于停止时的 dubbogo 3.0。 用一句话概括 dubbogo 3.0 即是：新通讯协议、新序列化协议、新应用注册模型以及新的效劳管理才能！本文主要着重讨论 dubbogo 3.0 的新通讯协议和应用级效劳注册发现模型。
dubbogo 3.0 vs gRPC 知己知彼，方能进步。dubbogo 3.0 的通讯层改良主要自创了 gRPC。
简单来说就是 http2 协议的根底之上，增加了特定的协议 header：“grpc-” 开头的 header 字段，采用特定的打解包工具（protobuf）对数据停止序列化，从而完成 RPC 调用。
1.png
众所周知，gRPC 简直没有效劳管理才能，而阿里云现有 dubbo 框架兼具 RPC 和效劳管理才能，整体实力不逊于 gRPC。但在“大家都用 gRPC” 这样的背景之下，dubbogo 3.0 的新通讯协议就必需圆满兼容 gRPC，对开发者已部署的效劳完整兼容，并在此根底之上持续已有 dubbo 协议和效劳管理才能，进而推出一系列新战略：比方 mesh 支持、应用级效劳注册等。
dubbogo 3.0 vs dubbogo 1.5 目前已有的 dubbo 2.7 协议曾经尽可能完成了 gRPC 的支持。开发者能够经过 protoc-gen-dubbo 工具将 pb IDL 协议转换为框架支持的 stub，再借助底层 gRPC conn 的 RPC 过程，将已有的效劳管理才能自上而下传送给 gRPC，因而完成了 gRPC 效劳的支持。
dubbo-go v1.5.x 也支持 gRPC 的 Stream 调用。和 unary RPC 相似，经过产生框架支持的 stub，在底层 gRPC stream 调用的根底之上，将流式 RPC 的才能和并入框架。但由于 dubbo v2.7.x / dubbo-go v1.5.x 自身并不支持流式调用，所以没有对 gRPC stream 调用的停止上层效劳管理支持。
2.png
开发者所面临的问题就是：我们在运用 dubbo-go2.7 停止 grpc 协议传输的时分，或多或少不是那么放心。
而行将推出的 dubbo-go 3.0 协议将从本源处理这个问题。
协议兼容的三种层次 笔者以为，一款效劳框架关于第三方协议的支持可分为三个水平：应用层次、协议层次、传输层次。
一款框架假如在一个协议的 sdk 之上封装接口，能够以为它处于应用层次支持，这样的框架需求遵照下层 sdk 的接口，可扩展性较差。
处于协议层次的框架，从配置层到效劳管理层均由本框架提供，而在此之下的协议层到网络传输层均运用某个固定的通讯协议，这样的框架能够处理效劳管理的问题，但框架自身无法与第三方协议完整适配，假如不适配就会呈现对第三方协议支持的削弱，比方上面说到的 dubbo-go 1.5 对 stream rpc 支持的缺陷。
假如想进一步支持更多的第三方协议，需求从传输层下手，真正理解第三方协议的详细字段、所依赖的底层协议（比方 HTTP2）的帧模型和数据流，再开发出与第三方协议完整分歧的数据交互模块，作为本框架的底层。这样做的益处是最大水平赋予了协议的可扩展性，能够在兼容已有协议的根底之上，可选地增加开发者需求的字段，从而完成已有协议无法完成的功用，就比方 dubbogo 3.0 将支持的反压战略。
基于 HTTP2 的通讯流程 gRPC 一次基于 HTTP2 的 unary rpc 调用传输主要流程如下：
client 发送 Magic 信息： PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n；
server 收到并检查能否正确； client 和 server 相互发送 setting 帧，收到后发送 ACK 确认； client 发送 Header 帧，包含 gRPC 协议字段，以 End Headers 作为 Header 完毕标志； client 紧接着发送 Data 帧，包含 RPC 调用的 request 信息，以 End Stream 作为 Data 完毕标志； server 调用函数取得结果； server 发送 Header 帧，包含 gRPC 协议字段，以 End Headers 作为 Header 完毕标志； server 紧接着发送 Data 帧，包含 RPC 调用回传的 response 信息； server 紧接着再次发送 Header 帧，包含 RPC 状态和 message 信息，以 End Stream 作为本次 RPC 调用完毕标志。 其中包含 gRPC 调用信息的 HTTP2 Header 帧如下图：
3.png
另外，在 gRPC 的 stream 调用中，可在 server 端回传的过程中发送屡次 Data，调用完毕后再发送 Header 终止 RPC 过程，并汇报状态信息。
dubbogo 3.0 的通讯层将在 HTTP2 通讯协议之上采用同样的通讯流程，以保证与 gRPC 的底层通讯沟通才能。
dubbogo 3.0 预期通讯架构 除了通讯协议采用 HTTP2 外，dubbogo 3.0 将采用基于 google protobuf 的 triple 协议【下面称为 dubbo3 协议】作为 dubbogo 3.0 的序列化协议，为 dubbo 未来支持更多的编程言语打下通讯协议层面的根底。
目前设计的 dubbogo 3.0 传输模型如下：
4.png
为保证同时支持 unary RPC 和 stream RPC，在 server 端和 client 端增加数据流构造，以异步伐用的方式完成数据传送； 继续支持原有的 TCP 通讯才能； 在 HTTP2 的通讯协议之上支持 dubbo3 协议，decode 过程兼容 gRPC 运用的 protobuf，保证与 gRPC 效劳打通。 应用级效劳注册发现
- 应用级效劳注册发现引见 dubbogo 3.0 运用的新一代效劳注册发现体系，将摒弃旧版的“接口级注册发现”，运用“应用级别注册发现”。
简单地说，接口级别注册发现，在注册中心中以 RPC 效劳为 key，以实例列表作为 value 来组织数据的，而我们新引入的“应用粒度的效劳发现”，它以应用名（Application）作为 key，以这个应用部署的一组实例（Instance）列表作为 value。这带来两点不同：
数据映射关系变了，从 RPC Service -> Instance 变为 Application -> Instance； 数据变少了，注册中心没有了 RPC Service 及其相关配置信息。 能够以为，基于应用粒度的模型所存储和推送的数据量是和应用、实例数成正比的，只要当我们的应用数增加或应用的实例数增长时，地址推送压力才会上涨。
而关于基于接口粒度的模型，数据量是和接口数量正相关的，鉴于一个应用通常发布多个接口的现状，其数量级普通是比应用粒度的数十倍。另外一个关键点在于，接口的定义更多的是业务侧的内部行为，接口粒度招致的集群范围评价的不透明，而实例、应用增长都通常是在运维侧的规划之中，可控性较好。
工商银行曾经对这两个模型停止消费测算：应用级效劳注册模型能够让注册中心上的数据质变成原来的 1.68%，新模型能够让 zookeeper 轻松至成 10 万级别的效劳量和 10 万级别的节点量。
- 元数据中心同步机制的引入 数据中心的数据质变少所形成的结果，是 RPC 效劳相关的数据在注册中心消逝了，只要 application - instance 这两个层级的数据。为了保证这局部短少的 RPC 效劳数据依然能被 Consumer 端正确的感知，我们在 Consumer 和 Provider 间树立了一条单独的通讯通道，目前针对元数据同步有两种详细的可选计划，分别是：
内建 MetadataService； 独立的元数据中心，经过中细化的元数据集群谐和数据。 3. 兼容旧版本 dubbo-go 为了使整个开发流程对老的 dubbo-go 用户更透明，同时防止指定 provider 对可扩展性带来的影响），我们设计了一套 RPC效劳到应用名的映射关系，以尝试在 consumer 自动完成 RPC 效劳到 provider 应用名的转换。
5.jpg
这套设计能够让 dubbogo 3.0 中同时坚持对 dubbo v2.6.x、dubbo v2.7.x 和 dubbo v3.0.x 三个大版的互联互通。
统一路由的支持 路由在概念上能够了解为从已有的一切 IP 地址列表中，依据特定的路由规则，选择出需求的 ip 地址子集。路由的过程需求依据配置好的路由规则停止挑选，最终取一切路由规则的交集取得结果。多个路由好像流水线一样，构成一条路由链，从一切的地址表中挑选出最终目的地址汇合，再经过负载平衡战略选择访问的地址。
- 路由链
- jpg
能够把路由链的逻辑简单了解为 target = rn(...r3(r2(r1(src))))。关于每一个 router 内部的逻辑，能够笼统为输入地址 addrs-in 与 router 中按全量地址 addrs-all 完成切分好的 n 个互不相交的地址池 addrs-pool-1 ... addrs-pool-n 按完成定义好的规则取交集作为输出地址。以此类推，完成整个路由链的计算。
7.jpg
failover 在路由规则配置文件中能够配置 failover 字段。在寻觅地址失败时能够 failover， 选择其他 subset，并且次第执行下来，直到找到地址，否则最后报地址找不到异常。
兜底路由 在的路由规则配置中，能够配置一个没有任何条件的 match, 最终的结果是至少会有一个 subset 被选到，以到达地址空维护的作用。
