目录

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

目录

注意Eureka组件实际上只提供了服务注册和发现的能力,实际上A在拿到B模块的服务地址后,仍然是点对点发起了调用。Eureka组件只管注册服务,并根据请求返回服务地址,而不管具体的服务消费调用整个过程,即整个消息和数据流都不会经过Eureka组件。

那么A要消费B模块的接口,A和B之间的网络策略必须是打通的,而不仅仅是打通和Eureka Server的网络策略。但是如果我们使用的是Zuul服务网关,网关是承载数据流的,实现底层完全的位置透明。因此A只需要打通到Zuul网关服务器的网络即可。也正是这个原因可以看到,一个大应用里面涉及到20个微服务模块,各有个的IP地址,都需要发布接口给外部访问,那么这个时候我们只需要在隔离区部署一个Zuul服务网关统一出口即可。

http://img.cana.space/picStore/20201114170950.png

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

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

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

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

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

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

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

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

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

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

参考