共计 4495 个字符，预计需要花费 12 分钟才能阅读完成。
Beeto 是一款面向中东市场主打阿拉伯语言的社交软件，在产品设计和技术架构上都是本地化落地施行的。曾在沙特 iOS 利用商店 Top Charts 榜单中超过老牌社交巨头 Facebook，位列第 4 名。
其实中东在互联网畛域算是倒退较成熟的区域，在社交网络中的沉闷用户渗透率十分高，尤其在沙特区域，2019 年的互联网用户就曾经达到了 90%，沉闷用户渗透率在 2020 年就曾经排到了第 9 位。
互联网市场的成熟，带来的是国际性软件的笼罩，像 WhatsApp、YouTube 和 Instagram 等都是当地支流的社交软件。但回过头看，你会发现在中东地区根本没有相似国内微博这种本地化的社交类软件。所以在 Beeto 产品诞生之前，就瞄准了「中东互联网成熟、渗透率高，但本地化少」的方向，并开启了专一「本地化特色」的产品筹备。
Beeto 在中东其实对标的是 Twitter 和 Facebook 这种 Feed 流利用，所以在业务架构的部署上一开始就布局好了绝对残缺的框架。比方满足社交属性的关系互动、内容生产（图文、视频直播、同城广告等），还有金融类和服务类的打赏、提现、投票和抽奖等等各种业务，甚至包含平台侧的监管、内容平安审核等要求。
在前文咱们也提到过，中东市场的互联网成熟度势必对一个产品的公布有着高质量的要求，所以想要切实打入中东市场，不可能先做一个简略性能的利用间接上线。
所以 Beeto 的第一版业务架构就是一个残缺，并且合乎支流社交软件应该具备的各种功能集一身的产品。同时 Beeto 的指标也很明确，就是要用「本地化特色」成为中东地区最大的阿拉伯语社交平台和最好的阿拉伯语社区。
Beeto 架构设计中的痛点
Beeto 产品要走本地化模式，除了在业务层面要满足当地现有的社交需要外，在技术层面也须要做一些本地化操作，比方服务部署和数据存储等都要要本地化。相熟微博或者 Twitter 的技术敌人应该都晓得，想要实现这种宏大信息流产品的背地，其实是须要几十甚至上百个架构零碎来合作实现的。
单体服务架构设计
目前 Beeto 产品的业务次要可划分为以上这些。这些业务的实现其实都须要在中东地区进行本地化部署。如果把每项业务依照服务进行拆分的话，那每个服务其实就是独立的单体架构。
上图展现的是一个很常见的部署架构。拿 Beeto 的 Feed 流服务来说，想要实现用户浏览 Feed 流需要，就必须要反对公网拜访，即南北向流量的拜访；同时 Feed 流服务还会提供一些相似话题业务等模式的外部调用，即东西向流量调用。所以整体的服务属性是明确反对内部和外部两种调用模式，用户流量通过七层负载平衡，调配到不同的服务器再调用不同的存储资源，东西向也相似。整个七层集群负责解决南北和东西向流量，进行负载平衡、平安认证和节点监控。
当把多项业务的的服务组合在一起时，就会造成如下所示的整体架构：
能够看到，无论是适配层、业务层还是根底服务层，都存在着若干服务。每项服务的部署架构都领有前文提到的单体架构细节，所以两头就会存在着若干个七层集群，这其实曾经是一套十分宏大且简单的零碎架构了。
但因为目前 Beeto 产品还处于守业阶段，尤其是产品自身在中东外乡落地，而研发人员在中国的情景，依照上述这个规模部署，须要投入十分大的服务器老本和保护老本。同时前期随着业务减少，单体服务的数量势必也会一直减少，不论在老本还是运维操作上都会变得更难管制。
多服务落地艰难
除了上述提到的架构部署简单外，其实在集群外部服务之间的调用也是非常复杂的。
南北向流量扩散到各个服务池，东西向流量也交织在各个服务之间，这些服务的调用关系之间错综相交。对每一套服务而言都须要去保护这些调用关系，从而导致调用链路不清晰且不好治理。
除了调用关系简单外，每个服务之间还存在技术栈的差别。比方在调用协定上，有些服务提供的是 HTTP，有些则是 RPC；而在开发语言上，则会呈现 Java、Go 等多语言混合的状况。
从上述这些细节就能够看出，这样的多服务架构体系在进行本地落地时，就会很显著地暴露出部署与保护老本高的问题，同时每套七层服务都须要投入服务器老本，而各个服务的流量差别又会导致流量不平衡，从而导致服务器等资源利用率低，造成资源节约。
因为目前 Beeto 的老本重点放在了业务降级与迭代上，所以在架构设计上更偏向于便于保护和对立治理，那么如何实现这个指标呢？
APISIX 网关为 Beeto 架构助力
为了解决服务治理不便与老本投入大的痛点，同时得益于 APISIX 配合 etcd 的动静体现更合乎 Beeto 的产品需要，所以在架构部署中引入了 APISIX 作为网关，并搭建了网关集群，如下图所示。
网关集群对所有的服务都提供了注册核心、服务管制、服务监控、协定转发和利用插件等扩大工具。各个服务的集群都能够对立在网关进行注册，新服务高低线也都能够间接通过网关来实现。
同时引入网关后，整个集群的调用链路也变得十分清晰。南北向流量对立由网关进行路由转发，东西向流量由网关进行内网的服务转发。在性能层面，APISIX 负责对立保护这些流量所调用的认证，这样在网关层就可能清晰理解到各服务之间的性能差别和流量差别等信息。
总结来说，引入 APISIX 网关做架构整合之后：
- 解决了南北向和东西向流量对立的问题，节俭了资源和人力老本，实现动静对立治理；
- 业务服务的部署架构重点在服务自身，从而实现网关独立存在和业务无感；
- 通过扩大插件，各服务的权限验证、路由散发和健康检查等性能均由网关托管；
- 新业务上线与服务迁徙都能够动静实现，对运维非常敌对。
当然，因为在此架构中，网关承载了所有的流量，前期随着服务的一直扩张，服务数量也会减少，届时网关的保护老本也会增大，就会须要思考新的应答计划。但在目前背景下，该计划仍是最优抉择。
利用 APISIX 后的业务实际
Apache APISIX 作为网关能够在网关层对立解决多种策略，比方平安认证、服务转发和健康检查等。因而 Beeto 在引入 APISIX 后，在业务实际层面也做了很多尝试。
安全性：认证插件
南北向流量 -Cookie
咱们后面讲了公网用户的拜访流量对立通过网关。而对于公网用户的认证，则是基于 Cookie 认证的用户申请。当用户申请携带 Cookie 达到网关时，在网关上通过认证插件对其进行验证。
如上方流程图所示，插件外部会先进行本地化验证，而后依据策略进行远端服务的认证校验。当申请实现 Cookie 校验后，再转发到指定的服务上。
这样做的劣势次要体现在两方面：
- 确保了用户 Cookie 的信息安全。因为 Cookie 属于敏感数据，在执行过程中确保只有网关层可能接管并进行解决，其余业务层均不能接触。避免业务解决规定不统一而导致的平安问题，也无效防止了人为因素和不标准问题导致的 Cookie 泄露等平安问题。
- 升高了各个服务 Cookie 认证的复杂性。前文提到了 Cookie 在过程中须要进行本地验证或远端验证，同时 Cookie 降级时，各个服务也都须要同步降级。通过网关进行对立治理与校验，在业务服务的解决上就省去了校验老本，只需关注后果，利用后果进行业务规定解决，从而保障各个业务解决更聚焦于业务自身。
东西向流量 -Token
像下图中的 A 服务调用 B 服务的操作，通常来讲相互调用时只需提供一个 API 即可实现。然而在外部流程中，须要去理解「API 被谁调用了、通过什么形式调用的、是否须要进行权限校验，是否须要对调研方进行管制」等这些问题，都是须要外部去解决的。
有了 APISIX 网关之后，流程就变得简略很多。所有外部服务的相互调用只需在 Auth 认证服务上进行注册，给每个服务颁发 App key，用来表明服务的身份 ID。同时外部服务相互调用也会通过网关，携带 Token 通过网关后，网关会通过 Token 插件进行 Token 认证。认证通过后会将认证标识传递给被调用的服务，整个过程中服务对立进行认证注册，实现相互调用。
得益于 App key 的 Token 规定，上述操作便于追溯调用起源，从而进行问题排查和权限管制，对非法调用也起到了无效的管制。
所以无论是南北向流量还是东西向流量的认证，对立认证的劣势就是保障了集群的安全性与统一性，在问题排查溯源和调用管制等方面都有很大的帮忙。
伸缩性：无状态服务扩容迁徙
目前 Beeto 的集群整体部署架构是从上到下是依照 APISIX 网关集群 - 无状态服务的业务服务集群 - 有状态服务的数据中心集群组成。在中东本地落地部署时，都是部署在各大星散群上的。依照中东地区的云笼罩规模和不同地区的云厂商，在进行服务部署时就须要思考云服务的扩容和迁徙问题。
在迁徙的过程中，Beeto 重点关注在无状态服务的迁徙。因为数据中心的迁徙老本，决定了它不适宜适宜做动静调整；同时大部分申请压力都是由无状态服务来承载的，所以保障无状态服务具备一个良好的伸缩性是十分重要的前提。
在 Beeto 的架构中，服务伸缩性次要体现在两个方面，即单体服务伸缩性和整体集群伸缩性。比方某个单体服务呈现资源不够，须要进行扩容操作时，利用 APISIX 网关就能够进行动静节点增加实现扩容。同样在跨集群或者跨云状况下，能够通过部署多个 APISIX 网关，将不同的服务迁徙到不同的网关节点下实现集群伸缩性。
对于业务服务来说，整体架构没有变动，就能够在网关层实现对各个服务的动静扩缩容、服务迁徙等。整个过程的计划和指标都很明确，一旦波及变更，也不会造成整体架构的不稳固。
性能扩展性：业务动静转发
除了上述这些耳熟能详的网关通用场景实际外，Apache APISIX 为 Beeto 的业务动静转发层面也提供了十分大的帮忙。
相熟 APP 端 UI 和后端的敌人应该都晓得，不同的产品页面是由不同的服务提供。一个页面是由不同模块组成的，其中的内容全副由接口下发。接口下发什么模块的数据，端上就渲染成什么样。这是一种联结客户端的渲染标准，目标是让客户端的渲染过程更通用，业务解决更灵便。
比方上图 PageA 的实现，就是客户端调用了服务 A 的接口，下发对应模块数据，实现 PageA 的渲染。这种操作会呈现一个问题，客户端须要去保护每一个页面，对接每一个服务的接口。如果内容呈现变更，就须要进行发版解决，操作性和效率体现上都很不敌对。
解决上述问题的次要思路就是在整体架构上实现服务的对立散发。即客户端首先对立申请接口地址，将这一类的所有申请都转发到一个接口，在网关层对 URL 地址进行申请参数和 URL 规定的解决，而后引入散发插件。最初依照配置规定，将解析后的申请在网关层间接将申请转发到指定的服务下来。
整个过程客户端只需确定渲染标准，无需关怀数据起源。网关层承当了业务散发的职责，间接将流量进行转发。同时 APISIX 中的插件配置文件能够做到动静实时更新，转发规定也能够动静调整，非常灵便。其实相似像 BFF(Backend for Frontend) 架构的利用，这种需要都能够网关层进行解决。
总结
本文从 Beeto 的产品设计视角，出现了 Beeto 引入 Apache APISIX 网关后的设计思路和与业务层面的一些利用实际。有了 APISIX 网关的加持，在管制资源老本与业务产品线多的前提下，也帮忙 Beeto 实现了中东本地化部署、对立治理及运维敌对的场景。
