中石化信息化建设——走向“云原生”

Posted 2021-04-03 数据工匠俱乐部

中石化信息化——

走向“云原生”

中石化信息化建设

——持续走向“云原生”

一、传统信息化之“痛”

      长期以来，中国石化一直非常重视信息化建设，信息化能力和应用水平在央企中位列第一方阵前列。但信息化快速发展带来的一些共性的问题也逐渐显现，如系统过多问题、功能重复问题、数据无法共享问题、对业务需求变化响应不及时问题等等，认真分析这些问题的起因，不难发现其根源在于传统的信息化建设模式，“立项式”的信息化建设方式实际上就是“补丁式”、“烟囱式”，每一个信息化建设需求，通过立项论证、招标建设队伍、设计评审等一系列流程，项目建设下来，填补了某一方面的业务需求，同时也形成了一个或多个烟囱，日积月累，系统日益庞大，效率低下、运维困难，业务部门提出新的需求，所有的流程还需要再重复一遍，需求满足缓慢。无法适应数字化时代，业务需求快速变化的新要求。

这些根植在传统建设模式中的根源性问题，需要从彻底改变IT建设的管理组织模式入手，才能得到有效解决。

“云原生”可以充分地利用云的优势，让企业在云上的投资收益最大化。通过云可以获取丰富的计算资源，通过云原生技术所倡导的自动化和智能化，可以提升应用的交付效率，把有限的精力放在核心业务的创新上，可以让企业更具竞争能力。云原生构建应用简便快捷，部署应用轻松自如、运行应用按需伸缩，是解决传统建设模式问题的有效方法、支撑业务快速变化的最佳途径。

二、云原生的基本概念

      原生就是“土生土长”的意思，云原生即应用一诞生就是基于云的，可以直接在云平台上运行或非常轻松的迁移到云平台。

云原生是一种构建和运行应用程序的方法，一套新的技术体系、一种新的工作方法论。

云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳态势运行，充分利用和发挥云平台的弹性+分布式优势。

Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念。

2015年云原生计算基金会（CNCF）成立，他们把云原生定义为包括：容器化封装+自动化管理+面向微服务。

到了2017年，Matt Stine在接受媒体采访时将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal公司官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。

到了2018年，CNCF又更新了云原生的定义，把服务网格（Service Mesh）和声明式API给加了进来。

可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的理解。但是，微服务、DevOps、持续交付、容器等是云原生的基本构成要素。

微服务技术是指应用原子化，所有的应用都可以独立的部署、迭代。DevOps使得应用可以快速编译、自动化测试、部署、发布、回滚，让开发和运维一体化。持续交付让应用可以频繁发布、快速交付、快速反馈、降低发布风险。容器使得应用整体开发以容器为基础，形成代码组件复用、资源隔离。

图1 云原生的核心要素

总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

云原生应用要运行在云平台，那么就必须要有云的特点，比如弹性伸缩、分布式、快速部署、快速迭代、高效、持续。这可不止是简单的把原先在物理服务器上的应用迁移到虚拟机里，不止是基础设施和运行平台在云上，应用架构、应用开发方式、应用部署方式、应用维护方式全都要做出改变。

在云原生之前，底层平台负责向上提供基本运行资源。而云的出现，可以在提供各种资源之外，还提供各种能力，从而帮助应用，使得应用可以专注于业务需求的实现。

三、云原生关键要素

1、微服务

      微服务倡导运用化整为零，实现各个功能的独立开发与部署、提升应用架构的灵活性，从而提升对业务的响应速度。在提倡敏捷的今天，微服务已经成为应用架构的一种默认的选择。

      微服务的定义是独立部署的、原子的、自治的业务组件，业务组件彼此之间通过消息中间件进行交互，业务组件可以按需独立伸缩、容错、故障恢复。

几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用。微服务架构的好处就是按功能（function）切分之后，服务解耦，内聚更强，变更更易。

