微服务时代下,我该如何学习__运维_spring_调用_docker_网易订阅

0分享至

用扫码二维码

分享至好友和朋友圈

前几天在交流群里有同学问我,想知道怎么学微服务?

我不太想像别人一样,给你丢出一堆的知识图谱。

我想先带大家一起了解下,微服务是怎么一步一步发展来的。

我相信,你读完这篇文章后,这个问题你自己就会有了答案!

首先声明:目前市面上没有统一的一代、二代、三代的微服务标准。

以下仅是个人根据经验对他们的归类,仅供交流学习!

第一代“微服务”

为什么这里的微服务三个字我加了引号,那是因为那时还没有微服务这个概念,只是像微服务的雏形,所以我给加了引号。

要说第一代“微服务”,就要回到十几年前,先来看下 06 年的淘宝网页(图片来自网络):

那会儿的网站大都是这样的一些超链接,一些图片就搞定了。

更甚者就是纯静态的网站,像淘宝这种动态网站都属于是稀有的。

我永远都记得,那时学校总爱考一道题:什么是动态网站?

其中必定会有一个选项:有图片会动的网站

但是总会有同学选它,哈哈。扯远了。

那时的网站,流量也不会特别多,并发也不会特别高!

甚至那时还没有现在特别流行的 Redis 缓存技术,主要就数据库 MySQL 和老牌的缓存 memcached。

到那时为止,都还是 单体服务(就是一套系统干完全部功能)。

渐渐的上网的人越来越多,特别是电商项目搞促销时,用户大都会频繁的增长,但是订单模块并不会有太大变化。

此时如果再全新部署一套服务,就有点浪费资源了,因为访问量小的模块就越来越冗余。

于是工程师们就有了拆分的意识!

有了拆分意识

于是,人们便开始想到把整个系统划分为不同的模块:

别较真哈,真实的电商系统肯定不是这样简单粗暴的拆分,这里只是做一个假设!

于是用户模块被拆分了出来,独立成了一个服务,就只提供,用户登录、注册、查询等。

拆出来后,过了不久发现一个服务还是不够用,于是又部署了一个用户服务。

此时就有了2个用户服务,那怎样才能更好的统一输出呢?

于是就有了负载均衡 (多个服务集体统一起来提供一个出口为别的服务提供服务),主要还是使用 Nginx 来完成。

时间推移,渐渐又发现订单模块就一个服务也不够用了,于是又部署了多个订单服务。

就这样,各个模块都变成了一个又一个的小集群。

拆分服务后,问题来了

理想是好的,但是现实总是残酷的!

拆时爽,一直拆一直爽,于是有了下面这张图:

一个系统有了很多个不同的模块,同时不同模块又有很多个服务。

各个服务之间存在互相的调用,模块与模块之间也存在互相调用。

比如:商品模块有时会去调用用户模块,订单模块有时也会去调用用户模块。

问题来了,用户模块不可能百分百每次都返回正确的数据呀!

当用户模块出现问题时,该怎么办呢?于是工程师们掉了几根头发后,又提出了新的概念:服务降级。

服务降级

什么是服务降级呢?

当服务出现问题了,比如:获取近期购买的、活跃的用户列表,如果出现问题就返回一个固定的、提前准备好的列表。

为什么要这么做呢?

主要是为了防止服务的调用链出现问题,可以进行及时的补救。

说得白话点,就是不让用户看出来服务出问题了。

马上问题又来了:

解决了出问题的服务,当维护好了之后,是不是该继续让它投入使用呀?

那怎么知道哪些服务上线了,哪些服务出问题了呢,出问题了怎么及时从可用列表里面剔除呢?

工程师们又掉了几根头发,于是就又提出了新的概念:服务发现。

服务发现

什么是服务发现呢?

在拆分的最开始,服务之间的调用,都是直接怼对方服务的IP。

这就容易出现,你写死的这个服务IP,如果哪天他挂了,你想切换IP,就必须重启服务,改代码或者改配置。

而服务发现的概念出现之后,服务之间调用就不直接怼某一个真实的服务IP,而是通过一个API来获取这个服务有效的IP,再去有选择的怼哪个真实的IP。

这个API就是服务发现服务。

他会有一整套服务的可用性维护逻辑在里面,这样服务之间的调用总是能往正常的服务上发请求。

