小墨学习记--微服务

嗨~

我是水文小墨~ 今天来水一水我理解的微服务，一说到微服务，很多小伙伴想到的是 啊~ 我知道 就是Spring cloud嘛~ 那我们就基于Java的spring cloud框架来聊一下。

spring cloud似乎就是为微服务而生的 那什么是微服务呢？接下来，小墨以小墨可以理解的角度带您去看一下微服务~

小墨理解的微服务是将很多的模块摘出来，形成可以独立运行的项目(服务)，项目(服务)进行单独部署之后，再次开发类似的项目时，可以直接调用这些服务来快速开发。缩短项目工期。

spring cloud是在sping boot的基础上把很多的三方框架以组件的形式，按照公司名将三方框架集成到spring中。

他们之间似乎没有特别的联系，考虑一下，将服务单独部署之后会出现什么问题呢?

服务运行期间，肯定不会在同一个上下文中，那如果A服务要调用B服务的方法是不是就成了一个问题？

spring cloud就是通过中间件的形式，将这些服务联系起来，对这些服务进行管理与监控！

 

1.服务发现与调用

不在同一个上下文中，我们怎么建立服务之间的联系？TCP协议嘛~

你可能会说，不对呀，服务间的调用是通过Rest的方式调用的呀，没错，spring框架有Rest的使用工具类，但是，Rest是通过HTTP协议的进行服务调用的，HTTP协议底层封装的是TCP协议。

这样服务之间的调用问题解决了，但是有没有问题呢？

在开发环境中，一个服务有可能依赖很多服务里面的方法，服务都是单独部署的，我们有可能会不知道有哪些服务，或者某一台机器的ip地址换了，我们之前的连接就连不上了，这样互相调用是不是会出现一团糟的情况？像这样，8这台机器IP换了，所有调用这个服务的服务就都连不上了。

我们可不可以有一个中间人来去管理他们呢？就像租房子的时候，我们找不到房源，可以求助于掌握了大量房源的房产经纪人(中介)一样。像这样

这样，房产经纪人维护着每个房子的地址，我们就能很方便的找到合适的房子了，这其实也是设计模式中 中介者模式的实现思路~

Spring cloud 就用Eureka这个服务发现与注册的组件充当房产经纪人的角色来维护服务地址，他是核心的组件之一。

2.服务降级与熔断

当我们的服务多了之后，服务之间的调用是会出现链条状甚至是网状的结构，像这样

 

假设当服务③挂掉之后，服务②在调用③的过程中一直得不到回应，就每隔一段时间去访问一下③服务，时间长了之后服务②就因为内存的原因，也挂掉了，同理所有调用服务2的服务也就会挂掉，最后整个微服务项目就因为服务③挂掉了，这是很危险的一种情况。

 为了避免这种情况，就出现了服务降级和熔断的解决方案。

服务降级可以有两种方式，一种是服务③中的某个方法出错了，在服务③中对这个方法进行降级。另一种是当服务③连接不通时，在服务②中对服务③降级。

降级是指，当服务不能返回正常数据时，我们给调用的服务回复一个友好的错误信息，保证调用的服务不会出错。其中一种方式是如果被调用的方法出错的话，我们把这个跳转到另外一个返回错误信息的方法里面。

熔断指的是：当服务在一定时间内的错误数达到一定的量级之后，将整个被调用的服务关闭掉，之后过一段时间以后，将服务设置为半开状态，如果半开状态下的服务请求能通过的话，就打开服务，否则继续关闭服务。

在spring cloud中我们是通过Hystrix组件来实现服务降级和熔断的。

3.路由管理

我们在上面篇幅说的服务的调用都是服务之间的调用，属于后台服务端部分，假设前端有一个请求，涉及到了三个服务，那前端是不是需要发送三次请求访问不同的主机呢？这样设计的系统调用太复杂了。对前端人员来说太不友好了

那么我们是不是可以通过一种封装的方式，将整个的服务部分封装起来，对外暴露一个连接地址，所有的连接都来连接这个地址，进来之后再用特定的规则去判断你要访问的是哪个服务？

像这样：

当我们将后端的服务部分封装起来之后，对前端只暴露一个接口，这样前端只需要去访问我这个接口就可以了，而且，有了这个接口，在后端，我们可以对前端发过来的请求进行过滤，这个接口是不是就相当于我们后端服务的一个访问门面呀？

这种方式类似于设计模式中的 门面模式 不管我后端写的多烂，我给你一个好看的门面，我就是完美的~