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

介绍

在前一篇BFF和网关是如何演化出来的文章中，我向大家解释了BFF和网关是什么，在微服务架构体系中各承担什么职责，以及它们是如何演化出来的。在上一篇Netflix的微服务是如何分层的一文中，我以Netflix公司为案例，分析了Netflix的微服务分层架构的组织方式和近期演进。

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

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

SoundCloud微服务分层架构

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

图片来自附录1

分析：

1. SouldCloud采用经典的三层微服务架构，用户体验层->边界BFF层->后端微服务层
2. SoundCloud的BFF主要分为四类：
   • 面向主站的Api-V2 BFF
   • 面向移动端的Api-mobile BFF
   • 面向嵌入页面场景的Api-embeded BFF
   • 面向开放平台场景的Public API BFF
3. SoundCloud没有像Netflix那样的独立的网关Gateway层，它的BFF层融合了网关功能+服务聚合裁剪和适配功能
4. SoundCloud的微服务分层架构也是为了应对业务和技术挑战，不断演化出来的。关于其内部微服务的演进历程，以及BFF在演进中扮演的角色，可以参考ThoughtWorks上的文章BFF@SoundCloud[附录3]

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

图片来自附录2

分析：

1. SoundCloud的BFF层兼具网关作用，会横向调用一些跨横切面的服务，例如，限流，认证，安全和ip定位等。这些跨横切面的能力由网关统一处理以后，后面的微服务就不需要再调用。
2. SoundCloud对其微服务层又进一步做了一次细分：

• 基础服务层，SoundCloud最底层的领域服务，例如tracks/users/playlists/stats/images等。
• 增值服务层，在基础服务基础上再封装提供一些增值的服务，例如track-coordinator/timeline/creator-stats等。

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

图片来自附录1

结论

1. Netflix的微服务架构有独立的网关层，SoundCloud则没有独立网关层，它的网关和BFF层是融合在一起的。我认为这个和两家公司的业务体量和团队规模不同有关。Netflix业务体量更大也更复杂，需要独立的网关层实现架构上的关注分离，保障研发交付效率。SoundCloud则业务体量和团队规模相对小，暂时还没有分解那么细。将网关和BFF融合的做法，在国内很多公司也是这么实践的。
2. SoundCloud对其微服务还进行了一层细分，包括基础服务+增值服务，这个应该是架构师根据需要，额外定义的一种架构分层规范，有助于研发人员更清晰理解架构，并遵循架构规范开展研发。
3. Netflix/SoundCloud等大公司的微服务分层架构仅供参考，各家做法有差异，但是背后原理相同。架构师要理解其背后的分布式原理，然后灵活应用，不可拘泥照搬。
4. SoundCloud还给出微服务架构的一种更抽象的描述，如下图所示，微服务架构本质上可以理解成是一种分布式的企业操作系统

• 内核是一个企业的业务领域基础服务
• 第二层是BFF，将基础服务聚合裁剪适配，暴露面向不同用户体验的API
• 第三层是面向不同用户体验(无线\PC\开放平台等)的客户应用
• 最外层是使用这个企业操作系统的用户

图片来自附录1

附录

1. SoundCloud’s Toolbox for Microservices
2. Microservices @ SoundCloud
3. BFF @ SoundCloud