#技术分享#我所理解的【微服务】中的【网关】之001篇
“面对微服务时代”，感觉自己有点无所适从，仿佛一夜之间一切都需要微服务化，没有微服务的架构简直项目简直不值得去讲，言必称“微服务”行业的老大 Spring Cloud、以及前几年比较流行的 Ali 的 dubbo 框架。算是目前主流的两大微服务框架，目前SpringCloud 占据了主导地位，毕竟有专业的团队打理，而且可以与Spring家族系列更好的集成，逐渐成为了微服务框架的主力。
我们先忽略框架本身带给我们的限制，单纯的从【微服务】自身出发， 治理上存在哪些难点，为何要引入微服务【网关】的概念，并且把它独立为微服务中一个重要的【支撑域】，它在整个体系架构中，充当了什么样的角色....本章节内容是我对微服务业务本身的思考，不涉及具体的框架，所以......见仁见智读者自己揣摩。刨析问题我采用的是基于DDD的思维模式，DDD是一套分析分析问题方法论之一（搞的如同哲学似的.....），接下来的篇章，我们围绕【微服务网关】的开展阐述，以及他所解决的问题：
1、目前的【微服务】普遍采用Restful 风格对外发布服务，这就带来一个问题有待解决：每个微服务模块的启动需要监听一个给定的IP+端口地址，随着【微服务】模块的增加，监听的IP+端口 也会成线性增长，完成一个业务逻辑的处理有时候不是一个模块能搞定的，可能先后要调用很多个模块，每个模块都需要指导其他依赖模块的IP+端口，显然这样的治理成本会很高，故 这里引入 【微服务网关】的第一个功能点：充当Http代理的功能，类似设计模式上的 调停者模式，所有请求都发给他，由他在决定发送的实际地址是什么，所有【微服务】模块都基于网关模式来协作，效率的确提高很多，就算遇到某个【微服务】的重新部署，也只要动态修改 网关配置即可。
1.1 【微服务网关】既然有HTTP代理的功能，那么他应该具备代理的一些特性，例如 故障转移 抑或 负载均衡， 系统在运行的过程中如果某个【微服务】的运算量比较大，消耗的CPU内存资源过高，需要把该服务进行独立多点部署，说白了就是把单点【微服务】 部署为多点【微服务】 以量多取胜，用于缓解大量请求下的负载处理，但是对于调用者而言，他只知道【微服务网关】，有【网关】来自动分配该请求到底应该发给那个处理。
1.2 目前的主流网关都待主动注册功能，把自己的信息主动告诉给网关，协助网关完成其配置。 如果说Http代理是很多Http服务器已经标配的功能，但是自动注册功能，目前还不具备
2、健康主动检测功能，大量的【微服务】模块分布在不同的服务器上，每个微服务的运行情况如何，则需要一个统一的管理平台，网关恰好成为充当这个角色的承载着，首先他指导并了解每个微服务的具体位置，每个微服务有自带一套标准的性能检测接口，定时被动与网关发生通信（可主动 可被动，类似TCP的心跳机制），完成健康状况的上报，例如 内存使用、CPU使用，IO操作等一些粗粒度的性能参数，如果设计到了 负载均衡的时候，这些参数就可以判断那个【微服务】模块可以接受更多的请求等。 我也是在做的过程中发现，需要监控，很有用也很有必要。发不后的健康问题，是我在做微服务模块的时候深刻体会到的。
2.1 健康检测带来的一个附加功能就是 熔断机制的诞生，网关可以清晰的了解到，那个微服务状态欠佳，或者已经GameOver 了，网关就可提前预知，如果该节点是执行某个业务流程中的某一个环节，那么整个业务流程都需要被中止掉。这就是熔断，把异常的信息前置了，当业务复杂度上来后，这一点的存在也是至关重要的。
3、限流机制，这也是网关功能，就是限制某个请求或者某一类请求的最大并发量，超过这个并发就就需要丢弃该请求，这样可以有效的保护业务【微服务】运行维持在一个较为合理的范围内，避免出现一些不必要的异常，最系统进行有效的防护。这一点在项目中也有尝试使用，仅仅是用来监控具体请求调用的次数，先写入Cache，在按照固定的频率把Cache的数据持久化到数据库，如果 间隔是 1s 或者 100ms 都可以的，该项是可配置项。
4、中断执行其他逻辑，网关需要在收到用户的业务请求之后，保持当前的请求，自己在完成其他的请求，之后在执行之前的请求继续，这一点使用比较多的用来做鉴权以及用户登录认证。当一个用户请求业务时，网关拦截到请求后，先从请求头拿到Token值，先对Token值进行验证，通过的情况下，在完成其业务逻辑的其他部分。这个过程必须要轻量化........，期间还可以有其他的一些拦截，也可以通过 Sevlte-filter 完成....
5、流程装配能力：完成一个业务逻辑的处理可能先后要调用不同的逻辑模块完成，这个业务逻辑过程的调用依赖应该在 这一层完成装配，同时也配合熔断机制完成熔断的监听。 这些配置项都应该时灵活配置可热加载。
上述只是从理论上来论述【微服务网关】的一些特点，他与Http代理还是有很大区别的。也是本人对 微服务网关 的一些理解。。。 毕竟我也在学习中~~~ZUUL 目前时一个不错的网关实现。
网关如此重要，单点故障一定要避免的，这时需要在网关外层增加一个 http的代理，再来一次LB的解析，分解单点故障能力~~~~
以上是 #技术分享#我所理解的【微服务】中的【网关】之001篇 的全部内容， 来源链接： utcz.com/z/511452.html
