ITPub博客

首页 > 数据库 > 数据库开发技术 > 你真的了解云原生吗?

你真的了解云原生吗?

原创 数据库开发技术 作者:运维book思议 时间:2023-03-15 12:03:05 0 删除 编辑

先放个链接,万一有人关注呢

优质文章推荐

↓ ↓ ↓ ↓ ↓

Linux系统初始化脚本

能够监控100台服务器的磁盘利用率的脚本——16行代码实现

Linux系统初始化脚本之二

Linux系统巡检脚本——快速获取当前系统信息

Linux远程执行脚本——Python运维脚本

哪个Linux发行版会成为CentOS的平替?

自从云计算的概念被提出后,与之相关的概念也逐渐走进大众的视野,云原生便是其中之一。秉着“技术变革,思想先行”的理念,目前云原生仍然没有确切的定义,这个概念还在发展中不断地完善。虽然云原生的概念仍不明确,但云原生一词确日渐流行起来。尤其是近几年的IT行业,云原生更是公认的云计算未来的发展方向。

云原生概念

云原生(CloudNative)是一个组合词,即“Cloud+Native”。Cloud表示应用程序位于云上,而并非传统的数据中心;Native表示应用程序从设计之初便以云为环境,原生为云而设计,在云上以最佳状态运行,充分利用和发挥云平台的弹性与分布式的优势。
Pivotal公司的Matt Stine于2013年首次提出云原生的概念;2015年,云原生刚推广时,Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征:12因素、微服务、自敏捷架构、基于API协作、扛脆弱性;到了2017年,Matt Stine在接受InfoQ采访时又将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6个特质;而Pivotal最新官网对云原生概括为4个要点:容器化、微服务、CI/CD与DevOps。
当前云原生较为公认的概念是,基于分布部署和统一运管的分布式云,以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。

容器化

在云原生中,容器化是其中的一个核心技术,它被广泛地应用于应用程序的部署和运行。
容器是一种轻量级的虚拟化技术,它可以将应用程序及其依赖的库和运行环境打包成一个可移植的镜像,并且可以在不同的平台和环境中运行,使得应用程序的部署和维护变得更加简单和高效。容器化技术的流行,主要得益于 Docker 公司开发的 Docker 引擎。Docker 引擎是一种开源的容器引擎,它可以在 Linux、Windows 和 MacOS 等多种操作系统中运行,使得开发者可以方便地构建、打包、分发和部署应用程序。

容器的出现和普及为开发者提供了良好的平台和媒介,使传统的开发和运维变得更加简单与高效。Docker本身非常适合用于管理单个容器,但真正的生产环境中还会涉及到多个容器的封装和服务之间的协同处理。这些容器必须跨过多个服务器主机进行部署与连接,单一的管理方式已经满足不了业务的需求。在这种情况下,容器编排工具应运而生,Kubernetes更是其中的佼佼者

在云原生中,容器化技术的应用,使得开发者可以更加轻松地构建和部署应用程序。在传统的软件开发中,应用程序的部署往往需要依赖复杂的运行环境和配置,这往往会导致开发和部署的时间长、成本高、可靠性低下。而通过容器化技术,开发者可以将应用程序及其依赖的库和运行环境打包成一个可移植的镜像,这样就可以将应用程序和它所依赖的库和环境整合在一起,使得应用程序的部署和运行更加轻松和高效。
微服务

微服务是一种软件开发和部署模式,其中应用程序被分解为一组小型、独立的服务,每个服务都可以独立地开发、测试和部署。这些服务可以以多种方式组合在一起,以实现复杂的业务逻辑。微服务架构的主要优势是,每个服务都可以独立地开发、测试和部署,这可以大大提高应用程序的可扩展性、可维护性和可靠性。

为了解决传统单体应用带来的弊端,可以采用微服务架构模式进行应用程序的开发或重构。“微服务”顾名思义就是把一个庞大的应用程序拆分为一套小而互联的服务,以服务作为边界,一个服务通常实现了一组不同的特性或功能。这些微服务还会暴露API供其他服务或应用客户端使用。在大型的项目中,微服务之间有条不紊的衔接可以使项目的开发和维护都变得更加得简单。

在云原生架构中,容器化和微服务结合使用,可以使应用程序更易于构建、部署和管理。容器化提供了一种轻量级的虚拟化方式,将应用程序和其依赖项打包成一个可移植的容器,从而使应用程序可以在不同的环境中运行。微服务则将应用程序分解为一组小型、独立的服务,每个服务都可以独立地开发、测试和部署,从而提高了应用程序的可扩展性、可维护性和可靠性。

