爱奇艺微服务标准技术架构实践

为数以亿计的用户提供优质的视频服务的爱奇艺技术产品团队，为了适应业务的快速迭代和创新，并支撑海量的用户请求，很多团队都对各自的业务系统自发地进行了微服务架构的改造。

在微服务化的过程中，各业务团队根据自身需要选择了不同的开源框架，如Apache Dubbo/Spring Cloud等，此外也存在一些自研性质的框架；另外为了满足对微服务应用的监控等需求，不少团队还自行维护了监控系统等基础设施。

随着实践的深入，一些问题逐渐开始暴露，这其中包括：

下图展示了爱奇艺微服务标准架构的全貌：

以下将从微服务SDK、注册中心、监控体系、熔断限流、API网关、微服务平台等几个微服务标准架构的核心点做一些展开的介绍。

开源SDK定制

根据各个业务团队的需求，爱奇艺中间件团队主要对Dubbo SDK做了以下几方面的扩展：

1.基础设施的适配：包括注册中心、监控系统、内部的容器平台等等；

2.可用性增强：包括非健康实例隔离以及区域就近路由的机制；

3.安全性增强：支持了服务间调用的认证机制；

4.序列化：增加了对protobuf序列化方式的支持。

这部分内容已通过其他的公众号文章进行了详细的介绍，这里不再展开，有兴趣的读者可以参考Apache Dubbo的爱奇艺之旅。

注册中心演进

注册中心在微服务应用中是最重要的基础设施之一，原先在爱奇艺内部，注册中心的选型并不统一，之前在线上运行的注册中心有ZooKeeper、eureka、consul等。事实上，ZooKeeper、eureka等并不是当前业界中微服务注册中心的最佳选型，以Zookeeper为例，其主要缺点包括：

1.无法横向扩展；

2.作为一个一致性的系统，在网络分区会产生不可用。

在调研了业界的各个方案后，我们选用了Nacos作为我们下一代的微服务注册中心。右下角是Nacos的整体介绍图，选用Nacos的主要原因是：

1.高性能，可以横向扩展；

2.既适用于传统为服务架构，也能适用于云原生环境，包括支持与Istio控制面对接；

3.提供了Nacos-Sync组件，可与其他注册中心进行数据同步，也使注册中心的迁移变得简便。

Nacos高可用部署

在部署Nacos服务时，我们充分考虑了服务部署架构方面的高可用性。目前我们的Nacos服务是一个大集群，实例分布在多个不同的可用区中，在每个可用区内部，我们会申请不同的VIP，最终的内网域名是绑定在这些VIP上。另外其底层所使用的MySQL也采用了多机房部署。这样的架构可以避免单个Nacos实例或者单机房故障造成整个Nacos服务的不可用。以下是一些可能的故障场景的模拟：

1.单个Nacos实例故障：利用Load Balancer集群提供的健康检查能力自动从VIP中摘除；

2.某个VIP集群故障：利用客户端重试机制解决；

3.单个AZ故障：利用客户端重试机制解决；

4.MySQL集群故障：MySQL与注册发现过程无关，不受影响；

5.整个Nacos服务故障：客户端兜底机制，如服务实例缓存等。

注册中心平滑迁移方案

接下来将简单介绍一下如何使用Nacos-Sync进行注册中心的平滑迁移。

1.首先要部署一个Nacos-Sync服务，从旧的注册中心向Nacos同步数据。Nacos-Sync支持集群化部署，部署多个实例时，其向新注册中心的写入时幂等的，并且它原生支持Dubbo的注册数据格式；

2.检查数据无误后，首先升级Consumer端，改为从Nacos注册中心进行发现。这时的服务发现的数据均是由Nacos-Sync从旧的注册中心同步过来的；

3.再升级Provider端，改为向Nacos进行服务注册；

4.下线Nacos-Sync服务及旧的注册中心，整个迁移流程就结束了。

