云查引擎
项目简介
云查引擎是一款为移动终端用户提供病毒云查询能力的产品，如果您使用的手机是华为、小米等国产机型， 那么您可以打开手机管家，点击病毒扫描功能，如果您能看到"安天AVL提供引擎支持"类似字样， 就说明此次病毒扫描由本产品提供支持。目前该产品已长期应用于多家合作厂商，日活数十亿。
从技术层面的角度来讲，云查引擎又是一个较为失败的产品。 它从早期的一个demo，衍生到现在的重量级产品，中间大概经历了4次重大迭代。 每次迭代都有一定的业务背景在里面，有点类似问题驱动。它没有从技术的角度出发演进，而是受限与很多业务场景，做了很多取舍。
部署说明
花山云
- staging
- master
华为云
server
- sync
- kv-db
- rds
- pg
- server
- api
- hw：80
- mi：35
- vi：60
- op：30
- cse：10
- risk：45
总计200个左右，部署均为1c1g，早期业务受限，购买机器配置较低，又要考虑容灾等特性。因此将粒度拆分到单核。
高峰期并发10w，因此单pod处理量差不多是500左右
流量说明
服务部署在华为云
- 带宽：200M
- 费用：近约6000元/月
高峰期并发10w，因此单请求体积差不多是2KB左右。
数据库表设计
由业务属性决定，数据库中有200多张基础表，包括有：
- app_hash：应用基础表
- cert_hash：证书基础表
- mf_hash：mf文件基础表
数据库中，以app_hash单表16亿数据最为突出。因此后续分析仅针对app_hash单表而论。
花山云（主库）
- app_hash：128分表，拆分后单表数据差不多是1200w条数据
分表原则：我们要求单表数据维持在2000w以内。因此对于大于2000w的数据，会按：1/4/8/32/128
华为云（从库）
- app_hash：16亿，数据160g，索引160g
索引优化：
- md5字符串转16进制，存储体积由32字节减小到16字节。优化后，体积减小了一半，数据100g+，索引80g+
- 基于业务的特殊性，将B+树索引改哈希索引，进一步优化索引体积。优化后，索引体积在60g+
架构演进
早期阶段
第一阶段
二代KV-DB
三代KV-DB
四代KV-DB
问题点
为什么要引入gRPC拆分API层
- 架构层面做拆分，API端仅负责业务逻辑，而KV-DB则负责数据处理。
- 这样拆分也是参考了MySQL的架构分层，server层和引擎层。
- 包括我们后端架构升级，从MySQL迁移到PG，对于API来说就不需要做任何调整。
为什么API是1c1g
- 从业务角度看，业务阶段决定了我们不能有类似一个8c16g这样的超体。对于8c16g的pod，我们更倾向于拆成8个1c1g的pod。
- 从高可用的角度看，一个8c16g，不如两台4c8g，pod部署在两台服务器上更可靠。
- 因此为了统一管理，我们全部采用的1c1g
- 关于这个，我们也做过压测，一个2c2g的pod和2个1c1g的pod，几乎没有差别
为什么不使用业界内的标准架构
- 这个是由个人能力和业务背景决定的。因为KVDB2已经正式上线并运行了，而基于当时我个人的技术视角和能力，是存在惯性的。