关于又拍云:统一接入层架构的演进

本文系云原生利用最佳实际杭州站流动演讲稿整顿。杭州站流动邀请了 Apache APISIX 我的项目 VP 温铭、又拍云平台开发部高级工程师莫红波、蚂蚁金服技术专家王发康、有赞中间件开发工程师张超，分享云原生落地利用的教训心得，以下是张超《有赞对立接入层架构演进》分享内容。

张超，有赞中间件团队开发工程师，网关、Service Mesh 畛域的专家，热衷技术，对 Golang、Nginx、Ruby 语言等有深刻的钻研。

大家好，我是来自有赞的张超，有赞中间件团队的开发工程师。明天给大家带来有赞接入层架构演进的分享。

先简略给大家介绍下有赞接入层，外部名为 YZ7，从概念来讲它与网关比拟靠近，是基于 OpenResty 和 Nginx 来实现的，次要是有规范 C 模块，自研发的 Nginx C 模块，以及基于 lua 实现的模块。它作为有赞业务流量的公网入口，提供 Traffic Shaping，包含限流、平安相干的像 WAF、申请路由等性能，申请路由蕴含规范的蓝绿公布、灰色公布性能，负载平衡等方面的性能。明天的分享，次要是从上面从三个方面来深刻解析：

• 旧版接入层架构痛点
• 新架构设计剖析
• 新架构设计总结

旧版接入层架构痛点

首先从旧版接入层架构的相干痛点登程，开始新架构的设计剖析。

上图是旧版接入层架构的纵向切面，计划是早几年之前的。过后风行用 redis 做配置同步，它人造的主从同步协定的确非常适合。其中黄色箭头线是配置同步，数据从 redis master 同步到每个实例上的 redis slave，而后本级的 YZ7 会去轮巡本级的 redis，并把数据读到本身内存中。

为什么有右下方的 k8ssync controller 呢？因为前几年 K8S 逐步的成为热门，很多利用都开始走向容器化的路线。

YZ7 是基于 OpenResty 来开发的，整个技术栈都是基于 lua，在 K8S 的生态里 lua 并不在其中。如果想要 watch K8S 外面的服务，须要实时晓得它有哪些 endpoints。尽管通过 lua 也能够实现，然而须要重头做一个相似像 K8S 规范的 client-go 库，这就得失相当了。因而会利用一个应用 GoLang 编写的 k8sssync controller，它负责向 K8S 获取它所感兴趣的后端服务 endpoints 数据，再通过 YZ7 配置的 API，再次写入到 redis master，最初由 redis master 散发到每个 YZ7 的实例上。

旧版接入层架构的毛病

• redis master 的单点问题：没有应用 redis closter 或者哨兵计划，只是简略的主从模式，呈现问题时会导致配置无奈下发。
• 当接入层是依照多机房的规模进行部署的，因为 redis master 是一个单点，它必然存在于一个机房中，从它所在的机房将数据同步到其余机房的 redis slave 时，容易受到机房之间专线稳定性的影响，稳定性差，配置同步的延时就高。
• 当 redis master 呈现问题，这意味着从 k8ssync controller 同步过去的 K8S 外部服务 endpoints 数据无奈实时同步到 YZ7 实例上。如果一些服务实例的 point 被革除了，接入层不能第一工夫感知到。如此一来当申请进来，这边还在用曾经下线的 point IP，导致申请会 502、504，引起服务不可用。还有一个毛病，因历史起因导致的 k8ssync controller 也是单点，如果它挂了，K8S server 会无奈同步，同样会导致服务不可用，甚至引起大规模的故障。
• 配置不具备属性特色。无奈在配置层面做多样化解决，包含配置的灰度下发。配置的灰度下发这个词是我集体提出来的，先保留这个疑难，前面会具体地揭开。

新架构设计三大组件

带着旧版接入层的种种缺点，接下来须要设计出可能解决这些缺点的新架构。当然，在设计新架构时须要遵循一些架构相干的要点。

