关于微服务:kubernetes是微服务发展的必然产物

4次阅读

共计 2595 个字符，预计需要花费 7 分钟才能阅读完成。

在很多我的项目的倒退初期，都是小型或者大型的单体我的项目，部署在单台或者多台服务器上，以单个过程的形式来运行。这些我的项目随着需要的递增，公布周期逐步增长，迭代速度显著降落。传统的公布形式是：开发人员将我的项目打包发给运维人员，运维人员进行部署、资源分配等操作。

随着软件行业架构形式的扭转，这些大型的单体利用依照业务或者其余维度逐步被合成为可独立运行的组件，咱们称之为微服务。微服务彼此之间被独立开发、部署、降级、扩容，真正实现了大型利用的解耦工作。对于微服务的介绍，大家能够去撸一下菜菜之前的文章：

为什么我会了 SOA，你们还要逼我学微服务？

[要想做好微服务架构，并非易事！！](
https://mp.weixin.qq.com/s/Bi…

软件开发行业就是这样奇葩，每一个问题被解决之后总是随同着另外的问题呈现，就像程序员改 bug，为什么总有改不完的 bug，真的很令人头大！！!

微服务尽管解决了一些问题，然而随着微服务数量的增多，配置、治理、扩容、高可用等要求的实现变的越来越艰难，包含运维团队如何更好的利用硬件资源并升高服务器老本，以及部署的自动化和故障解决等问题变得原来越辣手。

以上问题正是 kubernetes 要解决并且善于的畛域，它能够让开发者自主部署利用，自主管制迭代的频率，齐全解放运维团队。而运维团队的工作重心从以往的服务器资源管理转移到了 kubernetes 的资源管理。kubernetes 最厉害之处是对硬件基础设施进行了封装和形象，使得开发人员齐全不必去理解硬件的根底原理，不必去关注底层服务器。kubernetes 外部把设置的服务器形象为资源池，在部署利用的时候，它会主动给利用调配适合正当的服务器资源，并且可能保障这些利用能失常的和其余利用进行通信。一个 kubernetes 集群的大体构造如下：

微服务虽好，然而数量多了就会有量带来的问题。随着零碎组件的一直增长，这些组件的治理问题逐步浮出水面。首先咱们要明确 kubernetes 是一个软件系统，它依赖于 linux 容器的个性来治理组件（kubernetes 和容器并非一个概念，请不要混同）。通过 kubernetes 部署应用程序时候，你的集群无论蕴含多少个节点，对于 kubernetes 来说不会有什么差别，这齐全得益于它对底层根底设置的形象，使得数个节点运行的时候体现的如同一个节点一样。

主动扩容

在 kubernetes 零碎中，它能够对每个利用进行实时的监控，并能依据策略来应答突发的流量做出反馈。例如：在流量顶峰期间，kubernetes 能够依据各个节点的资源利用状况，进行主动的减少节点或者缩小节点操作，这在以前的传统利用部署形式中是不容易做到的。

简化部署流程

以往的传统利用公布的时候，须要开发人员把我的项目打包，并查看我的项目的配置文件是否正确，而后发给运维人员，运维人员而后把线上的利用版本备份，而后进行服务进行更新。在 kubernetes 中，咱们少数状况下只须要一条指令或者点击一个按钮，就能够把利用降级到最新版本，而且降级的过程中还可做做到不间断服务。当然整个的流程还波及到容器的操作，本次这里不再做过多介绍。

然而这里有一个意外状况，如果 kubernetes 集群中存在不同架构 CPU 的服务器，而你的应用程序是针对特定 CPU 架构的软件，可能须要在 kubernetes 中指定节点去运行你的应用程序。

进步服务器资源的利用率

传统利用部署的时候，少数状况下总会把资源留有肯定的比例来作为资源的缓冲，来应答流量的峰值，很少有人把单个服务器资源利用率进步到 90% 以上，从服务器故障的概率来说，服务器资源使用率在 90% 要比 50% 高很多，而且服务器一旦呈现故障，都是运维人员来解决问题和背锅，所以传统的物理机或者虚拟机部署利用的形式，硬件的资源利用率相比拟来说是比拟低的。

而 kubernetes 对集群的治理因为形象了底层硬件设施，所以曾经将应用程序和基础设施拆散开来。当你通知 kubernetes 运行你应用程序时，它会依据程序的资源需要和集群内每隔节点的可用资源状况抉择适合的节点来运行。而且通过容器的技术，能够让应用程序在任何工夫迁徙到集群中的任何机器上。而对于服务器抉择的最优的组合，kubernetes 比人工做的更好，它会依据集群中每台服务器的负载状况来把硬件利用率进步到最高。

主动修复

在传统的利用架构中，如果一台服务器产生故障，那么这台服务器上的利用将会全副 down 掉，少数状况下须要运维人员去解决，这也是为什么运维人员须要 7 *24 小时随时待命的一个重要起因。置信你也曾看到过因为中午故障运维人员骂娘的情景。在 kubernetes 中，它监督并治理着所有的节点和利用，在节点呈现故障的时候，kubernetes 能够主动将该节点上的利用迁徙到其余衰弱节点，并将故障节点在资源池中排除。如果你的 kubernetes 集群基础设施有足够的备用资源来撑持零碎的失常运行，运维人员齐全能够迁延到失常的工作工夫再解决故障，让程序员和运维人员过一下 965 的工作节奏。

这点有点像 Actor 模型的设计实践，提倡的是任其解体原理。

统一的运行环境

无论你是开发还是运维人员，在传统的部署计划中，总会有运行环境差异性的懊恼，这样的差异性大到每个服务器的差别，小到开发环境、仿真环境、生产环境，而且每个环境的服务器都会随着工夫的推移而变动。我置信你肯定遇到过开发环境程序运行失常，生产环境却异样的状况。这种差异性不仅仅是因为生产环境由运维团队治理，开发环境由开发者治理，更重要的这两组人对系统的要求是不同的，运维团队会对线上生产环境定时的打补丁，做平安监测等操作，而开发者可能基本就不会吊这些问题。除此之外，利用零碎依赖的第三方库可能在开发、仿真、生产环境中版本不同，这样的问题反正我是遇到过。

而 kubernetes 采纳的容器技术，在把利用打包的时候，运行环境也一起被打入包中，这就保障了雷同版本的容器包（镜像）在任何服务器上都有雷同的运行环境。