尽管如此费尽心思的保证服务的正常,但也不能完全保证服务就能 100% 正常调用,这么多服务之间的调用,该怎么知道服务之间调用的性能如何?以及出问题了怎么排查呢?

于是就又有了新概念:链路追踪。

这个概念,留给大家自行百度!

二代微服务的出现

在第一代微服务里面,当服务出现问题都是手工去重启,处理维护的!

于是你会发现那时的运维同事经常会抱怨,昨晚又被半夜叫起来重启更新服务了。(很可能现在也还是)

以上那么多概念,当这些概念都被大家接受的时候,就总会有大神出来搞大统一。

于是微服务框架就出现了,比如 Java 里面有以 Spring Cloud 为首的微服务框架,Go 里面有 go-micro 和 go-zero 等。

渐渐的,就有了比较统一的微服务五大件:

服务发现:Eureka / nacos

客户端负载均衡:Ribbon

服务网关:Zuul / spring gateway

断路器:Hystrix / sentinel

分布式配置:spring cloud config

这些服务都是围绕服务治理展开的!

像前面提到的,链路监控有 Zipkin / jaeger / 普罗米修斯 等。

到这里你会发现,我们开发要学的东西越来越多。

是的,我不由得摸了下日益高涨的发际线

Docker 的出现

随着微服务框架的出现,Go语言里明星项目 Docker 出现了。

最开始人们都只把它当虚拟机使用,因为大家都不太理解他能干啥,后来人们才发现可以把服务进行容器化。

于是就有了一堆容器需要编排,Docker官方借势也推出了自己的编排工具 Docker swarm,但是并没做好,被另一个 Go 语言的明星项目 kubernetes (后面简称 k8s )取代了。

K8S 的出现

k8s 的出现让我们的服务部署,扩容,收缩,服务发展都非常容易了。

此时你会发现学的东西越来越多,要部署一套微服务需要的人越来越多,需要运维及开发以及运维开发(注意:是三个岗位)。

是的,一般架构越大,运维成本越高,治理起来就越复杂。

最开始的 K8S 服务部署是这样的:

但是这样的部署有一个问题,服务与服务之间的调用没有网关,调用和管理起来都比较麻烦。

于是又出现了新的概念:网格服务(Server Mesh)

网格服务(Server Mesh)

你可以简单理解为,把K8S里面的服务进行了分区,组成了一小块一小块的局域网!

如果你的服务与服务之间有调用,那么加入了网格服务的 K8S 就可以非常轻松地搞定。

K8S 里面的网格服务目前比较出名、强大的是:istio。

像之前二代的五大件功能,在 K8S + 网格服务 里面都能轻松实现,而且还强大。

同时他对代码的侵入性还比较小,并不关心你是用什么语言开发的。

就比如:服务发现,你不需要再在代码里面使用 consul 的 SDK 去注册服务了。

你在 K8S 里面只要你的容器起来之后,就会被自动挂到 Service 里面,服务之间你只需要通过 Service 名字就能互相调用。

这样的微服务你喜欢么?

三代微服务

所谓三代微服务,即把服务治理交给了 K8S+Server Mesh 去处理,都是基于云原生去开发的。

或许以后会出现更好的架构,但这是目前大多数的架构。

这样的架构并不关心你是用什么语言开发的。

但是请你记住:一般架构越大,运维成本越高,治理起来就越复杂。

该怎么学?

最后回到最开始的问题,该怎么学习微服务?

这是智者见智仁者见仁的问题,请相信没有哪个技术学完后就可以不用再学新东西了。

这也是我写这篇文章的目的,我想从我的角度带给你对微服务发展的概览,以及目前为止微服务的发展状况。

当你有了这些了解之后,我相信你就知道该怎么去学习这块了。

开发要学 K8S 么?

按照目前 K8S 的发展趋势,个人的观点是,要学的,但不是往深的学那种,至少 K8S 里面的一些基础概念你需要了解。

以及一些基础的操作,比如部署、查看服务状态等这些基础命令还是要学习一下的。

就此搁笔,感谢你的阅读!

原文:

以上文章来源于GoLang全栈 ,作者小锟哥哥(侵删)

特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.

/阅读下一篇/

返回网易首页 下载网易新闻客户端