关于后端:后端接入层技术的一点思考

后端接入层技术的一些思考

前言

网上对于这块的技术文章曾经泛滥了，局部写得十分好，看着看着，就感觉本人太菜，感觉也没有下笔的必要了。然而，写文章也是一个梳理本身思路的一个过程，用输入倒逼输出，始终都是挺不错的学习办法，不然网上文章看完就不记得是马什么梅了，因而，还是决定写写本人对于这块技术的一些思考。

接入层，没找到具体的定义，按我的了解，就是位于防火墙之后，承接前端用户申请（通过浏览器或者 app 等）的最前沿的服务器集群，个别会和用户正向代理软件（浏览器、app 之类）间接建设网络连接，负责接管用户申请，转发到逻辑层服务解决，再将逻辑层响应返回给用户。当然，这只是最高级的场景，因为接入层理论是流量入口，所以它能够做很多流量调度的事件，举个例子，大家如果去过都江堰，就会看到江的两头，有一段沙洲，这片沙洲就能将奔流的岷江水分流，分流后，水流就不至于在暴雨季节对上游造成洪涝灾害。

“鱼嘴”是都江堰的分水工程，因其形如鱼嘴而得名，位于岷江江心，把岷江分成内外二江。西边叫外江，俗称“金马河”，是岷江正流，次要用于排洪；东边际山脚的叫内江，是人工引水渠道，次要用于灌溉。

而且这也才是第一道分水工程，我查了下都江堰的排沙工程，又被秀到了，居然暗合了软件架构中的限流熔断思维，当初去都江堰还是应该找个向导，当初感觉真是看了个寂寞。

飞沙堰的作用次要是当内江的水量超过宝瓶口流量下限时，多余的水便从飞沙堰自行溢出；如遇特大洪水的十分状况，它还会自行溃堤，让大量江水回归岷江正流。

什么叫“水旱从人，不知饥荒”，这就是。

说回正题，接入层就是个流量口子，咱们能够依据咱们的想法，自在地散发流量给后端的服务集群（负载平衡），当流量过大时，能够限流熔断，同时，能够进行认证鉴权，打击灰产，日志记录，监控上报，灰度公布等各类性能。

接下来，会说一下典型的架构。

单 idc 架构（无长连贯）

大部分中小型公司，如果就是提供一个网站对外拜访，也不须要接管后端告诉的话（如实时 IM 通信），可能都会是这类架构，我任职过的公司里，也有这类架构。下图就以我相熟的 nginx 来作为接入层组件了，lvs 也能够，集体钻研不多，就先算了。

这个架构次要的问题在于，接入服务都在单个机房，一旦这个机房挂了或者这个 vip 出了问题，服务根本就不可用了。

同城多 idc 架构（无长连贯）

解决的方法，就是多机房容灾，包含了同城多个机房（一个城市里多个机房）、两地多核心（两个城市，多个机房）、三地多核心（三个城市，多个机房）；再依据机房是否多活（多个机房能够同时解决用户申请，即每个机房都有流量），分为了：同城多活、异地多活（异地多活就是异地的多个城市，如深圳、上海，都能够同时解决流量，这时候根本要上单元化架构了）

中小公司，我集体感觉，同城多活根本也就足够了，根本就是上面这个样子。

单 idc 架构（有长连贯场景）

短连贯：tcp 建设连贯，传输完数据后，马上敞开连贯。下次要传数据时，再来一次三次握手 – 传数据 – 四次挥手。

长连贯：tcp 建设连贯，传输完数据后，不敞开连贯，下次要传数据时，找到后面没关的长连贯，间接传数据，传完也不敞开。

长连贯个别实用于，后端须要被动告诉用户的场景，当然了，也不是说，这种时候就必须要用长连贯，客户端轮询、长轮询也是能够实现这种场景的，但这里咱们只说长连贯这种实现形式。

这种形式的益处在于，十分实时，要的就是一个快，后端只有须要给我发音讯，我马上能收到。

对于这块的架构，我集体目前偏向于如下设计：

即，用户在筹备进行长连贯时，首要的事件就是，拿到要接入的长连贯服务器的 ip+ 端口，要拿到这个 ip+ 端口，有很多形式，像我图里画的，就是这样一种模式：

