前浪微博消息队列的最终决策：多方分歧与三原则逐一回应

[[前浪微博消息队列三个备选方案对比]]的评审会上，研发、测试、运维、业务主管四方对三个方案的态度出现了明显分歧，这本身说明了[[环评表列出后如何最终选择：按优先级而非数量或加权]]为什么不能只靠纯技术指标决定：方案一（开源Kafka）业务主管和部分测试、研发人员倾向支持（成熟、省投入），但运维代表强烈反对（团队没有Scala系统的运维经验、Kafka无法融入现有运维体系），部分研发人员也指出Kafka的设计目标是日志传输而非业务消息的可靠传输，场景本身就不太匹配；方案二（集群+MySQL）运维代表支持（能融入现有运维体系、MySQL运维经验丰富、可靠性有保障），但部分研发人员担心性能不如文件系统、也担心”用MySQL做消息队列”显得技术上不够有说服力；方案三（集群+自研存储）部分研发人员认为最能体现技术实力，但运维代表基于过往MongoDB、Tokyo Tyrant丢数据的真实事故经验强烈不看好，测试代表和业务主管也都从测试投入和上线风险角度表达保留意见。面对这种没有共识的局面，架构师最终选择了方案二，给出的理由完整对应了三条架构设计原则：排除方案一是出于合适原则——即使技术成熟，若无法快速定位和处理线上问题、且设计目标（日志传输）本就和当前需求（业务消息可靠传输）不匹配，就不是合适的选择；排除方案三是出于简单原则——团队总共只有6人还要维护其他中间件系统，人力和技术积累都撑不起一个稳定可靠的自研存储系统；针对方案二本身被指出的三个缺点，架构师逐一用原则回应：性能缺点用演化原则回应（当前性能需求不高，方案2够用，未来需求增加时数据分组方案本身就支持水平扩展）；成本缺点用具体优化方案回应（备机可以和其他系统共享部署，降低实际机器投入）；”技术上不够优越”这个缺点则直接用合适原则回应（设计的目的不是证明自己多厉害，而是更快更好地满足业务需求）。这个案例最有价值的启示是：同样的三个备选方案，换一个团队背景可能会做出完全不同的选择——人手紧张、急于上线的创业团队可能会选Kafka，而像阿里这样人力和资源都充裕、业务复杂度又极高的团队则可能像RocketMQ那样走自研路线，方案选择从来不是脱离约束条件的纯技术最优解，而是特定团队、特定阶段下的最合适解。