云计算带出了弹性云,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(持续集成、持续发布)等,都是为了提高效率,解放人。
提高效率,才是真正的目标。