微服务架构分层

Posted 2023-04-03 江南听雨声

一、微服务架构

名词概念

pod

• kubernetes集群最小调度或管理单元
• 用于封装容器

controller

• 用于控制pod的行为

label

给kubernetes资源对象打上标签,方便其它资源关联

label selector

指定关联的标签

service

• k8s中访问pod需要通过service
• service通过label selector找到打上对应标签的pod

DNS

• service和pod有时会需要通过名称来访问，而不是IP。这就需要用到dns

服务分层介绍

• LAMP 一台服务台安装 单服务架构
• LNMP 十台服务器安装 分层服务架构
• LNMP 使用容器进行分层，叫微服务架构

微服务架构组件之间的关系

使用kubernetes集群运行NMP或NMT

• 可以把Kubernetes集群看做是一个机房（IDC）
• 人访问N前面的service
• N访问T前面的service
• T访问M前面的service

内部用户访问

外部用户访问方法

• 可以通过添加边缘服务器将internet的客户访问转到k8s集群内部
  

控制器控制pod

service与pod关联

service通过label与pod关联

k8s集群内dns解析

下一篇：Service

微服务架构~Netflix的微服务是如何分层的

介绍

在之前一篇《》文章中，我向大家解释了BFF和网关Gateway是什么，在微服务架构体系中各承担什么职责，以及它们是如何演化出来的。

在本文和后续一篇文章中，我会分析Netflix(本文)和SoundCloud(下一篇)两家公司的微服务分层架构，帮助大家更深入理解BFF和网关Gateway在分布式微服务架构中的地位和作用，以及前沿互联网公司的微服务架构是如何分层组织的。希望对架构师理解和实践微服务架构有所帮助。

本文通过三个架构视图，展示Netflix微服务的分层架构。另外，2017~2018年间，Netflix对其微服务分层架构进行了升级，本文也会分析这次升级背后的架构驱动因素。

Netflix微服务分层架构(2017前)

下面两个架构图分别展示2017年前的Netflix微服务分层架构，两个图展示的总体分层架构是一致的，只是视角不同：

图片来自附录1

图片来自附录2

这个分层架构和《》一文中的V4架构基本类似，共分四个层次

1. 用户体验层，据说Netflix要支持超过一千种的不同设备体验，这个对Netflix技术团队特别是前端团队是一个巨大的挑战。

2. 网关路由层，Netflix使用Zuul网关作为服务路由层，同时兼具安全认证，监控，限流熔断等跨横切面功能。Zuul网关无状态以集群方式部署，前面依赖AWS ELB做负载均衡。

3. 边界API层，Netflix的裁剪聚合和适配层，也就是BFF层，将后端微服务，适配到不同的前端体验。在Netflix体系中，该层也称Edge Service Layer。

4. 微服务层，Netflix的核心领域服务，也称中间层(Middle Tier)服务。

网关+边界API层(BFF)+一些前端服务(如安全认证，Playback相关服务，DRM等)，统一由一个Netflix的前端团队负责，该团队也称边界工程(Edge Engineering)团队。

因为Netflix要应对处理的设备类型巨多，所以它们在边界层投入了大量工程技术资源，2017年前Netflix的边界API层(BFF)具有下面架构特点：

1. 整个边界API层(BFF)住在一个PaaS平台里头，称为Edge PaaS。

2. Edge PaaS本质上是一个动态脚本平台(Dyanmic Scripting Platform)，支持使用Groovy等JVM脚本语言，方便前端团队快速聚合裁剪后端微服务，并向前端设备暴露友好的API。之所以使用动态脚本语言Groovy，主要是考虑脚本语言对前端开发的友好性和生产率。

3. Edge PaaS里头同时预置后端微服务的Java客户端SDK，方便Groovy脚本调用后端服务，同时对客户端进行Hystrix埋点，保障对后台微服务调用的稳定性。

4. 由于前端需求变更比较频繁，所以Edge PaaS里头的脚本一般更新也比较频繁，前端团队可以按需每日更新，上传动态脚本即可。

5. 如果后端微服务有升级更新，一般需要升级Edge PaaS里头的客户端SDK，但是这个不是频繁操作，一般以固定周期（比如两周一个full release）发生，但是集成回归测试成本还是比较高的。