1. client 端，首先调用短连贯网关，短连贯网关可能首先对用户鉴权，提醒登陆等；登陆胜利后，client 端调用短连贯网关，申请获取长连贯服务器的 ”ip+ 端口 ” 列表。当然，这里为了简略，你能够间接写死成一个配置，然而，咱们倡议灵便一点，提取一个独自的服务（如上图的长连贯 server manager），对外提供对应的获取长连贯服务器列表的接口。
2. client 端，拿到长连贯服务器列表后，接下来要做的就是抉择其中的一个。这块就能够有很多策略了，比方，能够 ping 一下每个 ip，看看提早，能够抉择提早最低的；或者是依据业务逻辑，本人实现一个策略。
3. client 拿到想要连贯的 ip+ 端口后，进行 tcp 连贯即可；对应的长连贯服务器，收到 client 连贯申请后，就会在内存或者 redis 之类的，保护一个 map，key：用户 id/ 终端 id，value：长连贯对象。同时，能够上报一些统计数据给长连贯 server manager，如以后服务器 1.1.1.1 保护了 2000 个用户的长连贯，届时，长连贯 server manager 就能够依据这些统计数据，来提醒 client 能够连贯某个负载比拟小的服务器（这块的策略也能够自在实现，比方帮 client 端举荐一个长连贯服务器、强制客户端应用某台服务器等）

这里还有一点，客户端当初是通过调用如上形式，获取长连贯服务器；但要是这个链路有问题呢，这时候能够有对应的降级机制，比方应用 dns 域名形式来获取，或者是应用客户端中写死的一批 ip。

服务端如何被动做推送呢？这里不打算开展了，比方要给用户 xxx 发消息，那此时，有两种形式，一种是，想方法查问到，xxx 在哪台接入服务器上；另一种是，给每台接入服务器发申请，相似于播送，接入服务器收到这种播送申请后，查看对应的用户归不归本人管，不归的话，就不论。

多 idc 架构（有长连贯场景）

这个架构还有啥问题吗？大家能够看到，图里是位于深圳机房的，服务于广东用户，预计提早还好，要是服务北京用户，北京用户通过长连贯，连到深圳，深圳这边推送音讯时，走公网推送给用户，这个提早必定低不了。有啥好方法吗，我感觉，能够采纳多机房，就近接入的形式。

比方，深圳、上海各一个机房，北京用户接入上海机房，物理上就近多了，天然要快一些。这个场景下，流程是如何的呢？

1. 用户通过 dns（配置多条 A 记录，指向上海、深圳机房的短连贯网关地址），实践上，能够获取到就近的机房的地址；如广东用户应该会取到深圳机房地址，北京用户会取到上海机房的地址。如果不行的话，咱们还有其余方法，如 gslb，前面讲。
2. 此时，假如没有部署异地多活，上海机房只负责了接入层，没部署业务层的服务和 db 等；此时，深圳侧的业务服务发动音讯推送，推给北京某个用户，此时是能够通过长连贯 Server Manager，查到用户在上海接入；那就把这个推送申请，发给上海这边的接入服务器。因为大公司的机房之间，路线个别是有专网，或者是花了不少钱的，速度必定比公网要快一些。比方，腾讯的深圳上海机房的提早，根本就是几十 ms。

这边有一个点是，深圳、上海的长连贯 Server Manager 进行了双向同步。不双向同步，感觉也是能够的，咱们能够依据用户的登陆 ip，查问 ip 属于哪个省，如果是北京，则认为该用户在上海机房接入了，则交给上海机房去推送即可。

gslb 技术

咱们下面提到，深圳、上海各一个机房，此时，dns 要配两条 A 记录地址，指向各机房。同时，咱们假如了，dns 解析商那边，会把北京用户解析到上海机房。

但这个假如，不肯定失效，dns 解析商那边的解析还是比拟毛糙的，如果咱们心愿把这块把握在本人手里，那就能够应用 gslb 技术（global server load balance）。

有一种简略的实现形式，简略来说，就是 dns 解析那里，配置两条 ns 记录，ns 记录别离指向深圳、上海机房的自研的 dns 服务器。自研的 dns 服务器，就能够用咱们自定义的规定，来决定这次 dns 解析，给用户返回什么地址。自研 dns，能够这样做，比方查问用户属于电信还是网通，属于哪个省，来决定返回深圳、还是上海的机房地址。

这块具体还是比较复杂，我也还不太懂，前面能够独自讲讲。

本文由 mdnice 多平台公布