所以，一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway，他的作用包括
·提供统一服务入口，让微服务对前台透明
·聚合后台的服务，节省流量，提升性能
·提供安全，过滤，流控等API管理功能
我的理解其实这个API Gateway可以有很多广义的实现办法，可以是一个软件比如kong，也可以是一个swoole的服务端自己编写的程序。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。
基本都是通过consul等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到cosul（或类似框架），并通过心跳检测健康状态，实时更新链接信息。服务调用者通过cosul寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，consul会发通知给服务客户端。
注册服务
心跳维持、健康检查
协议的统一转换
服务挂了怎么办？
重试机制
限流
熔断机制
负载均衡
降级（本地缓存）
容错
1 快速失败
2 失效切换
3 失败安全
4 失败自动恢复
5广播调用
熔断
熔断技术可以说是一种“智能化的容错”，当调用满足失败次数，失败比例就会触发熔断器打开，有程序自动切断当前的RPC调用,来防止错误进一步扩大。实现一个熔断器主要是考虑三种模式，关闭，打开，半开。
CircuitBreaker
熔断器主要是考虑三种模式，关闭，打开，半开。
降级
关于降级限流的方法业界都已经有很成熟的方法了，比如FAILBACK机制，限流的方法令牌桶，漏桶，信号量等。
超时和重试
RPC
如果有一种方式能让我们像调用本地服务一样调用远程服务
分布式事务
