今天，我将与大家深入探讨金融级PaaS体系的规划。选择这个话题的原因有二。首先，金融行业是灵雀云在过去十年里深耕的领域，积累了大量的实践经验，以及为众多银行

等金融机构提供过深度服务。其次，PaaS体系的重要性日益凸显，尤其是在城商行选择PaaS产品的供应商时，不仅是在选择一个产品，更是在寻找一个能够共同成长的合作伙

伴。除标准化产品外，更需要一个能够解决运营、管理和建设等复杂关系的PaaS体系。因此，PaaS体系的规划与建设是一个系统化的过程，需要从全局出发，综合考虑各种因

素。在接下来的分享中，我将详细阐述如何进行金融级PaaS体系的规划与建设。

PaaS体系的概念说明

银行、政府、工业等各个领域对PaaS的认知存在差异，虽然大体上相似，但每个领域的具体理解和应用却不尽相同。因此，为了确保我们在讨论和实施PaaS时具有统一的基础，

需要先明确PaaS的概念和模型。首先，PaaS的建设目标是非常明确的，它是业务的支撑体系。业务从需求到开发、集成、运行到运维，应用的全生命周期管理。其次，PaaS需

要支撑所有相关角色的日常工作，包括工程管理、开发、架构设计、运维测试等人员。

PaaS体系的模型介绍

构建一个基本的PaaS体系框架大致分为四层。

图表1 PaaS体系模型

第一层：技术底座，这一层主要解决应用统一运维的问题。它包含了容器技术、微服务架构、以及应用的统一运维等，为应用提供稳定、高效的运行环境。

第二层：技术标准件，即组件层。这些组件大致分为四类：通用技术组件，如数据库中间件；共享技术服务，如API的短信、邮件、通知等；创新赋能组件，如人工智能平台、

区块链平台等；开发流程组件，如DevOps等。

第三层：领域标准件，这一层是对组件的进一步抽象，以解决某一领域的问题，如业务中台、数据中台、AI中台等。虽然它们属于PaaS的范畴，但由于项目规模庞大，可能会

独立立项，并由专门的团队负责运营。

第四层：服务门户，是PaaS体系中刚开始建设的一层。它主要解决存量技术资产服务化转型的问题，通过统一的工程平台，将下层的各种技术栈、组件整合，为用户提供统一

的概念和流程。

以上四层构成了PaaS的能力体系，云原生底座、组件与服务、工程平台三个部分，分别提供应用的支撑能力、组件服务能力与一体化工程服务能力。除了能力体系，PaaS还

有三个纵向的体系，分别是敏捷开发体系、运维运营体系和安全管理体系，共同构成了PaaS的全貌。PaaS致力于服务于数字化工程过程，为涉及的所有工程角色提供一体化服务。

PaaS体系的建设方法

在PaaS体系建设中，要解决三个核心课题：

底座建设。在某些情况下，金融机构会采购多个云平台以及各类基础设施，这些云平台和基础设施混杂在一起，导致基础设施碎片化。底座需要解决多云基础设施的统一纳管，

为应用提供统一支撑。

组件供给。在金融级PaaS体系建设中，组件的建设不是难题，供给才是。如何通过对组件的统一管理实现自助供给才是核心要解决的问题。

一体化门户。组件的供给需要借助统一的管理平台或服务门户来实现，因此，PaaS体系建设分两部分来完成，第一部分是底座的建设，第二部分是一体化工程平台的建设。

第一部分 底座的建设

1.1 先理顺IaaS和PaaS之间的关系。

图表3 IaaS和PaaS之间的四种关系

根据历史进程，可以将IaaS和PaaS的关系分为四种：

