评论系统架构设计
这节课程是结合实际业务场景，来做系统架构设计。
架构设计
做架构设计前，需要深度理解产品的业务背景，才能做出更好的设计与抽象，而不是简单的翻译需求。
例如视频评论系统，就可以抽象出通用的评论功能，从而实现评论平台，接入到各种业务形态：文章评论、漫画评论等。
核心功能
- 发布评论: 支持回复楼层、楼中楼。
- 读取评论: 按照时间、热度排序。
- 删除评论: 用户删除、作者删除。
- 管理评论: 作者置顶、后台运营管理(搜索、删除、审核等)。
在动手设计前，反复思考，可编写伪代码，理清思路，真正编码的时间只有5%。
做好抽象
产品要求支持二级评论，而不是无限嵌套，影响使用体验。
这里的最大评论层级就可以抽象出来，支持设置任意数值，而不是写死仅支持二级。两种方案在具体实现方面有很大的区别，所以要提前设计好。高度抽象，才能提升扩展性。
设计概览
一个好的架构可以在一个信封上画出来。
架构设计等同于数据设计，梳理清楚数据的走向和逻辑。尽量避免环形依赖、数据双向请求等。
BFF: comment
复杂评论业务的服务编排，比如访问账号服务进行等级判定，同时需要在 BFF 面向移动端/WEB场景来设计 API，这一层抽象把评论的本身的内容列表处理(加载、分页、排序等)进行了隔离，关注在业务平台化逻辑上。
Service: comment-service
服务层，去平台业务的逻辑，专注在评论功能的 API 实现上，比如发布、读取、删除，海量写入和读取，面对突发流量降级等，关注在稳定性、可用性上，这样让上游可以灵活组织逻辑把基础能力和业务能力剥离。
Job: comment-job
海量写系统的性能瓶颈一般都在DB，利用MQ comment-job将写操作削峰。
Admin: comment-admin
管理平台，按照安全等级划分服务，尤其划分运营平台，他们会共享服务层的存储层(MySQL、Redis)。运营体系的数据大量都是检索，我们使用 canal 进行同步到 ES 中，整个数据的展示都是通过 ES，再通过业务主键更新业务数据层，这样运营端的查询压力就下方给了独立的 fulltext search 系统。
admin包含复杂的查询，而mysql属于OLTP数据库，不适合做复杂查询。
OLTP，也叫联机事务处理（Online Transaction Processing），表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。
Dependency: account-service、filter-service
整个评论服务还会依赖一些外部 gRPC 服务，统一的平台业务逻辑在 comment BFF 层收敛，这里 account-service 主要是账号服务，filter-service 是敏感词过滤服务。
参考
惊群问题——维基百科
分布式系统的Thundering Herd效应
缓存更新的套路——陈皓
cache-aside——微软
关注点分离——维基百科
Post Views: 4
