转载

微服务架构-服务网关和注册中心(3.28)

对于微服务架构中的服务网关和注册中心，以及两者的关系，实际上在前面很多文章都已经谈到过，可以先参考我前面写过的两篇文章。

文章1： http://blog.sina.com.cn/s/blog_493a84550102xgx6.html

文章2： http://blog.sina.com.cn/s/blog_493a84550102xbbq.html

谈API网关： http://blog.sina.com.cn/s/blog_493a84550102yp6z.html

在这里重新再强调下为什么需要API网关，要知道在整个微服务架构中，谈注册中心的时候是去中心化的，但是一使用微服务网关，那么网关这个节点又会变成中心化的节点。那么使用网关的原因究竟在哪些地方。

总结来讲就是网关通过中心化来实现类似AOP横切的一些共性能力实现，其中包括了安全，日志，流控。其次一个就是通过网关实现SOA的关键位置透明特性，其中关键是服务代理，路由，负载均衡能力实现。如果存在上面这些需求点，那么就一定会涉及到使用API网关。

在前面我也谈到过，API网关的关键是将一个微服务架构体系内的能力通过网关层接入后统一开放给外部用。这个外部可以是外部的业务系统，也可以是微服务架构体系中的移动APP前端。通过网关层能力的开放来实现服务统一管控和治理，实现底层的位置透明。其次才是安全，日志和流控能力增强。

即一个架构体系，当涉及到需要开放能力给外部的时候，一定涉及到网关的使用，如果不涉及到能力对外开放，那么使用注册中心即可。但是这个外部本身又不觉得，如上图，当一个大的业务系统，分成了三组微服务模块，同时分给三个独立开发厂商开发。那么三个开发团队间的接口交互仍然可以理解为外部，这样往往才能够确保每个开发团队的高度独立自治能力。

基于上图，再总结下在使用网关和注册中心的时候一些关键点。

1. 一个独立的开发团队，为保证独立自治，以及内部多个微服务模块间的交互集成，最好启用独立的服务注册中心实现服务注册，发现能力。即开发团队内部多个微服务模块间的集成，不需要通过网关，只需要通过服务注册中心进行集成即可。

2. 开发团队需要暴露能力给外部，包括暴露能力给其它的开发团队，需要考虑将该API接口注册到外部的网关上。在这里建议是拆分两个独立网关，一个是内部API网关，一个是放置到DMZ区面对公网访问的API网关。对于服务如果同时涉及到内部和外部使用，则两边注册。建议不要通过两次网关去路由，一个是影响性能，一个是不方便后续问题排查。

3. 构建在开发团队之外的API网关必须具备负载均衡能力，可以配置多个IP地址。通过该API网关也最好具备和Docker容器扩展后的服务自动注册和地址加入扩展能力。

4. 对于开发团队内部，如果考虑和Docker容器的进一步自动化集成，可以考虑在内部先启用微服务网关，再将微服务网关开发的API地址进一步注册到外部的API网关上面。

5. 如果内部和外部启用各自独立的网关，但是定制化SOA管控治理平台的时候只需要定制一个，同时适配两个网关，同时能够对两个网关进行监控和日常管理。

原文 http://blog.sina.com.cn/s/blog_493a84550102ypv8.html

正文到此结束