<返回更多

从云计算到云原生:从概念到落地

2022-04-27    飞哥大数据
加入收藏

云计算最近几年已经火得不行,云原生(Cloud Native)这个概念又来了,如果上云不“原生”,那就等于白上云。究竟什么是云原生?云原生有何优势?怎么从“不原生”一步一步做到云原生?本文将给出切实可行的云原生落地指南。

我们先从云计算说起。在云计算普及之前,一个应用想要发布到互联网,就需要企业自己先买几台服务器,找一个IDC机房,租几个机架,把服务器放进去。接下来就是装linux系统,部署应用。我们就假定用JAVA写了Web应用,怎么部署上去呢?先配置Tomcat服务器,在把编译好的war包上传到服务器,有用FTP的,安全意识高一点的会选SCP,然后配置NginxMySQL这些服务,最后一通调试,把应用跑起来,就算齐活。

这种物理机配合自搭网络环境、自搭Linux、自配环境的方式,有很多缺点,但最主要的问题有这么几个:

  1. 扩容和维护难,因为是物理机,需要先采购后跑机房,遇到双十一业务量猛增是来不及扩容的,用行话讲就是计算资源缺乏弹性;
  2. 安全性太差,熟悉Linux的运维工程师本来就少,精通SELinux的更是凤毛麟角,而且,系统安全性仅仅是一个方面,应用部署的权限、流程造成的安全漏洞更大;
  3. 部署流程不规范,开发、测试和运维脱节,缺少自动化测试和部署,无法快速迭代业务。

解决方案是上云。上云不能解决所有问题,但部分解决了前两个问题:

  1. 云服务商提供的是虚拟机,比起物理机,虚拟机的创建、维护、销毁比物理机简单了太多,且随时可以扩容,很大程度上解决了“弹性计算”的问题,至于弹性程度有多大,还得看应用的架构设计水平;
  2. 和绝大多数中小企业相比,云服务商在网络和服务器安全方面要强若干个数量级。只要选择合适的官方镜像,配合防火墙规则,系统级别的安全问题大大减少,可以将重点放到应用本身的安全性上。

但是如果仅仅满足上云,把物理机换成虚拟机,把物理网换成虚拟专用网(VPC),是远远不够的。这些是计算资源和网络资源层面的简化。应用方面,如果延续旧的一套开发、测试、部署流程,做不到快速迭代。

要做到快速迭代,敏捷开发,就需要DevOps,即开发运维由一个团队负责,开发阶段,就要把部署、运维的工作考虑进去,而不是发布一个war包或者jar包后扔给运维不管了。

重开发、轻部署,直接后果就是缺少自动化发布流程。想要把部署规范化,就需要整体考虑一系列问题。

还是以Java应用为例,如果是手动部署,那么就上传war包到服务器,覆盖原有的版本,重启Tomcat,再测试。如果发现有严重问题要回滚怎么办?把老版本再传一遍,然后重启Tomcat。

手动部署,每次部署都是一次生死考验,所以最好不要安排在半夜,以免手抖敲错了命令,本来中断10分钟的服务,变成了灾备恢复,中断3天。

稍微靠谱一点的是写脚本部署,但各家写出来的脚本都有各家特色,不通用,不易维护,所以更好的方式是用成熟的部署方案,比如Ansible,把脚本标准化,比如做成蓝绿发布,把服务器分组,比如A、B两组,先把流量切到B组,升级A组服务器,有问题就回滚,没问题了,再把流量切到A组,升级B组服务器,最后,恢复正常流量,整个部署完成。

但是回滚这个事情,远没有那么简单。做过开发的同学都知道,升级新版本,一般要加配置,改配置,如果回滚到旧版本,忘了把配置改回去,那旧版本可能也不能正常工作。

上云,除了物理变虚拟,简化运维外,最重要的特点——弹性计算,一定要充分利用。

