线上qps2000，主要的性能瓶颈在于出现在数据库I/O上。另外，如果是一个正常部署的容器，qps能达到几百就不错了。资讯服务现在做了静态的底层页，所以热点新闻多数会命中底层页，即便没有命中底层页，也会走多层的缓存，不会直接打到资讯服务的接口上。

技术方案

解决哪些问题？模块如何拆分？
解决资讯服务mongo pg数据不是同事写入的问题，该问题会造成底层页404。

收敛资讯发文入口、目前发文都是直接写的PG，不好控制。

竞争对手的解决方案是什么？行业领先的解决方案是什么？

收敛服务业务垂直分割

数据存储怎么设计？扩展性考虑了嘛？

存储：Mongodb+PG

扩展性：mongo支持分表（按照SEQ分表)、非基础属性计划迁移到画像。

是否需要缓存？缓存如何设计？如何保证数据一致性？缓存失效怎么处理？

无缓存

代码设计是怎么样的？使用什么设计模式解决问题？

无

需要调用外部哪些服务？所有调用的处理容错和监控做了嘛？（所有服务都认为不可信：包括可用性，数据字段返回异常）

依赖的服务：stockMatch

容错：Sentinel 对 stockMatch、写mongo、写PG（出基础表以外的)、查pub205之类的

降级：Sentinel 对 stockMatch、写mongo、写PG（出基础表以外的)、查pub205之类的

监控: 基础监控报警 、jvm指标、所有写入的操作。

日志：所有写入的操作。

这个开发任务可以抽取哪几个组件？

基于接口抽象出http sdk（composer）

这个开发任务可以抽取哪几个服务？

服务：newsinfo（http)

是否需要独立平台来解决更大的系统性问题？

独立部署

性能瓶颈点是什么？业务需求并发是多少？如何保证并发支撑？如何做到线性扩容？

瓶颈：数据库，mongodb的IO，PG的IO。

并发：发文接口没有统计。需要挖一下日志。

并发支持：多副本

线性扩容：mongo可以做分区扩容、PG@ifind、容器副本扩容、cpu扩容

系统关键的容错方案是什么？如何兜底？

写PG失败：重试、如果不是基础表就丢弃。基础报表失败则发文失败。

写mongo失败：重试、不处理mongo了。

stockmatch失败：重试、丢弃

可测性如何保证？测试工具，测试数据能否提供？

在flashcms想中的savenews方法记录$item序列化日志，在测试环境上回放。验证PG数据的数据和正式环境的数据是否一致，验证mongo的数据格式。验证底层页。

工具：item日志解析脚本、回放脚本、数据对比工具

测试数据：$item的日志

监控如何考虑？这个业务或者功能有哪些关键节点？使用什么方式的监控？

基础监控模块，流控进行监控，监控 写入mongo、写入PG。失败进行报警。

日志需要覆盖哪些主要流程来确保后续的排查方案？

写入时、feign日志、feign失败日志

排查方案：记录elk日志

问题排查方案是什么？排查工具是否提供？

监控、Elk。

部署方案是什么？

k8s独立部署、