Beeto 是一款面向中东市场主打阿拉伯语言的 交软件，在产品设计和技术架构上都是本地化落地实施的。曾在沙特 iOS 应用商店 Top Charts 榜单中超过老牌 交巨头 Facebook，位列第 4 名。
其实中东在互联 领域算是发展较成熟的区域，在 交 络中的活跃用户渗透率非常高，尤其在沙特区域，2019 年的互联 用户就已经达到了 90%，活跃用户渗透率在 2020 年就已经排到了第 9 位。
互联 市场的成熟，带来的是国际性软件的覆盖，像 WhatsApp、YouTube 和 Instagram 等都是当地主流的 交软件。但回过头看，你会发现在中东地区基本没有类似国内微博这种本地化的 交类软件。所以在 Beeto 产品诞生之前，就瞄准了「中东互联 成熟、渗透率高，但本地化少」的方向，并开启了专注「本地化特色」的产品准备。
目前 Beeto 产品的业务主要可划分为以上这些。这些业务的实现其实都需要在中东地区进行本地化部署。如果把每项业务按照服务进行拆分的话，那每个服务其实就是独立的单体架构。
可以看到，无论是适配层、业务层还是基础服务层，都存在着若干服务。每项服务的部署架构都拥有前文提到的单体架构细节，所以中间就会存在着若干个七层集群，这其实已经是一套非常庞大且复杂的系统架构了。
但由于目前 Beeto 产品还处于创业阶段，尤其是产品本身在中东本土落地，而研发人员在中国的情形，按照上述这个规模部署，需要投入非常大的服务器成本和维护成本。同时后期随着业务增加，单体服务的数量势必也会不断增加，不管在成本还是运维操作上都会变得更难控制。
多服务落地困难
除了上述提到的架构部署复杂外，其实在集群内部服务之间的调用也是非常复杂的。
南北向流量分散到各个服务池，东西向流量也交错在各个服务之间，这些服务的调用关系之间错综相交。对每一套服务而言都需要去维护这些调用关系，从而导致调用链路不清晰且不好管理。
关集群对所有的服务都提供了注册中心、服务控制、服务监控、协议转发和应用插件等扩展工具。各个服务的集群都可以统一在 关进行注册，新服务上下线也都可以直接通过 关来完成。
如上方流程图所示，插件内部会先进行本地化验证，然后根据策略进行远端服务的认证校验。当请求完成 Cookie 校验后，再转发到指定的服务上。
这样做的优势主要体现在两方面：
- 确保了用户 Cookie 的信息安全。因为 Cookie 属于敏感数据，在执行过程中确保只有 关层能够接收并进行处理，其他业务层均不能接触。防止业务处理规则不一致而导致的安全问题，也有效避免了人为因素和不规范问题导致的 Cookie 泄露等安全问题。
- 降低了各个服务 Cookie 认证的复杂性。前文提到了 Cookie 在过程中需要进行本地验证或远端验证，同时 Cookie 升级时，各个服务也都需要同步升级。通过 关进行统一管理与校验，在业务服务的处理上就省去了校验成本，只需关注结果，利用结果进行业务规则处理，从而保证各个业务处理更聚焦于业务本身。
东西向流量-Token
像下图中的 A 服务调用 B 服务的操作，通常来讲互相调用时只需提供一个 API 即可完成。但是在内部流程中，需要去了解「API 被谁调用了、通过什么方式调用的、是否需要进行权限校验，是否需要对调研方进行控制」等这些问题，都是需要内部去处理的。
在 Beeto 的架构中，服务伸缩性主要体现在两个方面，即单体服务伸缩性和整体集群伸缩性。比如某个单体服务出现资源不够，需要进行扩容操作时，利用 APISIX 关就可以进行动态节点添加实现扩容。同样在跨集群或者跨云情况下，可以通过部署多个 APISIX 关，将不同的服务迁移到不同的 关节点下实现集群伸缩性。
对于业务服务来说，整体架构没有变化，就可以在 关层实现对各个服务的动态扩缩容、服务迁移等。整个过程的方案和目标都很明确，一旦涉及变更，也不会造成整体架构的不稳定。
功能扩展性：业务动态转发
除了上述这些耳熟能详的 关通用场景实践外，Apache APISIX 为 Beeto 的业务动态转发层面也提供了非常大的帮助。
熟悉 APP 端 UI 和后端的朋友应该都知道，不同的产品页面是由不同的服务提供。一个页面是由不同模块组成的，其中的内容全部由接口下发。接口下发什么模块的数据，端上就渲染成什么样。这是一种联合客户端的渲染规范，目的是让客户端的渲染过程更通用，业务处理更灵活。
总结
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！