背景
为数以亿计的用户提供优质的视频服务的爱奇艺技术产品团队，为了适应业务的快速迭代和创新，并支撑海量的用户请求，很多团队都对各自的业务系统自发地进行了微服务架构的改造。
在微服务化的过程中，各业务团队根据自身需要选择了不同的开源框架，如ApacheDubbo/SpringCloud等，此外也存在一些自研性质的框架；另外为了满足对微服务应用的监控等需求，不少团队还自行维护了监控系统等基础设施。
随着实践的深入，一些问题逐渐开始暴露，这其中包括：
·部分基础设施存在重复建设，在资源浪费的同时稳定性也不易保证；
·由于使用的技术架构和SDK不统一，最佳实践难以在团队间快速推广；
·技术架构不统一导致在东西向流量中大量引入了业务自行维护的网关，使得链路加长，影响排障效率和响应延时。
为了解决以上问题，爱奇艺中间件团队充分听取了业务在微服务实践中的需求和问题，推出了爱奇艺的微服务标准架构。在标准架构的建设过程中，我们主要遵循了以下的一些原则：
1.架构统一：同一技术领域往往有多种技术实现，但是过多的技术框架的采用容易造成维护成本过高，缺乏专人支持等问题。在微服务标准架构的选型过程中，我们综合了各开源项目的实际情况和业界的主流技术方案，将各个领域中的技术选型进行了统一，每个领域的技术选型原则上均不超过1种。
2.可扩展：微服务标准架构中有不少开发SDK的选型，为了满足各个开发团队不同的业务需求，需要保证各个SDK的可扩展性，如果开源版本无法满足内部需求的，爱奇艺中间件团队都会维护统一化的内部定制版本。
3.高可用：标准架构的建设目的之一是将各个团队维护的基础设施（如注册中心、监控系统等）逐渐收拢至内部的公共平台。对相关平台的技术架构review及可用性维护也是我们的重要工作之一，此外我们还建设了服务成熟度体系SMMI，会定期对核心系统及基础服务进行成熟度评估。
4.技术演进：开源软件均有其生命周期，需要充分考虑各个软件的社区维护情况，比如在熔断技术选型上，我们在标准架构中主推了Sentinel，而不是目前已经停止维护的Hystrix。另外标准架构也并非一个一成不变的体系，对于新技术的采纳，我们也提供了标准化的流程，确保我们的技术体系能持续迭代。
5.内部开源：在标准架构的建设过程中，在爱奇艺内部开展了内部开源的协作模式。除了基础服务部门以外，也鼓励业务团队参与到这些基础服务的维护工作中来，共同打造一个即符合业务需求，又有一定业界领先度的微服务技术体系，这样也进一步促进了相关标准架构的推广和完善。
爱奇艺微服务标准架构下图展示了爱奇艺微服务标准架构的全貌：
image标准架构主要包括如下主要内容：
*统一的微服务开发SDK：核心开发框架Dubbo/SpringCloud；熔断限流框架Sentinel等；
*统一的微服务基础设施，包括：
·注册中心：Nacos/consul；
·服务网关：基于kong进行二次开发的网关平台，提供鉴权、限流等功能；
·配置中心：基于携程Apollo进行二次开发的平台
·指标监控：prometheus集群托管服务；
·链路监控：全链路平台（基于skywalking进行定制开发）；
·混沌工程：在ChaosBlade基础上进行二次研发，提供各类故障演练功能。
*统一的微服务平台：QDAS（QIYIDistributedApplicationService，爱奇艺分布式应用服务），提供微服务应用生命周期管理、服务治理、服务市场等功能。
标准架构生态建设以下将从微服务SDK、注册中心、监控体系、熔断限流、API网关、微服务平台等几个微服务标准架构的核心点做一些展开的介绍。
开源SDK定制根据各个业务团队的需求，爱奇艺中间件团队主要对DubboSDK做了以下几方面的扩展：
1.基础设施的适配：包括注册中心、监控系统、内部的容器平台等等；
2.可用性增强：包括非健康实例隔离以及区域就近路由的机制；
3.安全性增强：支持了服务间调用的认证机制；
4.序列化：增加了对protobuf序列化方式的支持。
注册中心演进注册中心在微服务应用中是最重要的基础设施之一，原先在爱奇艺内部，注册中心的选型并不统一，之前在线上运行的注册中心有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实例故障：利用LoadBalancer集群提供的健康检查能力自动从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服务及旧的注册中心，整个迁移流程就结束了。
以上方案的主要优点包括：
*服务提供方和消费方的升级完全独立，可以自行进行；
*迁移涉及的应用仅需升级一次。
监控体系建设服务监控是所有业务团队都极为