微服务架构的演变可从早期的单体式架构、中期的SOA架构、后期的微服务架构来看。客户提出一个需求时，早期的做法是直接往现有的代码包里加东西，客户来一个需求，程序员们就写一串代码在里面，来十个写十串，来一百个写100串，反正就是不断的加，最后我们的应用就变成了一个巨无霸应用，要往里面再加东西很难，要保证全面测试无误很难，要保证按期上线很难，要保证线上出现了问题快速解决也很难，因为牵一发而动全身，即使是技术精湛的程序员也不敢轻易的下手做了。

    较新的解决方案是SOA架构（ServiceOrientedArchitecture面向服务的架构），即将业务服务化、抽象化，将整个业务拆分成不同的服务，服务与服务之间通过相互依赖提供一系列的功能，通过网络调用。常用的实现方式是使用ESB（EnterpriseServiceBus企业服务总线）来把各个服务节点，集成不同系统、不同协议的服务，通过ESB将消息进行转化，实现不同的服务互相交互。这个方案很大程度上解决了巨无霸应用的问题，但是对于ESB的维护成本却比较高。

图2 企业服务总线（ESB）成为新的瓶颈

云计算时代的到来推动应用“高内聚，低耦合”，高内聚就是熟悉同一块业务的人、提供服务的模块聚合在一起，低耦合就是应用与应用之间没有紧密强依赖关系，而高内聚低耦合的最佳实践便是微服务架构。通过将服务拆分成单独的服务，小型团队可专注于自己的功能开发上线，运维团队也可根据服务的调用情况弹性扩缩容，符合云计算时代的特色，确定是云原生的特性之一了。

2、容器化（Containers）

      容器是一种轻量级的虚拟化技术，通过容器可以简化应用的部署、管理和交付。

容器技术的定义就是一个单独的应用程序进程、运行资源的高度隔离。早期的时候，应用全运行在物理机上，这导致资源分配不均匀，即使是一个小的应用也要耗费同样的计算存储资源。中期的时候有了虚拟化技术将物理机划分为多个虚拟机，这样在一台物理服务器上可以运行多个虚拟服务器，实现了资源利用率的较大提升，而云计算时代的到来，带来了微服务、DevOps、持续集成持续交付等内容，要求应用要原子化、快速的开发迭代、快速的上线部署，划分为虚拟机的方式不能保障应用在每个环境（Dev、Test、Pre、Prod）都一致，容易引起应用因环境的问题而产生Bug，容器的出现极好的解决了这个问题。

在容器出现之后，整个的流程变成了研发人员在将代码开发完成后，会将代码、相关运行环境构建镜像，测试人员在宿主机上下载服务的镜像，使用容器启动镜像后即可运行服务进行测试；测试无误后运维人员申请机器，拉取服务器的镜像，在一台或多台宿主机上可以同时运行多个容器，对用户提供服务。在这个过程中每个服务都在独立的容器里运行，每台机器上都运行着相互不关联的容器，所有容器共享宿主机的cpu、磁盘、网络、内存等，即实现了进程隔离（每个服务独立运行）、文件系统隔离（容器目录修改不影响主机目录）、资源隔离（CPU内存磁盘网络资源独立）。

使用容器，研发团队可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上，而无需重新配置环境，这样就实现了强大的可移植性，实现了云计算时代的资源最大化利用，符合云计算时代的特色，确定是云原生的特性之四了。

容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护。Docker是应用最为广泛的容器引擎，在思科、谷歌等公司的基础设施中大量使用。谷歌公司推出的K8S是容器编排系统，用于容器管理，容器间的负载均衡。

3、DevOps

      DevOps如果从字面上来理解只是Dev（开发人员）+Ops（运维人员）的组合，实际上，它是一组过程、方法与系统的统称，其概念从2009年首次提出发展到现在，内容也非常丰富，有理论也有实践，包括组织文化、自动化、精益、反馈和分享等不同方面。首先，组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。其次，自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次，DevOps的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。

总之，如图3所示，DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

图3 自动化工具支撑高效的团队协作

      DevOps的定义是研发运维一体化，通过自动化流程使得软件过程更加快捷和可靠。它不是一个产品，而是一种新的团队工作方式、新的技术理念。

一个软件从0到1的最终交付包含如下阶段：市场规划、产品规划、编码设计、编译构建、部署测试、发布上线、后期维护。

早期的时候所有工作全由一个人完成了，自己开发编码，编译打包，进行测试之后，在云厂商上买一两台服务器，部署上应用就对外发布了，这就是瀑布式开发模型，确认好需求后就进入开发阶段，直到完成上线。

