如何搭建社交产品出海业务架构

一、背景
随着公司业务不断的升级，经过各方面的调研，认为陌生人社交产品是能够进入海外市场的；基于公司的战略以及需求，海外项目便由此开始启动。

二、海外架构迁移流程

1. 架构变化

国内服务端技术架构如下图所示（使用的阿里云服务器）：

• 网关层：用于处理任务想要请求服务进行信息交互的处理；对请求的应用校验、用户信息校验，加解密等操作。
• 控制台：不同的业务应用都会对应有不同的后台，包括定时任务也是根据不同的应用进行的部署。
• 业务层：业务层主要指的是，每个应用所对应的业务服务，所有的业务逻辑都在该层进行处理。
• 中台服务：中台服务指的是能够提供给不同应用提供基础能力的服务；例如：用户中心提供用户相关信息以及支持各种第三方登录，社会化系统提供用户在应用的与其他用户的关系，以及动态相关功能。
• 数据库：数据作为服务端最为重要的信息，单独将数据层拉出来，后续海外项目会提及到数据相关信息。
• 中间件：上述中间件，指的是服务中所使用到的开源或者其他第三方的一些组件能力。

服务器选择
首先从服务器部署层面来考虑海外项目，国内的应用，服务器是部署在国内的；那么海外的项目，服务器必然是不会部署在国内，会找要项目进军的市场国家较近的服务器部署位置。从各个微服务的角度考虑，业务服务根据不同的应用本就是区分开来，一款海外项目对应一个业务服务。但是中台的服务不太一样从定义上来说，中台服务是一套代码能够支撑各个应用的，多套产品如果都在国内的话，部署在一套服务器上就能够进行支撑；但是海外项目就必须都重新部署一次（代码一定是同一套，严记这是中台服务，必须能够具有支撑各个产品的能力）；所以只能将所有的中台服务在海外也部署一次，后续中台服务如果有能够进行补充或者修改的话，需要国内外都进行发布。
服务器的选择上，阿里云自然也是提供海外服务器的能力，如果选择阿里云服务器，那么整套服务的部署改动量一定是最小的，经过运维同学各方面的调查及综合考虑下，以及海外服务器使用情况，最终选择了使用 AWS 的服务器。

国外服务端技术架构如下图所示（使用的 AWS 服务器）：

差异性对比
从上图中我们可以看到海外的技术架构图，与国内的差异性不大，主要的几个差异点如下：
1、业务层不同，每一个业务服务对应一个应用，海外的应用自然不需要部署在国内，国内的应用也自然不需要部署在国外。除了业务层的服务之外，其他的都是属于中台的服务，那么自然不论是国内国外都是需要的。
2、服务器部署不同，根据上文的描述，海外这套环境整体都是在 AWS 服务器上进行部署的，包括所有的第三方组件，数据库，控制台等；这里也是整体架构上最大的一个不同点。
3、其实我们最初的目标就是希望能够使用最小的改动点，来实现一套稳定的海外项目，从国内外两张图中可以看出整体的一个架构上是几乎没什么变化的，只是在建立海外项目的时候，不同的第三方SDK的支持、改造、以及数据的初始化工作、应用的国际化工作、项目的业务能力上有一定的改动量。例如在存储文件的第三方组件上，阿里云提供了 OSS 组件进行存储，AWS 提供了 S3 组件进行存储，处于工作量，以及减少差异性角度考虑，海外架构中没有使用 S3 对 OSS 进行替换。

2. 功能变化

登陆功能
国内的登录使用手机号、微信等常见的登录方式；根据调研，海外产品使用手机号、google、facebook等进行登录的方式比较常见；所以我们需要重新接入google登录以及facebook的登陆方式；手机号登录方式，需要增加区域的选择，以及短信发送第三方的选择，在下面会进行讲解。
google接入链接：https://developers.google.com/identity/sign-in/android/backend-auth
facebook接入链接：http://cwqqq.com/2017/12/06/facebook_login_api_server-side
短信服务国内架构中，我们使用的是阿里云的短信发送服务；同时阿里云也是提供了海外的服务的，但是短信签名，阿里云是不支持除了大陆以外的公司进行申请的，所以重新选择了第三方；在接入 aws 的 sns 中的短信服务的时候，但是在测试的时候发现，国内的手机号是无法接收到短信的，虽然是海外项目，还是希望能够支持国内的手机号。最后又选择了创蓝的短信服务，虽然要支持国内手机号，需要创蓝的商务帮忙配置模版信息，但是也还是比较方便的。选择短信服务的第三方可以根据具体的需求来进行选择。

