• 背景

      • 最初目的是存储一些没有特定意义的用户信息，后面发展为具有业务价值的用户信息聚合微服务，可以提供多项关键信息的读写，减少了其他服务的多调用，在客户端诉求上经过网关后大部分数据需求在这个微服务上。

    • 实践

      • 技术选型，数据库DynamoDB，缓存DAX，容器集群管理k8s，api网关（kong）自建，fallback，s3 bucket

      • 服务聚合，把其他微服务的信息通过聚合到一个微服务，以用户纬度存储，一可以让其他微服务使用方式更简单，做到单依赖，二可以让真实消费方也就是客户端得到更快响应。但这也同时意味着，其必须承载大量来自内部和外部的并发。

      • 读写分离，分离的原因很简单，大量请求中，读请求占据90%以上。

      • 设计上，用户分区，每个用户都单独分区（以用户id为标识），同时，也在一个用户内设计从1到n个排序键，满足不同领域模型需求，每个排序键代表一种数据存储单元，其都需要定义其相应的数据格式，一般是jsonscheme。

      • 读上使用DAX缓存，不同的查询会有不同的延迟，比如这个微服务延迟与其他的是不同的，这个微服务内部不同用户或者不同信息也可能存在不同。但本身，其响应够快，所以相比可以设置一个低延迟，如果低延迟不通，进行一次请求重试，配置使用k8s实现按供应而不是按需，每有增长都会扩展。在异常情况下，kong网关层会调用fallback，指向一个s3 bucket，得到一个可能过时的数据来保证响应。

      • 写上，放弃了使用api写入数据库，而是中间设置了消息队列，api接收记录后，放到消息队列，消息队列经过jsonscheme格式验证，然后写入。优点，一不依赖于api，其可能会中断，同时api响应也不依赖于数据库的真实写入。二可通过消息队列调整接收的时效，控制写入的速度，也可以让消息队列被多个消费，实现信息复用。

      • 数据分批定时写入，每次500条批量在某个时间写入，一天达到百万条记录，每次间隔10-20分钟。