DevOps

DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发、技术运营和质量保障(QA)部门之间的沟通、协作与整合。

DevOps的主要目的是让开发人员与运维人员更好地沟通、合作,通过自动化流程使软件开发的整个过程更加快捷可靠。

1、瀑布模型

一款软件从构思到交付大致需要经历规划、编码、构建、测试、发布、部署和维护7个阶段。

随着软件产业的不断发展,程序逐渐趋于复杂且庞大,开发难度增加。此时,一个程序员已经难以应对整个交付流程。于是,整个交付流程大致分为三个部分,分别是由软件开发工程师负责的规划、代码与构建,由软件测试工程师负责的测试,以及由软件运维工程师负责的发布、部署与维护

软件开发工程师将编写完成的代码交给软件测试工程师(质量保障)进行测试,软件工测试程师测试完成后将通过测试的版本交给软件运维工程师进行发布。综上所述,此时软件交付大致分为3个阶段,即开发、测试、部署。

在上述软件交付过程中只有上一阶段全部完成后才能进行下一阶段,所以该交付模型被称为“瀑布(Waterfall)模型”。

2、敏捷开发

瀑布模型是一个比较理想化的交付模型,每个人只负责交付过程中的一部分即可。但在实际交付过程中,项目并非是单向运作的,而是根据需求不断地进行改进。

随着用户需求的不断变化与增加,瀑布模型逐渐无法满足软件交付的需求。于是,又一个新概念诞生了,它就是敏捷开发(Agile Development)。敏捷开发是一种能够应对不断变化的用户需求的软件开发能力,即将大项目化成多个小项目,将大时间点化成多个小时间点。在不断进行开发——测试的过程被称为“持续(Continuous)”。

敏捷开发提高了开发团队的工作效率,使软件版本更新更快。敏捷开发的可使产品更快交付到用户手中,更快获取用户的反馈并及时解决发现的问题。相较于瀑布开发,敏捷开发带来的版本变化更小,出现问题的风险较更小,及时出现问题也能得到更快的解决。

3、DevOps诞生

敏捷开发提高了软件交付的效率,但其主要作用在软件开发阶段,所以软件运维工程师成为了整个交付流程的瓶颈。敏捷开发的过程中,软件版本是根据用户需求不断变化的,而对于运维工程师而言,业务的稳定是最重要的,由此开发团队与运维团队产生了两种相悖的理念。

DevOps的诞生就是为了消除开发团队与运维团队之间的矛盾,使运维工程师也参与到持续的软件开发的流程中。

DevOps使开发人员与运维人员更好地合作交流,通过自动化流程使软件交付过程更加快捷可靠。在DevOps的流程中,运维人员需要在项目开发时参与其中,了解开发人员使用的系统架构与技术路线,从而制定合适的运维方案。而开发人员也需要在业务部署时参与到其中,并提供相关的优化建议。

CI/CD

随着DevOps的发展,衍生出了两个新名词,即CI与CD。CI是Continuous Integration(持续集成),而CD对应多个英文,Continuous Delivery(持续交付)或Continuous Deployment(持续部署)。

持续集成(Continuous Integration,CI),是一种能够使开发成员每天至少集成一次的软件开发实践。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集成错误。

持续交付(Continuous Delivery,CD),是一种能够使软件在较短周期内完成开发,并保证其稳定性与保持在随时可发布的状态的软件开发方式。持续交付的目的是让软件的开发、测试、发布更快更便捷,以减少软件开发的时间与成本,减少出现问题的风险。

持续部署(Continuous Deployment,CD),是持续交付的后续工作,指的是将通过测试的代码自动部署到生产环境。持续部署的主要目的是能够随时进行自动化部署,进入生产环境。

持续交付与DevOps的概念比较相似,它们的目标都是缩短软件开发周期,使开发人员、测试人员与运维人员之间的合作更紧密。持续交付体现的是软件交付的全部流程,DevOps强调的是由开发到运维的交付,而持续集成更强调开发到测试的过程。

结束!

谢谢你这么好看还关注我

原文作者:运维book思议;如有侵权,请联系管理员删除。

请登录后发表评论 登录
全部评论

注册时间:2022-09-24

  • 博文量
    333
  • 访问量
    215215