怎样理解 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（持续集成、持续发布）等，都是为了提高效率，解放人。
提高效率，才是真正的目标。
