十年情缘：Allegro微服务经验分享
内容提要
本文讨论了作者在Allegro使用微服务的10年经验，包括转型过程中的变化和经验教训。作者强调了微服务架构的优势和挑战，以及使用NoSQL数据库和云部署的经验。最后，作者强调了遵循最佳实践和灵活运用反模式的重要性。
延伸解读
从单体到微服务：数据库选型的挑战
Allegro在2013年从单一PHP应用和数据库转向微服务时，面临数据库选型的重大挑战。由于原单体缺乏模块化，领域层与持久层分离不清，团队必须深入重构数据操作，尤其是事务操作。他们选择了Cassandra等NoSQL数据库以实现水平扩展，但后来发现不同数据库适用于不同场景，甚至不得不将某个服务从Cassandra切换到MongoDB。这提醒我们，微服务转型不仅是架构调整，更是数据层重构的复杂过程。
云迁移的文化冲击：从IaaS到PaaS
Allegro的云迁移经历了从物理服务器到OpenStack IaaS，再到基于Mesos和Marathon的PaaS的转变。作者坦言，无法SSH访问虚拟机曾让他感到恐惧，这是职业生涯中最困难的技术转型之一。但通过构建自定义应用控制台等抽象层，团队逐渐适应了PaaS模式，甚至后来迁移到Kubernetes时影响也较小。这表明，云原生转型不仅是技术升级，更是开发文化和运维方式的深刻变革。
监控自主权：从集中式到团队自治
最初，Allegro的监控由集中团队管理，开发人员需通过JIRA工单申请图表或警报，流程耗时约一周，且修改需再次等待，效率低下。作者推动监控团队允许开发团队自行配置可观察性设置，这成为早期成功之一。这一转变体现了微服务架构下团队自治的重要性：将监控等运维职责下放给开发团队，能显著提升响应速度和开发效率。
反模式的智慧：何时打破规则
Allegro在解决Elasticsearch读写性能问题时，打破“两个微服务不应共享数据库”的最佳实践，将服务拆分为读写两个独立服务，共享同一个Elasticsearch集群。这一反模式方案成功解决了性能问题，且三年多仅出现一次相关问题。作者强调，良好实践是启发式的，需理解其保护目的和成本，在特定情况下明智地使用反模式，而非盲目遵循。
Q&A
Allegro为何决定转型为微服务架构？
Allegro因单一的PHP应用程序和数据库面临开发瓶颈，决定转型为微服务架构以提高开发速度和可扩展性。
在微服务转型中，Allegro使用了哪些数据库？
Allegro在转型中从SQL切换到NoSQL数据库，如Cassandra和MongoDB。
微服务架构带来了哪些主要优势？
微服务架构提高了开发速度、可扩展性和技术灵活性。
Allegro在云迁移过程中遇到了哪些挑战？
云迁移带来了文化冲击和技术转型，尤其是从物理服务器到PaaS模型的转变。
如何选择合适的微服务规模？
选择微服务规模需务实，过大或过小都会导致维护和性能问题。
反模式在微服务中如何有效使用？
反模式在特定情况下可以有效解决问题，但需明智地运用，避免紧密耦合。