一体耦合架构：在敏态IT时代，IaaS的最高成就是解决了IT管理和运维的问题。随着IaaS的发展，出现了一体化IaaS，IaaS基础之上叠加了K8s，形成全栈云。然而，一体耦合的架构存在一个问题，即IaaS和PaaS是紧密耦合的。这两个技术体系完全不同，一个是以厂商为导向，一个是以社区为导向。因此，它们的升级周期也不同。IaaS通常每3~5年进行一次大版本的升级，而K8s社区则是每4个月发布一个版本，每个版本维护14个月。这导致在正常的使用中，升级成为一个严峻的问题。也因为IaaS上的K8s无法升级，导致新技术的引入受到限制。

 分层解耦架构：到了双态IT时代，分层解耦架构崭露头角，为我们带来了更为优越的架构设计。这种架构在IaaS基础上构建虚拟机，使得我们在虚拟机内部能够自由应用不同厂商提供的IaaS和PaaS服务。其核心特点在于各层之间实现了互相解耦，PaaS的升级不再受制于IaaS的变化。这种设计理念与我们的需求高度契合，尤其受到城商行的青

睐。

平行解耦架构：这种架构比分层解耦架构更加大胆，将PaaS和IaaS下沉至物理机层面，使它们在物理机上平行存在。平行解耦的设计使得PaaS和IaaS能够独立升级和管理，已被广泛采用。从专业视角来看，这两种架构各有优劣，都值得推荐。第一种架构的优势在于，从底层向上看时，基础设施是统一对齐的。而第二种架构的优势在于从业务

的视角看，PaaS更加灵活易升级，甚至它们的网络也可以完全打通，彻底摆脱网络方面的耦合。

融合架构：来到敏稳融合的时代，出现了融合架构。这种架构打破了IaaS和PaaS的底层界限，使用K8s来统一管理物理机。在这个架构中，上层既可以承载容器，也可以承载虚拟机。但这种架构尚未完全成熟，因此建议在采用时优先考虑上述两种架构。

1.2 解决基础设施碎片化的问题。

图表4 PaaS云管平台

在长期的PaaS建设过程中，企业常常积累了大量且碎片化的K8s基础设施。这些基础设施来自不同供应商，可能是社区或厂商，并以一体或分层方式提供。即使是来自同一厂商

的K8s，也可能存在公有云和私有云的差异，导致每个K8s都拥有独立的PaaS管理界面，引发了基础设施碎片化的问题，给企业的运维和管理带来巨大的困扰。

构建PaaS云管理平台是一个高效的解决方案。通过将集群管理、应用发布、应用运维和微服务治理等能力集成到PaaS云管理平台中，可以实现对下层基础设施中碎片化K8s的统

一管理。利用标准的K8s API，对下层碎片化集群进行有效管理，为上层提供统一的PaaS和应用管理。这一整合的方法有助于解决基础设施碎片化的问题，提升企业的运维和管

理效率。

1.3 底座应该具备哪些能力？

统一管理： 实现对租户、权限、资源、集群的统一管理和集群运维。价值在于同一云管下的统一管理。

统一基础设施： 将存储、网络、计算、GPU虚拟化、节点等要素统一为通用语言，形成一个共同的基础设施。

统一应用发布： 包括通用容器应用的发布、前后端分离应用的发布、无状态应用发布、Spring Cloud应用发布等等。

统一应用管理： 包括容器应用管理、OAM应用管理、服务网格应用管理和Spring Cloud应用管理。

统一运维：包括统一日志、统一监控、统一告警、统一调用链、统一流量指标。

当这些能力得以实现，底座才能算是相对完备。向上具备灵活性支持各类应用，向下具备多云管理能力，有效避免对任何一家云服务商的过度依赖。

第二部分 一体化工程平台的建设

2.1 重新思考底座和组件的建设

问题一是组件或技术栈过于复杂，由于需要采购不同厂商的产品，用户在使用一个组件时不得不经历繁琐的流程，耗费了大量的时间，增加不必要的成本。

问题二是使用流程的割裂，因为企业采购的各类产品来自不同的供应商，导致在开发、DevOps、业务上云、容器化、微服务等阶段，不同产品的使用流程独立存在，造成流

程割裂。

问题三是技术资产碎片化，各组件分散在不同的业务团队中，虽然部分实现了统建收口，但整体服务界面却不统一。这种状况导致用户在面对众多组件时，难以找到一个一致

的服务界面，从而造成使用困扰。

