做业务架构，全局观很重要 作者 | 褚杏娟 采访嘉宾 | 吕倩今天的互联网，用户是本源。为了满足不断变化的用户需求、更好地解决业务发展痛点，很多企业选择了以业务战略为中心的业务架构，并不断优化和升级。 小红书作为一个生活方式社区，业务逻辑是保证用户能够生产足够的内容，并通过内容联动和交流，最后激发更多的创作分享行为。作为年轻人的聚集地，想法多变是小红书用户的主要特点，这也导致小红书在业务架构上经常面临优化和升级。为此，InfoQ 采访了小红书社区平台架构负责人吕倩，来聊聊业务与架构的那些事儿。 1架构升级史即业务发展史小红书的架构升级史就是其业务发展的缩影。从最初的单体服务到 16 年的微服务，再到 18 年的容器化、中台化，背后转变的推动力就是业务的发展和用户体量的增长。 “最开始，我们是想快速上线，可以立刻为用户服务。但随着用户量增多，单体架构难以支撑，我们改成了微服务。再到后面，我们发现业务越来越多，很多服务是可以通用的，团队要做的就是将其中台化。在水平扩容方面，我们便开始进行容器化，这也为后来做云原生打下了很好的基础。”吕倩说道。 小红书社区架构演进 2020 年上半年，小红书对资源耗费大、单机 QPS 承载不高的网关架构做了升级。这次升级的方向就是提高资源利用率和性能，同时应对日益增长的流量。小红书选择按功能模块将其拆成不同组，先打基础再做业务。“整个过程中，架构、业务和产品的同学一起沟通、改进和验证，架构升级是一个团队协作的事情。”吕倩说道。 如今业务迭代越来越快，意味着开发时间短，而用户量在不断快速增长，稳定性成为企业普遍面临的挑战。在研发服务上，小红书研发团队也会进行优先级划分，划分的依据依然是用户。用户核心主链路上的开发优先级最高，其次是网关等，以用户优先的系统也要求企业有很强的保障机制。 在吕倩看来，可观测性是稳定性治理的第一步。一套敏捷可靠的监控报警平台可以帮助研发人员及时发现问题。 小红书监控报警技术栈演进在高可用方面，小红书目前在做双活架构，未来也会探索多活架构，保证在像机场断电、火灾等极端场景下服务器仍可稳定运行。当然部署双活架构后，也会伴随着更复杂的流量调度、故障切换等问题出现，这些都需要解决。 现在，面对像双十一这样的高并发场景，很多企业已经轻车熟路。在这种情况下，小红书通常会事先做流量预估，并做预扩容和压力测试等，如果遇到计划之外的流量，则利用消息队列去“消峰填谷”，同时要建立流控、熔断、降级等机制应来保障后端的服务。最新数据显示，目前小红书月活用户已超 1 亿，系统完全可以支撑得起该级别体量。 在升级过程中，很多时候都是“边换轮子边跑”的状态。吕倩表示，在上线改造过程中，要保证新业务可以直接在底层架构上开发。新业务优先到新架构上做，老业务再逐步迁移，最后形成一个完整的架构升级。 吕倩总结了升级过程中需要注意的三点：了解现在遇到的问题，统一大家的诉求；有明确的规划，使大家行动一致，并有序进行；改造验证，这对用户体验很重要。 2做业务架构，全局观很重要架构迭代速度快似乎正在成为国内互联网企业的一个“特色”。一方面，国内互联网变化太快，用户需求和业务需求一直在变，并且变化速度非常快，这导致系统的迭代更新也要非常快。另一方面，国外企业更看重标准化，从提需求到测试、发布等，整个流程更加规范，但同时也会使流程更加繁琐且耗时更长。 “只有跑得足够快，才能跟上用户需求。”吕倩说道。 但面对成千上万种不同的业务需求，架构师们并没有统一的模型可以套用。很多人会选择“先做再说”。虽然业务逻辑可能千差万别，但吕倩认为技术却是通用的。比如高流量、高并发等技术痛点是很多企业都在面临的问题，对应的，云原生等这样的技术解决方案也可能是通用的。“技术本身是通用的，只是反映到业务上会各有不同的侧重点。” 无论搜索还是推荐，最终的落脚点还是内容。在对通用问题的处理上，小红书将一些通用化能力通过中台进行打包，并以接口形式支持外部系统，以此来避免很多重复性工作，快速支持业务发展。 吕倩表示，小红书提出中台化的目标除了保护核心数据，更重要的就是做标准化，让核心系统更加稳定和高可用，并且能够支撑业务迭代，让业务跑得更快。 但是，这里也存在一个矛盾：作为底层服务，改变接口会带来相关业务的一系列改变，这就要求接口不能有太大的改变，但用户需求和相关业务的变化是很快的，不变又无法跟上企业发展需求。既要保证新业务能够快速上线，又要保证业务能够平稳地水平扩展，成为当前企业在业务架构上普遍面临的难点。 那么，如何做到架构升级又快又稳呢？在吕倩看来，架构师需要有清晰的思路，明白哪些事情是需要优先解决的，哪些是可以稍往后放的。 “虽然架构师优先要紧跟业务需求、解决当前迭代痛点，但架构师不能只顾当下的问题，还要有前瞻性和全局观，走进用户和业务，了解当前业务的问题及未来可能的变化，提前做技术储备。” 面对快速变化的业务，企业在进行着大大小小的升级，有的可能一两个月就可以搞定，有的则可能要半年。吕倩表示，如果升级周期较长，架构师在设计的时候就要把思维放在这个周期之后，也就是说要预先去规划这个周期之后的事情。 在吕倩看来，业务预测并不简单，要预测业务发展基本方向。同时为计划之外的新业务出现，提前可以做库表、组件等接口的预留，保证系统可以轻松扩容等。 各大企业都在做业务闭环，链路越拉越长，导致不同的业务系统越来越多。吕倩表示这虽然会对底层架构产生一定的影响，但将不同的业务系统融合起来就会形成一个整体的生态体系，生态化也会降低事情的复杂度。 但如何构建业务生态系统，这涉及到了企业重要的发展规划问题，这对架构师来说会是一个巨大的挑战。 嘉宾介绍：吕倩，小红书社区平台架构负责人 你也「在看」吗？??