精华内容
下载资源
问答
  • MOXA串口网关工作不正常解决方法

    千次阅读 2016-04-10 18:52:56
    工作中经常会用到MOXA的5110网关,有时会出现配置正常但是串口死活打不开的情况,最后反复排查发现是使用的惠普商用机自带的WINDOWS 7家庭版系统的缘故。更换为旗舰版后MOXA网关工作正常
    工作中经常会用到MOXA的5110网关,有时会出现配置正常但是串口死活打不开的情况,最后反复排查发现是使用的惠普商用机自带的WINDOWS 7家庭版系统的缘故。更换为旗舰版后MOXA网关工作正常。
    
    展开全文
  • 判断IP和网关或者两个IP地址是否在同一个网段,将它们的IP地址分别与子网掩码做与运算,得到的结果为网络号,如果网络号相同,就在同一子网,否则,不在同一子网。 java代码: import java.util.regex.Pattern; ...

    要判断IP和网关或者两个IP地址是否在同一个网段,将它们的IP地址分别与子网掩码做与运算,得到的结果为网络号,如果网络号相同,就在同一子网,否则,不在同一子网。

    js代码:

    /**
        * [isEqualIPAddress 判断两个IP地址是否在同一个网段]
        * @param {[String]} addr1 [地址一]
        * @param {[String]} addr2 [地址二]
        * @param {[String]} mask [子网掩码]
        * @return {Boolean} [true or false]
        */
        function isEqualIPAddress (addr1,addr2,mask){
    	    if(!addr1 || !addr2 || !mask){
    		    // 各参数不能为空
    		    return false;
    	    }
    	    var
    	    res1 = [],
    	    res2 = [];
    	    addr1 = addr1.split(".");
    	    addr2 = addr2.split(".");
    	    mask = mask.split(".");
    	    for(var i = 0,ilen = addr1.length; i < ilen ; i += 1){
    		    res1.push(parseInt(addr1[i]) & parseInt(mask[i]));
    		    res2.push(parseInt(addr2[i]) & parseInt(mask[i]));
    	    }
    	    if(res1.join(".") == res2.join(".")){
    		    // 在同一个网段
    		    return true;
    	    }else{
    		    // 不在同一个网段
    		    return false;
    	    }
        }
    

    java代码:

     
    import java.util.regex.Pattern;
     
    /**
    * <pre>
    * IP地址范围:
    * 0.0.0.0~255.255.255.255,包括了mask地址。
    *
    * IP地址划分:
    * A类地址:1.0.0.1~126.255.255.254
    * B类地址:128.0.0.1~191.255.255.254
    * C类地址:192.168.0.0~192.168.255.255
    * D类地址:224.0.0.1~239.255.255.254
    * E类地址:240.0.0.1~255.255.255.254
    *
    * 如何判断两个IP地址是否是同一个网段中:
    * 要判断两个IP地址是不是在同一个网段,就将它们的IP地址分别与子网掩码做与运算,得到的结果一网络号,如果网络号相同,就在同一子网,否则,不在同一子网。
    * 例:假定选择了子网掩码255.255.254.0,现在分别将上述两个IP地址分别与掩码做与运算,如下图所示:
    * 211.95.165.24 11010011 01011111 10100101 00011000
    * 255.255.254.0 11111111 11111111 111111110 00000000
    * 与的结果是: 11010011 01011111 10100100 00000000
    *
    * 211.95.164.78 11010011 01011111 10100100 01001110
    * 255.255.254.0 11111111 11111111 111111110 00000000
    * 与的结果是: 11010011 01011111 10100100 00000000
    * 可以看出,得到的结果(这个结果就是网络地址)都是一样的,因此可以判断这两个IP地址在同一个子网。
    *
    * 如果没有进行子网划分,A类网络的子网掩码为255.0.0.0,B类网络的子网掩码为255.255.0.0,C类网络的子网掩码为255.255.255.0,缺省情况子网掩码为255.255.255.0
    *
    * @author Slive
    */
    public class IpV4Util{
         // IpV4的正则表达式,用于判断IpV4地址是否合法
         private static final String IPV4_REGEX = "((\\d|[1-9]\\d|1\\d{2}|2[0-4]\\d|25[0-5])(\\.(\\d|[1-9]\\d|1\\d{2}|2[0-4]\\d|25[0-5])){3})";
        
         /**
         * 比较两个ip地址是否在同一个网段中,如果两个都是合法地址,两个都是非法地址时,可以正常比较;
         * 如果有其一不是合法地址则返回false;
         * 注意此处的ip地址指的是如“192.168.1.1”地址
         * @return
         */
         public static boolean checkSameSegment(String ip1,String ip2, String mask){
        	 int maskInt = getIpV4Value(mask);
              // 判断IPV4是否合法
              if(!ipV4Validate(ip1)){
                   return false;
              }
              if(!ipV4Validate(ip2)){
                   return false;
              }
              int ipValue1 = getIpV4Value(ip1);
              int ipValue2 = getIpV4Value(ip2);
              return (maskInt & ipValue1) == (maskInt & ipValue2);
         }
       
         /**
         * 判断ipV4或者mask地址是否合法,通过正则表达式方式进行判断
         * @param ipv4
         */
        public static boolean ipV4Validate(String ipv4){
             return ipv4Validate(ipv4,IPV4_REGEX);
        }
       
        private static boolean ipv4Validate(String addr,String regex){
              if(addr == null)
              {
                  return false;
             }
             else
             {
                  return Pattern.matches(regex, addr.trim());
             }
         }
     
         public static int getIpV4Value(String ipOrMask){
              byte[] addr = getIpV4Bytes(ipOrMask);
              int address1  = addr[3] & 0xFF;
              address1 |= ((addr[2] << 8) & 0xFF00);
              address1 |= ((addr[1] << 16) & 0xFF0000);
              address1 |= ((addr[0] << 24) & 0xFF000000);
              return address1;
         }
     
         public static byte[] getIpV4Bytes(String ipOrMask){
              try{
                   String[] addrs = ipOrMask.split("\\.");
                   int length = addrs.length;
                   byte[] addr = new byte[length];
                   for (int index = 0; index < length; index++){
                        addr[index] = (byte) (Integer.parseInt(addrs[index]) & 0xff);
                   }
                   return addr;
              }
              catch (Exception e)
              {
              }
              return new byte[4];
         }
         public static void main(String[] args) {
        	 String ip1 = "168.1.1.11";
        	 String ip2 = "168.1.2.254";
        	 String mask1 = "255.255.255.0";
        	 boolean b = checkSameSegment(ip1, ip2, mask1);
        	 System.out.println(b);
    	}
    }
    
    
    

    参考地址:
    1.https://www.jb51.net/article/44430.htm
    2.https://blog.csdn.net/lipslive/article/details/10776381#

    展开全文
  • 网关

    2019-09-21 18:41:18
    每上线一个新的服务,都需要运维参与,申请域名、配置Nginx等,当上线、下线服务器时,同样也需要运维参与,另外采用域名这种方式,对于环境的隔离也不太友好,调用者需要自己根据域名自己进行判断。 另外...

     

    假设你正在开发一个电商网站,那么这里会涉及到很多后端的微服务,比如会员、商品、推荐服务等等。

     

    那么这里就会遇到一个问题,APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话,可以给每个业务都分配一个独立的域名(https://service.api.company.com),但这种方式会有几个问题:
     

    • 每个业务都会需要鉴权、限流、权限校验等逻辑,如果每个业务都各自为战,自己造轮子实现一遍,会很蛋疼,完全可以抽出来,放到一个统一的地方去做。

    • 如果业务量比较简单的话,这种方式前期不会有什么问题,但随着业务越来越复杂,比如淘宝、亚马逊打开一个页面可能会涉及到数百个微服务协同工作,如果每一个微服务都分配一个域名的话,一方面客户端代码会很难维护,涉及到数百个域名,另一方面是连接数的瓶颈,想象一下你打开一个APP,通过抓包发现涉及到了数百个远程调用,这在移动端下会显得非常低效。

    • 每上线一个新的服务,都需要运维参与,申请域名、配置Nginx等,当上线、下线服务器时,同样也需要运维参与,另外采用域名这种方式,对于环境的隔离也不太友好,调用者需要自己根据域名自己进行判断。

    • 另外还有一个问题,后端每个微服务可能是由不同语言编写的、采用了不同的协议,比如HTTP、Dubbo、GRPC等,但是你不可能要求客户端去适配这么多种协议,这是一项非常有挑战的工作,项目会变的非常复杂且很难维护。

    • 后期如果需要对微服务进行重构的话,也会变的非常麻烦,需要客户端配合你一起进行改造,比如商品服务,随着业务变的越来越复杂,后期需要进行拆分成多个微服务,这个时候对外提供的服务也需要拆分成多个,同时需要客户端配合你进行改造,非常蛋疼。

     

    API Gateway

     

    更好的方式是采用API网关,实现一个API网关接管所有的入口流量,类似Nginx的作用,将所有用户的请求转发给后端的服务器,但网关做的不仅仅只是简单的转发,也会针对流量做一些扩展,比如鉴权、限流、权限、熔断、协议转换、错误码统一、缓存、日志、监控、告警等,这样将通用的逻辑抽出来,由网关统一去做,业务方也能够更专注于业务逻辑,提升迭代的效率。

     

    通过引入API网关,客户端只需要与API网关交互,而不用与各个业务方的接口分别通讯,但多引入一个组件就多引入了一个潜在的故障点,因此要实现一个高性能、稳定的网关,也会涉及到很多点。

     

    API注册

     

    业务方如何接入网关?一般来说有几种方式。

     

    • 第一种采用插件扫描业务方的API,比如Spring MVC的注解,并结合Swagger的注解,从而实现参数校验、文档&&SDK生成等功能,扫描完成之后,需要上报到网关的存储服务。

    • 手动录入。比如接口的路径、请求参数、响应参数、调用方式等信息,但这种方式相对来说会麻烦一些,如果参数过多的话,前期录入会很费时费力。

    • 配置文件导入。比如通过SwaggerOpenAPI等,比如阿里云的网关:

     

    协议转换

     

    内部的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的方案,对于多语言支持也更友好。

     

    展开全文
  • zuul网关

    2019-11-26 18:37:04
    zuul网关 Zuul路由网关简介及基本使用 简介 Zuul API路由网关服务简介 zuul是spring cloud中的微服务网关网关: 是一个网络整体系统中的前置门户入口。请求首先通过网关,进行路径的路由,定位到具体的服务节点上...

    zuul网关

    Zuul路由网关简介及基本使用

    简介

    Zuul API路由网关服务简介

    zuul是spring cloud中的微服务网关。
    网关: 是一个网络整体系统中的前置门户入口。请求首先通过网关,进行路径的路由,定位到具体的服务节点上。

    Zuul是一个微服务网关,首先是一个微服务。也是会在Eureka注册中心中进行服务的注册和发现。也是一个网关,请求应该通过Zuul来进行路由。

    Zuul网关不是必要的。是推荐使用的。
    使用Zuul,一般在微服务数量较多(多于10个)的时候推荐使用,对服务的管理有严格要求的时候推荐使用,当微服务权限要求严格的时候推荐使用。

    在这里插入图片描述

    请看上图,这里的API 路由网关服务 由Zuul实现,主要就是对外提供服务接口的时候,起到了请求的路由和过滤作用,也因此能够隐藏内部服务的接口细节,从来有利于保护系统的安全性;

    路由配置
    Zuul 路由配置

    我们新建一个module microservice-zuul-3001
    在这里插入图片描述
    这里我们的zuul也注册到eureka服务里,端口3001;

    我们修改下Hosts,专门为zuul搞个本地域名映射
    hosts文件 加下:

    127.0.0.1 zuul.xzy.com

    pom.xml

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
        <modelVersion>4.0.0</modelVersion>
        <parent>
            <groupId>com.xzy</groupId>
            <artifactId>springcloud</artifactId>
            <version>1.0-SNAPSHOT</version>
        </parent>
        <artifactId>microservice-zuul-3001</artifactId>
    
        <properties>
            <java.version>1.8</java.version>
        </properties>
    
        <dependencies>
            <dependency>
                <groupId>com.xzy</groupId>
                <artifactId>microservice-common</artifactId>
            </dependency>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-web</artifactId>
            </dependency>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-test</artifactId>
                <scope>test</scope>
            </dependency>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-starter-eureka</artifactId>
            </dependency>
            <!-- actuator监控 -->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-actuator</artifactId>
            </dependency>
            <!-- hystrix容错 -->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-starter-hystrix</artifactId>
            </dependency>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-starter-config</artifactId>
            </dependency>
            <!--zuul网关-->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-starter-zuul</artifactId>
            </dependency>
        </dependencies>
    
        <build>
            <plugins>
                <plugin>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-maven-plugin</artifactId>
                </plugin>
            </plugins>
        </build>
    
    </project>
    
    

    application.yml

    server:
      port: 3001
      context-path: /
    spring:
      application:
        name: microservice-zuul
    eureka:
      instance:
        instance-id: microservice-zuul:3001
        prefer-ip-address: true
      client:
        service-url:
          defaultZone: http://eureka2001.xzy.com:2001/eureka/,http://eureka2002.xzy.com:2002/eureka/,http://eureka2003.xzy.com:2003/eureka/
    info:
      groupId: com.xzy.springcloud
      artifactId: microservice-zuul-3001
      version: 1.0-SNAPSHOT
      userName: http://xzy.com
      phone: 7758258
    
    

    启动类
    加上 @EnableZuulProxy 注解

    package com.xzy.microservicezuul3001;
    
    import org.springframework.boot.SpringApplication;
    import org.springframework.boot.autoconfigure.SpringBootApplication;
    import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;
    import org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration;
    import org.springframework.cloud.netflix.zuul.EnableZuulProxy;
    
    @SpringBootApplication(exclude={DataSourceAutoConfiguration.class, HibernateJpaAutoConfiguration.class})
    @EnableZuulProxy
    public class MicroserviceZuul3001Application {
    
        public static void main(String[] args) {
            SpringApplication.run(MicroserviceZuul3001Application.class, args);
        }
    
    }
    
    

    我们测试下:
    启动三个eureka 然后再启动下一个1004,1006服务,以及 zuul网关服务;
    在这里插入图片描述

    这里有两个服务;

    我们直接请求:http://localhost/student/hystrix能获取到数据;
    在这里插入图片描述
    在这里插入图片描述

    我们用 http://zuul.xzy.com:3001/microservice-student/student/hystrix 域名+端口+服务名称+请求地址 也能请求到数据;
    在这里插入图片描述
    说明我们的路由基本配置OK

    Zuul路由映射配置

    上面是zuul的简单使用,从接口地址很轻易的就暴露了服务提供者的唯一标识名microservice-student;有安全风险,我们需要将其隐藏;

    ignored-services的作用是将原来的服务提供者唯一标识名禁用;
    Prefix的作用是给服务加前缀

    zuul:
      routes:
        studentServer.serviceId: microservice-student
        studentServer.path: /studentServer/**
      ignored-services: "*"
      prefix: /xzy
    

    配置完毕后可通过以下链接做测试
    http://zuul.xzy.com:3001/microservice-student/student/list
    http://zuul.xzy.com:3001/studentServer/student/list
    http://zuul.xzy.com:3001/xzy/microservice-student/student/list
    http://zuul.xzy.com:3001/xzy/studentServer/student/list

    在这里插入图片描述

    对应的配置会出现上面的错误页面,这是正常现象。

    Zuul请求过滤配置

    比如我们登录某个系统 需要身份验证,用户名密码啥的;

    我们请求服务,也可以来设置身份验证,也就是过滤非法请求;Zuul通过ZuulFilter过滤器实现;
    一般具体实现的话 每次经过Zuul服务网关 我们都对带来的token进行有效性验证;

    我们先定义一个 AccessFilter类:

    package com.xzy.microservicezuul3001.filter;
    
    import com.netflix.zuul.ZuulFilter;
    import com.netflix.zuul.context.RequestContext;
    import com.netflix.zuul.exception.ZuulException;
    import org.apache.log4j.Logger;
    
    import javax.servlet.http.HttpServletRequest;
    
    /**
     * @author XZY
     * @site www.Xzy.com
     * @company
     * @create  2019-11-26 11:35
     */
    public class AccessFilter extends ZuulFilter {
    
        Logger logger=Logger.getLogger(AccessFilter.class);
    
        /**
         * 判断该过滤器是否要被执行
         */
        @Override
        public boolean shouldFilter() {
            return true;
        }
    
        /**
         * 过滤器的具体执行逻辑
         */
        @Override
        public Object run() throws ZuulException {
            RequestContext ctx = RequestContext.getCurrentContext();
            HttpServletRequest request = ctx.getRequest();
            String parameter = request.getParameter("accessToken");
            logger.info(request.getRequestURL().toString()+" 请求访问");
            if(parameter==null){
                logger.error("accessToken为空!");
                ctx.setSendZuulResponse(false);
                ctx.setResponseStatusCode(401);
                ctx.setResponseBody("{\"result\":\"accessToken is empty!\"}");
                return null;
            }
            //  token判断逻辑
            logger.info(request.getRequestURL().toString()+" 请求成功");
            return null;
        }
    
        /**
         * 过滤器的类型 这里用pre,代表会再请求被路由之前执行
         */
        @Override
        public String filterType() {
            return "pre";
        }
    
        /**
         * 过滤器的执行顺序
         */
        @Override
        public int filterOrder() {
            return 0;
        }
    
    }
    

    然后再开启下 Filter配置:

    package com.xzy.microservicezuul3001.config;
    
    import com.xzy.microservicezuul3001.filter.AccessFilter;
    import org.springframework.context.annotation.Bean;
    import org.springframework.context.annotation.Configuration;
    
    @Configuration
    public class ZuulConfig {
    
        @Bean
        public AccessFilter accessFilter(){
            return new AccessFilter();
        }
    }
    
    

    在这里插入图片描述

    浏览器输入地址进行测试

    http://zuul.xzy.com:3001/xzy/studentServer/student/list

    http://zuul.xzy.com:3001/xzy/studentServer/student/list?accessToken=1
    在这里插入图片描述

    在这里插入图片描述

    zuul网关配置总结

    网关配置方式有多种,默认、URL、服务名称、排除|忽略、前缀。
    网关配置没有优劣好坏,应该在不同的情况下选择合适的配置方案。
    zuul网关其底层使用ribbon来实现请求的路由,并内置Hystrix,可选择性提供网关fallback逻辑。使用zuul的时候,并不推荐使用Feign作为application client端的开发实现。毕竟Feign技术是对ribbon的再封装,使用Feign本身会提高通讯消耗,降低通讯效率,只在服务相互调用的时候使用Feign来简化代码开发就够了。而且商业开发中,使用Ribbon+RestTemplate来开发的比例更高。

    over~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    展开全文
  • Gateway网关简介及使用

    万次阅读 多人点赞 2019-10-09 20:54:12
    Gateway网关简介及使用 1. 什么是 API 网关(API Gateway) 分布式服务架构、微服务架构与 API 网关 在微服务架构里,服务的粒度被进一步细分,各个业务服务可以被独立的设计、开发、测试、部署和管理。这时,各个...
  • 故障现象:服务器B ping路由器网关地址192.168.1.1会出现间歇性丢包,服务器A ping路由器网关地址192.168.1.1正常,服务器B ping服务器A正常。 网络环境,如下图所示: 根据故障表现形式基本可以判定为单机网络...
  • 微服务网关

    2021-02-02 19:35:06
    微服务网关概述 在学习完前面的知识后,微服务架构已经初具雏形。但还有一些问题: 不同的微服务一般会有不同的网络地址 客户端在访问这些微服务时必须记住几十甚至几百个地址 这对于客户端方来说太复杂也难以维护。...
  • 网关配置

    万次阅读 2019-06-08 11:49:00
    网关配置 1. 什么是网关网关(Gateway)又称 网间连接器 、协议转换器。网关在传输层上以实现网络互连,是最复杂的网络互连设备,仅用于两个高层协议不同的网络互连。网关的结构也和路由器类似,不同的是互连层。...
  • API网关

    2020-07-27 21:11:04
    网关一词最早出现在网络设备,比如两个相互独立的局域网之间通过路由器进行通信,中间的路由器就被称为网关 任何一个应用系统如果需要被其他系统调用,就需要暴露API,这些API代表着一个一个功能点 如果两个系统中间...
  • Zuul网关

    2020-05-18 11:54:20
    1、基本架构 2、网关的功能 3、过滤器生命周期 4、统一鉴权
  • VXLAN网关

    千次阅读 2018-05-03 22:42:52
    VXLAN网关    首先,补充一下现在流行的OverLay技术: VXLAN: VXLAN是将以太网报文封装成UDP报文进行隧道传输,UDP目的端口为4798(可修改),标准5元组方式有利于在IP网络转发过程中进行负载分担;隔离标识...
  • 简易聊天系统-网关

    2020-05-14 11:19:57
    网关接受来自用户的数据并判断其类型,未登录用户不能发送非登录类型数据,确认正常数据后直接存进消息队列中。并且接受来自消息队列传来的信息,转发至对应客户端中。 接受来自客户端的数据: func.
  • 本章节要使用网关校验用户的身份是否合法。1.2 Zuul介绍 什么是Zuul? Spring Cloud Zuul是整合Netflflix公司的Zuul开源项目实现的微服务网关,它实现了请求路由、负载均衡、校验过 虑等 功能。 官方:...
  • zuul 网关基本入门

    2019-11-26 20:36:58
    zuul 网关入门Zuul路由网关简介及基本使用Zuul 路由配置Zuul 映射配置Zuul 请求过滤配置 本章知识: 1、Zuul 路由网关 简介 及 基本使用 2、Zuul 路由映射配置 3、Zuul 请求过滤配置 Zuul路由网关简介及基本使用 ...
  • 微服务网关Zuul

    2021-03-15 16:35:37
    1 微服务网关概述 不同的微服务一般会有不同的网 络地址,客户端在访问这些微服务时必须记住几十甚至几百个地址,这对于客户端方来说太复杂也难以 维护。如下图: 如果让客户端直接与各个微服务通讯,可能会有很多...
  • 网关、子网掩码

    2019-11-15 16:54:06
    1.什么是网关 大家都知道,从一个房间走到另一个房间,必然要经过一扇门。同样,从一个网络向另一个网络发送信息,也必须经过一道“关口”,这道关口就是网关。顾名思义,网关(Gateway)就是一个网络连接到另一个...
  • 虚拟网关与正规网关的区别

    千次阅读 2012-08-02 13:14:45
    1、虚拟网关(又叫卡发)发送后短信号码显示有以下几种:手机号如+8613100898232,模拟网关号码(10657+手机号)如1065713026589214,小灵通卡号如05926564235 2、正规网关显示的号码根据选择的运营商不同而不同,...
  • 网关ip

    2017-09-03 22:15:33
    这对于采用TCP/IP协议的网络来说非常重要,只有通过子网掩码,才能表明一台主机所在的子网与其他子网的关系,使网络正常工作。 常用的子网掩码子网掩码有数百种,这里只介绍最常用的两种子网掩码,它们分别是...
  • 网关uid管理

    2019-09-28 16:48:14
    1)上一节课我们完整的讲完了游客登录,登录成功以后,我们说过,网关有一个uid的管理, 我们需要注意: 因为对于我们的游戏服务器而言,所有的数据包都是网关转过来的,那么 网关怎么知道是哪个用户转的,那么这个时候,当...
  • 很多朋友多次问到什么是网关、dns、子网掩码,它有什么作用,确实,我们平时在网络中总是在不断的提到网关,却很少真正的去了解它。例:一、什么是网关一、什么是网关网关(Gateway)又称网间连接器、协议转换器。网关...
  • 服务网关Gateway

    2021-04-12 20:57:05
    服务网关Gateway 1.1 Gateway概述 网关旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。 在微服务架构中,不同的微服务可以有不同的网络地址,各个微服务之间通过互相调用完成用户请求,客户端可能通过...
  • Zuul路由网关

    2020-01-19 17:43:53
    目录Zuul路由网关简介及基本使用简介基本使用Zuul路由映射配置Zuul请求过滤配置 Zuul路由网关简介及基本使用 简介 请看上图,这里的API 路由网关服务 由Zuul实现,主要就是对外提供服务接口的时候,起到了请求的...
  • 网关测试用例 功能测试

    千次阅读 2017-12-03 21:45:00
     在判断程序代码能否一直应用时,难免会对其功能进行测试,判断各个功能在现有的程序代码下能否正常工作。现在对网关断网的一些报警功能调试用例进行总结。  一.  测试编号:F-01  测试项目:网关断网红绿灯报警...
  • 本文准备围绕七个点来讲网关,分别是网关的基本概念、网关设计思路、网关设计重点、流量网关、业务网关、常见网关对比,对基础概念熟悉的朋友可以根据目录查看自己感兴趣的部分。什么是网关网关,很多地...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 32,007
精华内容 12,802
关键字:

如何判断网关是否正常