从苏州银行的 API 治理,看银行数字化转型的合规性探索

1

为引导安全的 API 治理,中国信息通信研究院云计算开源产业联盟近期整理并发布了《API 治理应用案例汇编(2023)》。此次征集中,Eolink 参与共建的三大项目入选金融行业示范案 是入选项目最多的企业,充分体现官方对 Eolink 在金融行业市场地位的权威认可。

本期,我们给大家带来的是 Eolink 与苏州银行股份有限公司落地的 API 治理最佳实践案例分享。

<br>

2

苏州银行股份有限公司(苏州银行)成立于 2010 年,是唯一一家总部设在苏州的上市城商行。成立以来秉持“以民唯美,向实而行”的发展理念,专注服务实体经济和市民,推动区域经济社会发展。

苏州银行现有 12 家分行、172 个网点,发起设立 4 家村镇银行,入股 2 家农商行;设立苏州金融租赁公司,获批筹建苏新基金公司,境外开设新加坡代表处。英国《The Banker》杂志全球 1000 强银行排名第 265 位。

苏州银行建立公司银行、零售银行、金融市场和数字银行四大专业化经营事业总部,基于综合金融服务的集团一体化经营能力,以人为本干事创业队伍建设能力,持续在普惠金融、科创金融、绿色金融、民生金融等领域精耕细作,更好地服务经济社会发展。

苏州银行秉承“工匠精神”,凝聚专注、铸就专业,敢于创新,以可持续发展为目标,打造最值得信赖银行,为中国式现代化贡献苏州银行新实践!

<br>

3

随着信息技术和互联网的迅猛发展,开放性和接口概念已深入人心。为了跟上时代的步伐,苏州银行内部正加快 API 管理和治理规范体系的建设。

苏州银行对 API 管理的探讨在某种程度上起源于对 ESB 接口治理的探索。ESB 接口架构主要以系统间通讯和协议转换为导向。鉴于行内存在各类系统,涵盖接口与源码基线梳理、ESB 接口平台化流程、EDAS 分布式微服务治理以及建设安全高效的系统间访问以及解决第三方系统对接等方面,苏州银行研发管理团队迫切需要一个统一而高效的协作平台以解决当前所面临的问题。

  • ⚠️ 接口管理缺乏统一的平台统筹

企业内部缺乏统一的接口定义管理平台,每个系统团队都有按自己习惯使用不同管理工具,导致接口文档分散在各个系统中保存。

平台的不一致性增加维护和协作困难,而且关联的系统无法及时了解接口的变更以及变更后的版本差异,及变更后的版本差异;开发人员通常在开发的最后阶段才完善文档,导致前后端对接时需要反复沟通确认,增加了管理成本和沟通成本。

  • ⚠️ 系统壁垒林立,团队协作效率低下

各系统在开发和测试接口时采用不同的协议或工具,导致开发与测试之间形成了信息孤岛;接口的变动和上线发布通过邮件或线下会议通知,零散的沟通方式无法实现工具之间的数据共享和交互,从而降低了沟通效率.

在接口调试过程中,由于无法参考历史调试记录或数据,开发难以进行有根据的调试;前后端开发进度不同步,缺乏统一的 Mock 平台,导致联调和联测无法迅速进行。

  • ⚠️ 接口自动化测试效率有待提升

缺乏标准化和统一的接口文档作为参考,测试人员难以获得标准化和及时更新的接口文档,缺乏接口样例 Demo,导致测试人员编写案例的效率受到限制;当接口定义发生变更时,测试人员无法及时了解变更的具体内容,也难以有效评估变更是否影响现有的自动化案例。

目前存在的接口自动化测试工具不够统一,开源或自研的工具各自适应不同的场景,存在弱项或功能缺失的情况。

  • ⚠️ 缺乏规范的治理体系

研发团队缺乏一个统一的接口治理流程和接入规范,导致无法通过流程和管理工具有效监控接口规范的实施情况。

