云原生技术的前世今生

注：该文章来源——直播公开课《云原生技术的前世今生》

 

什么是云原生？

 

云原生的概念大家都有所耳闻，对于云原生中的一些具体技术，都有了解甚至很深入的研究。但是我们应该怎么定义云原生，通过与不同的人交流，每个人答案都不一样，有的是容器+微服务，有人说是分布式架构与声明式API，pivotal的12要素，CNCF的云原生定义。所以云原生其实对于大部分人来说，是一个相对模糊和笼统的概念。

      

云原生不只是一系列技术的组合，而是一套适用于云计算时代的IT架构与方法论，包括容器化、微服务、DevOps、持续交付等主题。它的核心是通过优化应用的架构设计、开发流程和部署、运维方式，让云计算的弹性、灵活、自动化优势得到充分发挥，使得工程管理和基础设施管理变得更加高效和自治，从而帮助管理者将精力集中到业务创新之中。

 

云原生的诞生历程

 

任何一个IT的理念都是来自业务的驱动的，对云原生来说也是如此，云原生理念的诞生来自以下三种业务的驱动：

第一个是IT用户量和业务规模的增长，首先是互联网用户的业务下沉，主要包括互联网业务向三四线城市下沉，同时互联网业务朝着老年人、儿童的下沉，就导致整个互联网业务的用户规模上升，其次是智能设备和物联网的出现，导致进入互联网的终端越来越多，同时市场运行活动的出现，伴随着明星效应、网红效应的产生，导致整个互联网的流量出现一种巨大的波峰、波谷。这些情况的出现对运维人员有巨大的挑战，即如何在支持业务高成本的同时节约资源的成本？这就是第一个业务所带来的挑战。

 

第二个业务在于我们的业务形态与组织架构形态逐渐变得复杂化，首先是APP的横向扩张，在以前每个APP的功能比较单一，搜素的仅是搜素，播放视频的仅播放视频，现在任何一个APP都是麻雀虽小，五脏俱全，任何一个APP都有包括会员、积分、支付、广告等不同功能。随着这种横向扩张，任何一个公司都会变得越来越复杂，包括各种的功能、模块和结构。其次是数据与技术中台的整合，现在是数据化运营，我们希望通过大数据的分析让数据产生更多价值。要做到这一点就需要将不同业务系统的数据打通，同时把这些数据汇总起来，这样就要将原本不相关的业务系统相连起来。最后是业务生态化发展，即各系统不仅内部数据需要打通，外部业务也需要打通。随着这些变化导致业务形态和组织架构越来越复杂化，这面临一个挑战，即如何在业务横向扩展和打通的时保证系统性能和可维护性？

 

第三个业务来自整个行业的研发团队规模的扩大，首先企业研发团队的扩大，研发投入会加大，其次是研发、测试、运维分工会越来越明确，这时候就会带来额外的沟通成本和交互成本。同时还会产生跨部门协同和外包开发。这时候就需要明确如何提升研发人效的同时增强系统保障？

 

为了满足业务发展的需求而持续演进的IT架构与方法主要有哪些呢？首先是基础设施方面，首先是物理机的方式承载业务的应用，但是物理服务器非常的笨重，一台物理机有几十或几百G的内存，如果分配给单个业务就会存在巨大的资源浪费，同时物理机的采购流程、部署流程、上线流程是非常漫长的，采购一台新的物理机到上线完成可能需要几天，甚至几周的时间。同时对于业务扩容而言也是很难满足业务敏捷上线和扩容的需求。第二代的基础是设施是出现云计算和虚拟机的技术。也就是通过虚拟机技术将原本的一台物理机切分成多台相互隔离的虚拟机，把业务运行在隔离的虚拟环境内，这样可以将业务细粒度的划分，同时虚拟机的部署和上线是在分钟级别的，能够加速业务上线和迭代。随着虚拟机技术的发展，现在的云原生时代，我们的基础设施已经变成了容器化。容器是比虚拟机一种轻量化的虚拟技术。通过容器我们只需将一个应用和它应用所需的依赖打包在一起，作为一个资源分配的单位，这就避免了像传统虚拟机一样，需要每一个虚拟机分配一个完整的操作系统和该操作系统所依赖的驱动。这样既节约了资源成本，节约了资源利用率，同时容器只包含业务需要的代码和依赖包，它的启动速度从分钟级别变成了秒级别。这样上线和扩容的速度也越来越快。同时因为容器的轻量级和快速启动特点，使得容器可以非常灵活地从一台虚拟机或物理机上移动到另外一台虚拟机或物理机上。这样当底层设备发生故障，我们可以在几秒中内重新部署、重新启动。

 

