PaaS重塑云计算时代

如今，各行业都在关注和讨论着的智能经济、数字化转型、智能制造、人工智能、工业互联网、5G与边缘计算等，实质上都是在描述一件事情——人类正在重构新的技术架构体系，正在经历一场技术架构的大变迁！这场技术架构的变革牵引着我们从传统信息技术时代进入基于云计算技术的架构体系时代。

本文摘自于山金孝，潘晓华，刘世民撰写的《OpenShift云原生架构：原理与实践》一书，经出版方授权发布。

PaaS统一云计算架构

在智能经济和数字化时代，复杂商业系统的不确定性需求与日俱增，基于传统IT架构的信息系统或解决方案正在面临业务系统“孤岛林立”、复杂臃肿、数据碎片化、迭代交付缓慢、市场需求响应迟钝等困境。为了满足企业的发展需求，我们需要一整套构建于云计算架构体系上的软件应用系统、新型商业模式和智能运维体系，并实现传统IT架构下业务系统的云化迁移和改造，打造基于“大中台、小前台”的平台赋能支撑体系，实现当代信息系统的主要特性，包括业务系统数据共享与互通、功能复用与快速迭代、需求敏捷开发与高效交付、应用流水线部署与滚动升级、资源弹性扩展与实时在线、运维自动化与智能化等。

商业的逻辑在于竞争，竞争的本质在于对企业各种社会资源的获取与整合能力，以及响应交付效率。软件应用系统作为当代企业竞争手段与工具的重要载体，直接决定了企业在智能经济和数字化时代的生存与发展。因此，能够实时响应用户需求、敏捷交付实现业务逻辑的云计算架构体系成为企业的必然选择。在基于云计算的应用架构体系中，存在由下至上和由上至下两种抽象，现阶段我们所看到、听到和正在学习研究的诸多技术架构和各种云原生技术栈，其目的都是实现这两种抽象。

所谓由下至上的抽象，实际上是一种基础设施的抽象，其最终的目标是下沉应用系统中的全部基础设施，从而将业务逻辑与基础设施完全解耦，并将全部精力聚焦在业务创新和逻辑功能实现上。从物理服务器到应用系统函数代码之间的全部技术架构和工具软件，都可认为是为了实现这一抽象过程。而这一抽象过程的实现可谓历时弥久，从20世纪便开始的虚拟化技术（Xen、KVM、PowerVM、ESXi、Hyper-V等），到现在的云计算（Eucalyptus、CloudStack、OpenStack、AWS等）、容器（LXC、Garden、Docker等）、编排引擎（Swarm、Mesos、Kubernetes等），以及服务网格（Linked、Envoy、Istio等）和无服务器计算（OpenWhisk、OpenFaaS、Knative等），无不是在为了实现这一抽象而努力，而这一从虚拟化开始的抽象过程，在可预测的将来，会以无服务器计算（Serverless）终结。我们当前所处的阶段，正是这一传统IT基础架构设施抽象过程即将进入高潮和尾声，而基于云计算架构体系的新型应用架构正在爆发的云原生数字化时代。

由上至下的抽象，实际上是一种业务逻辑能力的抽象，其目的是从前端业务系统中抽象、提取出共性能力，并将这些能力下沉至共性可复用的赋能平台，形成以厚平台赋能薄前端的业务架构体系，打造小而精的业务灵活创新前台和厚而广的共性能力赋能中台的企业平台架构，即所谓的“大中台、小前台”业务系统架构。而这种由上至下中台能力的抽象，很大程度上取决于由下至上基础架构设施的抽象进度。如果在中台能力的抽象过程中，企业还需要过多地考虑或是依赖于底层基础架构设施，那么中台能力抽象的灵活创新、敏捷响应、能力复用等初衷也将无法实现。例如，在中台能力建设过程中，如果没有微服务架构，没有云原生和DevOps等技术架构、组织架构和企业文化的支撑，那么中台能力的建设本身就没有坚实的落地基础。