如何解决困扰PaaS建设的三个关键问题？Gartner给出一个答案，即“工程平台”或“平台工程”。

2023年Gartner在战略技术趋势报告（Top Strategic Technology Trends for 2023）中首次提及“平台工程”。什么是平台工程？简单来说，是一种将零散、无序的基础设施、

工具和服务进行整合与规范化的方法。过去，这些服务常常呈现出碎片化、无序和蔓延的状态，给管理和使用带来诸多不便。因此需要构建一个统一的平台，将那些无序、蔓延

的服务和工具转化为标准化的、有明确边界的模块。

2.2 平台工程概念模型

图表7 平台工程概念模型

产品和服务团队需要什么？开发者门户和XaaS（即服务目录）。

开发者门户在整个过程中扮演着至关重要的角色，它贯穿了从业务需求到开发、上线、运行和运维的全流程，为用户提供了一个集中、统一的服务目录。这个目录使得团队

成员能够迅速找到并有效利用所需的服务和工具，极大地提升了工作效率。

XaaS，即服务目录，包括数据库即服务、组件即服务等，为团队提供了高效、便捷的服务。这些服务不仅简化了开发流程，提高了开发效率，同时也降低了维护成本。

谁来提供？企业的数字中台也就是工程平台。

平台应包含四个部分：可复用的组件、工具、平台服务和知识库。可复用的组件可以减少重复开发的工作量，提高开发效率。工具可以提供更好的开发体验，简化开发流程。

平台服务可以提供更高效、更稳定的服务，满足用户的需求。知识库可以提供丰富的经验和知识，帮助团队更好地解决问题和应对挑战。

2.3 从用户视角分析平台能力

图表8 用户视角的平台能力图

用户视角

面向应用开发、运维人员的统一服务，包含开发者门户、 组件服务目录、API服务目录、数据服务目录、资源服务目录、应用运维等模块。

管理视角

平台包含IaaS、PaaS、技术组件、数据组件等模块。平台应向平台建设、开发人员提供统一日志、监控、告警 等服务，平台开发人员也会复用开发者门户、服务目录等模块。

运营视角

面向管理层、运营人员的服务，包含租户管理、权限管理、计量计费、流程审批等模块，也包含聚合的领导驾驶舱等模块。

2.4 典型建设路径

图表9 平台工程典型建设路径

平台工程的建设是一个庞大且复杂的项目，要深度整合企业的技术体系和管理体系，因此无法通过直接购买标准化产品来实现。由于需要自主研发，费用也会相应高昂。开始

前，要考虑几个关键问题：

投入产出比：在平台工程的建设中，我们应该优先选择那些能够带来高价值、高回报的项目。这样，才能更快地展现出成果，从而获得更多的支持和资源。

管理的边界：平台建设初始，由于组件分布在各个团队无法统一接入，因此，项目范围不宜过大，否则可能导致团队间的沟通成本增加，协同效率降低。

项目风险：在平台工程的建设中，对可能出现的风险进行预估和防范。例如，技术风险、数据风险、安全风险等都需要被充分考虑。

基于上述考虑，平台建设分三步进行：

第一步：应用资源服务和应用集成服务

基础资源是构建应用的基础，但零散的资源需要统一的服务目录进行收口，服务目录可以帮助使用者快速获取现有的资源（组件）生态，形成对外统一、标准化、自助服务。

第二步：运营管理服务

打通应用发布和应用运维，实现具有企业特性的应用标准化管理。这可以通过运营管理工具来实现，确保应用、组件、服务三者协同运维。

第三步：应用开发服务、应用运维服务、项目管理服务

打通开发过程，实现流程贯穿的工程平台，加速应用迭代效率和运维能力。这意味着通过开发者门户，开发人员可以更方便地访问和使用各种开发工具和服务，从而提高开发

效率。同时，形成以应用+租户为视角的平台化支撑服务。使得开发者门户不仅为开发人员提供服务，还可以为租户（即最终用户）提供服务。

第三步：应用开发服务、应用运维服务、项目管理服务

