Istio详解

Istio

官网：https://istio.io/latest/

附一链接：https://www.cnblogs.com/luozhiyun/p/13874948.html

Istio 提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，只需要对服务的代码进行一点或不需要做任何改动。想要让服务支持 Istio，只需要在您的环境中部署一个特殊的 sidecar 代理，使用 Istio 控制平面功能配置和管理代理，拦截微服务之间的所有网络通信。

Istio服务网格   
Istio是一个Service Mesh开源项目，是Google继Kubernetes之后的又一力作，主要参与的公司包括Google，IBM和Lyft。
  凭借Kubernetes良好的架构设计及其强大的扩展性，Google围绕Kubernetes打造一个生态系统。其向下用CNI（容器网络接口），CRI（容器运行时接口）标准接口可以对接不同的网络和容器运行时实现，提供微服务运行的基础设施。向上则用Istio提供了微服务治理功能。
  Google借Istio的力量推动微服务治理的事实标准，对Google自身的产品Google
Cloud有极其重大的意义。可以预见不久的将来，对于云原生应用而言，采用Kubernetes进行服务部署和集群管理，采用Istio处理服务通讯和治理，将成为微服务应用的标准配置。

主要分为4个功能：连接(Connect)、安全(Secure)、控制(Control)、观察(Observe)

Istio服务包括网格由数据面和控制面两部分。

• 数据面由一组智能代理（Envoy）组成，代理部署为边车，调解和控制微服务之间所有的网络通信。
• 控制面负责管理和配置代理来路由流量，以及在运行时执行策略。
  

服务网格为微服务提供了一个对应用程序透明的安全、可靠的通信基础设施层。采用服务网格后，微服务应用开发人员可以专注于解决业务领域问题，将一些通用问题交给服务网格处理。采用服务网格后，避免了代码库带来的依赖，可以充分发挥微服务的异构优势，开发团队可以根据业务需求和开发人员能力自由选择技术栈。
  Istio具有良好的架构设计，提供了强大的二次开发扩展性和用户定制能力。虽然Istio目前还处于beta阶段，但已经获得众多知名公司和产品的支持，是一个非常具有前景的开源服务网格开源项目。

• 监控指标（Grafana）
由grafana组件实现

链接：https://www.jianshu.com/p/0d82c7ccc85a

• 网格可视化（Kiali）
由kiali组件实现。

Kiali为网格管理和可观察性提供了良好的用户体验的可视化工具。

链接：https://www.baidu.com/link?url=dsD_ZofeKRoIpnE0EZv-yCC5m5u6_ddruhIDLcyiNKHd5KV1p8ZvvEnsxweqFq9prj_qPMwclz9YN9A29-hAfq&wd=&eqid=b02b714600001e380000000660d3e596
链接：https://blog.csdn.net/sniperking2008/article/details/97647679
官网：https://kiali.io/documentation/latest/quick-start/

Kiali 为我们提供了查看相关服务与配置提供了统一化的可视化界面，并且能在其中展示他们的关联；同时他还提供了界面让我们可以很方便的验证
istio 配置与错误提示。

• 调用链跟踪（Jaeger）
由istio-tracing 组件实现。

链接：https://www.baidu.com/link?url=cdGyUZtGpy7kdEI3zry6jGO9lwFzX276UP0fACixI5RnVPH8TASPxRNAMD1gFyaurKULUcXfU0cuCRt4bWzqp_&wd=&eqid=8bb64a950007ede80000000660d3e6c1

Istio关键能力：
主要功能：
1、流量管理：负载均衡、动态路由、灰度发布、故障注入
2、可观察性：调用链、访问日志、监控
3、策略执行：限流、ACL(访问控制列表)
4、服务身份和安全：认证、鉴权
功能扩展：
1、平台支持：Kubernetes、CloudFoundry、Eureka、Consul
2、集成和定制：ACL(访问控制列表)、日志、配额

基础概念：Gateway、VirtualService、DestinationRule、ServiceEntry

Gateway

