文章目录

• 1. 为什么要云原生？
• 2. 简单了解云原生的技术基础
• • 2.1 云计算
  • 2.2 云原生
  • 2.3 Docker
  • 2.4 K8s
• 3. 关联解疑
• • 3.1 Docker和K8s的关系
  • 3.2 容器化的爆火
  • • 3.2.1 企业数字化转型大背景
    • 3.2.2 云计算企业降本增效缺口
    • 3.2.3 Docker和K8s火爆的必然性
    • 3.2.4 容器化带来的影响

1. 为什么要云原生？

现在容器化和云原生十分火爆，但如果要理解为什么这个技术在近几年突然爆火，身为传统的Springboot和Springcloud体系开发者都有很多困惑，怎么就突然这么火爆了呢？诸如我就产生了以下问题：

1. 传统的springboot或springcloud体系和云原生对比起来有何差别？
2. 传统的spring体系和云原生可以给开发者带来何种便利？
3. 对接云原生具有何种代价？
4. 使用云原生后业务系统使用MQ或Reids此类的中间件方式会有何种改变？
5. 云原生能提供何种服务？
6. 云原生对传统开发模式的对比？
7. 云原生所说的DevOps和持续交付具体如何实现？
8. Docker和K8S赋予了程序何种能力？又让程序付出了何种代价？
9. 云原生对传统开发模式中的开发人员有何影响？
10. 云原生和微服务的关系？
11. 不使用云原生的开发模式和使用云原生的开发模式？
12. 云原生和云计算的关系？

要解答这些疑问还是要了解清楚云原生是什么，以及其技术基础和应用场景到底是什么。

2. 简单了解云原生的技术基础

2.1 云计算

云计算本质是一个可以提供IaaS、PaaS和Saas三种不同服务的产品。

• SaaS：提供固定的功能，客户可根据需要的功能购买对应的产品，用户无需开发，直接付费使用；
• PasS：为程序运行时提供用于开发、测试和管理的应用程序，用户需要自行开发程序，但对程序的各种管理软件和资源都无需关心；
• IaaS：把IT的基础资源（如服务器、存储和网络）封装为产品，用户需要自行开发、维护和管理整个开发周期，包括一些公共框架。

2.2 云原生

云原生官方的定义：基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。

直白的说云原生就是制定一系列的应用规范，并将其集成封装后的云计算PaaS产品。

云原生带来的好处：

1. 便利性：公司自己购买维护机器和聘请技术人员开发维护技术框架都是成本，而云原生则是自己承担服务器资源和框架维护的成本，对外公共开放其使用权限，以避免处处都需要维护服务器和框架；
2. 低成本：中小型公司或技术薄弱的公司要想立马搭建起一套高可用高并发的微服务体系， 可直接购买云原生的服务支持；
3. 可靠性：云原生的产品基本都有大公司支持，稳定性、性能和容灾等各种指标都能兼顾；
4. 伸缩性：可针对不同的业务阶段进行性能伸缩，而无需考虑机器应该如何处置；

与Springcloud的差别：Springcloud体系要求开发者自己对技术较为熟悉，与Java程序绑定，且技术维护都需要自己做；而云原生则是为开发者提供基础资源，开发者只需要会使用即可，而无需自己再去维护基础资源；因此使用云原生，开发者就可以把更多的精力放到如何使用这些技术完成业务需求，而无需关心基础设施是否安全可靠稳定。

2.3 Docker

Docker是运行在Linux的开源的应用容器引擎程序，基于Go语言并遵从Apache2.0协议开源。

其最大优势就是只要目标方提供了容器的镜像，就可以直接拉取镜像运行，诸如MySQL、nginx和JDK这些开源资源都可以直接拉取其镜像。

当拉取了镜像后需要使用Dockerfile文本文件来定制镜像，如使用哪个镜像去运行镜像支持的可执行文件。

一台机器可运行多个镜像文件，即多个容器。

2.4 K8s

Kubernetes是一个用于自动化部署、扩展和管理容器化应用的开源容器编排工具，Docker官方的Docker Swarm是其竞争对手，其通过在集群上形成一个抽象层来部署和管理容器中的应用程序。

K8s的作用：

1. 控制和管理应用程序对资源的使用；
2. 自动负载均衡多个实例之间的请求；
3. 如果主机资源耗尽或主机死机，将应用程序实例从一台主机迁移到另一台主机上；
4. 当有新的主机加入集群时，新增额外可被自动使用的资源。

K8s被CNCF基金会倡议的项目，增长迅速，其优势在于：

1. 可移植性和灵活性：K8s可在各种基础设施和环境设置下运行，其它的容器编排器则做不到；
2. 开源支持：CNCF负责管理K8s，是一个完全开源、由社区驱动的项目，没有一家公司可以控制平台框架的发展方向，由很多大公司背书，因此不用担心稳定性和维护性；
3. 多云兼容性：K8s能够轻松的扩展到另一个云，简单来说就是跨机房；

