微服务架构之Spring Cloud Eureka简单理解与实战（一）

微服务架构之Spring Cloud Eureka简单理解

微服务并没有一个官方的解释，但是主要就是为了解决单体架构项目(图1)的一些弊端，以往我们开发java web工程，基本上都是采用的ssh框架或者ssm框架，开发工作完毕后，测试打成war包放在tomcat下运行。这样的弊端很多，比如说常见的电商项目，随着业务的扩大，项目模块越来越多，代码量几十万行甚至百万行，维护起来特别不方便，所以发版的间隔也是很长的，甚至一个模块的改动，要测试整个项目工程，同时也不利于技术的改革，例如想把ssh框架改成ssm框架，这里的工作量是非常大的，所以微服务应运而生。究竟什么是微服务(图2)？结合一张图说明一下

图1：

图2：

将原先的每一个模块都做成微服务，每一个微服务模块对应他们相应的数据库，甚至可以将其独立扔到tomcat下运行。各个微服务模块通过rest api进行通信，通常是指http协议或者https协议。每一个微服务模块都有独立的进程。

这样就解决了单体架构的弊端，维护性更强，扩展性强，避免了技术债务的叠加，各模块也可按需配置服务器规格。

这里来说明一点，通常我们微服务之间的调用是通过rest api进行的，spring提供了一种接口，RestTemplate(图3)

图3：

消费者通过restTemplate接口，传入生产者微服务所需要的参数和目标url，即可调用生产者微服务。但是这里有一个问题，就是说，targetURL在消费者当中肯定不止调用一次，甚至有可能不会只调用一个。不止一次就是说我们不能用硬编码的方式，直接把请求的url地址写在restTemplate的方法里面，这可以通过创建配置文件的方式进行解决，例如可以在springboot的配置文件xxxxx.yml文件中配置(图4)。然后在controller中定义一个成员变量，使其映射到配置中的url值(图5、6).

图4：

图5：

图6：

不止请求一次的问题解决了，那么也可能不止请求一个url，也就是说，作为消费者的微服务需要调用多个生产者微服务(图7)，此时上面的解决方案就变得束手无策.

图7：

图7中就是一种情况，用户模块有多台服务器实例来提供高可用服务或者负载均衡服务，每一个服务器实例都是单独的url地址，那么怎么办呢。解决的方案是使用nignx路由(图8)。

图8：

但是，这样看起来确实可以解决上述问题，但是实际项目中可以庞大到有很多个模块，每个模块又可能部署在不同的服务器上，如果每一个模块都用nginx路由，是非常麻烦的一件事情。正是这样，Eureka诞生了，我们把微服务注射到Eureka中(图9)。

图9：

上图中，服务启动的时候，会把服务的ip和端口注射到服务发现组(Eureka)里面去，具体的是放到一张注册表中，当服务消费者调用服务集群的时候，先进行的是从服务发现组件中获取服务提供者列表，并缓存到本地，之后通过负载均衡的相关算法，从缓存表中选一个来用。需要注意的是，该架构是一个动态的，服务提供者集群每隔一段时间就会向服务发现组件续约自己的列表，如果哪一台服务器没有即是续约，那服务发现组件就会将其在提供者列表中剔除掉，同时，服务消费者也是每间隔一段时间向发现组件发送心跳，来不断更新自己缓存的提供者列表，这样就避免了消费者因提供者宕机而请求不到的情况。

接下来重点介绍一下Eureka，这是Eureka的github地址：https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

结合其中一张结构图来看一下，eureka被定义成高水平的架构(图10)。

图9：

服务发现组件，也可以说是服务注册中心，它是Eureka Server，作为微服务的桥梁，存储和管理微服务列表的。应用的生产者和消费者都属于Eureka Client，他们可以和Eureka Server进行通信，向其获取或注册相关的信息。而两个Eureka Client之间调用（make remote call）的过程就是通过Eureka Server完成的。

具体的实战操作，会出现在《微服务架构之Spring Cloud Eureka简单理解（二）》。