微服务是啥？Docker是啥？Kubernetes是啥？

• 人类的科学实质上从第一次工业革命开始时就有了明显的体现，内燃机的发明带领人们进入了蒸汽机时代。之后经历了几代人的努力，人类文明从蒸汽时代跨入电气时代，电给世界带来了光明。然而，真正将世界联系起来的是信息产业的革命，人类的大脑得到了空前的“开拓”。回想起原始笨重的机械制造设备和交通工具，从根本上说，它们被发明出来的目的就是解放人类的劳动，提高工作的效率。
  效率，仔细想想，从人类最最原始的特性：会使用工具开始，人类历史上科技的进步的根本目的，就是为了解决效率的问题。蒸汽机的出现，使得工厂的生产效率大幅提升，人们的出行效率更加方便；电话的出现，使得人们可以避免长跋涉与人会面而浪费时间。从这个浅显的角度来说，微服务的目的亦是如此。

微服务，轻轻地拥抱世界

• 想一想苦大仇深的工人们，我们现在假设一个场景：规定个时间，在第一次工业革命时代，工厂A为了提升自己的生产效率向当时伦敦处于领头羊地位的制造商买了一批重型设备，但是用过一段时间后机器发生了故障，那么问题来了…由于工厂A只负责生产商品并销售，所以员工们并不懂怎么去修理，请该设备制造商的人来修又没有工具，所以修理机器的唯一途径就是花费大量的人力物力把笨重的机器送回机器制造商。 所以类比现如今的服务类型，这个需要返修的超重型设备就相当于如今的大型的，组件多，高耦合的单体应用，这种应用从开发，部署，到管理必须以同一个实体进行，如果此类应用的某个组件中出现了小小的bug，那么就需要修改后重新部署整个应用，这是让运维人员很头疼的事情。随着应用越来越大，各种问题也频繁出现，高耦合度导致整体难以修改，复杂度也越来越高，并且，当应用越来越大时，运行它所需要的硬件资源要求也越来越高，但明显这并不是短时间能做到的，所以我们便有了微服务的概念

• 微服务，顾名思义，就是一个一个微小的服务。我们通常把一个单体应用部署到集群中，那么我们的应用在集群中对用户提供的功能就是服务。当我们在开发过程中把应用的耦合度降低，达到把这个应用能够拆分成完成各个功能的小模块时，我们就可以把部署的单位从一整个单体应用变成了 一个一个的小模块，这时这些模块对用户提供的服务就是微服务。每个微服务都是独立的进程，通过协议进行通信。这样，运维人员部署应用就是以模块为单位，大大降低了工作量和复杂度，并且也不会过多的给硬件资源造成压力。

• But,一个应用的各个组件所需要的环境，以及依赖的库可能时不一样的，所以当我们以各个组件为模块部署时环境的搭建又成了运维人员很头疼的问题。有一种方法，就是用虚拟机为每个组件都虚拟出一个环境，把各个组件隔离开来，自己在自己的虚拟的环境下做事，em…OK,但是这种方法仅能在构成应用的组件比较少的情况下使用。为什么呢？因为虚拟机为各个组件所虚拟出的硬件环境的开销相对较大，当组件数量变多时，会造成服务器资源的大量浪费。所以，有没有什么办法，既可以为每个组件分配各自的环境把它们互相隔离开来，又能减少系统开销从而节约成本呢？？

• 有的，当然有，这种工作就交给Docker吧！！！^__

Docker：快到碗里来！！

• 既然把Docker放到这里，就是说明使用Docker能够解决上述的问题。那么，Docker干了什么事情呢？？其实就是一件事情：打包！把组件和它所需要的环境，依赖库啥啥啥的全部打包，打包好的东西我们给它起个名字，叫做镜像，而我们把在宿主机上面运行的镜像成为容器。这样打包的组件在自己的容器里做着自己想做的事情，别人看不见他，他也看不见别人，对于别的组件亦是如此，也就完成了对各个组件的隔离。But，这时候有人会问了：欸？这和虚拟机干的事情不是一样吗，我干嘛不用虚拟机？？嗯，的确，虚拟机所做的目的和Docker打包的目的是相同的，为各个组件虚拟环境，隔离组件，但是二者的过程是有区别的，看了下面的图便可以清楚的了解:
  
  上图表示了虚拟机和容器隔离组件后区别：虚拟机是通过对各个组件虚拟各自的硬件环境来实现隔离的，每个组件都有自己的虚拟操作系统，宿主机操作系统通过管理程序来管理各个虚拟环境，各组件执行各自虚拟机操作系统的系统调用，通过管理程序把这些系统调用转换成宿主机指令来执行。**那么，就出大事了，虚拟出个操作系统并不是个明智的决定，因为操作系统本身的资源耗费就相当巨大，并且每次启动组件时，都必须先启动它对应的虚拟操作系统，当组件众多时，资源耗费就会相当之高。**相比之下，Docker实现的对各组件打包形成镜像进而运行为容器的方式，CPU就不需要为各个组件虚拟硬件环境，各个容器会完全执行宿主机内核的系统调用，是十分轻量级的隔离手段。那么，问题又来了，Docker为啥能这么干，凭什么他就不用虚拟物理环境呢？？ 这就是Docker的隔离机制，它与底层的Linux系统的功能有关。实质上是使用了Linux的命名空间和控制组来实现组件隔离的，具体的方法请参照https://blog.csdn.net/z530234020/article/details/101032994
• 这样，我们就有了一个一个的容器，里面就是应用拆解后的各个组件和相应的环境以及依赖库。（ps：当我们把容器部署到集群中，在一些情况下，某些容器并不是相互完全隔离的，因为它们之间可能存在着协作运行，来共同提供一种服务，这就引申出了下一个概念，当我们在集群中部署容器时，用Kubernetes对它们进行调度时，调度的单位并不是容器，而是能够协作运行以提供同一服务的容器组，组内可能是一个容器或者多个容器，我们把这样的组取一个名字，叫做pod）

Kubernetes：这里是塔台！这里是塔台！***号容器，听我指挥，听我指挥！！

• 到了这里，可以用一个图简化Kubernetes干了什么事
  
  这张图的意思，就是程序员想把一个个pod部署到Kubernetes上，需要对Kubernetes master提供相应的应用描述，然后Kubernetes master就会根据这些描述，把相应的pod部署到对应的工作节点上，而部署到哪里，怎么部署，这是Kubernetes的事情，不用开发者或运维人员关心。
• 简而言之，Kubernetes实质上是针对于容器管理和部署的系统，Kubernetes所做的，就是海量规模服务器的环境下，能够很好的部署应用以达到最大的效率。那最终，微服务，Docker，Kubernetes如何联系起来呢？？
  
• 哈哈，大功告成，上面这幅图清楚的描述了微服务体系中，Kubernetes协同Docker的工作流程。其实，Kubernetes负责发出指令，它是指挥官，他知道该把哪些容器放在哪些节点上，该什么时候停掉哪些容器的运行，但是他并不进行操作。而真正操作的就是Docker（工具人）。Docker执行Kubelet的命令，Kubelet时Kuberletes工作节点中的一个组件，他负责和Kuberletes管理节点进行交互并接收命令，并把命令告诉给本节点上的Docker，最后，Docker就可以大胆的工作啦：指挥官，你指哪我打哪！让我们一起快乐的服务到底吧！
  ，你指哪我打哪！让我们一起快乐的服务到底吧！