怎样理解 kubernetes 以及微服务?

目录

云计算带出了弹性云,k8s等调度系统带火了微服务,微服务又反过来了给k8s等系统加了一把火。

微服务不是一个新的东西,一个系统要想承受大规模的访问压力,就会逐渐走向微服务。

譬如,一个网站,开始的时候,只有很小的访问量,只需要一个webserver,一套后端代码就可以了:

              --> /login
 webserver --/--> /shop   ---> database
              \-> /discuss

然后随着访问量增加,系统压力越来越大,这时候需要进行服务拆分:

           -> webserver --> /login ---                ---worker ---   
  proxy --/-> webserver --> /shop  ---\-> Register <-/---worker ---\->database
          \-> webserver --> /pay   --/                \--worker --/   

在将系统按照服务进行拆分之后,会发现有很多服务都是无状态的,譬如proxy后面挂接的webserver,以及数量众多的worker。

拆分后的系统中有众多的worker分别负责不同的业务逻辑,这些worker会将自己的地址注册到“注册中心”。

当一个服务要与另一个服务交互的时候,直接从注册中心获取worker的地址列表,也就是所谓的“服务发现”。

在最早的时候,这个webserver和woker用的都是真实的物理机,部署后数量就是固定的,不会随着业务压力的变化而变换。

有了云计算之后,加减物理机变成了加减虚拟机,而虚拟机的创建和删除又是非常快速简易,让服务跟随业务压力伸缩开始可行。

只需要开发一个监控系统,监控业务压力,当压力增大,就调用云平台的api创建虚拟机,反之就删除。

于是人们开始考虑,有了云之后,业务系统是不是可以有更好的设计方式,更好的发挥出云平台的优势,这样的业务系统也就是所谓的“云原生应用”。

云原生应用其实在理念上并没有什么革新,依然是服务拆分、通过设计成无状态服务得到水平扩展的能力和高可靠性。

但是虚拟机体积大、启动慢,一些云平台,譬如亚马逊,虽然也提供了弹性功能,但是人们还是习惯于把虚拟机当作物理机使用,延续以前的做法。

后来使用容器技术的docker出现了,容器与虚拟机非常不同,它其实就是一个自带运行环境的程序,启停都很迅速。 而且docker是一个全新的概念,不像虚拟机那样背负着传统的观念和习惯。它不仅没有任何历史负担,甚至有一种完全是为了微服务和弹性云而生的感觉。

谷歌又恰好推出了开源的容器管理系统kubernetes,将这一切推向了高潮。

因为只有docker是不够的,更重要的是要有一套管理docker的系统,可以很方便的在其中部署应用。

kubernetes率先回答了“云原生应用”要如何做,它从以往的经验中提炼出的”service”和”pod”这两个概念,精确地解答云原生应用的问题。

在kubernetes中,service是由多个pod组成的,每个service有一个固定的访问地址。

向service的地址发起的访问,会被kubernetes自动的转发给隶属这个service的pod,pod就是最后提供服务的容器。

其实,这就是一个负载均衡+多个后端的结构,但是kubernetes自动完成了诸如创建后端、配置后端这样的工作,并且内置了根据监控情况调整后端数量的工作。

k8s代为完成了原本需要人们自己操作的重复性的工作,使人们可以更为专注于服务的拆分和开发工作。

之后的devops又在此基础上发展了cicd(持续集成、持续发布)等,都是为了提高效率,解放人。

提高效率,才是真正的目标。

作者微信

推荐阅读

Copyright @2011-2019 All rights reserved. 转载请添加原文连接,合作请加微信lijiaocn或者发送邮件: [email protected],备注网站合作

友情链接:  李佶澳的博客  小鸟笔记  软件手册  编程手册  运营手册  爱马影视  网络课程  奇技淫巧  课程文档  精选文章  发现知识星球  百度搜索 谷歌搜索