• 首先就是解决根底的单点问题，为服务可用性提供保障。
• 组件的设计须要是无状态，可灰度、可回滚、可观测的。
• 无状态：意味着服务能够有弹性的进行扩缩容，应答弹性流量时十分的有帮忙。
• 可灰度：服务某个组件的更新，它的影响面不能是整个集群或者是所有的流量，必须有可灰度的能力，只影响局部流量与局部实例。
• 可回滚：当服务更新公布后，呈现一些连环的反映，能够独自的对它回滚。
• 可观测：从各个角度来加强组件的可观测性，包含日志、logging、metrics 甚至是 opentracing 等相干性能要做的更好，能最大地把控到组件在线上的运行水平。
• 升高组件间的耦合水平。各组件职能独立，可独立测试部署。即便架构设计的再好，然而部署简单，测试麻烦，就会加大老本。

遵循上述要点后，新架构计划细看有点像 Service Mesh 管制面、数据面拆散和 APISIX 的管制面、数据面拆散。两头虚线以上是管制面，下方则是数据面。管制面的外围组件叫 YZ7-manager，右边对接 K8S，左边对接 ETCD，ETCD 是它的配置存储核心，所有接入层的配置会寄存在 ETCD 中，同时又会去 watch K8S。

虚线下方的数据面是每个 YZ7 的实例，每个实例上都有一个伴生过程，叫做 YZ7-agent，agent 会做一些杂活。YZ7 则是保留外围性能的网关，从下往上的红线箭头即是申请的方向。

管制面外围组件 manager

• manager 是一个配置提供者，相似于 Istio Pilot，Istio 1.5 版本之前是由多个组件组成，其中最重要的就是 Pilot。配置保留在 ETCD 中，ETCD 的特点就是稳固牢靠，所以选型用了 ETCD。
• manager 是无状态的，能够做到程度扩容。
• manager 接管了原来 k8ssync controller 的性能，由它去 watch K8S，代替了原 K8S-think 的性能。因为 manager 是无状态、可程度扩容的，解决了 YZ7 K8S-think 的单点问题。同时在原架构当中，YZ7 配置的 admin server 和当初的 APISIX 是十分类似的，它的 admin server 是和网关放在一起的，而在新架构中把网关 admin server 替掉，只放在管制面的 YZ7-manager 中。
• 最初一个外围性能就是配置下发性能，从 YZ7-manager 的管制面，把数据下发到每个数据面。

管制面外围组件 agent

数据面的外围组件是 agent，是一个伴生服务，与每一个接入层的实例绑定。外围性能就是负责配置同步，包含配置注解的释义，这个和配置层面的灰度是相干的。还有配置间依赖治理，当有 A、B 两种配置时，可能 A 配置是依赖于 B 配置的，相当于 APISIX 里的 route 和 upstream。agent 的服务会把配置间的依赖治理做好。

接入层 YZ7

咱们把原有配置的 admin server 去掉了，同时负责向 redis 获取数据的局部配置相干代码也去掉了，只留下了 http 接口。咱们能够从内部将配置推送到 YZ7 实例中，放弃在共享内存中。原来的网关性能全副保留，没有做很多的革新，仅保留外围性能，简化了组件。

新架构设计细节要点

讲完三个外围组件之后，再来聊一下新架构中几个比拟重要的细节。

第一：从管制面的 YZ7-manager，到数据面的 YZ7-agent，配置下发协定怎么设计能力高效牢靠？

第二：从 YZ7-agent 和 YZ7 之间，数据是用推模式还是拉模式？

第三：配置注解怎么实现？

第四：配置依赖怎么保障？

带着这四个问题，接下来会具体解说，一一击破：

管制面 YZ7-manager 到 数据面 YZ7-agent

首先，咱们对于协定的要求肯定是简略、牢靠的，否则了解老本高，开发成本也会进步。

