与引擎相关改造

前言

目前读的部分只是来支持我们830对公司上层有个交代。本身这里面还是有一系列的问题，主要体现在

1. 老引擎写部分还是一个性能瓶颈。
2. 老引擎的循环依赖并没有解决，即使读部分能够降低概率，但并不保证肯定没问题。
3. 支付部分的风险较高，脏数据等可能性较大。
4. 调用链过长，不易于未来性能的进一步提升。

同时，原有社交业务代码也存在一系列问题，例如

1. 引用依赖还是比较乱（经常打不出日志来就是一个体现）
2. 目前有在缓存中存的数据需要持久化的，还是一个风险。
3. 华为云梳理出来的问题，最好还是要解决。
4. 数据库分片后，我们之前的sql查询，可能还是有性能的问题。
5. 一系列的黑名单等等还没有做。

老引擎部分

模块包括

1. 用户 （未来会去掉）
2. 圈   （未来会去掉）
3. 群   （未来会去掉）
4. 许愿灯 （保留，但改成依赖关系引擎）
5. 支付    （可能会深度改写）
6. 登录注册 （保留，但改成异步，提高性能）
7. 隐私 （去掉，考虑用关系引擎替代）
8. 消息  （ 保留 ）
9. 标签  （去掉，考虑用关系引擎）
10. 投诉 （保留）
11. 分享 （保留）
12. 行为分析（大数据） （深度改写，不能再读业务库）
13. 排行榜（大数据）   （深度改写，不能再读业务库）
14. 后管平台            （调用新统计引擎，也就意味着写也要写入统计引擎）
15. 。。。
注：华为云上的大数据平台是直接读的线上业务库，所以大数据部分也是一个强依赖。

因为历史原因，目前调用链比较长，而且调用次数也比较多

未完成的Engine部分

1. 第三方调用还没开始。
2. 历史记录引擎还没开始。
3. 数据补偿修复工具还没开始
4. 关系引擎还差用户信息更新体现到历史记录中。
5. 统计引擎还没有被验证。
6. 规则引擎还没有被验证。

未来希望的分层

第一层：Controller层 + 后管
第二层：业务Provider层（登录注册，许愿灯，消息。。。+ 社交原业务 + 后管）
第三层：基础服务Provider层（用户，圈，群，等级，特权。。。）
计算层：异步计算层（各个计算中心），大数据。
支持层：5个Engines，mysql, mongo, pika, queue...

这样，未来的架构中

1. 调用链应该控制在3层以里。
2. 不应该有循环依赖。（需要数据时可以通过关系或统计引擎获得）
3. 基础数据还是存数据库，主要支持主键查询。关系或统计部分走相应的Engine来处理。
4. 二三层还是需要支持Redis缓存，与之前没有区别。
5. 逐渐优化主要 rest 接口能支持300并发 tp90低于300ms。

工作安排

Engine部分：

1. 第三方调用engine         --- 刘增明。
2. 历史记录引擎还没开始     --- 张乐。
3. 数据补偿框架             --- 刘丰。

老引擎部分：

1. 登录注册异步化           --- 刘增明
2. 用户                     --- 张现伟
3. 圈                       --- 刘卫辉
4. 群                       --- 陈福领
5. 许愿灯                   --- 张生林/刘增明
6. 隐私                     --- 李三成/郭春杰
7. 标签                     --- 李三成/郜志勇
8. 投诉                     --- 李三成/郜志勇
9，分享                     --- 李三成/郭春杰
10，大数据的梳理和改造      --- 卫怀东/世龙

原来未支持功能

1. 黑明单                           --- 现伟/贺军
2. 隐私                             --- 现伟/贺军
3. 手机号是否注册（拉新也要用）     --- 现伟/贺军

原社交平台遗留问题

1. Cache/Redis中持久化数据落盘    --- 贺军/刘锐。

开发新增需求

用户部分：加上粉丝和关注