本文目录导航：
API网关从入门到丢弃
假定你正在开发一个电商网站，那么这里会触及到很多后端的微服务，比如会员、商品、介绍服务等等。
那么这里就会遇到一个疑问，APP/Browser怎样去访问这些后端的服务? 假设业务比拟繁难的话，可以给每个业务都调配一个独立的域名(，但这种形式会有几个疑问:
更好的形式是驳回API网关，成功一个API网关接收一切的入口流量，相似Nginx的作用，将一切用户的恳求转发给后端的主机，但网关做的不只仅只是繁难的转发，也会针对流量做一些裁减，比如鉴权、限流、权限、熔断、协定转换、失误码一致、缓存、日志、监控、告警等，这样将通用的逻辑抽进去，由网关一致去做，业务方也能够更专一于业务逻辑，优化迭代的效率。
经过引入API网关，客户端只有要与API网关交互，而不用与各个业务方的接口区分通信，但多引入一个组件就多引入了一个潜在的缺点点，因此要成功一个高性能、稳固的网关，也会触及到很多点。
API 注册
业务方如何接入网关?普通来说有几种形式。
协定转换
外部的API或许是由很多种不同的协定成功的，比如HTTP、Dubbo、GRPC等，但关于用户来说其中很多都不是很友好，或许基本没法对外泄露，比如Dubbo服务，因此须要在网关层做一次性协定转换，将用户的HTTP协定恳求，在网关层转换成底层对应的协定，比如HTTP -> Dubbo, 但这里须要留意很多疑问，比如参数类型，假设类型搞错了，造成转换出疑问，而日志又不够详细的话，疑问会很难定位。
服务发现
网关作为流量的入口，担任恳求的转发，但首先须要知道转发给谁，如何寻址，这里有几种形式:
服务调用
网关由于对接很多种不同的协定，因此或许须要成功很多种调用形式，比如HTTP、Dubbo等，基于性能要素，最好都驳回异步的形式，而Http、Dubbo都是允许异步的，比如apache就提供了基于NIO成功的异步HTTP客户端。
由于网关会触及到很多异步伐用，比如阻拦器、HTTP客户端、dubbo、redis等，因此须要思考下异步伐用的形式，假设基于回调或许future的话，代码嵌套会很深，可读性很差，可以参考zuul和spring cloud gateway的打算，基于照应式启动变革。
优雅下线
性能
网关作为一切流量的入口，性能是重中之重，早期大局部网关都是基于同步阻塞模型构建的，比如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等大促时，接口的恳求量是往常的数倍，假设没有评价好容量，又没有做限流的话，很容易服务整个无法用，因此须要依据业务方接口的处置才干，做好限流战略，置信大家都见过淘宝、网络抢红包时的升级页面。
因此必定要在接入层做好限流战略，关于非外围接口可以间接将升级掉，保证外围服务的可用性，关于外围接口，须要依据压测时失掉的接口容量，制订对应的限流战略。限流又分为几种:
稳固性
稳固性是网关十分关键的一环，监控、告警须要做的很完善才可以，比如接口调用量、照应期间、意外、失误码、成功率等相关的监控诉警，还有线程池相关的一些，比如生动线程数、队列积压等，还有些系统层面的，比如CPU、内存、FullGC这些基本的。
网关是一切服务的入口，关于网关的稳固性的要求相关于其余服务会更高，最好能够不时稳固的运转，尽量少重启，但当新增配置、或许加日志排查疑问时，无法防止的须要从新颁布，因此可以参考zuul的形式，将一切的外围配置都基于不同的阻拦器成功，阻拦器的代码驳回Groovy编写，存储到数据库中，允许灵活加载、编译、运转，这样在出了疑问的时刻能够第一期间定位并处置，并且假设网关须要开发新配置，只有要参与新的阻拦器，并灵活参与到网关即可，不须要从新颁布。
熔断升级
熔断机制也是十分关键的一项。
若某一个服务挂掉、接口照应重大超时等出现，则或许整个网关都被一个接口拖垮，因此须要参与熔断升级，当出现特定意外的时刻，对接口升级由网关间接前往，可以基于Hystrix或许Resilience4j成功。
日志
由于一切的恳求都是由网关处置的，因此日志也须要相对比拟完善，比如接口的耗时、恳求形式、恳求IP、恳求参数、照应参数(留意脱敏)等，另外由于或许触及到很多微服务，因此须要提供一个一致的traceId繁难关联一切的日志，可以将这个traceId置于照应头中，繁难排查疑问。
隔离
比如线程池、http衔接池、redis等运行层面的隔离，另外也可以依据业务场景，将外围业务部署带独自的网关集群，与其余非外围业务隔退出。
网关管控平台
这块也是十分关键的一环，须要思考好整个流程的用户体验，比如接入到网关的这个流程，能不能尽量简化、智能，比如假设是dubbo接口，咱们可以经过到git仓库中失掉源码、解析对应的类、方法，从而成功智能填充，尽量帮用户缩小操作；另外接口普通是从测试->预发->线上，假设每次都要填写一遍表单会十分费事，咱们能不能智能把这个事件做掉，另外假设网关部署到了多个可用区、甚至不同的国度，那这个时刻，咱们还须要接口数据同步配置，不然用户须要到每个后盾都操作一遍，十分费事。
这块团体的倡导是间接参考阿里云、aws等提供的网关服务即可，配置十分片面。
其余
其余还有些须要思考到的点，比如接口mock，文档生成、sdk代码生成、失误码一致、服务控制相关的等，这里就不累述了。
目前的网关还是中心化的架构，一切的恳求都须要走一次性网关，因此当大促或许流量突增时，网关或许会成为性能的瓶颈，而且当网关接入的少量接口的时刻，做好流量评价也不是一项容易的上班，每次大促前都须要跟业务方一同针对接口做压测，评价出大抵的容量，并对网关启动扩容，而且网关是一切流量的入口，一切的恳求都是由网关处置，要想准确的评价出容量很复杂。可以参考目前比拟盛行的ServiceMesh，驳回去中心化的打算，将网关的逻辑下沉到sidecar中，
sidecar和运行部署到同一个节点，并接收运行流入、流出的流量，这样大促时，只有要对相关的业务压测，并针对性扩容即可，另外更新也会更平滑，中心化的网关，即使灰度颁布，然而通常上一切业务方的流量都会流入到新版本的网关，假设出了疑问，会影响到一切的业务，但这种去中心化的形式，可以先针对非外围业务更新，观察一段期间没疑问后，再全量推上线。
另外ServiceMesh的打算，关于多言语允许也更友好。
究竟什么是api网关
API网关是一个主机，是系统的惟一入口。
从面向对象设计的角度看，它与外观形式相似。
API网关封装了系统外部架构，为每个客户端提供一个定制的API。
它或许还具备其它职责，如身份验证、监控、负载平衡、缓存、恳求分片与控制、静态照应处置。
API网关形式的外围要点是，一切的客户端和生产端都经过一致的网关接入微服务，在网关层处置一切的非业务配置。
通常，网关也是提供REST/HTTP的访问API。
API网关出现的要素是微服务架构的出现，不同的微服务普通会有不同的网络地址。
API网关的好处。
随着软件规模的日益宏大，咱们须要把复杂系统划分红小的组成局部，编程接口的设计十分关键。
程序设计的通常中，编程接口的设计首先要使系统的职责失掉正当划分。
良好的接口设计可以降落系统各局部的相互依赖，提高组成单元的内聚性，降落组成单元间的耦合水平，从而提高系统的保养性和裁减性。
微服务架构访问数据库有哪些形式
微服务架构访问数据库关键有以下几种形式：间接访问、经过API网关访问以及经常使用数据库代理。
1. 间接访问：在微服务架构中，每个微服务都可以间接与其所需的数据库启动交互。
这种形式繁难间接，每个服务独立地控制自己的数据访问逻辑。
例如，一个订单服务或许间接衔接到一个相关型数据库（如MySQL）以失掉订单消息。
间接访问的长处在于其繁难性和低提前，但缺陷是或许造成数据库衔接过多，难以启动集中式的数据库控制和优化。
2. 经过API网关访问：API网关作为微服务架构中的繁多入口点，可以处置客户端恳求并路由到相应的微服务。
在某些状况下，API网关也可以作为数据库访问的代理。
这象征着客户端的恳求首先经过API网关，而后由网关与数据库启动交互，并将结果前往给客户端。
这种形式可以成功恳求的一致控制和安保控制，但或许会参与额外的提前和复杂性。
3. 经常使用数据库代理：数据库代理是一个位于运行程序和数据库之间的两边件，它可以控制、路由和优化数据库恳求。
在微服务架构中，可以经常使用数据库代理来集中控制多个微服务的数据库访问。
例如，分片数据库代理（如Vitess）可以将恳求路由到正确的数据库分片，从而成功数据的水平裁减。
数据库代理还可以提供负载平衡、缓存、分片、缺点切换等配置，有助于提高数据库的性能和可用性。
在选用微服务架构访问数据库的形式时，须要掂量各种要素，包含系统的复杂性、性能要求、安保性需求以及团队的技术栈和阅历。
间接访问形式实用于繁难、低提前的场景，而经过API网关或数据库代理访问则更适宜须要一致控制、优化和安保控制的复杂系统。
在实践运行中，可以依据详细状况灵敏选用或组合经常使用这些形式。
