网关相关 - CongGreat/async-await GitHub Wiki

网关逻辑

总逻辑

graph LR
    st(发起请求) --> authentication[鉴权]
    authentication --> co{鉴权是否通过?}
    co -- no--> en1(403 Forbidden)
    co -- yes --> distribute[请求分发应用服务器]
    distribute --> record[记录操作日志]
    record --> en2(结束)

鉴权逻辑

flowchart TB
    st(鉴权流程开始) --> url_co{是否是public url?}
    url_co -- yes -->en1(鉴权通过)
    url_co -- no --> session_co{session 是否存在?}
    session_co -- no -->en2(403 Forbidden)
    session_co -- yes -->session_valid(session是否有效?)
    session_valid -- no -->en3(403 Forbidden)
    session_valid -- yes -->op[通过session获取user_info]
    op --存储及校验方式同public url --> inner_public_url{是否是登陆后开放的url?}
    inner_public_url -- yes -->en4(鉴权通过)
    inner_public_url -- no -->is_perm{判断url对应的权限是否在用户组及用户所有权限集合中?}
    is_perm -- yes  --> en5(鉴权通过)
    is_perm -- no --> en6(403 Forbidden)

apisix下的服务发现技术选型

前提: 目前开源网关选型基本确定是apisix的前提下，dashboard最高版本为3.0.1。能使用的服务发现组件有以下5种: 1.DNS 2.Consul KV 3.Nacos 4.Eureka 5.Kubernetes 这五大组件使用起来，原理上其实并没有多大区别。基础的服务发现原理就是基于下图

flowchart LR
    clinet(客户端) --2.客户端发起请求--> balancer[负载均衡器]
    balancer -- 3.负载均衡器发起请求 --> register[服务注册中心]
    register -- 返回可用地址 --> balancer
    A(服务A) -- 1.注册 --> register
    B(服务B) -- 1.注册 --> register
    balancer -- 4.调用 --> A
    balancer -- 4.调用 --> B
     A -- 返回结果 --> clinet
     B -- 返回结果 --> clinet

这里优先说一下DNS的缺点，DNS由于固有的缓存属性，所以这里不讨论DNS，不把DNS作为一个风控服务发现组件待选目标。(缓存有可能存在一个小时不更新，对于动态扩容，如果已经存在会down或者崩溃边缘，还要等待一个小时，颇感费劲)

各大组件优缺点

DNS（否）

Consul篇

优点: Consul本质上属于应用外的注册方式，但可以通过SDK简化注册流程。Consul本身对应用的侵入很小，只需要在服务启动时调用SDK注册即可。 Consul内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，使用起来也较为简单。 Consul是基于golang的，搭建起来快速简单，方便运维操作。缺点: 但目前的apisix dashboard并没有在页面端更新consul服务发现，这就导致了consul服务发现无法从页面手动选择(只能选择consul kv)，这点可以通过修改dashboard的源码来实现选择，本质上apisix是支持consul的，只是管理页面还没来得及更新consul。单单使用consul kv是没有健康检查的，其实这里只是使用了他的存储而已，少了健康检查，会减少我们对服务整体的把控。 consul也是主从模式，在leader节点宕机了之后，重新选举的leader节点的时候，consul的各个功能是无法使用的。

Eureka篇（否）

优点: 可用性（AP原则）：Eureka 在设计时就紧遵AP原则，Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用，只不过查到的信息可能不是最新的（不保证强一致性）。去中心化架构：Eureka Server 可以运行多个实例来构建集群，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。请求自动切换：在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。节点间操作复制：当节点开始接受客户端请求时，所有的操作都会在节点间进行复制操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。自动注册&心跳：当一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并完成初始化。Eureka Server 通过 getEurekaServiceUrls() 方法获取所有的节点，并且会通过心跳契约的方式定期更新。自动下线：默认情况下，如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳（默认周期为30秒），Eureka Server 将会注销该实例（默认为90秒， eureka.instance.lease-expiration-duration-in-seconds 进行自定义配置）。保护模式：当 Eureka Server 节点在短时间内丢失过多的心跳时，那么这个节点就会进入自我保护模式。缺点: Eureka官方python SDK要求是3.7+，如果tornado要用得自己实现3.6版本的SDK。 Eureka不存在宕机风险，保持了高可用性

Nacos篇

nacos是阿里开源的一个服务发现组件优点: Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。 Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。 nacos就比较全面，各种东西也有，Nacos的注册中心支持CP(一致、容灾)也支持AP(高可用容灾) 从电商那边使用来看，nacos没有反馈过痛点，也没有出现过问题，是一个比较好的技术选型。python sdk也比较友善，支持3.6。从注册组件角度看，nacos确实完胜其他的注册组件，几乎没有缺点。

看这张图就能明白nacos和各组件的区别了