在应用架构层，在最早的时候我们都是单体架构的，即一个应用从前端，到中台，到数据端，都是通过写在一个系统里面，一起打包一起部署。这种单体架构随着业务的扩大，就变成了分层的架构，即将应用的控制层、计算层以及数据层分开作为不同的系统来部署。这样就可以针对不同的层进行维护，扩容。这种分层架构随着各层之间的交互越来越多，如前面提到的需要将应用的数据平台、数据面打通，把应用所依赖的技术中间键可以共用，就出现了微服务架构。在微服务架构下，可能会将一个应用拆分成n个组件，并且不同应用的组件也可以进行引用，互相依赖。通过这种微服务架构可以将应用变得更加的灵活，更加具有可拓展性，同时降低重复造文本的成本，以及提升性能的技能及能力。

 

最后就是对于研发流程的引进，最传统的研发模型是瀑布式的模型，也就是一个季度或这是一年定一个目标，在这个目标之前，各个团队、各个组织架构都分别研发自己的组件，然后在截点之前做整合、集成。这种研发效率显然是非常低消的。接着就出现的敏捷开发的流程，敏捷通过迭代的方式来管理，一个迭代可能是一周、两周或一个月，在一个迭代之内，将我们的任务拆分成不同的模块，并且交给不同的人开发，在迭代结束之后，把这些模块进行整合和上线。在云原生时代，研发流程升级到了DevOps形式，所谓的DevOps就是在研发流程中将研发人员、测试人员、运维人员都整合到一起，把他们当做流水线中的不同环节，让他们的工作在一个串联的流水线上通过不同的工具来高效地执行。在这种DevOps形式下，任何一个新的需求出现的时候，这个应用可以随时开发，随时测试并且随时上线，而不受传统的迭代和开发周期的影响。

 

为了满足前面提到的业务发展述求，IT架构的基础设置、应用架构都在不断的引进。但是云原生并不是上述技术战略的有机组合，云原生是多种技术理念的一个有机整体，并且其中包含了怎样去有效地整合和运用这些技术能力的一个方法论。所以云原生的出现是随着这些技术能力的发展，尤其是容器的发展。我们可发现容器化、微服务化、DevOps化是相互促进的过程。当一个企业实现了容器化的搭建之后，就可将业务拆分成更细粒化的部署单元，通过容器的方式部署到技术架构之上。通过这种细粒度的拆分，就促进微服务能力的提升。随着业务的微服务化，在做DevOps与敏捷开发过程中，就不需要每次对整个系统及应用进行更新，可针对微服务的一个单元、一个容器做版本的更新、上线、管理。这样随着微服务的发展，DevOps流水线也能够变得更加的高效。因此云原生是一套有机的方法论，而不是技术的简单堆叠。

 

云原生转型技术中主要包含四个维度，首先是容器化设施的搭建，用容器化方法搭建一套来做部署、编排、管理的平台，它的优势能为企业带来更灵活的的资源使用方式。第二是当我们有了这样的容器化设施后，可以将应用通过容器化的方式来做托管管理，对应用环境、配置都用容器的方式做统一的管理，这样可使应用变得更加易于运维。第三个阶段是通过将部署单元拆分成容器之后，可以将业务拆分成更细粒度的方式来做部署，变成微服务。通过微服务，可以提升整个服务系统的秩序，让其变得可观测、可治理。这样可让我们在高度复杂的系统中依然保存高效的服务能力。第四点就是DevOps流水线的建设，即基于细粒度化容器化部署单元的拆分，并且依赖于容器设施上各种技术的编排工具、打包工具，可建设一套符合企业的DevOps流水线，能够保证我们的应用更高效、更优质、更安全的研发流程。

 

云原生的实现路径

 

一个企业如果要实现云原生技术，第一步就是实现容器化，实现容器化包含两个部分，第一个就是对应用做细粒度拆分，拆分成不同的组件，不同的部署模块，然后通过容器化的方式将这些部署模块打包成容器镜像。这里有一种称谓docker的打包、交互方式。

 

第二步就是管理这些容器镜像，并让这些容器镜像能随时运行在基础设施之上。这里首先需要的一个自己的容器仓库，能报交互的容器镜像存储起来，并管理他们的版本并且随时能够使用，其次就是在基础设施中部署容器运行时，也就是一个容器运行环境。这样启动一个业务时，就可随时从镜像仓库中将该镜像拉出来，并且通过容器运行时将其运行起来，来对外提供服务。

 

第三步是CI与CD的节点，当能够将应用拆分成容器，并且以容器方式运行的时候，第三步就是需要构建时序集成和持续部署一个工作流实现自动化的测试、灰度、回滚。

 

