Docker、kubernetes、微服务、SpringBoot/Cloud...好乱！到底要不要学？

2020-05-19 18:00:33

Docker、微服务日益火热的今天，相信标题上这些名词大家都不陌生。但也相信有很多同学并不够清楚他们的概念，不理解它们的关系，也可能有这样的疑惑：不知道跟我有没有关系？要不要学习？怎么去学习？学哪些东西？没关系，今天我们就从头捋捋，让大家都能得到自己的答案。

Docker诞生于2013年，之后就是迅速串红、火的已经发烫。它为什么会火呢？有什么牛x的技术吗？并没有，docker的技术都是linux内核早已存在的技术，像LXC呀，cgoup呀，namespace呀，都是很早就存在的。那docker有啥高明的地方？很重要的一个就是image，它定义了一个交付标准，早期docker官网首页的三个大的单词：build，ship，run。诠释了docker和核心：image的构建，image的传输，image的运行。docker就是定义并且实现了这些标准。那为什么直到2013年docker才出现呢？以前怎么没有人有这样的想法？其实想法一直都有，只是docker出现的时机更好，往往决定性的因素并不是技术本身，而是互联网的发展，市场的需要。

时至今日-2018年，Docker已历经5年发展，Docker公司揭露了今年新的Docker年度数据报告，至今在Docker上的容器镜像下载次数已经超过了370亿次，容器化的应用有高达350万个，目前在LinkedIn网站上的Docker相关职缺也有15,000个。全球活跃的Docker使用者社群已有200多个，包括台湾也有。

随着docker、容器的日渐成熟，容器编排的问题就凸显出来，大量的容器怎么去管理，怎么调度，怎么启停都成了迫切需要解决的问题。有需求就有人去解决，ApacheMesos、kubernetes、docker swarm陆续登场，大有三足鼎立之势，而随着各自的发展，到了2017年下半年，google的亲儿子kubernetes的呼声越来越高，社区也更加活跃、成熟。2017年底，docker swarm和ApacheMesos陆续宣称支持kubernetes，预示着容器编排大战的结束，kubernetes已然成为容器编排领域的事实标准。

服务编排框架的成熟，使得容器的管理越来越方便、高效，容器带来的好处也随之凸显：提升资源利用率节省成本、更高效的持续集成，持续交付、解放运维、快速扩缩容，应对突发流量...

服务编排框架的成熟也让微服务的概念得以落地，同时也催生了java界微服务化的方案，像SpringBoot，SpringCloud。然而服务编排一定是对微服务的编排吗？也就是我们容器里运行的一定是微服务吗？不是的，我们可以运行任何服务，我们现有的业务可以不做任何改造就运行到容器中，让kubernetes去管理、调度。至于微服务呢，只是有了kubernetes，让微服务变得容易管理了。让我们有条件把服务拆分的足够小，足够简单。再也不用担心运维管理的复杂了。了解了docker，服务编排，微服务的关系，我们在看看他们在企业的落地情况。

下面是数人云2018年初做的it行业系统调查报告

这张图纵向的是系统更新频率，其中互联网行业的更新频率高，有92%的服务要每月都更新，并且其中一定有很多的服务要一个月更新多次。

这张图统计的是目前企业it系统支撑所存在的问题。我们看两个比重大的问题，一个是系统的复杂性越来越高，一个是运维管理复杂。在传统单体架构或者SOA架构下，应用如果频繁升级更新，开发团队会非常痛苦。为什么呢？企业的业务系统经过多年发展，系统往往会非常庞大，复杂性越来越高，要改动其中任何一小部分，都需要重新部署整个应用，敏捷开发和快速交付根本无从谈起。还有传统企业在长期的IT建设过程中，往往会使用到不同的技术，这导致技术栈之间差异很大，统一的管理和运维变将得非常复杂。随着这样一些问题越来越凸显，企业向微服务架构转型的需求也越来越强烈。

这张图是目前微服务架构在企业的落地情况：有6%的企业已经部分引入了Spring Cloud开发框架。另外，9%的受访企业采用了Dubbo等其他微服务框架。此外，还有51%的企业在考虑往云原生方向转型，包括公有云、私有云。由此可见，绝大部分企业是有架构转型的需求的。

这张图是2017年docker的使用情况。在接受调研的企业中，在生产环境中采用Docker的比例为9%，测试环境使用达22%。而且规模越大的企业，尤其是服务器规模在500台以上的，是Docker容器的主要采用者。另外，正在考虑评估中的占到被调研企业的一半以上。企业的关注度急剧升高，Docker使用正在快速普及。而容器和微服务相辅相成，他们成熟的时间点也非常契合。