尹智宇

随着业务的增长，旧的架构设计和技术选项出现瓶颈，分析后进一步优化整体后端服务在高并发下的性能、可用性，并降低成本。

1. 性能优化：问题主要在于开发人员在快速迭代压力下会忽略对性能的思考和处理，关键解法是由服务架构提供更自动化、易用的性能优化能力。如：基于主键对db自动维护缓存，rpc框架支持超限请求自动转异步、进行请求削峰，提供进程内缓存能力，提供支持超时、并发控制的协程管理能力等。
2. 可用性优化：问题主要有：服务间网状调用严重，业务逻辑低内聚高耦合；同一业务的p0/p1场景混用服务、数据表，拉低p0场景可用性；微服务观测性差，没有链路追踪、日志可读性差。解法有：以事件驱动解耦服务、提高内聚性；服务和数据按重要性分层，隔离p0/p1场景；引入分布式链路追踪，提升服务观测性。
3. 成本优化：主要有机器成本和业务开发维护成本。解法上：和运维配合推进了服务上k8s，降低服务器成本；大力推进了bloomfilter的应用，优化存量服务、降低了db成本；落地代码自动生成能力，降低开发成本；业务逻辑算子化编排，降低业务维护成本。

最右社区治理在业务上是用户负反馈、社区标准、内容召回/审核/处置、用户处罚的一个闭环：从用户的负反馈迭代标准，根据标准进行内容的召回和处理，并辅以对用户的处罚，最终降低用户负反馈。其中关键点有：

1. 及时发现问题：对点踩、举报等关键负向行为建立统一的监控体系、设定红线指标，减少问题发现对人的依赖。
2. 校验标准质量：客观、易理解、能执行一致的标准，才能用于制定策略、训练模型、处罚用户，业务上通过运营交叉标注校验来保证标准质量。
3. 及时处置内容：策略有误伤需要人审，但从内容召回到人审结束有时间差，在这一个过程中引入仅自己可见、内容下沉、消息阻断等弱处理手段，尽可能地阻断差内容的传播，同时降低策略误伤的影响。
4. 策略长期维护：策略效果会随时间变化，业务上需要长期关注，因此建立了一套策略预警体系，除了定期复查外，还利用人审、用户申诉等的结果自动发现问题。

参考推荐的召回/粗排/精排模式，重新设计系统：引入存储隔离层，将评论排序由离线拟合升级为实时拟合；引入了策略编排层，进行算子的编排与复用。最终实现了20亿评论的个性化排序，提升了开发效率（AB实验的准备周期从5天降至0.5天）。

1. 存储隔离层（召回）：隔离存储与业务逻辑，开发者直接拿到“帖子下所有评论”，无需考虑db性能。技术上：通过内存+redis两级缓存、pb压缩解决db读io、网络io放大问题，通过拆分存量/增量缓存提升缓存命中率，通过分布式锁避免缓存重复构建。
2. 实时拟合层（粗排）：在内存中，实时对评论的消费特征进行归一化、拟合算分，结合用户个性化数据进行排序。对比老模式（离线任务拟合统一的分数，写入db，建立索引和缓存进行排序），支持了用户个性化、支持了算分的低成本快速调整。
3. 策略编排层（精排）：在算分粗排的基础上，叠加各种后规则策略，满足产品功能、社区氛围等各种维度的业务需求。算子在代码中实现和注册，在yaml中进行参数调整、编排。