基础架构设施和业务能力的抽象过程，其实就是企业IT架构、组织架构不断调整与变化的过程。在这一过程中，新的技术架构不断在提出、否定和否定之否定中交替螺旋前进，由下至上诞生并积累了覆盖不同领域和功能的分支技术栈，这些技术栈的交互集成、编排调度、维护治理以及全生命周期的管理，构成了智能经济和数字化时代的云原生技术架构体系。而企业如何以简单、高效的方式构建并维护这些历经几十年发展才沉淀下来的技术架构，将从核心基础层上决定企业数字化转型的成败和未来几十年的战略发展机遇。在这样的背景之下，企业PaaS平台一直伴随着基础架构设施的抽象过程默默发展。事实上，业界一直期盼可以将抽象之后的基础设施全部沉淀到一个PaaS平台上，由这个PaaS平台集成并治理所有的软件技术栈，并将企业上层应用逻辑与下层基础设施完全解耦。过去，这样的PaaS平台实现难、维护难、应用难，而且功能也非常有限，伴随云计算、容器技术、编排调度技术和微服务架构等新一代云原生技术的应用，由下至上集成全部云原生技术栈，并实现自动治理和应用全生命周期管理的PaaS平台时代已经到来，并且正在支撑起企业由传统IT架构向云计算架构体系的迁移。可以这样说，PaaS平台正在帮助企业塑造基于云计算体系的应用架构，帮助企业由信息化向智能化和数字化转型。

PaaS构建云计算未来

云计算从出现至今已走过十余年的发展历程，云计算的IaaS、PaaS和SaaS三大服务模式已被各行业广泛接受和认可。在这3大服务模式中，SaaS以其轻量级、产品标准化、实时购买且及时可用、无须应用构建和维护等便捷特性，从最前端的应用侧切入，深受广大中小企业和创业公司群体的青睐，迅速占领了云计算市场，成为早期云计算的代表。以巨头和资本加持、重资产的IaaS服务模式紧随其后，在弹性灵活的基础设施、规模经济效益和数据即生产资料等技术和行业背景下，迅速迎来市场发展风口，并一举反超SaaS，在云计算市场中占据了主导地位，在各大巨头厂商的宣传下，IaaS似乎已成为大众心目中云计算的代名词。

与IaaS面向基础设施和SaaS面向行业应用不同，PaaS上承应用、下接基础设施，位于IaaS和SaaS之间，PaaS在云计算中的战略地位，注定其不会在云计算发展的初期就得到广大用户的青睐和巨头厂商的垂青。但是，在云计算发展已十余年后的今天，随着传统大中型企业的数字化转型，以及各行各业“互联网 ”战略的推进，IaaS的通用计算能力和SaaS的特定行业应用属性，在传统行业复杂应用上云、定制化需求与日俱增、市场需求敏捷响应以及企业中台战略不断普及的今天，显得力不从心。而下沉了共性能力又可赋能行业应用的PaaS，正随着以Docker容器、Kubernetes编排引擎和微服务为代表的新兴技术迎来新一轮爆发，并开始占据云计算后半场的制高点。现阶段，几乎所有IaaS厂商都在向上攻取PaaS，而SaaS厂商则在向下沉淀，以提升企业在复杂多变和不确定性环境下的核心竞争力。

具有后发优势的PaaS正在上拓下扩，不断融合IaaS与SaaS服务模式，当前云计算市场，正朝着“两端黯然，中间闪光”，并最终实现全栈云的态势发展。然而，PaaS虽好，却也最难！在云计算三大服务模式中，SaaS进入门槛最低，竞争格局也最为混乱，IaaS则过于依靠巨头和资本的投入，最终的竞争格局很有可能是几家头部企业瓜分IaaS市场。而PaaS却是真正的技术高地，进入门槛最高、实现难度也最大，至今仍未出现PaaS领域的巨头。