控制着网格边缘的服务暴露。，Mesh外的服务想要访问Mesh内的服务通过Gateway。在入口处部署一个ingress的Envoy，在其上执行服务治理。配合VirtualService使用，使用标准Istio规则治理。Istio服务网格中，gateway可以部署任意多个可以公用一个，也可以每个租户，namespace单独隔离。

Gateway也可以看作网格的负载均衡器，提供一下功能：

1、L4-L6的负载均衡 2、对外的mTLS Gateway根据流入流出方向分为ingress gateway和egress gateway
Ingress gateway：控制外部服务访问网格内服务，配合VirtualService。 Egress
gateway：控制网格内服务访问外部服务，配合DestinationRule、ServiceEntry使用。

Gateway VS Kubernetes Ingress：

Kubernetes Ingress集群边缘负载均衡、提供集群内部服务的访问入口，仅支持L7负载均衡，功能单一。
Istio1.0以前，利用Kubernetes Ingress实现网格内服务暴露。

但是Ingress无法实现很多功能：
1、L4-L6负载均衡
2、对外mTLS
3、SNI的支持
4、其他Istio中已经实现的内部网络功能：Fualt Injection、Traffic Shiftion、Circuit Breaking、Mirroring。

为了解决这些问题，Istio在1.0版本设计新的v1alpha3 API:
1、Gateway允许管理员指定L4-L6的设置：端口及TLS设置。
2、对于Ingress的L7设置，Istio允许将VirtualService与Gateway绑定起来。
3、分离的好处：用户可以像使用传统的负载均衡设备一样管理进入网格内部的流量，绑定虚拟IP到虚拟服务器上。便于传统技术用户无缝迁移到微服务。

Gateway与普通的sidecar均是使用Envoy作为proxy实行流量控制。Pilot为不同类型的proxy生成相应的配置，Gateway的类型为router，sidecar的类型为sidecar。
Gateway不是流量的终点只是充当一个代理转发。

理解外部请求如何到达应用：
1、Client发起请求到特定端口。
2、Load Balancer监听在这个端口、并转发到后端。
3、在Istio中，LB将请求转发到IngressGateway服务。
4、Service将请求转发到IngressGateway pod
5、Pod获取Gateway和VirtualService配置，获取端口、协议、证书、创建监听器。
6、Gateway pod根据路由将请求转发到应用pod(不是service)

VirtualService

服务访问路由控制。满足特定条件的请求流到哪里，过程中治理。包括请求重写、重试、故障注入等。定义了一系列对指定服务的流量路由规则。

• ·hosts——流量的目标主机
• gatesways——Gateway名称列表
• http——HTTP流量规则(HTTPRoute)的列表
• tcp——tcp流量规则(TCPRoute)的列表
• tls——tls和https(TLSRoute)流量规则的列表

DestinationRule：

目标服务的策略。其定义的策略、决定了路由处理之后的流量访问策略。负载均衡设置、断路器、TLS设置、连接池管理等。

ServiceEntry：

将Mesh外的服务加入到服务发现中，像Mesh里面的服务一样的被治理。将ServiceEntry描述的服务加入到服务发现中；对这些服务的outbound流量进行拦截，进而进行治理。与VirtualService和DestinationRule配合使用。

Istio网格内默认不能访问外部服务，如果需要访问外部服务有三种方式：
1、Istio安装时设置：–set global.proxy.includeIPRanges=”10.0.0.1/24”
2、创建应用时指定pod annotation：traffic.sidecar.istio.io/includeOutboundIPRanges:”1270.0.0.1/24,10.96.0.1/24”
3、创建ServceEntry。

上面是官方给的架构图，

核心组件有：Proxy代理、Mixer混合器、Pilot引导、Citadel堡垒，以及Galley。

Proxy代理：

网络代理，拦截下所有想拦截的流量。使用的代理组件是Lyft团队的Envoy。

Envoy：

主要用于流量的转发和治理，基于C++的L4/L7 Proxy转发器,是CNCF第三个毕业的项目。
4个概念：Listeners(LDS)、Routes(RDS)、Clusters(CDS)、Endpoints(EDS)
Envoy之所以有能力拦截下所有的流量，是因为它被设计为部署在每一个需要管理的Pod里，作为一个独立容器存在。主要功能：规则校验、 数据采集、日志、动态服务发现、负载均衡、TLS 终止(最后停止)、HTTP/2 & gRPC 代理、 熔断器、 健康检查、基于百分比流量拆分的灰度发布、 故障注入、 丰富的度量指标。