同时,与 DevOps 系统以及其他研发系统(如测试数据平台、缺陷管理系统)之间缺乏数据打通。基于此,苏州银行决定引入 Eolink 对 API 接口实行全面的规范化管理。对 API 资产进行清晰了解和有效管理,并进一步提升接口研发的效率,为银行的智慧金融竞争力夯实基础。

<br>

4

Eolink (深圳市银云技术有限公司)作为技术提供方为苏州银行打造了 API 数字化治理平台,通过构建一站式的 API 治理协作体系,统一管理行内各类系统,包括接口与源码基线梳理,同时梳理 ESB 接口平台化流程、EDAS 分布式微服务治理,以及满足《商业银行应用程序接口安全管理规范》的标准规范。

5

苏州银行 API 数字化治理平台实现了安全高效、系统间直连接口关联、对接第三方接口的标准化等功能,使得任何互相关联的系统都能在平台规则内使用。实现所有系统的开发、测试都能在一个统一平台上协作,进行关联开发与测试,提高接口信息互联效率。

  1. 建立统一的 API 资产管理平台,作为唯一的权威接口信息发布平台,统一API管理、研发、测试和接口治理、发布流程。

统一管理通用的 HTTP / Websocket / Sockt / HSF / SOAP 以及 ESB 接口和微服务接口;统一管理接口文档、测试用例、Mock 等研发过程资产。

  1. 将人行和行内相关的接口规范融合产品中。制定了结合《苏州银行接口管理规范指南》,该规范包括开发规范、过程的规范、API 设计规范、测试规范、安全规范等部分。

同时也融合考虑了人行的《商业银行应用程序接口安全管理规范》的接口安全设计、变更控制要求,并将规范内容体现在 API 模板中,通过文档模板实现接口规范化设计。

6

  1. API 数字化治理平台围绕 API 文档,进行开发 API 管理、API 研发变更、API 调试Mock、接口自动化测试统一关联平台。基于 API 文档,开发对接口文档继承进行接口调试;测试对继承开发案例进行自动化测试;第三方基于文档进行 Mock 调试及研发。

7

  1. 平台与行内相关研发和运维管理系统进行打通,实现 API 研发、测试、治理和运维一体化管理;实现与 Devops 系统打通,实现接口的自动化发布和测试;实现与测试数据管理平台、缺陷管理平台打通,实现 API 接口研发一体化管理。
<br>

8

苏州银行 API 数字化治理平台基于 Eolink 行业首创的 DTDD(文档与测试驱动开发)先进理念设计,实现了 API 的统一规范管理,通过用标准文档代替口头约定和笔记文档,让开发、测试、运维、协作有迹可循。

同时,结合快速用测试结果推动开发进度,让团队沟通更充分、管理有事实依据,实现敏捷开发。帮助企业管理 API 研发、测试、对接以及进行无人值守的自动化测试等工作,能够有效提高 API 管理规范程度、研发效率、测试效率,以及完善 DevOps 研发流程。

Eolink 助力苏州银行践行 API 资产化建设,构建 API 数字化管理体系:

  1. API 资产统一数字化管理。 API数字化管理完成苏州银行API资产的全面梳理,平台已管控接口资产 8000 余个,覆盖行内 170 多个系统苏州银行。

  2. API 全生命周期统一线上化管理。 平台的场景覆盖了 API 的设计、开放、对接、测试、发布、异常、维护、废弃下线的完整生命周期管理功能。对接了行内 ESB、EDAS、核心系统、开放平台等系统,提升了平台对接服务能力,支撑不同的行内外系统、供应商之间拥有不同的接口设计、开发、测试、对接等方式。

Eolink 与苏州银行项目组将所有行内、行外第三方接口资产都作统一全面梳理、拉平接口定义和系统源码之间的基线差异、补充接口正反样例报文、规范接口说明定义等规范操作,通过规范化接口过程,补充接口样例报文 10000 多个,下线废弃 400 多个接口。

  1. API 层标准化敏捷研发能力。 构建了系统间消费订阅关系关联,接口变更导致关联系统影响面分析一目了然;支持线上接口版本对照变更差异能力,以版本维度的变更直接通知接口消费方;支持接口代码进行线上开发、调试及自动化测试。

  2. API 的平台化管理优化了接口研发流程,先确定接口定义再开发,使得文档不再滞后于开发。设计、开发、调试线上化自服务,系统间调试无需面对面沟通也可配合默契。

