开云app(中国)官方网站IOS/安卓通用版/手机APP下载

原文地址：https://www.infoq.cn/article/AJj3lKQyaKVeA08Bgj9e配景为数以亿计的用户提供优质的视频服务的爱奇艺技术产物团队，为了适应业务的快速迭代和创新，并支撑海量的用户请求，许多团队都对各自的业务系统自发地举行了微服务架构的革新。在微服务化的历程中，各业务团队凭据自身需要选择了差别的开源框架，如 Apache Dubbo/Spring Cloud 等，此外也存在一些自研性质的框架；另外为了满足对微服务应用的监控等需求，不少团队还自行维护了监控系统等基础设施。

随着实践的深入，一些问题逐渐开始袒露，这其中包罗：·部门基础设施存在重复建设，在资源浪费的同时稳定性也不易保证；·由于使用的技术架构和 SDK 不统一，最佳实践难以在团队间快速推广；·技术架构不统一导致在工具向流量中大量引入了业务自行维护的网关，使得链路加长，影响排障效率和响应延时。为相识决以上问题，爱奇艺中间件团队充实听取了业务在微服务实践中的需求和问题，推出了爱奇艺的微服务尺度架构。在尺度架构的建设历程中，我们主要遵循了以下的一些原则：1.架构统一：同一技术领域往往有多种技术实现，可是过多的技术框架的接纳容易造成维护成本过高，缺乏专人支持等问题。

在微服务尺度架构的选型历程中，我们综合了各开源项目的实际情况和业界的主流技术方案，将各个领域中的技术选型举行了统一，每个领域的技术选型原则上均不凌驾 1 种。2.可扩展：微服务尺度架构中有不少开发 SDK 的选型，为了满足各个开发团队差别的业务需求，需要保证各个 SDK 的可扩展性，如果开源版本无法满足内部需求的，爱奇艺中间件团队都市维护统一化的内部定制版本。3.高可用：尺度架构的建设目的之一是将各个团队维护的基础设施（如注册中心、监控系统等）逐渐收拢至内部的公共平台。

对相关平台的技术架构 review 及可用性维护也是我们的重要事情之一，此外我们还建设了服务成熟度体系 SMMI，会定期对焦点系统及基础服务举行成熟度评估。4.技术演进：开源软件均有其生命周期，需要充实思量各个软件的社区维护情况，好比在熔断技术选型上，我们在尺度架构中主推了 Sentinel，而不是现在已经停止维护的 Hystrix。另外尺度架构也并非一个一成稳定的体系，对于新技术的采取，我们也提供了尺度化的流程，确保我们的技术体系能连续迭代。5.内部开源：在尺度架构的建设历程中，在爱奇艺内部开展了内部开源的协作模式。

除了基础服务部门以外，也勉励业务团队到场到这些基础服务的维护事情中来，配合打造一个即切合业务需求，又有一定业界领先度的微服务技术体系，这样也进一步促进了相关尺度架构的推广和完善。爱奇艺微服务尺度架构下图展示了爱奇艺微服务尺度架构的全貌：尺度架构主要包罗如下主要内容：*统一的微服务开发 SDK：焦点开发框架 Dubbo/Spring Cloud；熔断限流框架 Sentinel 等；*统一的微服务基础设施，包罗：·注册中心：Nacos/consul；·服务网关：基于 kong 举行二次开发的网关平台，提供鉴权、限流等功效；· 设置中心：基于携程 Apollo 举行二次开发的平台·指标监控：prometheus 集群托管服务；·链路监控：全链路平台（基于 skywalking 举行定制开发）；·混沌工程：在 ChaosBlade 基础上举行二次研发，提供各种故障演练功效。*统一的微服务平台：QDAS（QIYI Distributed Application Service，爱奇艺漫衍式应用服务），提供微服务应用生命周期治理、服务治理、服务市场等功效。

尺度架构生态建设以下将从微服务 SDK、注册中心、监控体系、熔断限流、API 网关、微服务平台等几个微服务尺度架构的焦点点做一些展开的先容。开源 SDK 定制凭据各个业务团队的需求，爱奇艺中间件团队主要对 Dubbo SDK 做了以下几方面的扩展：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 实例故障：使用 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 中发现要收罗的应用实例信息。指标检察主要接纳了 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 网关支持认证、限流、会见控制等通用功效。

结构如下图所示：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 和传统微服务都适用的控制面。在开发者支持方面，未来计划推出项目脚手架以及在线调试等服务，使得开发人员能更利便地举行项目开发，以及线上问题的排查等。

本文来源：开云手机版官方下载-www.jxhtzy.com