传统开发方式，所有的服务都是本地的，UI可以直接呼叫，现在功能拆分成独立的服务，跑在独立的虚拟机器上的java程序了。客户端如何访问他呢？
后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不符合我们拆分的理念。微服务在系统内部通常无状态，使用者登入资讯和许可权管理最后有个统一的地方维护管理（OAuth）。
不同的微服务有不同的网络地址，而外部的客户端可能要呼叫多个服务的接口才能完成一个业务需求。比如一个电影购票可能呼叫使用者微服务，电影微服务等，如果客户端直接和微服务通讯，会存在如下常见问题：
客户端多次请求不同微服务，增加客户端的复杂性跨域问题，一定场景下处理相对复杂认证复杂，每个服务都要独立认证难重构，随着专案迭代，可能需重新划分微服务，重构难以实施某些微服务可能使用了其他协议，直接访问会有问题以上问题可以借助微服务闸道器API Gateway来解决，微服务闸道器介于客户端和服务器端之间，所有的外部请求都会先经过微服务闸道器：
这样客户端只需和闸道器互动，无需直接呼叫特定微服务的界面，方便监控，易于认证，减少客户端和各微服务间的互动。
Zuul
Zuul作用：
提供统一服务入口，微服务对前台透明聚合后台服务，节省流量，提升效能安全，过滤，流控等API管理功能提供统一服务出口，解耦过滤器型别：
PRE：请求路由之前调ROUTING：路由到微服务POST：路由到微服务之后ERROR：其他阶段发生错误后执行除了预设的过滤器型别，Zuul还允许建立自定义的过滤器型别。
Zuul高可用
通过将多个zuul节点注册到Eureka Server实现高可用。存在以下两种情况：
Zuul客户端注册到了Eureka Server
Zuul客户端自动从Eureka Server查询Zuul Server列表，并用Ribbon负载均衡请求Zuul丛集。
未注册到Eureka Server
微服务可能被其他微服务呼叫，也可能直接被终端app呼叫，这种情况，我们需要借助额外的负载均衡器来实现Zuul的高可用，比如Nginx等。
Zuul聚合微服务
许多场景下，一个外部请求，可能要查询后端多个微服务。比如一个电影售票系统，在购票订单页上，需要查电影微服务，还有使用者微服务，如果让系统直接请求各个微服务，就算使用Zuul转发，网络开销、流量耗费、时长都不是很好，这时我们就可以使用Zuul聚合微服务请求，即应用系统值传送一个请求给Zuul，由Zuul请求使用者微服务和电影微服务，并把资料返给应用系统。
连结：blog.csdn.net/hongwei15732623364
练手专案源代码、新技术介绍、原理性知识、应用框架知识点讲解、常见笔试面试题分析，搜寻【Java知音】