打通开发过程，实现流程贯穿的工程平台，加速应用迭代效率和运维能力。这意味着通过开发者门户，开发人员可以更方便地访问和使用各种开发工具和服务，从而提高开发

效率。同时，形成以应用+租户为视角的平台化支撑服务。使得开发者门户不仅为开发人员提供服务，还可以为租户（即最终用户）提供服务。

2.5 工程平台的本质

图表10 平台工程的本质

从技术角度来看，平台工程的本质是将已有的技术能力转化为服务，并通过开放服务层为用户提供统一门户。平台工程的核心是服务接入，即将各种技术组件、资源和能力整

合到一个平台上，然后通过网络对外提供服务。

在平台工程的建设中，开放服务层是PaaS服务于用户的统一门户。其采用自主开发模式，通过组件接入方法，实现应用全过程贯通、与全角色支持。用户可以通过其访问和使

用各种服务，而无需关心服务的具体实现细节。

同时，平台工程还建设了统一运营中心模块，实现全域组件计量计费。这个模块可以对平台上的各种组件进行计量和计费，确保服务的透明度。

2.6 PaaS体系运营

图表11 1E5R方法论

对于技术能力较强的金融机构来说，构建PaaS体系并非难事，也可以引入成熟的技术厂商协助。真正的挑战在于如何有效地利用这一平台，使其真正为业务提供价值。为此，

建立一个有效的运营体系至关重要。运营体系应包含三个关键模块：

平台运维体系

这一体系负责确保PaaS平台的日常稳定和安全运行。包括监控平台健康状况、及时处理故障、确保资源分配的优化等。需要有一套高效的运维流程和工具，确保平台的持续、

稳定运行。

应用上云体系

这一体系涉及对现有应用进行改造或为新应用提供指导。需要对应用进行分类评估，确定其迁移的优先级和策略。根据应用的特性，可能需要重新设计、修改或采用微服务化

等方式。迁移过程中，需要考虑流量割接、应用运维等问题，确保平滑过渡。

 用户服务体系

这一体系旨在为用户提供全面的服务，包括开发团队和业务团队。提供租户管理规范、服务申请流程、使用文档等，确保用户能够轻松使用平台。定期收集用户反馈，为平台

改进和二期建设提供方向和建议。

此外，要确保PaaS运营体系的稳定和高效，还需要关注两个重要的保障要素即组织保障和制度保障。

组织保障是确保运维、业务上云和用户服务等方面得到有效管理的关键。如果企业没有专门的平台团队，后期的管理将会变得非常困难。因此，需要有专门的组织来负责这些

关键模块的管理工作。

制度保障也是非常重要的。虽然平台工程的理想状态是通过功能和流程实现真正的约束，但制度规范作为辅助仍然是必要的。这些制度规范可以包括流程、标准和操作指南等，

以确保所有相关人员都能够遵循统一的标准和规范进行工作。

在应用上云过程中，结合Gartner、AWS的标准模型沉淀下的方法论，即“1E5R”：

Encapsulate（封装）：封装一部分应用，暴露 API 供创新应用调用。

Rehost（迁移）：应用不做任何修改，直接迁移到云上。

Replatform（重新选择平台）：对应用进行容器化等少量改造。

Refactor（重构）：利用云原生优势对应用进行部分重构。

Rearchitect（重建架构）：用云原生架构重构应用，将其变成微服务应用，真正融入到云中。

Rebuild（重新构建）：构建全新的云原生应用。

实际使用中需要根据输入指标对应用进行分类，并选择适合的迁移方式。这里提供的是一个基本的纲领，以供参考。

在金融行业日益数字化的浪潮中，构建一流的金融级PaaS体系已经提升到组织内的战略高度。这一体系建设不仅是技术创新的体现，更是对金融行业未来发展的战略投资。

除了对金融行业本身具有重要意义外，金融级PaaS体系的建设也为其他行业提供了重要借鉴。随着数字化转型的深入推进，越来越多的行业头部企业已经借助灵雀云的方案

成功构建与企业自身深度融合的集团级PaaS体系。因此，金融级PaaS体系的建设为其他行业提供了宝贵的经验和参考。