网易面试：亿级用户，如何做微服务底层架构？
尼恩说在前面
在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业网易、美团、字节、如阿里、滴滴、极兔、有赞、希音、百度、美团的面试资格，遇到很多很重要的面试题：
微服务改造，你是怎么做的？
亿级用户，如何做服务治理？
亿级用户，如何做微服务底层架构
你们公司的微服务底层基础设施，是如何架构的？
最近有小伙伴在网易，又遇到了相关的面试题。小伙伴懵了， 当然，面试也就挂了。
这里，尼恩找到一个漂亮的生产级案例：《爱奇艺微服务改造》。借助这个案例，给大家做一下系统化、体系化的微服务底层架构 梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。
也一并把这个题目以及参考答案，收入咱们的 《尼恩Java面试宝典PDF》V146版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。
特别说明：《爱奇艺微服务改造》 这是一个非常 牛逼的工业级、生产级微服务改造案例。
这个案例，并不是尼恩的原创，仅仅是尼恩在备课的过程中，在互联网查找资料的时候，收集起来的，供大家学习和交流使用。
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】获取
文章目录
-
- 尼恩说在前面
- 一、爱奇艺微服务改造背景
- 二、爱奇艺微服务标准架构
- 三、标准架构生态建设
-
- 开源SDK定制
- 注册中心演进
- Nacos高可用部署
- 注册中心平滑迁移方案
- 监控体系建设
- 指标监控
- 链路追踪
- 熔断限流方案
- API网关
- QDAS
- 混沌工程
- 四、未来规划
- 说在最后：有问题可以找老架构取经
- 尼恩技术圣经系列PDF
一、爱奇艺微服务改造背景
作者：爱奇艺中间件团队
爱奇艺技术产品团队为亿万用户提供卓越的视频服务，为了顺应业务的迅猛发展和创新需求，并支持巨量的用户请求，众多团队都自发对其业务系统进行了微服务架构的升级。
在微服务化的过程中，各业务团队根据自身需要选择了不同的开源框架，如Apache Dubbo/Spring Cloud等，此外也存在一些自研性质的框架；此外，为了满足微服务应用的监控需求，一些团队还独立运维了监控系统等基础设施。
随着实践的深入，一些问题逐渐开始暴露，这其中包括：
- 部分基础设施出现重复建设，导致资源浪费且稳定性难以保证；
- 由于技术架构和SDK的不统一，最佳实践在团队间难以迅速推广；
- 技术架构的不统一使得东西向流量中大量引入了业务自行维护的网关，导致链路加长，影响排障效率和响应延时。
为解决上述问题，爱奇艺中间件团队充分了解了业务在微服务实践中的需求和问题，并推出了爱奇艺的微服务标准架构。
在构建标准架构的过程中，我们主要遵循了以下原则：
1、架构统一：在同一个技术领域中，往往有多种技术实现，但过多的技术框架会导致维护成本过高，缺乏专人支持等问题。在微服务标准架构的选型过程中，我们综合了各开源项目的实际情况和业界的主流技术方案，将各个领域中的技术选型进行了统一，每个领域的技术选型原则上均不超过1种；
通过统一技术选型，我们可以降低技术债务，提高开发人员的技术熟练度，从而更高效地推动业务发展。
2、可扩展：微服务标准架构中有不少开发SDK的选型，为了满足各个开发团队不同的业务需求，需要保证各个SDK的可扩展性，如果开源版本无法满足内部需求的，爱奇艺中间件团队都会维护统一化的内部定制版本；
通过提供可扩展的SDK，我们可以更好地支持开发团队的创新和业务拓展。同时，统一的内部定制版本可以确保各个团队在开发过程中遵循相同的技术规范，提高系统的稳定性和可维护性。
3、高可用：构建标准架构的目标之一是将各团队负责的基础设施（例如注册中心、监控系统等）逐步整合到内部公共平台。对相关平台的技术架构审查和可用性维护是我们的重要任务之一。此外，我们还建立了服务成熟度体系SMMI，定期对核心系统及基础服务进行成熟度评估；
通过整合基础设施并建立服务成熟度体系，我们可以更好地监督和管理系统的健康状况，及时发现并解决潜在问题。
4、技术演进：开源软件有其生命周期，需要充分考虑各软件的社区维护状况。例如，在熔断技术选型上，我们选择在标准架构中推广Sentinel，而非已停止维护的Hystrix。此外，标准架构并非固定不变的体系，对于新技术的引入，我们提供了标准化的流程，确保技术体系能够持续迭代；
通过关注开源软件的社区维护状况并引入新技术，我们可以确保标准架构始终保持与时代同步。同时，标准化的技术引入流程有助于规范开发过程，提高系统的可维护性和稳定性。
5、内部开源：在标准架构建设过程中，爱奇艺内部实行内部开源协作模式。除了基础服务部门外，还鼓励业务团队参与这些基础服务的维护工作，共同打造既满足业务需求，又具有一定业界领先水平的微服务技术体系，进一步推动相关标准架构的推广和完善。
通过鼓励业务团队参与基础服务的维护工作，我们可以更好地整合内部资源，提高开发效率。同时，这种协作模式有助于培养技术人才，提升团队的技术实力。
在微服务架构的实践过程中，团队们面临了诸多挑战，包括基础设施的重复建设、技术架构的不统一、链路加长等问题。为了解决这些问题，爱奇艺中间件团队推出了微服务标准架构，并在构建过程中遵循了架构统一、可扩展、高可用、技术演进和内部开源等原则。
通过这一系列举措，爱奇艺旨在打造一个既符合业务需求，又具有业界领先度的微服务技术体系，以推动业务的快速发展。
二、爱奇艺微服务标准架构
下图展示了爱奇艺微服务标准架构的全貌：
注意：请点击图像以查看清晰的视图！
标准架构主要包括如下主要内容：
1、统一的微服务开发SDK：核心开发框架Dubbo/Spring Cloud；熔断限流框架Sentinel等；
2、统一的微服务基础设施，包括：
- 注册中心：Nacos/consul；
- 服务网关：基于kong进行二次开发的网关平台，提供鉴权、限流等功能；
- 配置中心：基于携程Apollo进行二次开发的平台
- 指标监控：prometheus集群托管服务；
- 链路监控：全链路平台（基于skywalking进行定制开发）；
- 混沌工程：在ChaosBlade基础上进行二次研发，提供各类故障演练功能。
3、统一的微服务平台：QDAS（QIYI Distributed Application Service，爱奇艺分布式应用服务），提供微服务应用生命周期管理、服务治理、服务市场等功能。
总的来说，标准架构为微服务的开发、部署和管理提供了一整套完整的解决方案，涵盖了开发框架、基础设施和服务平台等各个方面，旨在提高开发效率，降低运维成本，保证微服务架构的高可用性和高稳定性。
通过统一的微服务开发SDK，可以简化开发流程，提高开发效率；统一的微服务基础设施，可以降低运维成本，提高系统稳定性；统一的微服务平台，可以提供全方位的服务治理和应用管理功能，使得微服务的开发、部署和管理变得更加便捷和高效。
三、标准架构生态建设
接下来，我们将从微服务SDK、注册中心、监控体系、熔断限流、API网关、微服务平台等几个微服务标准架构的关键点进行详细的介绍。
开源SDK定制
根据各个业务团队的需求，爱奇艺中间件团队主要对Dubbo SDK做了以下几方面的扩展：
- 基础设施的适配：包括注册中心、监控系统、内部的容器平台等等；
- 可用性增强：包括非健康实例隔离、以及区域就近路由的机制；
- 安全性增强：支持了服务间调用的认证机制；
- 序列化：增添了对protobuf序列化方式的支持。
我们还优化了SDK的性能，提高了服务的并发处理能力，并且增强了日志记录功能，以便于快速定位问题。
同时，通过引入负载均衡策略，我们确保了服务的稳定性和可靠性。
这些扩展不仅提升了SDK的易用性和安全性，而且使得爱奇艺的微服务架构更加健壮和高效。
注册中心演进
在微服务架构中，注册中心是至关重要的基础设置之一。
在爱奇艺内部，注册中心的选型并不一致，之前在线上运行的注册中心包括ZooKeeper、eureka、consul等。
然而，ZooKeeper、eureka等并不是目前业界最佳的微服务注册中心选型。
以Zookeeper为例，其主要缺陷包括：
- 无法进行横向扩展；
- 作为一个一致性的系统，在网络分区会产生不可用。
在对业界的各种方案进行调研后，我们决定采用Nacos作为我们下一代的微服务注册中心。
如下图所示，选择Nacos的主要原因包括：
- 高性能，能够进行横向扩展；
- 适用于传统服务架构，同时也适用于云原生环境，包括支持与Istio控制面对接；
- 提供了Nacos-Sync组件，可以与其他注册中心进行数据同步，使得注册中心的迁移变得简单。
注意：请点击图像以查看清晰的视图！
Nacos不仅具有高性能和可扩展性，还提供了丰富的功能，如动态配置管理、服务发现和健康监测等。这使得Nacos成为爱奇艺微服务架构的理想选择。
通过使用Nacos，我们能够更好地管理和服务实例，提高系统的可用性和稳定性。同时，Nacos的灵活性和可扩展性也为我们的微服务架构提供了更大的发展空间。
Nacos高可用部署
在部署Nacos服务时，我们充分考虑了服务部署架构方面的高可用性。
目前我们的Nacos服务是一个大集群，实例分布在多个不同的可用区中，在每个可用区内部，我们会申请不同的VIP，最终的内网域名是绑定在这些VIP上。
另外其底层所使用的MySQL也采用了多机房部署。这样的架构可以避免单个Nacos实例或者单机房故障造成整个Nacos服务的不可用。
以下是一些可能的故障场景的模拟：
- 单个Nacos实例故障：利用Load Balancer集群提供的健康检查能力自动从VIP中摘除；
- 某个VIP集群故障：利用客户端重试机制解决；
- 单个AZ故障：利用客户端重试机制解决；
- MySQL集群故障：MySQL与注册发现过程无关，不受影响；
- 整个Nacos服务故障：客户端兜底机制，如服务实例缓存等。
注意：请点击图像以查看清晰的视图！
通过引入负载均衡器和客户端重试机制，确保了在单个实例或集群出现故障时，Nacos服务仍然能够正常运行。
同时，对MySQL数据库实施了多机房部署，进一步提高了整个Nacos服务的可靠性。
这些措施有效地保障了Nacos服务的连续性和稳定性。
注册中心平滑迁移方案
接下来将简单介绍一下如何使用Nacos-Sync进行注册中心的平滑迁移。
- 首先要部署一个Nacos-Sync服务，从旧的注册中心向Nacos同步数据。Nacos-Sync支持集群化部署，部署多个实例时，其向新注册中心的写入时幂等的，并且它原生支持Dubbo的注册数据格式；
- 检查数据无误后，首先升级Consumer端，改为从Nacos注册中心进行发现。这时的服务发现的数据均是由Nacos-Sync从旧的注册中心同步过来的；
- 再升级Provider端，改为向Nacos进行服务注册；
- 下线Nacos-Sync服务及旧的注册中心，整个迁移流程就结束了。
注意：请点击图像以查看清晰的视图！
以上方案的主要优点包括：
- 服务提供方和消费方的升级完全独立，可以自行进行；
- 迁移涉及的应用仅需升级一次。
通过使用Nacos-Sync进行注册中心迁移，能够确保整个迁移过程的平滑性和稳定性。Nacos-Sync不仅支持集群化部署，还具备数据同步的幂等性，从而降低了迁移过程中出现数据不一致的风险。此外，Nacos-Sync原生支持Dubbo的注册数据格式，使得迁移过程更加便捷。在迁移过程中，服务提供方和消费方的升级相互独立，可以根据实际情况灵活进行。而且，迁移涉及的应用只需升级一次，大大降低了迁移工作的复杂度和风险。
监控体系建设
服务监控是所有业务团队都极为关注的主题。完整的微服务监控体系一般需要有以下3个方面组成：
- 指标监控：涵盖QPS/响应延时/错误率等黄金指标、业务的自定义指标、JAVA应用的JVM指标，以及基础环境相关指标，如CPU、内存利用率等；
- 日志监控：例如错误日志数量；可以利用AI技术对日志模式进行统计分析等；
- 链路监控：由于微服务调用关系的复杂性，调用链追踪显得尤为重要，它可以帮助业务人员更好地分析应用间的依赖关系，并能够监控各个调用关系上的关键指标。
注意：请点击图像以查看清晰的视图！
构建一个完善的监控体系对于保障微服务架构的稳定运行至关重要。通过指标监控，我们可以实时了解服务的运行状态，发现并解决问题。
日志监控则可以帮助我们分析错误产生的原因，为问题的定位和解决提供有力支持。而链路监控则有助于我们了解各个服务之间的调用关系，分析应用间的依赖，从而更好地监控整个微服务架构的运行状况。
在监控体系的建设过程中，我们不仅需要关注监控的全面性和准确性，还需要关注监控数据的实时性和可分析性。通过引入先进的监控技术和工具，如AI技术、大数据分析等，我们可以提高监控数据的实时性和可分析性，从而更好地支持微服务架构的运行和维护。
在未来的工作中，我们将继续优化和完善监控体系，以提高微服务架构的运行效率和稳定性。
指标监控
在指标监控方面，我们基于Prometheus构建了一套相对完善的监控和告警标准化方案。
在这个过程中，我们需要解决以下几个问题：
- 首先是指标计算问题。为了减少侵入性，我们在SkyWalking agent的基础上进行了二次开发，能够自动拦截Spring MVC、Dubbo等主流框架的调用，统计调用次数、处理耗时和是否出错等数据；
- 其次是指标采集的问题，Prometheus是采用拉模式采集指标的，对于微服务场景一般是利用Prometheus的服务发现机制。Prometheus默认集成了consul、k8s等服务发现方式，不过并未对Nacos注册中心直接提供支持，我们在开源的Nacos adapter的基础上进行了改造，使得Prometheus能够从Nacos中发现要采集的应用实例信息。
指标查看主要采用基于SkyWalking UI和Grafana开发的界面。我们提供了一套通用的配置模板，业务可以根据需要自行扩展。
在告警方面，我们将告警策略设置在Prometheus中，具体的告警由Alert-Manager通过Adapter发送给内部的监控告警平台。
监控dashboard查看、告警策略设置、订阅的入口统一设置在我们内部的全链路监控平台上，用户可以在该平台上查看进行相应的操作。
注意：请点击图像以查看清晰的视图！
下图展示了服务监控界面：
注意：请点击图像以查看清晰的视图！
通过基于Prometheus的指标监控方案，可以实时了解微服务的运行状态，为业务提供可靠的数据支持。
在解决指标计算和采集问题的过程中，对SkyWalking agent和Nacos adapter进行了二次开发，提高了监控数据的准确性和实时性。
同时，通过统一的监控平台，用户可以方便地查看监控数据、设置告警策略和订阅告警通知。
链路追踪
链路追踪的基本原理与Google关于Dapper的论文相同，应用程序通过植入agent产生调用链数据，通过日志收集或网络直接上报的方式统一汇总至Kafka，然后通过我们的实时分析程序进行分析。
分析结果大致可分为三类：原始的调用链数据我们会使用ES+HBase进行存储，调用关系上的实时监控数据我们采用时序数据库Druid进行存储，拓扑关系则采用图数据存储。
注意：请点击图像以查看清晰的视图！
链路追踪主要提供了一下功能：
- 调用依赖关系分析：提供了服务间依赖和接口间依赖的多个层次粒度，支持MySQL、Redis等各类中间件，为开发人员提供各种上下游依赖的直观展示；
- 服务间调用关系指标：提供QPS/响应延时错误率等核心指标监控，且能在一个调用关系上同时提供客户端及服务端两个视角的监控值，便于进行问题定位；
- 程序异常分析：在调用链数据中心记录异常类型及堆栈信息并进行分析，支持展示某个应用的程序异常种类及每分钟发生次数等；
- 日志关联：将调用链与业务日志进行关联查询，便于获取程序运行的详细信息。
链路追踪在微服务架构中起着至关重要的作用，它可以帮助我们更好地了解服务之间的调用关系，分析依赖关系，从而为问题的定位和解决提供有力支持。通过实时分析程序对调用链数据进行处理和分析，我们可以实时掌握微服务的运行状况，发现并解决问题。
熔断限流方案
由于微服务架构的特点，上下游依赖和网络通信都比较多，这些因素都会对应用本身产生一定的风险，比如上游系统的突发流量或者热点参数；下游系统服务不可用、延时增大、错误率升高等等。
如果缺少对自身系统的保护，有可能产生雪崩的效应。
为了应对这些场景，我们主要引入了Sentinel框架进行解决。
Sentinel的核心原理是用户可以定义各类资源（资源可以是本地的一个接口，或者远程的某个依赖），并在资源上设置各种规则（比如限流规则），在访问某个资源时，Sentinel组件会检查这些规则是否满足，在不满足的情况下会抛出特定的异常。用户可以通过捕捉这些异常实现快速失败或者降级等业务逻辑。
Sentinel还提供了一个控制台，可以用来管理规则的参数设置以及查看实时监控等。
注意：请点击图像以查看清晰的视图！
为了适应爱奇艺各个业务团队的需求，我们对sentinel框架做了一定的扩展，下面的例子即是我们实现的复杂参数限流功能。
Sentinel框架本身就自带热点参数限流的功能，不过仅支持一些简单类型的参数（如String、int等）。
在有些情况下，限流的场景可能比较复杂，比如下图中，可能要根据第一个参数的id属性进行限流，这种场景原生的sentinel并未提供支持。针对这种情况，我们提供了一个抽象接口，允许用户通过自己的实现从参数中提取出需要限流的资源。
注意：请点击图像以查看清晰的视图！
为了实现规则参数的动态下发，我们将sentinel与内部的配置中心进行了适配。在sentinel dashboard上进行的参数改动，最后都会保存至配置中心，业务系统通过引入配置中心的SDK，即可实现在不重启应用的前提下进行参数的动态调整。
注意：请点击图像以查看清晰的视图！
在QDAS管理平台上，我们还利用K8s技术提供了Sentinel Dashboard的托管功能，节省了各业务团队在这方面的部署和维护成本。
注意：请点击图像以查看清晰的视图！
通过引入Sentinel框架，可以有效地应对微服务架构中可能出现的各种风险，保障系统的稳定运行。通过定义资源和设置规则，我们可以实现对访问量的控制，防止系统过载。同时，通过捕捉异常和降级处理，我们可以确保在系统压力过大时，仍能提供基本的服务。
API网关
爱奇艺 API 网关底层基于开源项目 Kong 实现，旨在为开发者提供稳定、便捷、高性能、可扩展的服务入口功能，一站式管理API 配置和生命周期，对微服务治理具有重要意义。
在 API 网关控制流架构设计中，微服务平台 API 网关模块通过内部系统集成及服务化实现，为开发者提供全部所需入口配置及管理功能，且无需代码侵入、工单申请等人工干涉，实现API 创建即可用。API 网关支持认证、限流、访问控制等通用功能。
结构如下图所示：
注意：请点击图像以查看清晰的视图！
API 网关在微服务架构中发挥着重要作用，它为开发者提供了一个统一的接口管理平台，使得开发者能够更方便地管理和维护 API。通过集成开源项目 Kong，我们实现了 API 网关的高性能、可扩展性和稳定性，为爱奇艺微服务平台提供了强大的支持。
QDAS
在完善的微服务架构中，微服务治理平台至关重要。
QDAS 是一个以应用为核心的一站式平台，通过功能插件的方式，为微服务应用的开发、部署、运维等各个环节提供全生命周期的支持，同时兼容 Dubbo/Spring Cloud 传统微服务框架和 Istio 服务网格架构。
注意：请点击图像以查看清晰的视图！
QDAS平台主要支持的功能包括：
1、应用基本信息维护；
2、传统微服务治理；
- 实例列表及与Nacos注册中心集成的实例上下线管理；
- Grafana核心指标监控大盘；
- Sentinel dashboard托管；
- 基于Sentinel的接口鉴权和流量配额管理（开发中）。
3、应用生命周期管理
支持在各类平台（容器/虚机）上的应用部署和版本升级功能；
4、服务市场
接口契约管理：包括基于Swagger UI的接口描述查看等。
QDAS 平台在微服务架构中发挥着重要作用，它为开发者提供了一个统一的应用管理和治理平台，使得开发者能够更方便地管理和维护微服务应用。
通过集成各类功能插件，实现了 QDAS 平台的高性能、可扩展性和稳定性，为爱奇艺微服务平台提供了强大的支持。
混沌工程
Netflix最早系统化地提出了混沌工程的概念，旨在尽早识别风险，针对性地加强薄弱环节。
我们同样重视故障演练，通过内部工具和外部开源项目，逐步发展出自己的故障注入平台——小鹿乱撞。
利用该平台，用户可以制定演练方案进行演练，以检验服务的健壮性。
注意：请点击图像以查看清晰的视图！
目前，小鹿乱撞平台已支持对服务器、容器（Docker）、数据库、中间件、网络设备、K8s 集群等进行故障注入，并在演练过程中实时展示相关监控、日志和报警等信息，演练结束后自动生成演练报告。
另外，借助平台定时演练的能力，用户可以方便的实现周期性演练的效果。
混沌工程在提高系统稳定性和可靠性方面具有重要意义。
通过故障演练和注入，我们可以主动发现系统的潜在风险，并有针对性地进行优化和改进。
借助小鹿乱撞平台，我们实现了故障演练的自动化、智能化和周期化，为爱奇艺微服务平台的稳定运行提供了有力保障。
四、未来规划
对于微服务标准架构的未来规划，大概分为以下几方面的工作：
- 微服务技术趋势：云原生和服务网格（Service Mesh）已经成为微服务技术发展的趋势。我们将重点关注如何引入服务网格技术，并为各业务提供顺畅的过渡解决方案；
- 服务治理：我们将继续扩展 QDAS 平台的功能，力求打造一个既适用于服务网格又适用于传统微服务的统一控制面；
- 开发者支持：未来计划推出项目脚手架和在线调试等服务，以便开发人员能更便捷地进行项目开发和线上问题排查。
在微服务架构的未来发展中，我们将密切关注技术趋势，不断优化和改进现有的技术体系。通过引入服务网格技术，我们将进一步提升系统的稳定性和可扩展性，为业务的发展提供有力支持。
同时，我们还将持续完善 QDAS 平台，使其成为一个全面、高效的服务治理工具，以满足各种微服务场景的需求。
此外，通过推出项目脚手架和在线调试等服务，我们将为开发人员创造一个更加友好、便捷的开发环境，提高开发效率。
说在最后：有问题可以找老架构取经
高并发写相关的面试题，是非常常见的面试题。
以上的内容，如果大家能对答如流，如数家珍，基本上 面试官会被你 震惊到、吸引到。
最终，让面试官爱到 “不能自已、口水直流”。offer， 也就来了。
在面试之前，建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》，里边有大量的大厂真题、面试难题、架构难题。很多小伙伴刷完后， 吊打面试官， 大厂横着走。
在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。
另外，如果没有面试机会，可以找尼恩来帮扶、领路。尼恩指导了大量的小伙伴上岸，前段时间帮助一个40岁+就业困难小伙伴，拿到了一个年薪100W的offer。
尼恩技术圣经系列PDF
- 《NIO圣经：一次穿透NIO、Selector、Epoll底层原理》
- 《Docker圣经：大白话说Docker底层原理，6W字实现Docker自由》
- 《K8S学习圣经：大白话说K8S底层原理，14W字实现K8S自由》
- 《SpringCloud Alibaba 学习圣经，10万字实现SpringCloud 自由》
- 《大数据HBase学习圣经：一本书实现HBase学习自由》
- 《大数据Flink学习圣经：一本书实现大数据Flink自由》
- 《响应式圣经：10W字，实现Spring响应式编程自由》
- 《Go学习圣经：Go语言实现高并发CRUD业务开发》
……完整版尼恩技术圣经PDF集群，请找尼恩领取
《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF，请到下面公号【技术自由圈】取↓↓↓