今天,我将与大家深入探讨金融级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体系的建设为其他行业提供了宝贵的经验和参考。