也正是因为PaaS的高度，行业里对PaaS的认知和理解各不相同，在对PaaS的划分上，就有APaaS（Application PaaS）和IPaaS（Integration PaaS），以及轻PaaS和厚PaaS之分。所谓的APaaS，是指应用运行和部署平台，也就是我们通常所说的PaaS。APaaS解决的是单个应用如何基于PaaS基础设施快速和自动化地部署与运行的问题。IPaaS则是指资源集成平台，其解决的是多个应用间如何基于PaaS平台实现集成和交互的问题。而所谓的轻PaaS更倾向于APaaS，厚PaaS则是APaaS和IPaaS的融合。早期PaaS主要基于公有云实现，提供的主要是APaaS能力，如force.com、Heroku、GAE等。

但是，随着传统企业数字化转型的不断加速，私有云PaaS平台建设的需求与日俱增，私有云环境下，基于PaaS平台构建的应用之间存在大量的交互和集成需求，在很多传统、复杂应用云化时更是如此。另外，私有PaaS平台底层的服务和能力本身可以被编排、组装和整合成新型应用，因此IPaaS在传统企业数字化转型中扮演着极为重要的角色。而PaaS平台的根本目标是简化开发、贯通DevOps、实现应用和业务的弹性敏捷，因此融合APaaS和IPaaS的厚PaaS才是未来PaaS平台的发展之路。

从PaaS的发展历史来看，PaaS的出现并不比SaaS晚。早在2005年，公有云供应商Rackspace就提供了托管PHP和.NET Web应用的服务，在2007年和2008年前后，SaaS领域巨头Salesforce的force.com和Google的GAE提供了基于Python、Ruby和Java的应用托管服务。这一时期的PaaS平台使用门槛较高、用户需要学习特定的API，平台绑定性较强，应用可移植性也较差。随后以Heroku和Engine Yard为代表的第二代PaaS平台开始出现，这类PaaS平台一定程度上解决了平台特定API依赖的问题，同时用户代码无须做过多修改便可直接运行在平台上，应用程序移植性也有所提升，但是支持的语言仍然非常有限。

2011年前后，Pivotal的Cloud Foundry和RedHat的OpenShift问世，并掀起了开源PaaS的浪潮，但是早期的OpenShift和Cloud Foundry并非基于Kubernetes和Docker来设计，如OpenShift采用了Cartridge和Gear机制来进行设计，而Cloud Foundry主要基于Garden容器和Diego调度系统来实现，因此在易用性、功能性和所支持的语言方面都有所限制。2014年前后，随着Kubernetes和Docker的成熟和普及，PaaS迎来了最佳的历史发展机遇。2015年，RedHat基于Kubernetes和Docker彻底重构了OpenShift，推出了全新架构的OpenShift 3.0版本，而Cloud Foundry也在2017年开始兼容Kubernetes和Docker。这一阶段的PaaS在易用性、兼容性、应用可移植性、多语言支持、DevOps、应用生命周期管理和开源社区支持等方面都达到了前所未有的高度。不过，此时的PaaS与IaaS还存在比较明显的边界和依赖关系，传统企业尤其是传统大中型企业，在数字化转型过程中，仍然需要按照先IaaS后PaaS的顺序来构建自己的私有云和PaaS平台，而这势必会导致企业的PaaS平台建设周期较长、运维管理难度增加。

随着PaaS与IaaS的不断整合，最新一代的PaaS正在朝着全栈云模式发展，在这个大趋势下，RedHat在2018年收购了不可变容器操作系统CoreOS，并将应用全自动生命周期管理框架Operator大量运用到最新一代OpenShift中，于2019年推出了基于CoreOS和Operator的全栈自动化PaaS平台——OpenShift 4.0，实现了PaaS向下对IaaS的完全整合和管理，并以“基础设施即代码（Infrastructure as Code）”理念实现了对IaaS资源的自动化高效率使用。因此，我们完全可以预测，鉴于企业对PaaS平台赋能数字化转型的迫切需求，全栈融合PaaS平台的时代即将到来！而作为云计算三大服务模式之一，随着云计算发展进入深水区和企业数字化转型热潮的来临，PaaS正在超越IaaS和SaaS，必将成为云计算的未来。

