一个小白的云原生学习心得|社区征文

社区征文
前言

云原生这个概念这两年可谓是爆火,无论是应用还是安全,凡是和云相关的,都要在云后面加上原生二字,好像不提云原生,在技术上就落后了一大截,经过一段时间的学习,我也从云原生的小白慢慢变成了一个入门者。为了记录一下自己这段努力学习的经历,先将学习知识和感受整理一下,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。

云原生是什么?

说到云原生,想必大家跟我刚接触时一样,一头雾水,若是查阅资料来看,看完云里雾里,对云原生的解释总是迷迷糊糊,说来说去可能还是不知所以然。

简单来看,我们可以把云原生分成原生两部分来看。

云我们应该都不陌生,公有云、私有云、混合云等各种云,它代表的是应用程序所处的环境并不是传统的物理服务器;

原生就是亲生的、土生土长的意思,代表应用开发应用的设计之初就考虑到应用所处的环境是在云环境之上,为云而设计,可以直接在云平台上运行或非常轻松的迁移到云平台。

简单来说,云原生就是换了个开发环境,由原来的本地服务器换到了云服务器,应用程序构建、运行为了适应这个云服务器这个环境而行形成的一套完整的技术体系和方案。

picture.image

云原生的核心元素

云原生并非是一个独立的应用或产品,它通常由微服务、Devops、敏捷基础设施三者组成,首先通过敏捷的基础设施快速的进行业务架构的设计,然后基于微服务的方式进行快速的业务开发与迭代,最后通过Devops快速的交付业务价值。

可以简单地把云原生理解为:云原生 = 微服务 + DevOps + 持续交付 + 容器化。

picture.image

微服务

传统的单体架构随着业务的发展,复杂度增加,更新、维护困难,代码都在同一个程序中,增删改业务修改,也会影响其他代码,给测试增加了难度,针对单体架构的不足,为了适应大型项目的开发需求, 微服务便应运而生,其本质就是根据业务领域和模块进行划分、解耦,拆分成一个一个单独部署、运行的微小应用。

picture.image

微服务的优点:单一职责,扩展灵活,独立自治,耦合性低。

容器

容器我们可以理解为一个个相互隔离的集装箱,每个集装箱中都包含自己的应用程序。容器化就是将应用程序代码和依赖项捆绑到一个单一的可执行程序包中,能为我们提供一种可移植、可重用的方式来打包、分发和运行程序。

picture.image

现在比较流行的工具是docker和k8s,Docker是一个开源的应用容器引擎,k8s是一个开源的容器集群管理系统,可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

DevOps

它是一组过程、方法与系统的统称,dev就是开发,ops就是运维,开发和运维人员通过持续不断的沟通和协作,可以以一种标准化和自动化的方式快速、频繁且可靠的交付应用。从而做到比传统DevOps更高的服务质量、更低的开发运维成本,让研发专注于业务的快速迭代。

picture.image

持续交付

持续交付的意思就是在不影响用户使用服务的前提下,可以稳定、持续地保持随时可发布状态的把新功能发布给用户使用,它的目标是促进产品迭代更频繁,持续为用户创造价值。

学习建议

现在网上的资料很多,但也很乱,不同的人对云原生有着不同的理解,反而会让自己困惑,可以选一个最容易记住和理解的定义:微服务+容器+DevOps+持续交付。

听再多大佬的“夸夸其谈”,都不如自己动手实战出来一些东西,可以手动创建出来一些实例,从部署上线几个应用开始;

另外,云原生的基础架构编排工具K8S的底层实现是使用go语言,想要很好的运维和开发K8S,必须掌握好go语言。

官网技术栈梳理:

https://landscape.cncf.io/?category=app-definition-and-development&grouping=category

总结

说了这么多,你可以简单的理解为,云原生就是换了个开发环境,由物理服务器换到了云服务器,然后为了适应这个云服务器的环境做了一些技术架构调整,这就是云原生。

云原生是未来开发的方向,还有很多需要去学习的地方,以后还会继续努力,也希望正在做这个方向的朋友可以多多交流。

0
0
0
0
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论