而随着使用人群的增加，应用的整体维护开始变得艰难。慢慢的团队里有了产品经理、开发人员、测试人员、运维人员的划分，由产品经理负责需求的规划、产品交互设计，研发人员负责编码、构建包，测试人员负责功能测试和自动化测试、上线发布，运维人员负责维护线上服务的正常运行、扩容缩容，这就是敏捷开发模型，在开发过程阶段测试介入，快速验证修改问题直到基本无误后上线部署。这一切所带来的问题是整体的交付周期变长了，团队之间沟通合作成本变高了，因此DevOps应运而生。它将整个软件开发测试运维过程变为一体化，每完成一个小的需求点便测试上线部署，快速验证需求，捕获用户，占领市场。

图4 DevOps强调组织的沟通与协作

云计算时代的到来带来了虚拟化、容器、微服务等新的技术理念，强调的是服务的拆分、精细化的分工，奠定了DevOps落地的基础条件，只有当服务拆分的原子化了，整个团队密切合作的成本才会降低，才能实现云上应用的快速迭代

因此，DevOps的出现是一种组织架构的变革，一种开发模式的变化，团队人员在需求规划、代码设计、编译构建、测试部署、上线发布、后期维护的过程全程参与，每个人都对整体的方案了解清晰，可制定合适的系统架构、技术架构、运维部署方案。

4、持续交付

持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，需要很多流程和工具支撑。

图5 不同开发模式的对比

软件设计有两个关键目标：高内聚、低耦合，软件工程师一直都在为这两个目标而努力奋斗，以求把软件编写得更加清晰、更加健壮、更加易于扩展和维护。但后来，人们发现有更多的诉求，希望开发软件变得更简单、更快捷，程序员希望更少编写代码，非专业人员也希望能开发程序，于是，更多的更傻瓜的编程语言被发明出来，更多的编程技术和编程思想被发明出来，比如库、组件、云基础设施。

互联网发展大的趋势是技术下沉，特别是近些年，随着云计算的发展和普及，基础设施越来越厚实，业务开发变得越来越容易，也越来越没有技术含量，而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在。

持续交付的定义就是一直在交付，敏捷开发和DevOps要求随时都有一个合适的版本部署在生产环节上，频繁发布、快速部署、快速验证，所以必须要持续交付。

持续交付应对的情况是需求迟迟不能确定，从而缩短了开发时间，需求不能确定所带来的问题是在确定的过程中整个市场或用户已经发生了变化，开发出来的内容早已不符合当下用户的新需求了。为了快速的验证需求，往往在生产环境上会部署多个版本，从而也产生了不同的发布部署方式，比如灰度发布、蓝绿发布。

所谓灰度发布便是当新的需求开发完成后，将线上的版本只升级部分服务，让一部分用户继续使用老版本，一部分使用新版本，如果用户对新版本没有意见，再迁移到新版本来，整个过程是运维人员从负载均衡上去掉灰度服务器，待服务升级成功后再加入负载均衡服务器列表，这时候有少量用户访问业务时流量到新版本，如果这小部分用户使用没有反对，逐渐扩大灰度范围，最后升级剩余服务器。

图6 灰度发布模式示意图

所谓蓝绿发布则是将应用从逻辑上分为A、B两组，升级时将A从负载均衡组里删除，进行新版本的部署，同时B组仍然继续提供服务。当A组升级完成后，负载均衡重新接入A组，再把B组从负载列表摘除，进行新版本的部署。A组重新提供服务。最后B组升级完成，负载均衡重新接入B组。此时AB组版本都升级完成，并且都对外提供服务。保障整个过程对用户无影响，出现问题及时回退上一个版本。

图7 蓝绿发布模式示意图

通过灰度发布和蓝绿发布的方式，可以快速的验证用户需求，频繁的发布，根据用户情况规划产品演变方向，实现了云计算时代的快速迭代。

此外，最新的进展中还有两个要素，一个是无服务器架构（Serverless），是指未来不再着重关注底层的基础架构，更多的注意力可以放在和业务更相关的一些逻辑实现上，例如一些函数的代码片段，平台自动根据负载按需部署和启动，以及自动伸缩代码逻辑来满足业务处理的需求；另一个是服务网格（Service Mesh）。Service Mesh是近年兴起的一个话题，在容器微服务的基础上，通过Service Mesh可以让用户更精细、更智能的去管理服务之间的通讯。

以上各个方面并不是孤立的，而是相互联系的。云是一切的基础，为上层应用的运行提供了计算、网络、存储等基础架构资源。应用层面，用户可以根据场景来选择微服务架构或者是无服务器架构。在复杂的交互场景当中，通过服务网格，可以对服务组建的通讯进行管控。通过DevOps构建一个应用架构不断迭代更新的正向循环。

