3、技术背景介绍 | 一步步将项目改造成微服务架构

上一篇介绍了项目背景，这篇再简单说下技术背景。

现有项目采用的技术大致有：spring、spring mvc、mybatis、redis、solr。相信这都是些很常见的技术了，所以你看后应该比较亲切和自信。

现有项目整体架构，如下图

相信当你看了这幅架构图之后更亲切了，很简单有木有！单库单服务，只不过部署了两个实例而已。由易到难，我相信这是个好的开头。

接下来我们要做的是将项目微服务化，技术上首先想到的就是spring cloud：spring家族的、组件丰富、社区活跃，所以选择它就成了理所应当的结果。但是本人对spring cloud和spring boot知之甚少。所以先补了点spring cloud的知识，它里面的常用组件简单的罗列下：

Eureka

简单的讲他是负责服务治理的，各服务启动时都需要到Eureka那里注册，并且告诉Eureka自己的地址、服务名称等信息。

服务启动后会定时的给Eureka发送心跳，告诉Eureka I AM OK！如果Eureka在规定时间内没收到某一服务的心跳，就会将该服务状态标为DOWN（不知道是不是这个单词，有点忘记了），表示不可用。

总之，Eureka里有一份列表，记录着所有服务的状态，需要这份列表数据可以通过接口去获取，ribbon（后面会介绍）就是个例子。

Eureka可以集群，各个Eureka会相互同步列表数据。

Feign

简单的讲他是负责微服务间接口互调的。既然将项目拆成多个微服务了，那么他们之间必定需要相互调用的。使用Feign可以很优雅的完成调用：调用方调用其他服务的接口时，跟调用本地方法一致，interface.method()即可；提供方只需通过spring mvc 写个controller即可，这和给前端app提供接口完成一致。

在spring cloud中，feign还集成了ribbon和hystrix(后面会介绍)，用来解决处理调用时的各种情况，这些对我们完全透明，我们唯一要做的就是动动配置（比如说配置超时时间，轮询策略），打打响指。

Ribbon

终于出场了，简单的讲他是负责服务间相互调用接口时的负载均衡的。有点难理解？那就对了，我自己都感觉有点绕。

举个例子：A服务需要调用B服务，B服务集群部署，且都在Eureka中注册了。那么服务A使用feign调用B服务接口的时候，他需要知道B服务在哪里？他应该调用B服务的哪个实例？

这些都是都是ribbon负责处理的事情，对于第一个问题，ribbon会存一张B服务各实例的状态列表，这个列表数据是从Eureka拉取过来的。第二个问题，ribbon会提供几个策略供我们选择，比如随机、轮询、权重，ribbon会根据我们设定的规则去查找B服务的某一实例。当然ribbon也可以让我们自定义规则。

所以说ribbon主要功能就是负载均衡，且是客服端侧的负载均衡，这里画一张和nginx（服务端侧负载均衡）的对比图：

Hystrix

简单的讲他是负责处理微服务间调用时的各种异常问题的，比如服务挂掉、超时、请求线程池满了等等的问题。这个在当前项目中没深度使用，所以也就不详细介绍了，详细介绍可以看一下这位大兄弟的文章：https://www.cnblogs.com/cjsblog/p/9391819.html。

Gateway

简单的讲他是负责url的路由和请求的过滤（Filter）的。其实gateway有其他很多功能，但目前我们项目里没怎么用。最爽的一点是gateway可以根据url自动路由到对应的服务，无需特殊配置，所以说它与微服务已经紧密的整合在了一起。

gateway有点像你们公司的前台，有外人来访时，她需要询问情况（对客户端的情况进行认证），问清来意后她会进行登记（对请求日志进行记录），然后带领来访者找到技术部或者销售部（url路由），推销人员就直接拒绝（拦截请求拒绝访问）。

在spring cloud 全家桶里还有个zuul组件，貌似已经被gateway取代掉了

---

 

在spring cloud家族里还有很多组件，比如：spring cloud config、spring cloud consul等。这些等需要的时候再使用，目前项目中没涉及。最后再用一张图表示下各组件的关系，没有什么事情是一张图解决不了的，如果有，那……就真解决不了了。

除了spring cloud外，还需要准备spring boot的一些知识，这部分没怎么系统的学习，更多的是用到的时候百度。当然还需要一位技术大牛的支持，关键的时候引导一下。

好，背景讲的差不多了，接下来几篇将会涉及到开发了，技术人员应该会比较感兴趣。