微服务架构 SoundCloud的微服务是如何分层的

介绍

本文继续以SoundCloud公司为案例，通过一系列架构视图，展示SoundCloud微服务架构的分层组织方式。如果你阅读并理解了前面两篇文章的内容，那么就比较容易理解本文的内容，所有本文的分析会相对简单一点。

注，SoundCloud是一家德国网站，提供音乐分享社区服务，成长很快，Alexa世界排名已进入200位以内。

SoundCloud微服务分层架构

下图展示SoundCloud微服务分层架构：

图片来自附录1

分析：

SouldCloud采用经典的三层微服务架构，用户体验层->边界BFF层->后端微服务层

SoundCloud的BFF主要分为四类：

面向主站的Api-V2 BFF

面向移动端的Api-mobile BFF

面向嵌入页面场景的Api-embeded BFF

面向开放平台场景的Public API BFF

SoundCloud没有像Netflix那样的独立的网关Gateway层，它的BFF层融合了网关功能+服务聚合裁剪和适配功能

SoundCloud的微服务分层架构也是为了应对业务和技术挑战，不断演化出来的。关于其内部微服务的演进历程，以及BFF在演进中扮演的角色，可以参考ThoughtWorks上的文章BFF@SoundCloud[附录3]

下面是SoundCloud微服务的另一个架构视图，展示了一些额外细节，

图片来自附录2

分析：

SoundCloud的BFF层兼具网关作用，会横向调用一些跨横切面的服务，例如，限流，认证，安全和ip定位等。这些跨横切面的能力由网关统一处理以后，后面的微服务就不需要再调用。

SoundCloud对其微服务层又进一步做了一次细分：

基础服务层，SoundCloud最底层的领域服务，例如tracks/users/playlists/stats/images等。

增值服务层，在基础服务基础上再封装提供一些增值的服务，例如track-coordinator/timeline/creator-stats等。

下面是SoundCloud微服务的另外一个更全面的架构视图

图片来自附录1

结论

Netflix的微服务架构有独立的网关层，SoundCloud则没有独立网关层，它的网关和BFF层是融合在一起的。我认为这个和两家公司的业务体量和团队规模不同有关，Netflix业务体量更大也更复杂，需要独立的网关层实现架构上的关注分离，保障研发交付效率。SoundCloud则业务体量和团队规模相对小，暂时还没有分解那么细。将网关和BFF融合的做法，在国内很多公司也是这么实践的。

SoundCloud对其微服务还进行了一层细分，包括基础服务+增值服务，这个应该是架构师根据需要，额外定义的一种架构分层规范，有助于研发人员更清晰理解架构，并遵循架构规范开展研发。

Netflix/SoundCloud等大公司的微服务分层架构仅供参考，各家做法有差异，但是背后原理相同。架构师要理解其背后的分布式原理，然后灵活应用，不可拘泥照搬。

SoundCloud还给出微服务架构的一种更抽象的描述，如下图所示，微服务架构本质上可以理解成是一种分布式的企业操作系统

内核是一个企业的业务领域基础服务

第二层是BFF，将基础服务聚合裁剪适配，暴露面向不同用户体验的API

第三层是面向不同用户体验(无线\PC\开放平台等)的客户应用

最外层是使用这个企业操作系统的用户

图片来自附录1

附录

SoundCloud’s Toolbox for Microservices

https://www.slideshare.net/grandbora/soundclouds-toolbox-for-microservices

Microservices @ SoundCloud

https://www.slideshare.net/grandbora/microservices-soundcloud

BFF @ SoundCloud

https://www.thoughtworks.com/insights/blog/bff-soundcloud