主要观点：

• 2013 年起 Allegro 开始进行架构 overhaul，引入 SOA、Agile、TDD 等理念，采用 Java 进行后端开发，开启 Project Rubicon 项目，全面转向微服务架构。
• 项目执行过程历经 10 多年，涵盖众多方面，如创建共同架构、常见库，招聘 Java 开发者，开发内部工具，迁移到不同平台等，是一项巨大投资和赌博。
• 分享了微服务实施过程中的多个闪回事件，包括选择 NoSQL 数据库、迁移到云平台、监控方式转变、使用多种编程语言、运用反模式、服务规模考量、服务网格和公共库的发展以及持续学习等。
• 强调微服务带来的好处及成本，通过实践避免了许多陷阱，改变了公司的思维方式和工作方式，虽然工具仍有改进空间，但已取得显著成效，且技术在不断变化，知识转移和持续学习仍很重要。

关键信息：

• 2013 年 Allegro 代码库为单体 PHP 应用，存在发展瓶颈，如代码库大、每日 PR 多、数据库性能挑战等。
• Project Rubicon 项目范围广，有自己的章程，包括工作方式、学习价值等方面，成功标准包括去除单体、有 Java 专家等。
• 执行过程中发生了众多事件，如创建共同架构、常见库，开发 Hermes 消息代理，进行技术选型讨论等，创建了大量生产服务和工具。
• 闪回事件涵盖 NoSQL 数据库转换、云平台迁移、监控方式改变、多种编程语言使用、反模式运用、服务规模考量等方面的经验和教训。
• 目前正面临技术更新、系统积累问题、人员变动等挑战，但微服务架构带来的便利仍显著，且持续学习和知识转移至关重要。

重要细节：

• 2013 年开始创建新平台作为 SOA 的试点，随后决定切换到 Java 进行后端开发，命名为 Project Rubicon。
• 2014 年开始有各种自助工具、自动化工具，开发 Hermes 消息 broker，进行战略 DDD 培训等。
• 选择数据库时从优先使用 Cassandra 到认识到需要多语言持久化，如使用 MongoDB 等。
• 从 IaaS 到 PaaS 迁移过程中，对不能通过 ssh 访问服务器感到文化冲击，后来构建了抽象层。
• 监控最初由单一团队集中处理，后来允许开发团队自行配置。
• 从一开始用 Java 到后来尝试多种 JVM 语言，如 Scala、Kotlin 等，还使用了 C#、Go、Python 等语言。
• 对于服务拆分，有时会运用反模式解决性能问题，同时要权衡利弊。
• 关于服务规模，大多数服务不是太小也不是太大，避免纳米服务陷阱和服务过度增长。
• 最近迁移到服务网格，减少了公共库的作用，同时仍有部分功能需要代码实现。
• 公司在转型过程中重视学习和发展，投资培训和会议，举办开发者活动等。
• 见证了一个服务从创建到被替换的完整生命周期。