跨国际链路的数据服务系统架构设计的一种实现思路

现在数据在互联网产品中发挥的作用越来越大，很多公司都开始收集数据、整理数据，之后再数据建模、分析数据；最终我们得到的是知识，是某种规律的发现。发现知识和规律之后，我们需要将这些知识和规律运用到产品的改进或者运营中去。有些知识可以渗透在整个产品的设计中，比如说，我们通过数据分析发现，对于某种类型的网站的用户，他们大多数喜欢暖色调，那么我们就可以在设计界面的时候，多去使用一些暖色调；但是有些知识却不能或者说不易集成到产品的设计中，比如一种针对于某个用户，而不是全体全体用户的策略：如果当前这个用户是类型1用户，我们就要做动作A，其实这也就是一种推荐系统。对于后者的实现，其实直观的思路上并不难，不外乎是分析用户数据，给用户打标签，存入数据库中，产品直接从数据库中取得用户的标签信息，继而判断用户类别，进而采取相应的个性化服务。但是对于某些跨国
部署的产品，我们面对的一些条件却限制了我们采取这样直观的设计方法，首先，我们来看一下我们的系统应该满足那些需求：

1. 高效性：数据服务系统API嵌入到产品之后，不能对产品产生阻塞，如果因为这一点造成产品卡得不行，影响用户体验，那就和我们的初衷背道而驰了；

2. 稳定性：如果我们的数据中心宕机，对产品造成破坏性影响，那这就是个非常重要的隐患；

3. 易用性：API的接口必须简洁，嵌入必须方便，这是出于控制扩展成本方面的考量；

出于以上几个点的考量，一种异步+缓存的机制是最能满足这样的需求的。大体的实现思路是这样的：

从整体架构上，分为三个角色：数据中心数据服务进程+IDC数据服务进程+数据服务API；下面点一下这三个角色的作用（指提及核心的数据交互协议）：

数据中心数据服务进程：负责从用户标签库中提取相应用户的标签数据（可以使用KV数据库，比如HBase，Redis等），实现提取数据的异步RPC方法；

IDC数据服务进程：负责管理IDC端的缓存（存储RPC方法，提取RPC方法），向数据中心数据服务进程询问某用户对应的标签数据；

数据服务系统API：嵌入到产品中，负责通过RPC调用，从IDC数据服务进程中取得某用户相应的数据；

更具体的实现方法，可以见下图：



这个架构，结合了我们整个数据体系之中的Scribe日志收集系统，用来收集反馈数据，一方面是用来反馈命中率信息，另一方面反馈业务系统中相关的数据，最后做效果评估时使用。

这个系统在使用过程中，首先在用户登录的时候做一次到数据中心异步RPC调用，数据中心的服务会从HBase中获取到用户的相关数据，通过到IDC数据服务进程的异步RPC调用将数据更新到IDC端的一个memcache中，在这个数据过期之前，需要此用户数据的时候，只需要从缓存里取出即可。

如果大家有更好的建议和想法，欢迎给我留言，相互交流。