PaaS赋能微服务架构

微服务是一种软件架构设计模式，是一种具备细粒度、松耦合、可扩展、高可用、故障隔离和高度自治等特性的分布式软件架构设计体系，其解决的是应用系统软件架构设计的问题，是面向服务架构（SOA）的一种实现。微服务架构的重点在于强调业务系统需要彻底组件化和服务化，原有的单个业务系统被拆分为多个可独立开发、设计、运行和运维的小应用（Microservices，微服务）。这些服务基于业务能力构建，并通过自动化机制进行独立部署和管理维护，同时这些微服务组件使用不同的编程语言实现，使用不同的数据存储技术，并保持最低限度的集中式管理。

事实上，微服务所倡导的设计思路由来已久，但是“微服务架构”这一术语的流行时间并不太久。以Spring Cloud和Dubbo为主的微服务架构被认为是最流行的第一代微服务应用开发框架，但是随着Docker容器和Kubernetes编排引擎技术的兴起和普及，以Service Mesh（服务网格）为主的新一代微服务架构正在开启后Kubernetes时代应用架构的新方向。此外，伴随时下企业数字化转型浪潮的到来，越来越多的开发者和企业正在拥抱和践行微服务架构，由于在快速响应市场需求、敏捷业务开发及快速迭代科技创新等方面所扮演的关键角色，微服务正在成为企业数字化转型的基石和必由之路。

在传统企业的数字化转型道路上，采用微服务架构就意味着众多单体或集中式的传统应用需要进行微服务化改造。而传统巨型单体应用在微服务架构下的细粒度拆分，必然给企业带来数量庞大、管理复杂的众多服务对象，微服务的拆分不仅是对原有应用系统的一种挑战，更是对如何部署、管理和维护众多微服务的一种挑战，尤其对于传统企业而言，这些挑战是数字化转型过程中前所未有而又必须面对的。在面对这些挑战时，我们需要非侵入式的微服务架构、轻量级和依赖封装的服务运行环境、自动编排调度微服务的引擎、实现从开发测试到部署运维全流程自动化的DevOps，以及针对微服务集群的跟踪和监控服务等，而这一切的需求正是当代云原生PaaS平台所赋予的能力。所谓的云原生PaaS平台，是指以新一代容器Docker及其编排引擎Kubernetes技术为核心，集成日志、监控、安全、跟踪等微服务集群管理工具及实现CI/CD的DevOps工具链，提供多语言运行环境、中间件和数据库等服务目录，支持新一代微服务架构Service Mesh，并满足云原生应用运行环境的PaaS平台。

PaaS平台以生态链服务组件集成的方式，赋能和支撑上层云原生微服务应用的敏捷开发和全生命周期管理。由于PaaS平台屏蔽了微服务通信层以下的全部基础设施，因此基于PaaS平台的分布式微服务应用系统的开发将会像单体应用一样简单，因为开发者只需关注如何以微服务架构实现业务逻辑和编码，服务的构建、部署管理和运维监控已完全由PaaS实现。因此，可以说，作为企业数字化转型的关键和必由之路的微服务正在重塑当代软件架构，而PaaS则是微服务得以落地生长的土壤和得以推进实施的平台保障，没有PaaS，尤其是当代云原生的PaaS平台，则基于微服务架构的企业数字化转型恐将寸步难行。

PaaS加速DevOps实践

DevOps是实现敏捷企业过程中的工具链、方法论和企业文化，是一种敏捷理念。DevOps最早在2009年就被提出，但直到容器和微服务架构普及之后才得到广泛实践和快速发展。在企业数字化转型的现阶段，DevOps已成为众多传统企业进行数字化转型的切入点。而在具体的实践过程中，DevOps并不是某种技术或方法，而是企业组织、流程、技术和文化的结合。在企业数字化转型过程中，DevOps理念能够更好地帮助打通开发（DEV）、测试（QA）和运维（OPS）之间的隔阂并进行优化，实现开发运维一体化，从而帮助企业缩短交付周期、提升交付质量和交付的投入产出比，并进一步帮助企业完善流程管理体系、形成持续改进机制和敏捷文化。通过践行DevOps文化和理念，企业能够打通需求、开发、测试、发布、部署上线和运维管理等各个环节，促进需求、开发、测试和运维团队的紧密合作，实现敏捷开发、持续交付和自动运维，最终帮助企业走向敏捷化和数字化，提升企业应对市场需求不确定性和用户需求多样化的能力。

