API 网关从入门到放弃

API 网关从入门到放弃**

假设你正在开发一个电商网站，那么这里会涉及到不少后端的微服务，好比会员、商品、推荐服务等等

网关因为对接不少种不一样的协议，所以可能须要实现不少种调用方式，好比HTTP、Dubbo等，基于性能缘由，最好都采用异步的方式，而Http、Dubbo都是支持异步的，好比apache就提供了基于NIO实现的异步HTTP客户端。由于网关会涉及到不少异步调用，好比拦截器、HTTP客户端、dubbo、redis等，所以须要考虑下异步调用的方式，若是基于回调或者future的话，代码嵌套会很深，可读性不好，能够参考zuul和spring cloud gateway的方案，基于响应式进行改

而异步化的方式则彻底不一样，一般状况下一个CPU核启动一个线程便可处理全部的请求、响应。一个请求的生命周期再也不固定于一个线程，而是会分红不一样的阶段交由不一样的线程池处理，系统的资源可以获得更充分的利用。并且由于线程再也不被某一个链接独占，一个链接所占用的系统资源也会低得多，只是一个文件描述符加上几个监听器等，而在阻塞模型中，每条链接都会独占一个线程，而线程是一个很是重的资源。对于上游服务的延迟状况，也可以获得很大的缓解，由于在阻塞模型中，慢请求会独占一个线程资源，而异步化以后，由于单条链接所占用的资源变的很是低，系统能够同时处理大量的请求。

**