K8s的组件：

• K8s使用Etcd来完成整个集群的服务注册与发现，Etcd是由golang语言编写的，在集群中每个机器都被称为节点；
• K8s通过控制平面来管理不同节点，使用HTTP发送接收命令或连接到系统运行命令行脚本，控制了K8s与应用程序的交互；
• K8s的Pod是K8s管理容器集的最小单位，每个Pod中都有被分配的单独IP地址，在Pod中的容器内存和存储资源都是共享的，Pod也可以只有一个容器；
• Kubelet被用来跟踪Pod及其容器的运行状态，检查Pod规则并确认Pod是否健康；
• Kube代理被用来实现网络代理和负载均衡，充当在每个节点和API服务器之间的连接，在每个节点上都会运行，外部和内部请求到Pod都会经过Kube代理；

3. 关联解疑

3.1 Docker和K8s的关系

到这里可以很好的理解Docker和K8s的关系了，Docker是运行在机器上的容器引擎，可以看成是虚拟机，但性能比虚拟机强很多，直接对接底层Kernel核心。Docker能够让一台机器可以创建多个容器以运行多个应用程序。而由于Docker的容器编排器Swarm由于易用性不能满足要求，被开源框架K8s所代替，因此K8s成为了运行在Docker容器上的最主流容器编排器，用来支持在容器上快速部署管理应用程序。

3.2 容器化的爆火

一个技术的兴起爆火原因是多方面的，但云原生和容器化的流行个人认为主要还是有两个原因：企业数字化转型大背景和云计算提供者的降本增效

3.2.1 企业数字化转型大背景

现在每个企业都想进行数字化转型，特别是传统行业，在看到新兴互联网行业依靠各种软件系统混的风生水起，谁不想来掺和一脚？况且数字化管理是真真切切可以提高企业的管理能力和效率，所以企业数字化转型对于企业的发展来说是必要的。

此时企业有两种选择，一是购买SaaS产品服务，但自定义产品的代价十分高昂且效率无法保证；二是自己成立一个业务开发组，所有需求从内部孵化落地。第二个方案现实问题就是传统企业中程序员的占比是非常小的，如果靠自己从无到有做数字化转型，招聘大量的程序员且不说，各种机房服务器的搭建都是一笔巨大的开销。此时就产生了一个很大的需求缺口：很多企业都需要PaaS服务。

这些企业只需要购买基础的服务器和设备资源，并招一些相对资深程序员更加便宜的初中级程序员，就能开始开发自己系统和产品。对于大部分企业而言这相对于从头到尾自己搭建机房性价比要高很多。

3.2.2 云计算企业降本增效缺口

市场存在巨大的PaaS需求缺口，云计算火爆是必然的事情。但对于云计算企业而言，如何以客户相对满意的价格提供服务是最重要的事情，如果还是和以前一样，以机房服务器租赁的方式提供云计算服务，大部分企业还是无法接收这种成本。

对于云计算企业而言，巴不得可以一台服务器可以服务N家企业，这样自己的收益才会最高。

3.2.3 Docker和K8s火爆的必然性

云计算企业要求一台服务器可以服务N家企业来提高自己的收益，而Docker和K8s正是为这种场景而诞生的，因此众多云计算企业选择Docker和K8s来实现PaaS服务就是很理所当然的事情了。

在此基础上CNCF提出了云原生的规范，为提供云计算PaaS服务的企业提供了规范和背书，在这种背景下，容器化想不火都由不得它了。

3.2.4 容器化带来的影响

私以为容器化带来的最大影响就是业务型开发需求进一步扩张，而各种中间件维护开发工程师需求量会被压缩。

当越来越多的企业加入到云原生，一起平摊服务器成本后，越来越多的技术维护将会慢慢淡出我们的视野。以最常见且重要的负载均衡来说，阿里云提供SLB服务，可以实现内网调用和外网调用的负载均衡，这样我们只需要知道对应的域名直接调用即可，无需再考虑使用负载均衡中间件来控制流量。

这种变化会导致一个趋势：

1. 业务开发将占绝对主流：业务开发只需要会熟练使用各种中间件来解决业务问题即可；
2. 维护中间件开发的技术大佬生存空间被挤压：由于大部分企业都不再需要维护中间件，出了问题后直接找云服务商，中间件开发的大佬岗位将会减少。

但毕竟经过这么多年的发展，技术存量摆在那里，岗位需求一定是会有的，只是岗位增量会逐步减少。

而对于业务开发来说，这种趋势虽然不再要求精通各种中间件管理知识，但对中间件的使用要求将会越来越高，毕竟要关注的技术点变少，那就只能精通剩余的技术了。