当前，数字化转型是大势所趋，微服务架构已成为传统企业数字化转型的必由之路，而DevOps则是实施微服务架构的关键点和切入点。在传统企业巨型单体应用向微服务架构转型升级的过程中，首先需要做的便是从自动化配置部署开始来改造传统应用，在此过程中逐步打造企业DevOps平台，并以DevOps平台为生产线，对企业应用进行统一的自动化管理和运营。在企业文化、组织架构和技术工具链均已达到DevOps所倡导的成熟理念后，再将传统应用架构改造为微服务架构，最后实现传统应用向云端的顺利迁移，并最终实现企业数字化转型。在这个过程中，企业DevOps生产线的构建至关重要，然而DevOps的构建并不简单，究其原因，主要在于DevOps工具链上所涉及的诸多软件具有不同的技术体系、形态架构、运行依赖环境、部署维护流程，这会导致DevOps落地需要大量定制化，工具链落地难度极大。

随着基于Docker和Kubernetes等云原生技术的PaaS平台的出现，DevOps工具链难以落地实现的情况正在改善，云原生PaaS平台为DevOps工具链软件在平台支撑、服务组件支持、运行依赖环境上进行了标准化。通过PaaS平台提供的自动编排、自动部署、生命周期自动管理等云原生共性能力，DevOps工具链的部署得以从基础架构设施中解耦出来，同时借助PaaS平台一致性能力，基于传统IT架构或IaaS服务的DevOps的实现难度得到极大降低，DevOps的落地实现变得极为优雅、简洁。此外，配合PaaS平台对云原生微服务应用架构的支持，基于PaaS平台构建的DevOps生产线与微服务应用天然契合，可以直接为企业数字化转型中的微服务提供DevOps服务能力。因此，借助PaaS平台，DevOps的价值优势才能得到最大程度的发挥。

基于云原生PaaS平台的自动编排调度和集群管理能力，利用DevOps工具链上的诸多软件功能，可以将DevOps流水线可视化、自动集成、代码质量分析、持续管理、持续集成、持续测试、持续交付和持续运维等敏捷功能在PaaS平台上简洁且优雅地实现。简单来说，PaaS简化和促进了DevOps在企业中的应用实践，同时也最大化了DevOps的价值，而作为企业微服务应用架构转型的切入点，DevOps极大地推动了传统应用向微服务架构的快速转型，最终推动了企业的数字化转型进程。

PaaS构筑云原生时代

云原生的概念由Pivotal公司的Matt Stine于2013年提出，之后得到业界的广泛认可和持续完善，是在云计算时代指导企业基于云架构设计和开发应用，并将应用向云端迁移的一套全新的技术理念。所谓的云原生应用，就是完全基于云计算资源而设计的应用，即为云而生，并可在所有云平台上无缝移植运行的应用。

2015年，Google牵头成立的云原生计算基金会（Cloud Native Computing Foundation，CNCF）是云原生理念发展到特定阶段，为了响应业界对云原生应用的呼吁而成立的官方组织，致力于推动云原生计算的普及和可持续性发展，是CNCF成立的初衷。目前CNCF在全球已拥有近400家企业会员，托管22个云原生开源项目，大名鼎鼎的Kubernetes、Prometheus、etcd、Envoy等都是毕业于CNCF的项目。