Mixer混合器：

Mixer混合了各种策略、后端数据采集、遥测系统的适配器、监控，从而实现了前端Proxy与后端系统的隔离与汇合。它一端连着Envoy，同时可以将自定义的日志、监控、遥测等各种系统“插入”到Mixer的另一端中，从而得到我们想要的数据或结果。Mixer被设计为一个独立运行的模块，它可以“插入”logging日志、quota指标(配额)、auth安全认证、Tele遥测等很多模块。每插入一个模块都会在前端生成一个规则过滤器。前端的Enovy在每次流量到来时，都会请求Mixer，匹配每一个过滤器。
功能上：负责策略控制和遥测收集。
架构上：提供插件模型，可以扩展和定制。
Mixer的Adapter机制：
Mixer处理不同基础设施后端的灵活性是通过使用通用插件模型实现的，这种插件称为Adapter。
Mixer通过它们与不同的基础设施后端连接，这些后端可提供核心功能，提供日志、监控、配额、ACL检查等。

Mixer配置模型概述：

·Handler：创建Handler，即配置Mixer适配器。
·Instance：从Istio属性中生成instance。
·Rule：配置一组规则，这些规则描述了何时调用特定适配器及哪些实例。

Handler：
实例化一个Adapter，包括了Mixer和后端交互的接口。
实例(Instance):实例将请求中的属性映射成为设配器的输入，每次请求设配器消费的数据。
规则(Rule)：告诉Mixer那个instance在什么时候发送给哪个handler来处理。

Pilot引导：

Pilot是为我们提供配置智能路由（如A/B测试、金丝雀发布等）、弹性（超时、重发、熔断等）等功能的管理系统，它提供了一系列rules api，允许运维人员指定一系列高级的流量管理规则。Pilot负责将我们的配置转换并写入到每个sidecar（Enovy）。管理服务和服务之间的通讯。实现服务发现、服务配置功能 。

Citadel堡垒：

服务访问的安全管理中心。它管理着集群的密钥和证书，是集群的安全部门。典型的如果我们的服务是跨网络通讯（Istio允许我们建立一个安全的集群的集群网络），开发人员想省事懒得对通讯数据进行加解密和身份认证，这事就可以交给Citadel来处理了。更详细的说，Istio各个模块在安全性上分别扮演以下角色：
• Citadel，用于密钥和证书管理
• Sidecar和周边代理，实现客户端和服务器之间的安全通信
• Pilot，将授权策略和安全命名信息分发给代理
• Mixer，管理授权和审计

Galley：

目前这个组件的作用是验证用户编写的Istio api配置。从官网的说法来看，后面这个组件会逐步接管获取配置、处理和分配的工作，比如从k8s的数据中心（etcd）获取集群信息的活，理论上应该交给Galley干。从这个信息来看，Galley的定位应该类似于k8s的api server组件，提供集群内统一的配置信息接口，从而将用户配置的细节隔离开来。

xDS是什么：
xDS是一类发现服务的总称，包含LDS、RDS、CDS、EDS(Envoy的4个概念)以及SDS。
Envoy通过xDS API可以动态获取Listener(监听器)、Route(路由)、Cluster(集群)、Endpoint(集群成员)以及Secret(密钥、证书)配置。
xDS协议是Envoy获取配置信息的传输协议，也是Istio与Envoy连接的桥梁。
Envoy动态的发现服务以及相关的资源的API就会指xDS。xDS可以通过两种方式承载：gRPC、REST,这两种方式都是通过xDS-API发送DiscoveryRequest请求，然后资源通过DiscoveryResponse下发。

xDS未来的发展：

Istio目前是全量的向sidecar分发配置，由此带来几个问题：

1. 配置更新频率高，大集群的服务，实例数目多，其中有一个更新后便会触发全量的配置推送到所有的sidecar。带宽占用大，Pilot端cpu利用率高。
2. Sidecar占用内存多，随着集群规模增大。配置资源呈指数级增长，极大的限制了网格服务的规模。
3. 频繁的配置加载影响sidecar性能稳定性。

