image
那么这里就会碰着一个问题，APP/Browser怎么去访问这些后真个做事? 如果业务比较大略的话，可以给每个业务都分配一个独立的域名(https://service.api.company.com)，但这种办法会有几个问题:
image
更好的办法是采取API网关，实现一个API网关接管所有的入口流量，类似Nginx的浸染，将所有用户的要求转发给后真个做事器，但网关做的不仅仅只是大略的转发，也会针对流量做一些扩展，比如鉴权、限流、权限、熔断、协议转换、缺点码统一、缓存、日志、监控、告警等，这样将通用的逻辑抽出来，由网关统一去做，业务方也能够更专注于业务逻辑，提升迭代的效率。通过引入API网关，客户端只须要与API网关交互，而不用与各个业务方的接口分别通讯，但多引入一个组件就多引入了一个潜在的故障点，因此要实现一个高性能、稳定的网关，也会涉及到很多点。
API注册
业务方如何接入网关?一样平常来说有几种办法。
第一种采取插件扫描业务方的API，比如Spring MVC的表明，并结合Swagger的表明，从而实现参数校验、文档&&SDK天生等功能，扫描完成之后，须要上报到网关的存储做事。手动录入。比如接口的路径、要求参数、相应参数、调用办法等信息，但这种办法相对来说会麻烦一些，如果参数过多的话，前期录入会很费时费力。配置文件导入。比如通过Swagger\OpenAPI等，比如阿里云的网关:协议转换
内部的API可能是由很多种不同的协议实现的，比如HTTP、Dubbo、GRPC等，但对付用户来说个中很多都不是很友好，或者根本没法对外暴露，比如Dubbo做事，因此须要在网关层做一次协议转换，将用户的HTTP协议要求，在网关层转换成底层对应的协议，比如HTTP -> Dubbo, 但这里须要把稳很多问题，比如参数类型，如果类型搞错了，导致转换出问题，而日志又不足详细的话，问题会很难定位。
做事创造
网关作为流量的入口，卖力要求的转发，但首先须要知道转发给谁，如何寻址，这里有几种办法:
写去世在代码/配置文件里，这种办法虽然比较挫，但也能利用，比如线上仍旧利用的是物理机，IP变动不会很频繁，但扩缩容、包括运用高下线都会很麻烦，网关自身乃至须要实现一套康健监测机制。域名。采取域名也是一种不错的方案，对付所有的措辞都适用，但对付内部的做事，走域名会很低效，其余环境隔离也不太友好，比如预发、线上常日是同一个数据库，因此网关读取到的可能是同一个域名，这时候预发的网关调用的便是线上的做事。注册中央。采取注册中央就不会有上述的这些问题，纵然是在容器环境下，节点的IP变更比较频繁，但节点列表的实时掩护会由注册中央搞定，对网关是透明的，其余运用的正常高下线、包括非常宕机等情形，也会由注册中央的康健检讨机制检测到，并实时反馈给网关。并且采取注册中央性能也没有额外的性能损耗，采取域名的办法，额外须要走一次DNS解析、Nginx转发等，中间多了很多跳，性能会有很大的低落，但采取注册中央，网关是和业务方直接点对点的通讯，不会有额外的损耗。做事调用
网关由于对接很多种不同的协议，因此可能须要实现很多种调用办法，比如HTTP、Dubbo等，基于性能缘故原由，最好都采取异步的办法，而Http、Dubbo都是支持异步的，比如apache就供应了基于NIO实现的异步HTTP客户端。由于网关会涉及到很多异步调用，比如拦截器、HTTP客户端、dubbo、redis等，因此须要考虑下异步调用的办法，如果基于回调或者future的话，代码嵌套会很深，可读性很差，可以参考zuul和spring cloud gateway的方案，基于相应式进行改造。
优雅下线
优雅下线也是网关须要关注的一个问题，网关底层会涉及到很多种协议，比如HTTP、Dubbo，而HTTP又可以连续细分，比如域名、注册中央等，有些自身就支持优雅下线，比如Nginx自身是支持康健监测机制的，如果检测到某一个节点已经挂掉了，就会把这个节点摘掉，对付运用正常下线，须要结合发布系统，首先进行逻辑下线，然后对后续Nginx的康健监测要求直接返回失落败(比如直接返回500),然后等待一段韶光(根据Nginx配置决定)，然后再将运用实际下线掉。其余对付注册中央的实在也类似，一样平常注册中央是只支持手动下线的，可以在逻辑下线阶段调用注册中央的接口将节点下线掉，而有些不支持主动下线的，须要结合缓存的配置，让运用延迟下线。其余对付其他比如Dubbo等事理也是类似。
性能
网关作为所有流量的入口，性能是重中之重，早期大部分网关都是基于同步壅塞模型构建的，比如Zuul 1.x。但这种同步的模型我们都知道，每个要求/连接都会占用一个线程，而线程在JVM中是一个很重的资源，比如Tomcat默认便是200个线程，如果网关隔离没有做好的话，当发生网络延迟、FullGC、第三方做事慢等情形造成上游做事延迟时，线程池很随意马虎会被打满，造成新的要求被谢绝，但这个时候实在线程都壅塞在IO上，系统的资源被没有得到充分的利用。其余一点，随意马虎受网络、磁盘IO等延迟影响。须要谨慎设置超时时间，如果设置不当，且做事隔离做的不是很完善的话，网关很随意马虎被一个慢接口拖垮。
而异步化的办法则完备不同，常日情形下一个CPU核启动一个线程即可处理所有的要求、相应。一个要求的生命周期不再固定于一个线程，而是会分身分歧的阶段交由不同的线程池处理，系统的资源能够得到更充分的利用。而且由于线程不再被某一个连接独占，一个连接所占用的系统资源也会低得多，只是一个文件描述符加上几个监听器等，而在壅塞模型中，每条连接都会独占一个线程，而线程是一个非常重的资源。对付上游做事的延迟情形，也能够得到很大的缓解，由于在壅塞模型中，慢要求会独占一个线程资源，而异步化之后，由于单条连接所占用的资源变的非常低，系统可以同时处理大量的要求。如果是JVM平台，Zuul 2、Spring Cloud gateway等都是不错的异步网关选型，其余也可以基于Netty、Spring Boot2.x的webflux、vert.x或者servlet3.1的异步支持进行自研。
缓存
对付一些幂等的get要求，可以在网关层面根据业务方指定的缓存头做一层缓存，存储到Redis等二级缓存中，这样一些重复的要求，可以在网关层直接处理，而不用打到业务线，降落业务方的压力，其余如果业务方节点挂掉，网关也能够返回自身的缓存。
限流
限流对付每个业务组件来说，可以说都是一个必须的组件，如果限流做不好的话，当要求量突增时，很随意马虎导致业务方的做事挂掉，比如双11、双12等大匆匆时，接口的要求量这天常平常的数倍，如果没有评估好容量，又没有做限流的话，很随意马虎做事全体不可用，因此须要根据业务方接口的处理能力，做好限流策略，相信大家都见过淘宝、百度抢红包时的降级页面。因此一定要在接入层做好限流策略，对付非核心接口可以直接将降级掉，保障核心做事的可用性，对付核心接口，须要根据压测时得到的接口容量，制订对应的限流策略。限流又分为几种:
单机。单机性能比较高，不涉及远程调用，只是本地计数，对接口RT影响最小。但须要考虑下限流数的设置，比如是针对单台网关、还是全体网关集群，如果是全体集群的话，须要考虑到网关缩容、扩容时修正对应的限流数。分布式。分布式的就须要一个存储节点掩护当前接口的调用数，比如redis、sentinel等，这种办法由于涉及到远程调用，会有些性能损耗，其余也须要考虑到存储挂掉的问题，比如redis如果挂掉，网关须要考虑降级方案，是降级到本地限流，还是直接将限流功能本身降级掉。其余还有不同的策略:大略计数、令牌桶等，大部分场景下实在大略计数已经够用了，但如果须要支持突发流量等场景时，可以采取令牌桶等方案。还须要考虑根据什么限流，比如是IP、接口、用户维度、还是要求参数中的某些值，这里可以采取表达式，相比拟较灵巧。稳定性
稳定性是网关非常主要的一环，监控、告警须要做的很完善才可以，比如接口调用量、相应韶光、非常、缺点码、成功率等干系的监控告警，还有线程池干系的一些，比如生动线程数、行列步队积压等，还有些系统层面的，比如CPU、内存、FullGC这些基本的。网关是所有做事的入口，对付网关的稳定性的哀求相对付其他做事会更高，最好能够一贯稳定的运行，只管即便少重启，但当新增功能、或者加日志排查问题时，不可避免的须要重新发布，因此可以参考zuul的办法，将所有的核心功能都基于不同的拦截器实现，拦截器的代码采取Groovy编写，存储到数据库中，支持动态加载、编译、运行，这样在出了问题的时候能够第一韶光定位并办理，并且如果网关须要开拓新功能，只须要增加新的拦截器，并动态添加到网关即可，不须要重新发布。
熔断降级
熔断机制也是非常主要的一项。若某一个做事挂掉、接口相应严重超时等发生，则可能全体网关都被一个接口拖垮，因此须要增加熔断降级，当发生特定非常的时候，对接口降级由网关直接返回，可以基于Hystrix或者Resilience4j实现。
日志
由于所有的要求都是由网关处理的，因此日志也须要相比拟较完善，比如接口的耗时、要求办法、要求IP、要求参数、相应参数(把稳脱敏)等，其余由于可能涉及到很多微做事，因此须要供应一个统一的traceId方便关联所有的日志，可以将这个traceId置于相应头中，方便排查问题。
隔离
比如线程池、http连接池、redis等运用层面的隔离，其余也可以根据业务场景，将核心业务支配带单独的网关集群，与其他非核心业务隔离开。
网关管控平台
这块也是非常主要的一环，须要考虑好全体流程的用户体验，比如接入到网关的这个流程，能不能只管即便简化、智能，比如如果是dubbo接口，我们可以通过到git仓库中获取源码、解析对应的类、方法，从而实现自动添补，只管即便帮用户减少操作；其余接口一样平常是从测试->预发->线上，如果每次都要填写一遍表单会非常麻烦，我们能不能自动把这个事情做掉，其余如果网关支配到了多个可用区、乃至不同的国家，那这个时候，我们还须要接口数据同步功能，不然用户须要到每个后台都操作一遍，非常麻烦。这块个人的建议是直接参考阿里云、aws等供应的网关做事即可，功能非常全面。
其他
其他还有些须要考虑到的点，比如接口mock，文档天生、sdk代码天生、缺点码统一、做事管理干系的等，这里就不累述了。
总结目前的网通知样中央化的架构，所有的要求都须要走一次网关，因此昔时夜匆匆或者流量突增时，网关可能会成为性能的瓶颈，而且当网关接入的大量接口的时候，做好流量评估也不是一项随意马虎的事情，每次大匆匆前都须要跟业务方一起针对接口做压测，评估出大致的容量，并对网关进行扩容，而且网关是所有流量的入口，所有的要求都是由网关处理，要想准确的评估出容量很繁芜。可以参考目前比较盛行的ServiceMesh，采取去中央化的方案，将网关的逻辑下沉到sidecar中， sidecar和运用支配到同一个节点，并接管运用流入、流出的流量，这样大匆匆时，只须要对干系的业务压测，并针对性扩容即可，其余升级也会更平滑，中央化的网关，纵然灰度发布，但是理论上所有业务方的流量都会流入到新版本的网关，如果出了问题，会影响到所有的业务，但这种去中央化的办法，可以先针对非核心业务升级，不雅观察一段韶光没问题后，再全量推上线。其余ServiceMesh的方案，对付多措辞支持也更友好。
来源：http://github.com/aCoder2013/blog/issues/35
:-D 搜索微旗子暗记（ID：芋道源码），可以得到各种 Java 源码解析、事理讲解、口试题、学习指南。
:-D 并且，回答【书本】后，可以领取笔者推举的各种 Java 从入门到架构的 100 本书本。
:-D 并且，回答【技能群】后，可以加入专门谈论 Java、后端、架构的技能群。
来吧，骚年~