围绕 API 基线可以拓展便接口自动化测试功能,目前平台拥有接口调试及自动化案例 10000 余个,并按版本周期维度,持续迭代。显著节省测试和接口发布的时间和成本,降低了项目上线的风险。

  1. 统一 API 治理规范和接入流程。 建立统一的 ESB 和 SSF 接口治理流程,统一对接 ESB 平台和智能微服务平台,实现接口的统一治理和管理。

苏州银行研发团队表示,Eolink 对比市面上其他的平台产品最大的优势是能力强大,场景覆盖更加全面,帮助苏州银行真正落实 API 的全生命周期治理模式,助力提升研发测试一体化效能提升。

9

经过三期的项目实施后,苏州银行的 API 治理能力显著提升,根据 Eolink API 治理成熟度模型其治理能力已经达到了 LV3 级成熟度,平台为苏州银行在 API 管理方面的持续发展奠定了坚实的基础。

通过 Eolink 的全方位支持,苏州银行成功地践行了 API 资产化建设,构建了高效的 API 数字化管理体系,为银行未来的数字化持续发展打好根基。

10-无

点赞
收藏

评论区

加载中...

相关推荐

DevOps平台支撑企业IT运营

一、普元DevOps平台建设历程普元从2008年开始研发持续集成平台(CIP)、自动化测试平台(UTP),2009年内部的所有产品都实现了持续集成、自动化测试、自动化部署。随着DevOps理念的兴起,企业的数字化转型的需求也愈发强烈,于是开始着手研发DevOps平台,并在这个过程中不断探索微服务、DevOps、容器云、Cha

DevOps 初学者宝典

什么是DevOps随着软件发布迭代的频率越来越高,传统的「瀑布型」(开发—测试—发布)模式已经不能满足快速交付的需求。2009年左右DevOps应运而生,简单地来说,就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程,开发运维一体化,通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。!DevOps

DevOps路线图

随着软件发布迭代的频率越来越高,传统的「瀑布型」(开发—测试—发布)模式已经不能满足快速交付的需求。2009年左右DevOps应运而生,简单地来说,就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程,开发运维一体化,通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。过去的一年,越来越多的公司正在转型Dev

SpreadJS 纯前端表格控件应用案例:雨诺订单管理系统(雨诺OMS)

由青岛雨诺研发的雨诺订单管理系统,为各医疗零售门店提供了统一、简单的操作界面,通过打通线上线下平台,在两个信息孤岛之间搭建通信桥梁,实现了订单、库存、财务信息在线上平台和线下ERP之间自由流转。下面,让我们一起来看看青岛雨诺是如何在“雨诺订单管理系统”中应用表格技术,实现“类Excel报表设计(https://www.oschina.net/ac

SpreadJS 纯前端表格控件应用案例:表格数据管理平台

由某科技公司研发的表格数据管理平台,是一款面向业务和企业管理系统定制开发的应用平台,包括类Excel设计器、PC应用端和移动应用端等应用模块。该平台具备强大的业务配置和集成开发能力,对于企业客户的信息系统在管理模式、业务流程、表单界面等个性化需求,均可快速实现个性化配置。下面,让我们一起来看看该公司是如何在“表格数据管理平台”中应用表格技术,实现“

DevOps 中 API 治理的工程问题和落地实践案例

API的全生命周期管理与Devops是紧密相关的,Devops中的各个环节都会对API治理有一定的业务诉求,很多时候企业需要一体化的API管理平台来提供相应的业务能力。在Devops工作流中进行API全生命周期管理时,成功交付的核心其实就是为企业提供工程问题的解决能力。那么所谓工程问题都有哪些呢?