流媒体平台SoundCloud在2014年从SOA切换到微服务架构以后，几年经验证明其软件开发交付速度和生产力都有所提高。

遥想当初2014年，流行音乐和播客的流媒体平台SoundCloud变成自己成功的受害者。当时，用户每分钟都会上传12小时的音乐，每天有成千上万的游客从平台上消费各种音频。SoundCloud不仅面临着软件的扩展性问题，而且还面临新功能交付实施的效率低下。

这些问题的根源可以追溯到90年代中期，当时面向服务的架构（SOA） - 一种让各种应用程序组件在网络上共享服务的架构风格 - 成为编程领域的热门趋势。这种设计风格是基于网络服务，从而使跨部门和跨公司的技术集成变成可能。

然而，自从鼎盛时期以来的数十年里，对这种设计风格的批评却不断上升，SOA的使用率也开始下降 - 其主要缺点是开销成本可能很高并且性能低下。由此，程序员越来越多地将 “微服务” 作为替代的架构方案。其思路是：将服务分解成更小的组件，将应用程序拆分成更容易分发和复制的组件。关键的是，微服务架构能够实现更快速的持续交付和部署，因为较小的组件能够更容易、更频繁地更新。

新时代的新架构

SoundCloud于2014年开始转向微服务，其开发人员在这里精心记录了如何将单体架构转换为新架构的劳动密集型过程。

“当时，我们公司的前端团队致力于提供面向用户的功能，而后端团队则注重提供数据和API，”SoundCloud的高级首席工程师Sean Treadway说。“前端团队可能会等待后端团队一个月,后端团队拖后腿了，主要开销花在对新功能的支持和实施上，这会增加很多工作管理量并拖延最后的交付进度。”

Treadway说，转向微服务架构导致了端到端交付团队的建立。除此之外，“他还介绍了一种类似于Netflix发布的API网关方法，称为BFFs [Backends for Frontends]，”他解释说。“提供为每个前端桌面网站、移动应用程序或嵌入式小部件的API​​网关，工程师能够实现针对每个应用程序量身定制的数据API，避免了多个团队之间的无需协调。”

Treadway表示，这种切换已被证明是该平台的成功，“特别是对于基本功能和API网关的更新。”

Treadway说：微服务显着增加了运营的复杂性，拥有DevOps思维能够让一个小团队管理好复杂性。

SoundCloud工程方法是“根植于敏捷方法论”，他指出，微服务能很好地融入了DevOps思想。 “我们的文化和人员配备团队既具备开发和运营技能，又能提供更高质量的服务和更短的事件响应时间，”他说。

重组的成本和挑战

虽然实践已经证明切换到微服务是适用SoundCloud的，但这一过程本身并非易事。

“我们预计到了转向微服务架构需要通用的约定和工具，”Treadway说道，“但我们低估了在建立新的或维护现有服务时需要花费多少努力来保持工程师的生产力。我们还了解到，运营服务还需要满足一系列非功能性需求。“

一致性和安全性是微服务的额外挑战。Treadway表示，网络API很容易编写，但很难保持一致。

“我们的每个服务将API映射到HTTP的方式都略有不同，从而产生了处理这些细微差别的API客户端库，，”他解释说。“链接到共享的API客户端库却导致了依赖的传递冲突，这打破了独立服务部署的目的。”

尽管如此，结果证明这些额外的工作还是值得的，他说：“工程师在通用工具诸如监视、日志记录、跟踪、部署、配置验证和连接池等产品化掌控方面的能力提高了，工作效率显着提高。”

那么，Treadway会推荐大家都切换到微服务吗？不，他认为微服务在合适的情况下才能得到回报。“我认为，当一小队工程师维护少量服务时，SOA服务架构是最有效的，”他建议道。