微服务

原创
2020/08/25 08:34
阅读数 49

嗨~

 今天来聊一聊我理解的微服务,一说到微服务,很多小伙伴想到的是 啊~ 我知道 就是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.路由管理

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

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

像这样:

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

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

 

本文分享自微信公众号 - 软件测试大咖经验分享(gh_8a6f5732cffa)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部