本文主要是介绍Zuul和API gateway; Ribbon和LB，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
API gateway是在云内的，为云外的各个clients服务的程序。这段程序有特点就是，它要在server-side，为clients提供各种功能，支持各种API。比如说Netflix的流使用MPEG-DASH（Dynamic Adaptive Streaming over HTTP）
为什么需要API gateway，或者edge server这种东西?
Netflix早在2012年，已经把云内的API gateway按照不同的client，用BFF (Backends for frontends) pattern分拆成Iphone，android，PC等。
这其实是软件工程里面的一个封装概念。如果没有API gateway，那么Client端就被迫要知道很多内部服务的事情，这也是一个
- Client-side service discovery
vs - Server-side service discovery
Client-side service discovery需要知道server-side的服务，然后client side智能化的提交到服务。需要自己做Routing。
Server-side service discovery就把内部细节隐藏起来了。Client side就单纯的提交request就好了。API gateway会来做Routing。
Client-side service discovery会是个紧耦合的系统。但是因为省掉了API gateway，会少一级HOP，节省系统开销。
Ribbon
Ribbon是一个应用级的LB。有时又被称为Client-side load balancer. 这是指着对应的平台级的load balancer说的，比如Nginx等等。
平台提供的LB特点就是满足大多数用户的需要，因为是Customerization，而不是Programmable，可以定制的范围还是比较有限。Ribbon的特点是能够知道其他的服务在哪里，所以能够智能的LB。
与Client-side service discovery结合起来的话，可以看到Ribbon能够被用来做那个routing服务的工作。在client端发挥作用。
- client-side load balancing
vs - server-side load balancing
client-side load balancing是建立在client-side discovery前提上的，至少要知道服务在哪里，才能LB。所以也是个紧耦合的系统。
混合
比较有趣的是，Ribbon也可以被用来和API gateway结合，在API gateway上提供用户级LB。
这样，其实做了两层的LB，第一层是由平台提供的，第二层是由Ribbon提供的。
其实在BFF模式下，内部的API gateway就等于是Client的一个代理，这样想的话，把Ribbon放在这里做“Client-proxy-side LB”就非常合理了。
所以在Spring Cloud或其他Framework里面，可以看到Zuul作为API gateway的使用，以及Ribbon作为Zuul的一部分，在server端被使用。
这篇关于Zuul和API gateway; Ribbon和LB的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