有了这一套从应用层到容器上线的流程之后，就可以把容器部署到平台之上，下一步就是对容器应用做编排。这里最核心的就是对容器编排做调度，也就是应用代码通过容器化拆分和构建打包成100个容器镜像，我如何将这100个容器镜像合理的编排到不同的物理机上，让他们能够运行起来，并且考虑到不同容器之间的调度关系，能够正常的户型访问以及当一个服务器出现故障的时候，如何能够快速将这台服务器上的容器调度到其他服务器上启动起来，这就是容器编排调度所需要做的事情。第二点就是应用的定义与编排。容器是应用的细粒度拆分，一个完整的应用的运行是需要多个容器来共同执行的，那这里如何去定义这些容器之间的关系，能够在调度的时候考虑到这些关系并且让应用能够正常的对外提供访问以及内部互相访问，这时候就需要一套逻辑和模型帮助我们把这些不同特点、不同类型的应用定义出来，并且站在应用的角度来编排这些问题。

 

第五步就是对应用的观察和分析，当应用被编排在容器当中，并且容器都正常应用在服务器之上，下一步就是如何观察容器的运行状态以及如何优化容器的编排和部署，这里就涉及到对应用状态的监控，如应用消耗多少资源、应用对外服务的端口是否正常、请求时间是否在合理范围之内。同时应用容器化环境中会产生大量的日志，通过对日志的分析也能够帮助我们找到很多应用运行过程中状态，帮助我们排查一些历史错误，对应用的性能做优化。同时对反复复杂的请求链做追踪，找到错误的具体位置。

 

第六步是对网络的性能与安全和优化，容器是部署到不同的服务器上的，容器能够在一台物理机故障的时候快速转移到另外一台服务器上，但随着这种转移，容器的物理地址是不固定的，那这是如何创建一个虚拟网络，为每个容器创建一个虚拟地址，从而让容器不能怎么转移，我们都能通过一个固定的地址访问到它？这就是容器网络管理需要解决的问题。又因容器是一个虚拟地址，没有一个真实的固定路径，那么容器之间的访问需要很多次的转换，那怎么在这些转换过程中确保网络得到优化，并且做好安全策略的控制，这也是在这一环节需要考虑的问题。

 

接下来就来到了第七个节点，第七个节点就是信息流的管理和消息的管理，前面的网络管理可以每个容器有一个网络地址，A服务需要访问B服务时，就可通过这个网络地址进行访问B服务所在的容器。这里存在一个问题，当A服务需要调用B服务的一个方法应该怎么处理？因为容器是分布式部署在不同平台上的，这是需要B服务暴露一个网络接口，让A服务通过这个接口进行访问，传统的方式是通过API方式访问，我们这里引入的是RPC框架，RPC框架叫着远程过程调用，它的作用是当我们的服务需要远程互相调用的时候，能够解决在分布式系统中服务之间的调用问题，同时有让服务之间在远程调用的同时和本地调用一样方便，它的在使用的时候与本地访问是一样的。RPC解决了服务与服务之间的交互问题，但有时候服务与服务之间是间接交互的，即服务A发布一个请求，一个消息，但是它不知道下一个服务是什么，或者是一个异步的请求，它需要获得下一个服务立即的答复，这时候就需要引入分布式小时中间件，将上述情况管理起来，这时只需要将消息发布到中间件即可，再有下游服务在中间件获取相关请求或内容。

 

第八个节点就是关于服务网关与路由的管理。随着整个服务越来越大，整个服务的逻辑关系就会变得非常复杂，这时候就需要一套服务注册与发现的机制来帮助管理者第一时间了解整个系统中有哪些服务对外暴露了哪些端口，同时在服务网管中服务管理，管理哪些服务可以互相访问，哪些服务只允许单向访问或不能互相访问。同时服务网路还要做到负载均衡与健康检查的作用。

 

最后一个节点是持久化存储。我们可以发现容器是可以在个服务器间转移的，但当数据是不易在不同节点之前传输的，特别是当数据量非常大的时候，传输是非常耗时的，这时候就需要计算与存储的分离。

 

云原生技术生态现状

 

关于云原生技术生态现状最重要是两个概念，分别是CNCF和Kubernetes。CNCF的全称是云原生计算基金会，它是目前云计算领域最成功的开源组织之一，CNCF致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。通过将最前沿的模式通用化，让这些创新为大众所用。CNCF最早托管的项目是Kubernetes，它是全世界最活跃的开源项目之一，容器编排领域的事实标准，Kubernetes作为云原生技术发展的基石，发展出了丰富的开源生态，并得到了企业广泛采用。

百度内部的云原生实践

      

现在百度有超过一半的系统是用容器方式部署的，其中包括百度app、百度安全、百度一些新兴业务，如百度AI、自动驾驶等等。

 

注：该文章来源——直播公开课《云原生技术的前世今生》