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