根据CNCF对云原生的定义，云原生技术是通过一系列软件、规范和标准，帮助企业和组织在现代化的云计算架构体系（公有云、私有云和混合云）中构建和运行敏捷、可扩展应用程序的一整套技术栈，容器及其编排引擎、微服务及其治理、声明式API等都是极具代表性的云原生技术。通过云原生技术的应用，基于云原生12要素开发的分布式松散耦合系统将具备更好的可扩展性和可管理性，同时也更易于监控、跟踪和观察。将云原生技术与DevOps工具链结合，系统管理员和软件工程师便可频繁且可预见地任意更改应用系统，并尽可能地减少由此带来的工作量，进而以最简洁的方式实现对业务实时需求的快速响应，而这正是云原生技术为企业带来的价值。

在CNCF维护的云原生技术栈Landscape中，包含一张路线图和一张全景图。路线图（Trail Map）是CNCF推荐的使用开源项目及云原生技术构建云原生应用的过程，在路线图的每个步骤中，用户都可以选择使用开源项目或供应商提供的产品，而路线图帮助用户梳理了整个云原生应用的最佳流程（如图1-5所示）。整个路线图分成10个步骤，包括容器化、CI/CD、应用编排、监控与分析、服务发现与治理、网络与策略、分布式数据库与存储、流和消息处理、容器运行环境与镜像仓库、软件发布。其中每个步骤都是用户在开发、实践云原生应用过程中需要循序渐进地思考和实现的环节，只有实现了路线图中所有步骤的应用才是真正意义上的云原生应用。

在按照CNCF云原生路线图实现云原生应用的过程中，用户需要了解每个环节都有哪些具体的开源项目或成熟供应商产品可供选择，而这正是CNCF云原生全景图所要做的事情。全景图将CNCF定义的云原生生态圈划分为“五横两纵”，“五横”分别是应用定义与开发、编排与治理、运行时、供应保障和云基础设施，“两纵”分别是平台、观察与分析。全景图中包含经过CNCF社区认证的较为成熟或使用范围较广、具有最佳实践的产品和方案，试图从云原生的层次结构及不同的功能组成上让用户了解云原生体系的全貌，并帮助用户在不同的云原生应用实践环节选择恰当的软件和工具来实现。

尽管CNCF为企业用户定义了云原生应用实践的实现路径和在这个路径中可以选择的云原生软件或产品，但是如果用户完全从零开始，参考CNCF云原生全景图来构建自己的云原生应用，其难度不言而喻，这将会是一个需要耗费大量人力和财力的复杂工程。由此，云原生PaaS应运而生，将企业IT化繁为简一直是PaaS的使命。只不过，云原生时代的PaaS需要参考CNCF Landscape进行重构，如基于Docker和Kubernetes进行构建，实现对CI/CD、DevOps的支持，实现服务编排与治理、微服务架构、监控与分析等CNCF云原生路线图中的步骤。云原生PaaS的目标是让企业开发者只需提交代码即可运行云原生应用，为企业屏蔽CNCF云原生路线图中的十大步骤，快速交付满足12要素的云原生应用。

随着云原生PaaS平台的出现，企业构建云原生应用的门槛越来越低，越来越多的企业正在考虑向云原生架构迁移，云原生时代正在到来！云原生PaaS平台典型参考实现架构，利用CNCF全景图中云原生生态圈认证推荐的开源项目或软件，该参考架构基本实现了对CNCF云原生路线图中十大步骤的全覆盖，并实现了对Microservices和Serverless这两大当下和未来云原生软件架构的支持。可以说，随着PaaS平台的不断成熟和完善，技术隔阂正在被打破，PaaS正在构筑起云原生时代。

推荐阅读《OpenShift云原生架构：原理与实践》

推荐语：本书由IBM官方专家亲自推荐，深入剖析OpenShift架构设计、实现原理、集群的部署和运维，以及基于PaaS平台的数字化转型。深度讲解基于OpenShift的云原生架构，为以微服务、DevOps、ServiceMesh、Serverless和Spark为核心构建企业云原生技术平台提供详尽指导。

kubernetes serverless devops

0 人点赞