微服务架构-服务注册中心和服务网关(6.8) （转载）

原文链接：微服务架构-服务注册中心和服务网关(6.8)

这篇文章还是基于SpringCloud开源框架体系来谈下对Eureka服务注册中心和Zuul服务网关在使用上的一些理解和说明。在使用微服务架构进行开发的时候，最基本的就是SpringBoot，但是对于一个大的项目会根据实际的业务和需求场景，使用到类似服务注册中心，服务网关，负载均衡等多个其它子组件的能力。对于各个组件之间的协同关系如下图：

对于各个组件间关系简单说明如下：

1. 服务注册中心Eureka：实现服务注册，服务发现，服务的路由分发基础能力。
2. 断路器Hystrix：负责监控服务之间的调用情况，连续多次失败进行熔断保护。
3. 服务网关Zuul: 所有外部需要访问和请求的服务全部通过Zuul进行转发，类似API服务网关。
4. 服务链监控Zipkin：实现服务日志监控和服务链监控。

在这里重点讨论下服务注册中心和服务网关。

首先说下Eureka服务注册中心，假设有两个微服务模块，一个是产品管理ProdModule，一个是客户管理CustomerModule，我们用SpringBoot框架来独立开发这两个微服务模块。这两个微服务模块间通过Rest接口进行交互。在实现的时候我们可以直接在在各自模块的配置文件里面进行Rest接口服务映射，配置服务端的Rest接口IP地址和端口即可。

那这种场景下我们完全可以不用Eureka组件，而使用Eureka组件最主要的就是原来ProdModule和CustomerModule两个模块间点对点的直接接口调用发生了变化和进一步的解耦。比如产品管理需要查询客户管理中的客户信息接口服务，那么整个过程会变化为：

1. CustomerModule模块和接口注册到 Eureka组件
2. ProdModule模块和接口注册到 Eureka组件
3. ProdModule访问Eureka组件获取查询客户接口地址，然后再发起对CustomerModule模块调用。

在ProdModule接口消费处的配置，不再配置到具体的Rest接口地址，只配置相当路径名。实际的接口访问地址需要访问Eureka组件后根据均衡算法返回给你一个可用地址。而这种做法做大的作用就是起到了负载均衡和多个可用服务路由的作用。

即CustomerModule模块可能不止部署了一个实例，而是部署了多个服务实例，那么多个服务实例都会注册到注册中心，在消费端进行访问的时候再动态选择一个最佳的服务提供者进行访问。这个功能说成路由不太合适，实际上更多的是微服务模块的动态集群分发能力。

如果你不用Eureka组件，那么你也可以采用类似HaProxy，F5硬件负载均衡来做这个事情。但是如果微服务架构和容器化自动部署和动态扩展是集成在一起的，那么就需要这种计算节点的动态扩展，服务的注册能够自动完成。而对于Eureka组件恰好能够很好的完成这个事情。

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

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

当前Eureka的设计仍然不是完全去中心化的，即如果Eureka持续故障，那么对于模块A就无法发现模块B对应的接口服务能力。而实际上最好的方式是对于服务目录库能够有一套本地数据缓存，以确保服务注册中心在宕机故障的时候也不会对整个服务调用造成影响。

通过以上说明可以看到，如果要考虑和Docker容器集成，考虑到微服务模块本身实例的扩展，那么一定要启用Eureka服务注册和发现中心。以方面微服务模块实例实现集群化动态扩展，同时也方便整个微服务架构应用体系的整体环境迁移和配置。

再回来看下Zuul微服务网关，注意微服务网关本身才是和轻量的ESB总线类似的一个子产品，至少微服务网关实现了基础的服务代理，服务路由，服务安全等基本的服务管控能力。同时通过微服务网关实现内部微服务模块完全的位置透明，内部微服务模块不再需要对外发布，而只是将需要对外发布的接口进一步注册和接入到微服务网关上面即可。

即微服务网关更多是一个大的应用体系下，需要有RestAPI接口对外发布的场景下才会使用，否则不需要使用。那么我们再回来看下实际的业务场景。

如果一个CRM应用，分为10个微服务模块进行开发，这10个微服务模块之间有接口访问和调用，那么这个时候启用Eureka注册中心即可，而不需要启用微服务网关。如果出现这个CRM应用涉及到一个手机APP应用，一个外部电商平台需要访问CRM应用的数据，那么就可以启用微服务网关，这时只需要将10个微服务模块中涉及到外部访问的这些API接口接入和注册到微服务网关即可。

进一步回归到企业内部传统应用的微服务和组件化架构改造。

比如涉及到CRM应用拆分为10个微服务模块，一个PLM应用拆分为8个模块，一个MES应用拆分为6个微服务模块。那么这三个应用内部的微服务模块间通过ureka注册中心完成协同即可。而三个应用之间的接口访问和调用，我们更加建议采用微服务网关组件来完成。毕竟在微服务网关上更加容易实现对安全，日志，路由，流量控制等各种能力。