支付功能
国内的支付，只要使用的有微信、支付宝、银行卡等；而海外的支付，Android 我们可以使用 Google Pay，已经为我们整合了海外常用的各种支付方式，Ios 不论是国内外都使用的是苹果自带的支付，所以不需要修改。
Google Pay 的接入地址：https://developer.android.com/google/play/billing?hl=zh-cn
参考文档：https://blog.csdn.net/weixin_43878332/article/details/118524224?spm=1001.2101.3001.6650.2&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-2.no_search_link&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-2.no_search_link

国际化功能
既然产品作为海外项目，那么语言就成为了一个不可避免的问题，所以服务端及客户端就都需要进行国际化；具体如何进行国际化，网上有较多的教材，以及需要结合我们自己的业务架构，设计出国际化的方案；初期根据上述的架构，我们是针对每个不同的服务进行的国际化，后续发现有很大一部分的国际化数据都是重复的，并且国际化的工作散落在各个微服务中，后续一定是需要将国际化的信息进行统一处理。

3. 数据迁移及初始化
数据作为项目最为重要的部分之一，项目迁移到海外的过程中，我们需要将一些必要的数据也进行迁移，例如租户信息数据、资源信息需要迁移；像用户相关数据，日志记录数据就不需要进行迁移了，当然全部都迁移过去也没有关系，因为数据我们一定是都要根据应用进行区分的，不能把不同应用数据混淆在一起，但是毕竟是无效的，以及线上的大量数据，一定程度上降低性能，所以没有必要的数据不进行同步。数据存放的组件有 mysql、es、redis等。
mysql：
需要查看每个服务的数据库中的每个表，梳理出需要同步的数据（固定不变的数据需要进行同步，比如说：聊天的系统话术、用户注册自动的昵称库等），最后提交给运维同学进行同步。
缓存：
数据库中具有一些需要同步的初始化数据，缓存中自然也有，所以需要对缓存进行一次整理，但是方式与数据库不一样，如果说，因为该缓存不存在，而导致出现了问题，并且数据不会重新写入缓存中，那么该段的代码存在一定的不合理性，需要进行修改处理。
ES：
相信各公司都有使用到 es 进行存储数据，那么也会存在初始化数据的问题；es中数据的处理方案与缓存一致；还有一个值得注意的点是，es 中可能存在一些早期写入的初始化脚本，因为没有发现，导致新项目使用 es 的时候出现问题；所以还需要找出所有的初始化脚本，并进行执行，并且梳理起来，减少后续新项目的工作量。

4. 日常迭代
基于当前公司的业务，所有的中台服务就需要在国内的阿里云服务器上部署一套，以及海外的AWS服务器上部署一套，所有新增修改的脚本也同样需要在国内国外进行同步；再加上目前的开发流程，国内国外都具有开发、测试、预发、线上环境；以及开发及测试的环境具有多套。无疑是很大程度上的增加了测试以及发布的代价。
在没有海外项目前的流程为，每个对应的需求开发负责人，从master拉取当前功能需要的分支，进行开发；开发完成后，合并到开发环境进行自测联调等工作；完成冒烟之后合并到测试环境给到测试同学进行测试；完成之后将功能合并到预发环境进行回归以及验收，最后发布到线上；如果有脚本的话根据脚本需要在发布时机及影响选择执行时间。
当前增加了海外项目之后，所有的中台服务流程中，在每次代码合并到开发、测试、预发、线上的过程中都需要在海外的服务也发布一次，并且根据具体的功能确认是否国内外都进行测试；以及所有的脚本也需要在对应的时机在海外进行执行。一套流程下来，基本比原先流程步骤多了一倍，步骤多了一倍，可能出现风险的情况是几何倍的增长。
从时间成本上来考虑，一定要将整套流程都进行自动化，在发布构建对应环境的时候，国内外进行同时发布；在执行脚本的时候，也能够做到同步操作；这样从时间上能够大量节省，并且降低因为人工操作发布脚本导致的问题。
从风险角度考虑，需要对项目中的开发同学贯彻中台服务的意义以及目前架构现状；以及开发同学增加对代码中测试用例的覆盖率，测试同学尽可能增加接口自动化的覆盖率，尽可能将风险通过机器、代码等暴露出来。

三、总结
上述便是搭建海外项目过程中，服务端的主要流程；其中还有非常多详细信息就不在这一一列举了。本次也是首次搭建海外项目架构，并进行架构迁移，如果有好的建议，欢迎留言。如果您也希望搭建一套海外项目，希望上述信息能够对您提供一些帮助，谢谢！