关于Netflix动态脚本平台的更多技术细节，可以参考其官方博客[附录4]。

Netflix微服务分层架构(2018)

上述的Edge PaaS其实是一个单块架构，随着Netflix的前端业务变得更加复杂，Edge PaaS也逐渐遭遇康威法则的约束，暴露出如下问题：

1. Edge PaaS里头同时耦合了前端聚合裁剪适配和后端API/SDK逻辑，当后端API有升级，一般需要升级Edge PaaS里头的客户端SDK，这种升级可能因不兼容和测试不充分，造成前端业务代码出问题。总体上前后端团队因升级、集成测试而造成的沟通协调成本非常大。

2. 所有面向用户体验的脚本逻辑都住在一套Edge PaaS里头，缺乏隔离性，当某个团队的脚本有bug，很容易负面影响到其它脚本。整个Edge PaaS也是一个大单点(Single Point of Failure)，严重脚本缺陷或者流量洪峰可致集群宕机。

3. 前端脚本有上传快和动态加载等优势，但是本地调试不方便，很多依赖的环境(Edge PaaS + API/SDK)难以在本地开发环境复制，造成开发反馈效率低下，出现问题排障困难。

为解决上述问题，Netflix边界工程团队对Edge PaaS的架构进行了调整，从单块一分为二，新的架构如下图所示：

图片来自附录3

主要变化是将边界API层分成两个子层次：

1. API聚合层，专注对后端微服务进行聚合，提供前端友好、抽象统一的API。API聚合层主要基于Java+后台服务的客户端SDK实现。API聚合层还按业务功能进行分集群部署(API Sharding)。

2. 设备适配层BFF，专注对API聚合层的服务进行裁剪和适配，提供给不同的用户体验展示。

设备聚合层采用对前端开发友好的Node.js框架，各个团队的服务可以独立部署在容器环境(Netflix的容器云Titus)中，使用容器机制进行隔离，避免相互干扰。Node.js+容器在Netflix称为NodeQuark平台。NodeQuark环境在开发人员本地可以搭建，方便开发本地调试。

经过拆分，当前Netflix演化出一个五层的微服务分层架构，前面三层(用户体验、网关路由和设备适配层)专注解决前端开发人员生产率的问题；后端两层(API聚合层和微服务层)专注解决领域抽象和运维监控稳定性问题。整个体系架构层次职责分明，初步解决了之前单块Edge PaaS的诸多问题，解放了生产率。

结论

1. Netflix采用经典的微服务分层架构，前端体验->网关路由->边界API层(BFF)->后端微服务。这个分层架构可供一线企业实践微服务参考。

2. 近年，为了进一步提升前端研发效率，Netflix又将边界API层(BFF)拆分成两个子层次，设备适配层BFF和API聚合层。总体演化出一个五层的微服务分层架构。增加新的层次对于Netflix这种体量的公司来说，有其架构合理性，但一般企业没必要细分5层，采用上述经典4层架构就OK了。BFF层也未必要采用脚本nodejs之类，java/.net等强类型语言开发也OK，毕竟一般企业没有Netflix那么多的用户设备要处理。

3. 从Netflix架构体系演变我们可以看出，为了提升研发效率，它的架构经过很多层细分，额外分层会带来一定的性能损失。但是对于前沿大体量的互联网公司，性能一般并不是其架构的首要考量，灵活性、可治理性和研发效率才是它们的首要考量。性能的损失一般可以通过云计算+水平扩展+缓存等手段来弥补。

4. 波波近期和极客时间合作，推出《微服务架构实践160讲》的视频课程，其中第三个模块(预计6月份推出)，会对Netflix的微服务网关Zuul的升级版Zuul2进行深度剖析，欢迎大家关注。

附录

1. Netflix Edge Engineering Open House
   https://www.slideshare.net/danieljacobson/netflix-edge-engineering-open-house-presentations-june-9-2016

2. The New Netflix API
   https://www.slideshare.net/KatharinaProbst/the-new-netflix-api

3. Edge Engineering Women in Tech Dinner
   https://www.slideshare.net/kcasella/edge-engineering-women-in-tech-dinner-20180322

4. The Netflix Dynamic Scripting Platform
   https://medium.com/netflix-techblog/the-netflix-dynamic-scripting-platform-78c1b18b2a74