当前Istio xDS的弊端大大限制了Istio服务网格的规模，如何解决：

1. sidecar按需请求资源，懒加载形式，当真正需要流量转发的时候，再去获取路由等配置。
2. 定义workload的服务依赖，例如工作负载A可以访问ns1/ServiceB
3. 定义配置规则、Service的NetworkScope，例如服务A只能被同一 Namespace的workload访问。

增量xDS

Incremental xDS是一个独立的xDS endpoint,是一种runtime的动态配置获取方案，用于增量的更新xDS客户端订阅的资源，适用于ADS,CDS和RDS:

1. 保证Envoy按需/懒请求所需要的资源。例如当流量路由到未知的cluster时，Envoy就会请求获取未知的cluster信息。
2. 支持大规模可扩展的目标。例如在一个有100K个服务实例的集群中，如果一个服务实例有更新，管理服务器只需要下发一个Cluster的信息。

DiscoveryRequest：

DiscoveryResponse：

xDS流程：类似TCP中的三次握手工程。

LDS是什么：

Listener发现服务。Listener监听器控制Envoy启动端口监听(目前只支持TCP协议)，并配置L3/L4层过滤器，当网络连接达到后，配置好的网络过滤器堆栈开始处理后续事件。这种通用的监听器体系结构用于执行大多数不同的代理任务(限流、客户端认证、HTTP连接管理、TCP代理等)。

RDS是什么：

Route发现服务。用于HTTP连接管理过滤器动态获取路由配置。路由配置包含HTTP头部修改(增加、删除HTTP头部键值)，virtual
hosts(虚拟主机)，以及virtual hosts定义的各个路由条目。

CDS是什么：

Cluster发现服务。用于动态获取Cluster信息。Envoy
cluster管理器管理着所有的上游cluster。鉴于上游cluster或者主机可用于任何代理转发任务，所以上游cluster一般从Listener或Route中抽象出来。如果是TCP协议的话cluster是通过Listener直接关联的，如果是HTTP协议cluster是从Route中关联的。

EDS是什么：

Endpoint发现服务。在Envoy术语中，Cluster成员就叫Endpoint，对于每个Cluster，Enovy通过EDS
API动态获取Endpoint。EDS作为首选的服务发现的原因有两点：
1、与通过DNS解析的负载均衡器进行路由相比，Enovy能明确的知道每个上游主机的信息，因而可以做出更加智能的负载均衡策略。
2、Endpoint配置包含负载均衡权重、可用域等附加主机属性，这些属性可用于服务网格负载均衡、统计收集等过程中。

SDS是什么：

Secret发现服务。用于运行时动态获取TLS证书。若没有SDS特性，在k8s环境中，必须创建包含证书的Secret，代理启动前Secret必须挂载到sidecar容器中，如果证书过期，则需要重新部署。使用SDS，集中式的SDS服务器将证书分发给所有的Envoy实例，如果证书过期，服务器会将新的证书分发，Envoy接受到新的证书后重新加载，不用重新部署了。

ADS是什么：

ADS是一种xDS的实现，它基于gRPC的长连接。gRPC的实现是承载在HTTP/2之上。

ADS最终一致性的考量：
xDS是一种最终一致性的协议，所以在配置更新过程中流量会丢失。EDS还没有来的及下发，如果通过CDS/EDS获得ClusterX，一条指向ClusterX的RouteConfiguration刚好调整为指向ClusterY，但是在CDS/及下发ClusterY的配置条件下，到Y的流量会全部被丢弃，并且返回给客户端状态码503。
在某些场景下，流量丢弃是不可接受的。Istio通过遵循 make before break模型，调整配置更新顺序可以完全避免流量丢失。

服务发现流程：

1、服务注册表：pilot从平台获取服务发现数据，并提供统一的服务发现接口。
2、服务注册：无
3、服务发现：Envoy实现服务发现，动态更新负载均衡池。
在服务请求时使用对应的负载均衡策略将请求路由到对应的后端。