以上方案的主要优点包括：

*服务提供方和消费方的升级完全独立，可以自行进行；

*迁移涉及的应用仅需升级一次。

监控体系建设

服务监控是所有业务团队都极为关注的主题。完整的微服务监控体系一般需要有以下3个方面组成：

1.指标监控：包括QPS/响应延时/错误率等黄金指标、业务的自定义指标、JAVA应用的JVM指标，此外还需要采集和基础环境的相关指标，包括CPU/内存利用率等；

2.日志监控：如错误日志的数量；也可以利用AI技术，对日志的模式进行统计分析等；

3.链路监控：由于微服务调用关系的复杂性，调用链追踪也是非常必要的，它可以帮助业务人员更好地分析应用间的依赖关系，并能够监控各个调用关系上的核心指标。

指标监控

指标监控方面，我们内部围绕着Prometheus建设了一套较为完整的监控和告警的标准化方案。这里面要解决几个问题：

首先是指标计算的问题，为了降低侵入性，我们在skywalking agent的基础上进行了二次开发，可以自动拦截Spring MVC/Dubbo等主流框架的调用，统计其调用次数、处理耗时、是否错误等等。

其次是指标采集的问题，Prometheus是采用拉模式采集指标的，对于微服务场景一般是利用Prometheus的服务发现机制。Prometheus默认集成了consul、k8s等服务发现方式，不过并未对Nacos注册中心直接提供支持，我们在开源的Nacos adapter的基础上进行了改造，使得Prometheus能够从Nacos中发现要采集的应用实例信息。

指标查看主要采用了基于skywalking UI开发界面及grafana，我们提供了一套通用化的配置模板，业务也可以根据需要自行扩展。

告警方面，我们将告警策略设置在Prometheus中，具体的告警会由alert-manager通过adapter发送给内部的监控告警平台。

监控dashboard查看、告警策略设置、订阅的入口统一设置在我们内部的全链路监控平台上，用户可以在该平台上查看进行相应的操作。

下图展示了服务监控界面：

链路追踪

链路追踪的基本原理也和google关于Dapper的论文一致，应用程序通过埋点的agent产生调用链数据，通过日志采集或者网络直接上报的方式统一汇总至kafka，通过我们的实时分析程序进行分析。分析结果大致可以分为三类，原始的调用链数据我们会使用ES+HBase进行存储，调用关系上的实时监控数据我们采用时序数据库druid进行存储，拓扑关系采用图数据存储。

链路追踪主要提供了一下功能：

1.调用依赖关系分析：提供了服务间依赖及接口间依赖的多个层次粒度，支持MySQL/Redis等各类中间件，为开发人员提供各种上下游依赖的直观展示；

2.服务间调用关系指标：提供QPS/响应延时错误率等核心指标监控，且能在一个调用关系上同时提供客户端及服务端两个视角的监控值，便于进行问题定位；

3.程序异常分析：在调用链数据中心记录异常类型及堆栈信息并进行分析，支持展示某个应用的程序异常种类及每分钟发生次数等；

4.日志关联：将调用链与业务日志进行关联查询，便于获取程序运行的详细信息。

熔断限流方案

由于微服务架构的特点，上下游依赖和网络通信都比较多，这些因素都会对应用本身产生一定的风险，比如上游系统的突发流量或者热点参数；下游系统服务不可用、延时增大、错误率升高等等。如果缺少对自身系统的保护，有可能产生雪崩的效应。为了应对这些场景，我们主要引入了Sentinel框架进行解决。Sentinel的核心原理是用户可以定义各类资源（资源可以是本地的一个接口，或者远程的某个依赖），并在资源上设置各种规则（比如限流规则），在访问某个资源时，Sentinel组件会检查这些规则是否满足，在不满足的情况下会抛出特定的异常。用户可以通过捕捉这些异常实现快速失败或者降级等业务逻辑。Sentinel还提供了一个控制台，可以用来管理规则的参数设置以及查看实时监控等。

