dubbo+zookeeper专题

  dubbo使应用能够通过RPC远程调用来调用服务，接口与实现分离，使应用间解耦，zookeeper作为注册中心，所有服务提供者与服务消费者之间都注册到dubbo上，也可使用redis作为注册中心。zookeeper默认推荐，当服务提供者与校服这注册到zookeeper上时，这时会产生一个树形结构，会为每一个暴露的接口在zookeeper上建立一个节点，每个接口下会显示该接口的服务提供者与消费者，这样当服务启动时，服务调用者获取zookeeper里面去找提供服务的列表，找到了会缓存到自己本地，这时调用如果有多个服务则会根据自己的负载均衡算法去选择一个服务进行调用，当服务列表发生变化时，服务监听zookeeper事件，zookeeper会通知调用者重新更新服务器列表，这样即使zookeeper注册中心挂掉，也不会影响正常服务调用，当服务数量较多，可增加zookeeper集群提高注册中心可用性。zookeeper提供idea与eclipse插件。

这个时候会延伸出一个问题，dubbo只是提供服务治理以及对注册服务进行发现，服务之间的安全授权、统一服务网关、配置中心、服务熔断又是如何处理？

  统一网关服务：如果只是单纯做负载均衡，可使用nginx对dubbo服务在进行一次路由，如果有多个不同服务做集群，比如订单服务近集群与商品服务集群，这是需要将订单服务所有地址配置成一个路由，商品服务所有地址配置一个路由，然后再在上层在添加一个路由，如gateway/order路由到订单服务，对个订单服务会从中挑选一个，gateway/goods路由到商品服务，这样可以做到统一入口从gateway进入，但是缺点也显而易见，当服务数量比较大时，维护麻烦，并且需要手工去添加新加的服务或删掉去掉的服务，并且很难扩展，比如在网关处做权限安全控制。这就提到另一种网关实现方式，自定义网关。

  自定义网关也是一个dubbo服务，注册到zookeeper上，主要是为了注册中心对所有服务有一个很好的监测，自定义网关首先从zookeeper上拿到注册的服务提供者的信息，同时对zookeeper做一个监听，路径发生变化会相应的去更新服务信息，同时对所有请求做一个拦截，根据地址能够知道是请求那个服务，参数以及请求路径，这是就可以根据从zookeeper拿到的服务信息，如果服务提供者只有一个就直接封装好相应的参数直接路由到相应的服务，如果服务提供者有多个，这是就需要做负载均衡去选择其中一个去调用，这里提供三种算法规则：随机算法，权重算法，活跃量算法。随机算法就比较简单，随机从众多服务中选取一个，这个比较适合个服务器性能差不多，单机访问量能够支撑大部分请求，权重算法是给服务设置一个权重，请求按照权重比例随机分发到服务集群，权重越大，路由到该服务器上的可能性越大，这种比较适合个服务器性能不一致，性能高的服务承载的请求就越大，活跃量算法是将每个请求做一个统计，每个请求到那个服务有一个计数，请求少的后面的请求就分发到该服务器上，这样能够保证各服务器均摊请求。

同时网关还需要解决高并发的问题，当大量请求到达网关时，网关应该如何处理？

  可实现两种方案，一种信号量隔离，一种线程池隔离，型号量隔离就比较简单，请求某服务同时达到某个数量，比如500次，其他请求就直接拒绝服务，这种方案的优点和缺点很明显，对网关服务的负载也是最小的，但对高并发电商可能就不合适，另一种线程池隔离，每一个路由使用自己单独的线程池，这样就降低了不同业务线之间的影响，线程池应该设置线程池大小，线程存活时间，最大队列长度等等。超高并发时，网关应该做负载均衡集群，并且网关的集群规模应该比较大，因为网关是对所有请求相当于做了一次前置处理。

如何对dubbo服务进行安全授权处理？

  权限处理可以放在网关处处理，也可放到服务单独去处理，权限框架现热度高的有springsecurity与shiro，也可自定义权限处理，权限框架应该是统一授权与鉴权，数据存储也应该是在公共地方，其他服务都可访问到，只是权限框架再封装一层而已。