面对一堆的知识图谱，我该怎么学习微服务？

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

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

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

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

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

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

第一代“微服务”

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

要说第一代“微服务”，就要回到十几年前，先来看下 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 里面的一些基础概念你需要了解。

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

就此搁笔，感谢你的阅读