四、中石化信息化建设持续走向“云原生”

中石化在推进企业数字化转型的过程中，企业内部的IT建设模式率先转型，2017年就提出“一切应用上云，一切开发上平台”的思路，2019年进一步落实到全面推进“数据+平台+应用”的新的建设模式。

这一模式的基础是数据，核心是平台，应用则是轻量化的APP。这完全颠覆了传统的以应用为核心的建设模式。

传统的建设模式是“补丁式”、项目型。项目完成后，就得到一个可独立运行的应用系统——一个“烟囱”（如图8左侧）。

图8 IT建设模式转型升级之路

这种传统的建设模式会不断地制造信息孤岛，随着信息系统的增多，相互之间集成和互联的关系越来越复杂，增加了信息系统使用和运维的复杂度，加大的企业信息化的总体成本。

按照“数据+平台+应用”的新模式，强调了企业数据资产的统一治理和共享，大幅度提升企业数据资产价值。所有新的开发建设都在统一的平台之上，按照标准接口规范进行组件式开发，形成业务组件和技术组件的积累和共享复用，各类业务应用APP由各类组件构建而成，大幅度降低开发成本、提升对业务需求的响应速度。

在组织方式，改变了传统的信息化项目“甲乙方”建设组织模式，提出了ABCD四方模式。新增加的B方就是PASS平台服务方，C方就是平台上的软件开发质控方。从而完善了持续交付的组织模式。

依据云原生应用设计思路，敏捷基础设施依赖于传统云计算的3层概念（基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）），用来提供计算网络存储等基础资源，各类应用通过PaaS服务就能组合成不同的业务能力，不一定需要从头开始建设；还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务，即SaaS能力，用户直接面对的就是原生的应用。

应用基于云服务进行架构设计，对技术人员的要求更高，除了对业务场景的考虑外，对隔离故障、容错、自动恢复等非功能需求会考虑更多。借助云服务提供的能力也能实现更优雅的设计，比如弹性资源的需求、跨机房的高可用、很高的数据可靠性等特性，基本是云计算服务本身就提供的能力，开发者直接选择对应的服务即可，一般不需要过多考虑本身机房的问题。如果架构设计本身又能支持多云的设计，可用性会进一步提高。

图9 云原生的根基是“云”

基础设施的范围也会更加广泛，不仅包括服务器，还包括不同的机柜或交换机、同城多机房、异地多机房等。技术人员部署服务器、管理服务器模板、更新服务器和定义基础设施的模式都是通过代码来完成的，并且是自动化的，运维人员和开发人员一起以资源配置的应用代码为中心，不再是一台台机器。基础设施通过代码来进行更改、测试，在每次变更后执行测试的自动化流程中，确保能维护稳定的基础设施服务。

为了满足业务需求频繁变动，通过快速迭代，产品能做到随时发布，即持续集成、持续部署、持续发布，从而实现从需求的提出，到设计开发和测试，再到让代码快速、安全地部署到产品环境中。打通开发、测试、生产的各个环节，自动持续、增量地交付产品，当然，在实际运行的过程中，有些产品会增加如前所述的灰度发布等环境。

图10 通过持续交付强化项目管控

通过持续交付中心强化项目过程监管，为各应用云的建设提供端到端的研发运维工具链，提升了交付与运维效率，为石化集团业务快速发展与创新提供有力支撑。服务范围已经覆盖总部、企业及外部开发商，实现了所有新开在建系统的在线研发过程管控，使用自动化部署效率提升86%，测试效率提升80%。

随着中石化数字化转型的持续深入，给传统的信息化建设模式提出了“率先转型”的迫切要求，持续走向“云原生”是顺应时代要求的必然选择。

(欢迎大家加入数据工匠知识星球获取更多资讯。)

联系我们

微信：DaasCai

邮箱：[e-mail]

QQ：2286075659

热门文章

我们的使命：发展数据治理行业、普及数据治理知识、改变企业数据管理现状、提高企业数据质量、推动企业走进大数据时代。

我们的愿景：打造数据治理专家、数据治理平台、数据治理生态圈。

我们的价值观：凝聚行业力量、打造数据治理全链条平台、改变数据治理生态圈。

了解更多精彩内容

数据工匠俱乐部

专注数据治理，推动大数据发展。