主题推荐从纯离线自然演化为Lambda架构的路径

1号店主题推荐系统的演进过程，展示了一条Lambda架构常常不是”从一开始就被设计出来”、而是随着需求增长自然长成的路径。最初主题推荐只有四个步骤：建立商品与主题、用户与商品、用户与主题的关系，建立主题选品池，再根据用户与主题的关系从选品池里给用户做推荐——这个阶段整个推荐结果完全由离线数据算出来，用公式表达就是Topic_recommend = topic_recommend_function(offline data)，完全不需要任何”实时处理范式”就能跑通，是一个纯粹的批处理系统。后来业务需求进一步演进，加入了”增量推荐”能力——根据用户当下的实时行为（浏览、购买、评论）动态调整离线算好的推荐结果，公式相应地变成了Topic_recommend = merge(topic_recommend_function1(offline data), topic_recommend_function2(online data))：这时系统结构已经天然长成了批处理层算离线结果、实时处理层算在线结果、再用一个merge函数把两者结合的Lambda架构，尽管团队最初设计系统时可能并没有刻意”选择Lambda架构”，而是业务需求（既要有稳定全面的离线基础推荐，又要能对用户实时行为快速响应）自然推着系统朝这个方向演化。这个案例提示了一条理解架构模式的实用视角：很多经典架构模式（不只是Lambda）与其说是工程师主动选择的产物，不如说是特定类型的业务需求（这里是”既要全面又要实时”）几乎必然导致的结构性结果——理解一个架构模式，除了记住它的名字和结构图，更重要的是理解它对应着哪一类需求的组合，这样在遇到类似需求组合时，即使不刻意套用某个”架构模式”的名字，自然而然设计出来的系统结构也会和这个经典模式高度吻合。