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.
/阅读下一篇/ 返回网易首页 下载网易新闻客户端