其次，协定必须反对服务端的被动推送，就像 APISIX 的配置失效工夫很低，因为 ETCD 是反对 watch 性能。而 Kong 的配置工夫绝对比拟高，是因为 kong 上对接的是 PostgreSQL 和 Cassandra，这两种关系数据库是不反对 watch 的。服务端有数据变更，客户端只能通过轮巡的形式获取。轮巡的距离太长，配置失效工夫就高；距离太短，能够及时获取到数据变更，然而资源耗费会更高。

基于上述两点，咱们以 gRPC 为根底，并参考 xDS，设计了一个新的协定。首次连贯时，能够全量获取管制面的数据，后续始终放弃长连贯，能够增量地获取服务端的数据配置变更。

上图是 gRPC、XDS 的片段。最下面有一个 ConfigDiscoverService，这个 gRPC 就是做配置同步的外围，其中外围的两个 message 是 configrequest 与 configresponse。

configrequest 中，node 是带有某个数据链实例相干的数据，比方所在的集群，hostname，IP 等。resourcecondition 是在数据面申明感兴趣的配置，比方对路由配置，对 upstream 配置或对跨域配置感兴趣。在列表中把感兴趣的配置全副申明好，通知服务端，管制面能力精准的把所感兴趣的配置推送到数据面。

configresponse 就是把响应码，包含 error detail 在出错的状况下，将包含错误码在内的信息，把 resource 全副放在 resource 列表外面而后推送给客户端。它的传输模型也比较简单，客户端会在连完之后发送 config request，而后服务端第一次会把所有的配置数据推送到客户端。

当一个接入层只是推送一些配置，它的配置量不会很大，几百兆就十分多了，因而全量的推送并不会带来特地多的带宽与内存上的开销，全量推送也是一个低频事件，不必过于担心它的性能。

随着工夫的推移，服务端会有新的配置变更，比方运维新增了配置或是公布业务利用，公布之后 pond 做了迁徙，导致 pond 的 endpoints 变更了。管制面感知到这些变更，会将这些数据实时地推送到 Client 端，实现管制面到数据面的配置推送。

这跟 xDS 协定是很类似的，xDS 里的 discovery request 发送到服务端之后，如果有数据就把数据推回来，在 discover response，如果没有数据会其中退出一个 none 标记，通知咱们筹备同步这个 discovery quest。没有数据时相当于是申请 ACQ 的性能。咱们设计的有点相似 xDS 的简化版本，没有这方面的性能。

数据面 YZ7-agent 到 接入层 YZ7

从 YZ7-agent 到 YZ7 即数据面的 agent 到数据面的实例，其配置同步的抉择到底是拉还是推？

首先来思考拉，它的长处是按需加载，在须要时去加载对应的配置。毛病是如果配置提供方没有像 ECTD 的 watch 性能，就须要数据存在内存中必须要有淘汰的机制，否则就没有方法获取到同一个实例新的配置变更。而如果配置应用了淘汰策略，带来的问题就是配置失效工夫高。失效工夫高，对于一些动态配置像路由、host service 配置是无关痛痒，然而对于容器化业务的 endpoints 变更，它须要尽可能快的推送数据面，否则可能会呈现 502、504 等 5XX 的谬误。因而拉的模式不适用于新的架构中。

其次是推模式，YZ7-agent 须要被动把数据推到 YZ7。长处是 YZ7 只须要做简略的保留动作即可，不须要思考数据过期，而且组合的耦合水平会更低。这样的 YZ7 交付给测试，能够加几个接口，把须要用的测试数据推动去就行，而不须要额定部署 YZ7-agent，对交付测试比拟无利。毛病是依赖于他人推会有一个问题，如果服务是刚刚起来或者 Nginx 刚刚实现热更新时，共享内存里是没有数据的，要采纳推模式就必须解决这个问题。咱们采纳的形式是 agent 会定期的把数据缓存转储到磁盘上，当接入层 YZ7 实例热更新完或刚启动的时候，就会从磁盘上加载旧的数据，保障能够失常起来。再者是强制在此时要求 YZ7-agent 全量推送一次数据，就能够立即达到最新的配置。

