金融级PaaS体系规划

近日，在美丽春城昆明举办了一场闭门的金融行业讨论会，会上灵雀云首席解决方案专家杜东明受邀进行了《金融级PaaS体系规划》的主题分享。他指出，PaaS体系的重要性日益凸显，已经成为金融行业发展的重要驱动力，它能够为金融机构提供灵活、高效和可靠的技术支持，助力其实现业务的可持续创新。

PaaS体系的概念说明

银行、政府、工业等各个领域对PaaS的认知存在差异，虽然大体上相似，但每个领域的具体理解和应用却不尽相同。因此，为了确保我们在讨论和实施PaaS时具有统一的基础，需要先明确PaaS的概念和模型。首先，PaaS的建设目标是非常明确的，它是业务的支撑体系。业务从需求到开发、集成、运行到运维，应用的全生命周期管理。其次，PaaS需要支撑所有相关角色的日常工作，包括工程管理、开发、架构设计、运维测试等人员。

PaaS体系的模型介绍

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

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

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

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

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

以上四层构成了PaaS的能力体系，云原生底座、组件与服务、工程平台三个部分，分别提供应用的支撑能力、组件服务能力与一体化工程服务能力。除了能力体系，PaaS还有三个纵向的体系，分别是敏捷开发体系、运维运营体系和安全管理体系，共同构成了PaaS的全貌。PaaS致力于服务于数字化工程过程，为涉及的所有工程角色提供一体化服务。

PaaS体系的建设方法

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

图表2 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 底座应该具备哪些能力？

图表5 技术底座能力图
统一管理：实现对租户、权限、资源、集群的统一管理和集群运维。价值在于同一云管下的统一管理。
统一基础设施：将存储、网络、计算、GPU虚拟化、节点等要素统一为通用语言，形成一个共同的基础设施。
统一应用发布：包括通用容器应用的发布、前后端分离应用的发布、无状态应用发布、Spring Cloud应用发布等等。
统一应用管理：包括容器应用管理、OAM应用管理、服务网格应用管理和Spring Cloud应用管理。
统一运维：包括统一日志、统一监控、统一告警、统一调用链、统一流量指标。

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

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

2.2 平台工程概念模型

图表7 平台工程概念模型

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

开发者门户在整个过程中扮演着至关重要的角色，它贯穿了从业务需求到开发、上线、运行和运维的全流程，为用户提供了一个集中、统一的服务目录。这个目录使得团队成员能够迅速找到并有效利用所需的服务和工具，极大地提升了工作效率。

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

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

平台应包含四个部分：可复用的组件、工具、平台服务和知识库。可复用的组件可以减少重复开发的工作量，提高开发效率。工具可以提供更好的开发体验，简化开发流程。平台服务可以提供更高效、更稳定的服务，满足用户的需求。知识库可以提供丰富的经验和知识，帮助团队更好地解决问题和应对挑战。

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

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

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

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

2023年Gartner在战略技术趋势报告（Top Strategic Technology Trends for 2023）中首次提及“平台工程”。什么是平台工程？简单来说，是一种将零散、无序的基础设施、工具和服务进行整合与规范化的方法。过去，这些服务常常呈现出碎片化、无序和蔓延的状态，给管理和使用带来诸多不便。因此需要构建一个统一的平台，将那些无序、蔓延的服务和工具转化为标准化的、有明确边界的模块。

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体系的建设为其他行业提供了宝贵的经验和参考。