微服务之API网关接口设计
API网关，顾名思义，就是外部到内部的一道门，其主要功能：
- 服务路由：将前段应用的调用请求路由定位并负载均衡到具体的后端微服务实例，对于前端应用看起来就是1个应用提供的服务，微服务对于前段应用来说就是黑盒，前段应用也不需要关心内部如何分布，由哪个微服务提供。主要有静态路由和动态路由。
- 静态路由：有时候需要通过域名或者其他固定方式提供和配置路由表
- 动态路由：通过服务发现服务，动态调整后端微服务的运行实例和路由表，为路由和负载均衡提供动态变化的服务注册信息。
- 安全：统一集中的身份认证，安全控制。比如登录，签名，黑名单等等，还可以挖掘和开发更高级的安全策略。
- 弹性：限流和容错，也是另一个层面的安全防护，防止突发的流量或者高峰流量冲击后端微服务而导致其服务不可用，另一方面可以在高峰期通过容错和降级保证核心服务的运行。
- 监控：实时观察后端微服务的TPS、响应时间，失败数量等准确的信息。
- 日志：记录所有请求的访问日志数据，可以为日志分析和查询提供统一支持。
- 其他，当然还有很多需要统一集中管理的都可以在网关层解决。
定制的路由规则的主要功能:
- 路由表中包含源路径，微服务名称，目标路径。
- Endpoint粒度配置支持。
- 路由支持1对1精确路由。
- 源路径可以前缀/**格式来模糊路由。
- 目标路径可以使用前缀/**格式来装配目标路径。
- 保留默认动态路由规则：服务名称/** --> 是否截去前缀 --> 目标路径。
- 保留默认动态路由规则是否支持截去前缀的配置参数stripPrefix特性。
- 路由规则可以在不重启服务动态更新，这个功能通过外化配置来支持。
- 匹配股则采取谁先匹配路由谁，也就是说在路由表中有2个或以上的路由规则可能被匹配到时，匹配最先查询到的规则。
路由规则格式采用properties格式：
源路径 = 微服务名称, 目标路径
启动时读取配置并解析，放入路由表。请求时通过查询匹配到合适的路由转发。
例如：
/api/v1/trade=trade,/v1/trade
/api/customer/**=customer,/api/v1/**
/api/user/**=user
在上面的例子中：
- /api/v1/trade会精确的路由到trade微服务的/v1/trade；
- /api/customer/开头的api会路由转发到customer微服务的/api/v1/**，其中后面的**会被前面的**部分替换，比如/api/customer/card->/api/v1/card的转换。
- /api/user/开头的api会路由转发到user微服务的/api/user/**，endppoint不变。
如果在Eureka Server中已经注册了微服务payment,那么在zuul启动后会自动添加路由规则，如果stripPrefix=false:
/payment/**=payment,/payment/**
复制代码如果stripPrefix=true:
/payment/**=payment,/payment/**
复制代码API网关通过部署多个实例来保证可用性，前端通过Nginx来负载均衡。
API网关使用场景
在使用微服务架构场景下，客户端在调用后台微服务时，都需要进行登陆认证、权限认证、流量控制、负载均衡、健康检查等操作，这些操作是调用每一个微服务都必须。因此需要将该操作交给一个高性能的中间层进行处理，以降低系统间的耦合，并使微服务更加专注于业务逻辑处理，降低整体系统的响应时间。
API网关技术选型与应用架构
API网关作为后台微服务请求的入口，必然要求其具有高性能的特点，为了使其可以按照自己的使用场景定制开发，对其易扩展性也要求很高，并且最好是有成熟的产品与规范的文档以及活跃的社区支持。OpenResty自然成为了首选！OpenResty是一款基于Ngnix的利用lua语言作为扩展的API网关技术。
操作
首先应该把组员召集起来，宣讲项目对各成员的意义，从心态上重视该项目。
制定接口开放规范，不允许有不清晰的接口结构。
在执行上对接口进行严格审查，建立奖罚制度
建立有效的沟通反馈机制，比如每天开展晨会，项目日报，周报总结等。
但是一般的效率问题和质量问题都不会得到解决。
有效的解决之道
真正的解决方法应该从技术层面上去思考，是对程序的把控，而不是去把控人。
Http API接口实现过程
控制器A和B两者都是做参数解析，参数转换，服务调用，返回结果。那我们可不可以把控制器A和B省略，减少我们的代码量呢？用API网关代表控制器，不会影响我们的效率。