理论指导实践,实践完善理论。如果我们分析大多数基于互联网的应用,可以看到,一个应用,通常用到的资源如下:

  1. 存储资源,通常对应着一个或多个数据库,例如MySQL、Oracle、PostgreSQL等;
  2. 计算资源,以Java应用为例,就是一个或多个Web应用,跑在Tomcat,或者通过SpringBoot自带嵌入式服务器;
  3. 网关,通常是Nginx之类的服务器,对外作为统一的服务入口,对内提供反向代理;
  4. 其他支撑业务的组件,例如,为提升应用性能采用的redis集群作为缓存,应用内部各组件通信使用的消息系统如Kafka等,以及随着业务不断扩大增加的ES集群、日志分析和处理的集群等。

上云后,云服务商通常都提供托管的数据库,以及大规模存储系统(S3),可解决存储资源问题。通过云服务商提供的负载均衡(Load Balancer),也无需自行部署Nginx等网关,免去了运维的问题。各种标准的业务组件如Redis、Kafka等,均可直接租用云服务商提供的资源。

我们重点讨论计算资源,也就是云上的虚拟机资源。对于应用来说,可以设计成有状态和无状态两种。一个应用在一台虚拟机内跑着,如果有本地文件的修改,它就是有状态的。有状态的应用既不利于扩展,也不利于部署。反过来,如果一个应用在运行期数据总是存在数据库或者缓存集群,本地文件无任何修改,它就是无状态的。

无状态的应用对应的虚拟机实际上就是不变的计算资源。这里的“不变”非常重要,它是指,一台虚拟机通过一个固定的镜像(预先内置好必要的支持环境,如JRE等)启动后,部署一个应用(对应一个war包或者jar包),该虚拟机状态就不再变化了,直接运行到销毁。

有的同学会问:如果给这台虚拟机重新部署一个新的应用版本,它的状态不就发生了变化?

确实如此。为了确保虚拟机的不变性,一旦启动后部署了某个版本,就不允许再重新部署。这样一来,对虚拟机这种计算资源来说,就具有了不变性。不变性意味着某个虚拟机上的应用版本是确定的,与之打包的配置文件是确定的,不存在今天是版本1,明天变成版本2,后天回滚到版本1的情况。

计算资源不变,能确保启动一台虚拟机,对应发布的应用版本和配置是确定的且不变的,对于运维、排错非常重要。

那么如何在保持计算资源不变的前提下发布新版本?

我们以AWS的CodeDeploy服务为例,假设一组正在运行的某应用v1集群包含3台虚拟机:

从云计算到云原生:从概念到落地

 

现在,我们要把应用从v1升级到v2,绝不能直接把现有的3台虚拟机的应用直接升级,而是由CodeDeploy服务启动3台新的一模一样的虚拟机,只是部署的应用是v2。现在,一共有6台虚拟机,其中3台运行v1版本,另外3台运行v2版本,但此刻负载均衡控制的网络流量仍然导向v1集群,用户感受不到任何变化:

从云计算到云原生:从概念到落地

 

v2集群部署成功后,做一些自动化冒烟测试和内网测试,如果有问题,直接销毁,相当于本次部署失败,但无需回滚。如果没有问题,通过负载均衡把流量从v1集群切到v2,用户可无感知地直接访问v2版本:

从云计算到云原生:从概念到落地

 

稳定一段时间(例如15分钟)后,销毁v1集群。至此,整个升级完成。

上述的蓝绿部署就是CodeDeploy的一种标准部署流程。CodeDeploy也支持灰度发布,适用于更大规模的应用。

把计算资源不可变应用到部署上,实际上是充分利用了弹性计算这个优势,短时间创建和销毁虚拟机,只有上云才能做到,并且针对云计算,把部署流程变得更加简单可靠,每天发几个版本甚至几十、几百个版本都变得可能,DevOps能落地,有点“云原生”的味道了。