Istio服务发现实现：(基于Eureak)

1、Pilot实现若干服务发现的接口定义
2、Controller使用EurekaClient来获取服务列表，提供转换后的标准的服务发现接口和数据结构；
3、Discoveryserver基于Controller上维护的服务发现数据，发布成gRPC协议的服务功Envoy使用。
4、当有服务访问时，Envoy在处理Outbound请求时，根据配置的LB策略，选择一个服务实例发起访问。

Istio服务发现实现：(基于Kubernetes)

1、Pilot实现若干服务发现的接口定义
2、Pilot的Controller List/Watch
KubeApIserver上service、endpoint等资源对象并转换成标准格式。
3、Envoy从Pilot获取xDS，动态更新
4、当有服务访问时，Envoy在处理Outbound请求时，根据配置的LB策略，选择一个服务实例发起访问。

Istio服务访问规则维护和工作机制：

1、配置：管理员通过Pilot配置治理规则。
2、下发：Envoy从Pilot获取治理规则。
3、执行：在流量访问的时候执行治理规则。

Istio+Kubernetes：云原生应用治理+云原生应用设施

Istio主要功能：调用链追踪、动态路由、熔断限流… Kubernetes主要功能：负载均衡、服务发现、扩缩容、运维、部署

Kubernetes服务治理的能力比较简单、两者结合Istio刚好补齐了Kubernetes服务治理的能力，两者在功能上完美的结合。

Spring Cloud + Kubernetes（不推荐）

1、治理业务：治理业务和代码共存
2、治理升级：治理逻辑升级用户业务也需随之升级
3、服务注册：业务代码中需要配置注册中心地址，本服务的描述，启动时候注册。
4、治理规则：治理规则和服务注册一起，获取单独的配置服务。
5、服务发现方式：业务代码中需要配置注册中心地址，获取目标服务实例信息。
6、服务发现不一致：服务注册和K8s两条通道，引起不一致问题，Pod重启服务，注册中心更新不及时，导致服务访问不同。

以下是从官网各项示例中整理出来的Istio所支持的功能列表：

流量管理

请求路由：
A/B测试、金丝雀发布等，包括对集群出入口、及集群内部的流量的控制。比如某应用新版本发布，可以配置为5%的流量流向新版本，95%的给旧版本

流量转移：

与上一条请求路由类似，可以平滑的将流量从旧版本转移到新版本上

负载均衡：

目前支持3种方式，轮询、随机和带权重的最少请求

服务发现：

带心跳的健康检查，失败率超标的Pod移出负载均衡池

故障处理：

超时、重发、熔断、上游并发请求或下游连接数限制等

微调：

支持用特殊的请求头参数，覆盖默认的超时、重发值

故障注入：

由Enovy在正常的集群中人为注入故障，比如TCP包损坏或延迟、HTTP错误码等，
支持按百分比注入，比如给10%的流向服务A的请求包增加5秒延迟

多重匹配：

上述规则的配置，支持按多种条件匹配，且支持and或or的方式匹配多条规则

Gateway：

接管集群入口的流量，替代了Ingress，从而对入口流量执行其他规则

Service Entry：

接管集群内部访问外部服务的流量，从而对出口流量执行一些规则

镜像：

 支持将特定的流量镜像到服务路径之外，而不影响主服务路径的正常执行

安全

命名空间访问控制：	支持配置某命名空间的所有或个别服务可以被其他命名空间访问
服务级别访问控制：	允许或禁止访问某个服务
双向TLS：	HTTPS加密传输
其他安全策略：	

策略

速率限制：比如限制每秒的请求次数
黑白名单：支持基于IP或属性的黑名单、白名单

遥测

日志收集：支持将Prometheus、Jaeger等系统插入Mixer，从而完成数据的采集
指标采集：	
分布式追踪：

灰度发布：

服务器端升级时，需要将应用源码或程序包上传到服务器，停止掉老版本服务，再启动新版本。但是这种简单的发布方式存在两个问题，一方面，在新版本升级过程中，服务是暂时中断的，另一方面，如果新版本有BUG，升级失败，回滚起来也非常麻烦，容易造成更长时间的服务不可用。
灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。
在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。
当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。
如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。

