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

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

二、海外架构迁移流程

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

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

最后

以上就是贤惠紫菜为你收集整理的如何搭建社交产品出海业务架构的全部内容，希望文章能够帮你解决如何搭建社交产品出海业务架构所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。