说到AWS的CodeDeploy,最早我使用AWS时,对于它的计费采用Reserved Instance预付模型感到很不理解,租用一台虚拟机,按国内阿里云、腾讯云包年包月预付享折扣不是更直观吗?如果仅仅把上云变成租用虚拟机,那就完全丧失了弹性计算的优势,相当于租用了一台虚拟机在里面自己折腾。AWS的Reserved Instance计费并不绑定某一台虚拟机,而是一种规格的虚拟机。

我们还是举例说明,如果我们有1台2v4G规格的虚拟机,并购买了1年的Reserved Instance,那么,我随时可以销毁这台虚拟机,并重新创建一台同样规格的新的虚拟机,Reserved Instance计费会自动匹配到新的虚拟机上,这样才能实现计算资源不变,频繁实施蓝绿部署,真正把部署变成一种云服务。最近阿里云终于推出了节省计划的付费模式,有点真正的云计算的付费味道了,但是腾讯云、华为云还停留在包年包月和按量付费这两种原始租赁模型。

讲了这么多自动化部署,实际上一个指导思想就是如何充分利用云的弹性计算资源。从充分利用云的弹性资源为出发点,设计一整套开发、部署、测试的流程,就是云原生。弹性资源利用得越充分,云原生的“浓度”就越高,就越容易实施小步快跑的快速迭代。

那么虚拟机是不是弹性最好的计算资源呢?从应用的角度看,显然容器是一种比虚拟机更具弹性,更加抽象,也更容易部署的计算资源。

容器和虚拟机相比,它实际上是一种资源隔离的进程,运行在容器中的应用比独占一个虚拟机消耗的资源更少,启动速度更快。此外,容器的镜像包含了完整的运行时环境,部署的时候,无需考虑任何额外的组件,比其他任何部署方式都简单。使用容器,开发部署流程就变成了开发,生成镜像,推送至Docker Hub或云服务商提供的Registry,直接启动容器,整个过程大大简化。

使用容器比使用CodeDeploy部署还要更加简单,因为CodeDeploy需要在虚拟机镜像中预置Agent,由于没有统一的发布标准,还需要配置CodeDeploy,告诉它去哪拉取最新版本,这又涉及到一系列权限配置。而容器作为标准的部署方案,连发布系统都以Registry对各个镜像版本进行了有效管理,所以部署非常简单。

容器作为一种弹性计算资源,也应遵循计算不变性,即不要给容器挂载可变的存储卷。一组不变的容器集群才能更容易地升级。容器的运行方式本身就遵循了不变性原则,因为通过一个镜像启动一个容器,在运行过程中,是不可能换一个镜像的。容器本身也强烈不建议应用写入数据到文件系统,因为重启后这些修改将全部丢失。

容器的启动和销毁非常容易,不过,容器的管理却并不简单。容器的管理涉及到创建、调度、弹性扩容、负载均衡、故障检测等等,Kube.NETes作为事实上的容器编排标准平台,已经成为各个云服务商的标配。

如果要直接使用K8s,在云环境中首先要有一组虚拟机资源作为底层资源,然后搭建K8s环境,定义好容器编排并启动容器。云服务商几乎都提供托管的K8s服务,但直接管理K8s仍然需要非常熟悉K8s的工程师。

还有一种更简单的使用容器的方式,即完全将底层虚拟机和K8s托管给云服务商,企业客户只需关心如何部署容器,底层的K8s和虚拟机对企业不可见或者无需关心。AWS的Elastic Container和阿里云的弹性容器均为此类服务。对于中小规模的应用来说,计算资源直接使用容器,再配合云服务商提供的负载均衡,托管的数据库、消息系统、日志系统等组件服务,应该是目前最“云原生”的一种方案。

最后,我们总结一下云原生的特点:

所谓云原生,就是在上云的过程中,充分发挥云平台的弹性计算、弹性存储的优势,尽量把应用设计成适合云计算的架构,把部署设计成简单易用的流程,这样才能实现业务快速上线,快速迭代。

云原生是一个大方向,在上云的过程中,逐步改造应用架构和部署流程,从手动往自动转,逐步增加计算资源的弹性,就能把云原生一步步落地。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>