智能灰度发布：
目标：细粒度控制的自动化的持续交付
特点：

1. 用户细分
2. 流量管理
3. 关键指标可观测
4. 发布流程自动化

智能灰度发布图：

自适应灰度发布参数：

• 1、负载健康状态
• 2、请求成功率
• 3、平均请求时延
• 4、流量权重步长
• 5、回滚门限值

A/B Test：

配置策略–>监控指标–>分析数据–>做出决策–>执行决策 A/B
Test主要对特定的用户采样后，对收集到的反馈数据做想关对比，然后根据对比结果做出决策。用来测试应用功能表现的方法，侧重应用的可用性，受欢迎程度等。

故障注入：

故障注入是一种可靠性验证技术，通过受控实验向系统中刻意引入故障，并观察系统中存在故障时的行为。
容错机制是提高服务可靠性的重要手段，故障注入是对容错机制的有限评测。

调用链：

分布式系统之后，系统变的错综复杂，一般很难全盘理解整个系统，并且错误比较难定位，需要有调用链监控，快速的帮我们定位监控问题，了解微服务体系。哪个服务调用哪个服务都被监控记录下来。和SpringCloud
Sleuth(分布式请求链路跟踪)技术有相同之处。 ACL(访问控制列表)：
访问控制列表(ACL)是一种基于包过滤的访问控制技术，它可以根据设定的条件对接口上的数据包进行过滤，允许其通过或丢弃。访问控制列表被广泛地应用于路由器和三层交换机，借助于访问控制列表，可以有效地控制用户对网络的访问，从而最大程度地保障网络安全。
ACL（访问控制列表）是一种路由器配置和控制网络访问的一种有力的工具，它可控制路由器应该允许或拒绝数据包通过，可监控流量，可自上向下检查网络的安全性，可检查和过滤数据和限制不必要的路由更新，让网络资源节约成本。

认证、授权、鉴权、权限控制：

认证：

是指根据声明者所特有的识别信息，确认声明者的身份。为了确认用户的身份，防止伪造，在安全要求高的场合，经常会使用组合认证（或者叫多因素认证），也就是同时使用多个认证方式对用户的身份进行校验。

授权：

是指资源所有者委派执行者，赋予执行者指定范围的资源操作权限，以便执行者代理执行对资源的相关操作

鉴权：

是指对于一个声明者所声明的身份权利，对其所声明的真实性进行鉴别确认的过程。鉴权是一个承上启下的一个环节，上游它接受授权的输出，校验其真实性后，然后获取权限（permission），这个将会为下一步的权限控制做好准备。

权限控制：

是指对可执行的各种操作组合配置为权限列表，然后根据执行者的权限，若其操作在权限范围内，则允许执行，否则禁止。
对于权限控制，可以分为两部分进行理解：一个是权限，另一个是控制。权限是抽象的逻辑概念，而控制是具体的实现方式。
先看权限（Permission），这是一个抽象的概念，一般预先定义和配置好，以便控制的具体实现。权限的定义，若简单点，可以直接对应于一个可执行的操作集合。可以看到，权限作为一个抽象的概念，将执行者和可具体执行的操作相分离。
对于控制，是根据执行者的权限，对其所执行的操作进行判断，决定允许或禁止当前操作的执行。

认证、授权、鉴权和权限控制的关系：

认证、授权、鉴权和权限控制这四个环节是一个前后依次发生、上下游的关系，
java 认证-->授权-->鉴权-->权限控制
需要说明的是，这四个环节在有些时候会同时发生。 例如在下面的几个场景：
使用门禁卡开门：认证、授权、鉴权、权限控制四个环节一气呵成，在瞬间同时发生。
用户的网站登录：用户在使用用户名和密码进行登录时，认证和授权两个环节一同完成，而鉴权和权限控制则发生在后续的请求访问中，比如在选购物品或支付时。

认证和鉴权的关系：

认证是确认声明者的本身身份，其作为授权的上游衔接而存在。 鉴权是对声明者所声明的真实性进行确认的过程，其作为授权的下游衔接而存在。