为了适应爱奇艺各个业务团队的需求，我们对sentinel框架做了一定的扩展，下面的例子即是我们实现的复杂参数限流功能。Sentinel框架本身就自带热点参数限流的功能，不过仅支持一些简单类型的参数（如String、int等）。在有些情况下，限流的场景可能比较复杂，比如下图中，可能要根据第一个参数的id属性进行限流，这种场景原生的sentinel并未提供支持。针对这种情况，我们提供了一个抽象的接口，允许用户通过自己的实现从参数中提取出需要限流的资源。

为了实现规则参数的动态下发，我们将sentinel与内部的配置中心进行了适配。在sentinel dashboard上进行的参数改动，最后都会保存至配置中心，业务系统通过引入配置中心的SDK，即可实现在不重启应用的前提下进行参数的动态调整。

在QDAS管理平台上，我们还利用k8s技术提供了sentinel dashboard的托管功能，省去了各业务团队在这方面的部署维护成本。

API网关

爱奇艺 API 网关底层基于开源项目 Kong 实现，旨在为开发者提供稳定、便捷、高性能、可扩展的服务入口功能，一站式管理API 配置和生命周期，对微服务治理具有重要意义。

在 API 网关控制流架构设计中，微服务平台 API 网关模块通过内部系统集成及服务化实现，为开发者提供全部所需入口配置及管理功能，且无需代码侵入、工单申请等人工干涉，实现API 创建即可用。API 网关支持认证、限流、访问控制等通用功能。

结构如下图所示：

API网关的具体功能及实现原理也已通过公众号文章进行了介绍，有兴趣的读者可以参考一站式入口服务|爱奇艺微服务平台 API 网关实战。

QDAS

在完善的微服务体系架构中，微服务治理平台也必不可少。QDAS是一个以应用为中心的一站式平台，通过功能插件的形式，对微服务应用的开发、部署、运维各个环节进行全生命周期的支持，同时兼容Dubbo/Spring Cloud 传统微服务框架和Istio服务网格架构。

QDAS平台主要支持的功能包括：

1.应用基本信息维护

2.传统微服务治理

    (1)实例列表及与Nacos注册中心集成的实例上下线管理；

    (2)Grafana核心指标监控大盘；

    (3)Sentinel dashboard托管；

   (4)基于Sentinel的接口鉴权和流量配额管理（开发中）；

3.应用生命周期管理

    支持在各类平台（容器/虚机）上的应用部署和版本升级功能

4服务市场

    接口契约管理：包括基于Swagger UI的接口描述查看等。

混沌工程

Netflix最早系统化地提出了混沌工程的概念，目的是尽早的识别风险，对薄弱的地方做针对性的加强。我们也一直在注重自己的故障演练，借助一些内部的工具跟外部开源项目，逐步演化出自己的故障注入平台——小鹿乱撞。借助平台，可以编排自己的演练方案进行演练，检验服务的健壮性。

目前小鹿乱撞平台已经支持包括服务器、容器(docker)、数据库、中间件、网路设备、k8s集群等进行故障注入，并可在演练过程中实时展示关联的监控、日志以及报警等，演练结束后自动生成演练报告。

另外，借助平台定时演练的能力，用户可以方便的实现周期性演练的效果。

对于微服务标准架构的未来规划，大概分为以下几方面的工作：

微服务技术趋势方面，云原生与service mesh已经是微服务技术演进的一个趋势了，如何引入service mesh技术，并向各个业务提供平滑过渡的解决方案，将会是我们今后工作的一个重点。

在服务治理方面，我们会进一步扩展QDAS平台的功能，以期建成一个对service mesh和传统微服务都适用的控制面。

在开发者支持方面，未来计划推出项目脚手架以及在线调试等服务，使得开发人员能更方便地进行项目开发，以及线上问题的排查等。