SoundCloud：我们最终是如何使用微服务的？很多的技术文章着重介绍的都是项目后总结出的最佳实践，本文从另外的角度，介绍项目中解决问题的整个探索过程，详细讲述了在最终使用微服务架构之前所做的种种分析和尝试，这对于正在尝试解决问题的技术人员来说有很大的启示作用。AD：51CTO技术沙龙|赋予APP不同凡响的交互和体验>>微服务是近期的热点。当我在SoundCloud工作时，负责从一个巨大的RubyonRails应用程序里迁移到众多的微服务上。我已经多次讲述这个过程的技术问题了，在演讲里，也在SoundCloud的工程师博客里写了一系列文章。这些是工程师们最感兴趣的话题，但是最近我才意识到从来没有向大家解释过我们最终使用微服务之前做了什么尝试。我很抱歉可能会让一些技术人员失望，但是我们迁移到微服务更多的是跟生产力相关，而不是单纯的技术因素。下文会详细解释。注意：本文有很多修正之处，为了使其更容易理解，将相当混乱的一系列事件简化成了线性的时间链。不过，我相信这很好得展示了在SoundCloud最初几年所做的工作。Next项目当我最初加入公司的时候，手头最重要的项目内部称之为v2。该项目对我们的网站做彻底的改版，发布时的商标名称为TheNextSoundCloud。一开始我加入了后端团队，App团队。我们负责巨大的RubyonRails应用程序。那时候还不称其为遗留系统，而称之为mothership。App团队负责Rails应用相关的所有事情，包括旧的用户接口。Next是一个单页面的JavaScriptweb应用程序，我们遵照当时的标准实践，将其构建为公开API的常规客户端，用Railsmonolith实现的。App和Web这两个团队是完全隔离的--甚至在Berlin距离挺远的不同的大厦办公。我们几乎只在所有人都参加的大会上才能看到彼此，主要的沟通工具是问题跟踪系统和IRC。如果你问任何一个团队的任何人我们的开发流程时如何工作的，他们可能会这么回答：1.有人想到了某个功能，随后写了很多描述，并且画了些模拟图。2.设计师优化了用户体验。3.编写代码。4.一些测试之后，将应用部署。但有时候这个过程会遇到一些障碍。工程师和设计师都抱怨他们加班过多，但同时产品经理和合作伙伴则抱怨他们永远无法按时得到想要的东西。作为一个小型消费者企业，我们非常需要能够确保吸引尽可能多的合作伙伴(就是那些Apple和Google在发布产品时在一页PPT里列出的合作伙伴)，因为这些意味着免费的宣传和增长。我们也需要在圣诞节前发布Next的内测版本，否则连续的假日就会将我们的所有计划推延到新...