配置注解的实现

设计配置注解是为了做配置灰度。其作用是当新增了配置，但不心愿对集群里所有的实例失效，只须要集群中的一两个小规模实例失效时不便进行验证。因为如果配置有误可能会带来大规模故障，而进行配置灰度能够无效升高故障的影响面。

上图是配置 payload 的片段，从上往下接入的是配置数据，外面只有一个 server，而 antotations 就是这个注解，外面的 canary 字段能够设计成灰度配置所需字段。这是依照 hostsname 来配置，这个配置只有 hosts2 或者 hosts3 才会失效。其中的 id、name、kind 是用来给配置做标识的，像 name、品种、UUID 之类的。其实 K8S 的申明配置也是如此的，具体的配置是放在 steak 面，里面会有像 laybol 等云数据相干的，图中的 antotations 就是效仿 K8S 申明式配置的 antotations。

有赞是一个 SaaS 服务提供者，域名十分多，配置非常复杂，比拟依赖人为配置。为了升高因人为操作失误引起的故障面，须要有配置灰度这样的性能。操作流程也很简略，首先运维平台上创立一个配置，并标注为灰度配置，底层会创立出相干的配置注解。之后察看配置在相干实例上的体现，体现 OK，就能够将该配置失效到所有的机器，去掉灰度配置注解，这时全副的接入层实例上也就失效了。如果呈现问题，立即删除灰度配置，也可防止引起其余强烈的反馈。

创立灰度配置，并携带灰度注解。通过 YZ7-manager 散发到每个 agent。agent 会判断该配置在机器上是 hit 还是 miss。如果是 miss 就会疏忽掉这个配置，不会推过去。如果是 hit 就推送到本机中的 YZ7。

当灰度了一段时间，体现也失常，须要将其全副失效时就能够批改配置了，去掉灰度注解推送到 YZ7-manager 后会一成不变的再推到 YZ7 各个实例上。左下角这台是利用了灰度配置，因为 name 是雷同的，这时稳固版本的配置就会把之前灰度版本的配置替换掉，所有接入层实例的配置也就都雷同了。

当发现配置有问题，删除也会很简略。配置删除后，因为左下角这台曾经灰度命中了，它会把删除配置的事件推到 YZ7，进而 YZ7 会被动删除内存中的正本。而左中、左下本来就没有命中灰度配置，会间接疏忽，到此这三台 YZ7 的实例配置又复原到了灰度配置利用之前的状态。

配置依赖治理

局部的配置间会有相互援用的关系。比方 host 配置，每一个 host 可配置一个规范的谬误页，谬误页又是一个独自的配置，在做 host 配置时，就必须先有谬误页配置，否则会没方法下发。所以数据面的 agent 就须要保障好数据配置的推送关系，当 A 配置依赖于 B 配置，就不能先把 A 配置推送到接入层实例。因为 A 配置和 B 配置两头推送有工夫窗口，会无奈正确处理在 A、B 工夫窗口之间进来的申请。

架构设计总结

走向云原生，须要咱们在工作中学习更多的借鉴在云原生方面好的组件，像 K8S、Envoy 等都是值得学习的优良范本。有赞接入层新架构遵循的管制面和数据面的职能拆散设计准则，就是参考了 Service Mesh 的设计；配置下发协定是参考了 Envoy、xDS；退出注解的性能，设计上是参考了 K8S 的申明式配置的申明定义。

走向云原生的路线上咱们应该多向前看，把云原生上所须要的性能、学到的新货色更好的融入到工作当中，把用到的组件可能更好的符合到云原生当中，走向云原生就会更有意义。

举荐浏览

技术选型：为什么批处理咱们却抉择了 Flink

【实战分享】从选型到我的项目落地，漫谈 gRPC