api网关
网关在后端架构中之api gateway，接口调用经过的网关。大家在微服务的开发环境下，对网关并不陌生，如是复杂一点的微服务架构基本都会有网关层。springcloud体系中用的可能是zuul、gateway等
我们从软件的体系发展来看，网关也是随着微服务兴起的，传统单体应用只有一个应用直接访问，由于单体应用顶不住现在的数据流量，产生的微服务、分布式等，后台服务从单体应用剧增，为了安全以及流量的管控等，服务需要一个统一的入口和出口，网关因此而生。
很明显，网关作为后台服务的一个入口和出口；决定了他需要保证高性能高可用；以及进行流量的管控；容错、降级等安全防护。
api生命周期
从swagger等工具中可以总结到api应该有哪几种状态
设计-构建-文档-测试-分享-运行-下线
泛化调用
泛化调用对我来说第一次听到，确实在复杂、大流量的架构下才会产生这种概念，简单来说就是网关中是所有服务的入口，会调用很多rpc，rpc调用需要依赖api的jar包，如果每个服务提供者都依赖它的jar包，那网关就会变得很臃肿。
泛化调用很多rpc框架都有，如dubbo的GenericService，原理和依赖api调用是一样的，都是通过序列化，网络，反射等技术实现，不过泛化不需要api了，不需要pojo，全部用map来表示，简化了众多服务下的网关结构，网关只需要依赖一个rpc泛化调用服务。
api发布至网关
依据以上所述，网关和rpc服务是有所依赖的，泛化之后，没有了依赖，网关依赖了一个rpc泛化服务，因此这个服务作为了网关的api调用口，也是rpc api发布的平台，这里api发布上来后一般通过缓存存储
管道技术
夜深，明日更。。。
继续
网关中是没有业务的，不过很很多种校验，结合这种处理，我们利用管道技术会非常优雅(上面图再截一遍发现模糊，于是以下用原图，需要旋转一下)
可以看到如下图，管道技术首先是一种解耦，把每种校验(处理)拆开，而且可插拔可配置很方便；管道的实现如图下方，用pipe接口处理检验逻辑，线程类包装pipe，再交给线程池处理。
如何获取管道
每个api都有管道，因此在以上的api平台入口可以在发布时配置管道，之后通过接口即可获取到管道；管道中处理根据管道的顺序向下传递
优点
管道解耦也在于可以随时去掉某些管道，如黑白名单，开始需要后面可以撤掉等。
与责任链
管道与责任链很容易联想起来，非常相似；责任链的处理是每个处理中存有变量nextHandler和方法handlerRequest()；管道技术会更加灵活自由，责任链比较限制，而且实际的实现看起来会更复杂。
传统网关弊端
网关演进的阶段为：同步、半同步、全异步
传统
这里的传统指的是同步、半同步的网关；同步即从接受请求到调用api都是同步，半同步是io请求和业务请求分开，业务处理内部还是同步调用api；
网关的特点已经知道，承受流量大、rpc调用多、各种系统、接口调用；外部复杂度到了服务器内部，我们就需要关注计算机每个部件、负载以及网络等。
关注点
- cpu cpu是最宝贵的资源；关注cpu利用率和负载，利用率是实时占用百分比，负载是最近平均任务数。都需要关注
- 磁盘 网关调用量大，实时关注磁盘使用率，例如日志系统；进入容器时代，更需关注
- 网络 关注每个环节的耗时，尤其rpc调用跨进程跨网络
servlet3异步
异步化处理，网关请求量超大，io线程和业务处理线程需要分开，不能一个请求进来一个线程处理到结束。servlet3开启异步支持，asyncSupported=true，注解或者xml。
tomcat nio/servlet3 async/spring mvc
- nio是一个io模型，和异步没有关系，是一种通信模式，可以用少量线程处理大量请求
- servlet3异步是请求接收和业务处理的异步化，如此可以业务隔离。
- spirngmvc是基于servlet3封装的
servlet3非阻塞io
数据量大的接收参数时可以异步化
整体流程
全异步网关
rpc调用异步化
脱库与多缓存
脱库
不建议使用数据库，直接使用缓存，缓存也要考虑高可用。
多级缓存
热更新
热更新其实很多地方都需要，网关层需要管理的东西多，配置更新等；二流量大不适合重启，因此需要热更新支持
热更新可以用mq/rpc/zk....方法很多。
网关功能总结
- 降级
- 限流
- 熔断
- 线程池隔离
- 管道技术
- 热更新
- 异步
