上海银行消息中心平台建设项目 -供应商征集公告及项目采购信息公示
· 2024-05-30
上海银行消息中心平台建设项目
供应商征集公告及项目采购信息公示
上海机电设备招标有限公司受上海银行股份有限公司（以下简称采购人）委托，对上海银行消息中心平台建设项目项目进行供应商征集，诚邀合格的供应商参与，并对项目相关信息进行公示。
一、项目概况及内容
本次拟通过引入成熟消息中间件软件产品，建设符合信息科技创新要求的高可用、高可靠、高吞吐的消息中间件平台，实现同城双中心部署以及异地灾备部署，满足核心业务系统、统一支付清算系统、调度平台等系统对于消息中间件平台的需求。
二、采购方式
竞争性磋商。
三、合格供应商资质要求
1、中华人民共和国境内依法设立且具有完全民事行为能力的法人或其他组织。
2、2021年1月1日至今未因诚信问题、违法等行为被相关部门予以处罚、通报、或受到法律制裁。
3、本项目不接受联合体参与，且入围后不得转包、分包。
4、本项目不接受单位负责人为同一人或者存在直接控股、管理关系的不同供应商同时参加。
5、2021年1月1日至今投标人具有消息中间件平台相关实施案例至少1例。
6、本项目只接受拥有消息中间件相关软件产品著作权的供应商参与或具有消息中间件相关软件产品的授权证明的集成商参与。
四、服务要求（包含但不限于）
详见附件。
五、报名时需提交的资料
（一）工商行政管理部门或市场监督管理部门登记的企业法人营业执照、税务登记证、组织机构代码证或三证合一的《营业执照》或同等效力的文件（复印件并加盖公章）。
（二）提供下列14张查询截图，且查询页无不良记录，并加盖公章。
| 1 | 2021年1月1日至今，供应商在中国裁判文书网（http：／／wenshu.court.gov.cn／）有关贪污行贿的查询截图并加盖公章，且无不良记录 |
| 2 | 2021年1月1日至今，法定代表人在中国裁判文书网（http：／／wenshu.court.gov.cn／）有关贪污行贿的查询截图并加盖公章，且无不良记录 |
| 3 | 2021年1月1日至今，被授权人在中国裁判文书网（http：／／wenshu.court.gov.cn／）有关贪污行贿的查询截图并加盖公章，且无不良记录 |
| 4 | 2021年1月1日至今，供应商在信用中国网站（https：／／www.creditchina.gov.cn／）有关失信被执行人的查询截图并加盖公章，且无不良记录。 |
| 5 | 2021年1月1日至今，法定代表人在信用中国网站（https：／／www.creditchina.gov.cn／）有关失信被执行人的查询截图并加盖公章，且无不良记录。 |
| 6 | 2021年1月1日至今，被授权人在信用中国网站（https：／／www.creditchina.gov.cn／）有关失信被执行人的查询截图并加盖公章，且无不良记录。 |
| 7 | 2021年1月1日至今，供应商在信用中国网站（https：／／www.creditchina.gov.cn／）有关 重大税收违法失信主体的查询截图并加盖公章，且无不良记录。 |
| 8 | 2021年1月1日至今，法定代表人在信用中国网站（https：／／www.creditchina.gov.cn／）有关 重大税收违法失信主体的查询截图并加盖公章，且无不良记录。 |
| 9 | 2021年1月1日至今，被授权人在信用中国网站（https：／／www.creditchina.gov.cn／）有关 重大税收违法失信主体的查询截图并加盖公章，且无不良记录。 |
| 10 | 2021年1月1日至今，供应商在信用中国网站（https：／／www.creditchina.gov.cn／）有关政府采购严重违法失信行为记录名单的查询截图并加盖公章，且无不良记录。 |
| 11 | 2021年1月1日至今，法定代表人在信用中国网站（https：／／www.creditchina.gov.cn／）有关 政府采购严重违法失信行为记录名单的查询截图并加盖公章，且无不良记录。 |
| 12 | 2021年1月1日至今，被授权人在信用中国网站（https：／／www.creditchina.gov.cn／）有关 政府采购严重违法失信行为记录名单的查询截图并加盖公章，且无不良记录。 |
| 13 | 2021年1月1日至今，供应商在国家企业信用信息公示系统网站（www．gsxt．gov．cn）有关列入经营异常名录信息的查询截图并加盖公章，且无不良记录。 |
| 14 | 2021年1月1日至今，供应商在国家企业信用信息公示系统网站（www．gsxt．gov．cn）有关列入严重违法失信名单（黑名单）信息的查询截图并加盖公章，且无不良记录。 |
（三）提供2021年1月1日至今投标人具有消息中间件平台相关实施案例至少1例，需显示所要求的时间、类型、合同内容等信息的、含签章页面的合同（复印件并加盖公章）
（四）提供消息中间件相关软件产品著作权证书（复印件并加盖公章）。如为集成商参与，还须提供软件产品的授权证明。
（五）对下列事项的承诺（格式自拟，加盖公章）：1）非联合体投参与，且入围后不转包、分包；2）不存在单位负责人为同一人或者存在直接控股、管理关系的不同供应商同时参加本项目。
（六）法定代表人身份证(复印件并加盖公章)、被授权人授权书有效原件(加盖公章)、被授权人身份证 (复印件并加盖公章)和被授权人姓名、手机、邮箱(复印件并加盖公章)。
（七）其他资质条件中要求的所有相关承诺函及供应商认为需要提供的资料。
注：以上资料复印件必须加盖公章（电子扫描件以邮件形式发送至招标代理机构邮箱）。如有缺漏，采购人将拒绝接受。采购人仅对供应商递交的资料进行审查，符合要求的合格供应商将有机会参与本项目的采购。
六、资料递交时间、地点
凡有意参加本项目的供应商委派授权代表按要求持供应商征集资料，至招标代理机构递交。
（一）递交资料时间：2024年5月31日-2024年6月6日上午9:00-11:30，下午13：30-17：00时（北京时间，节假日除外）。
（二）递交资料地点：yyuan@shbid.com
七、有关单位或个人如对本项目采购信息有异议的，可以自本公示发出之日起五个工作日内，以书面或邮件形式向上海银行总行采购中心或相关部门提出。
八、联系方式
采购单位：上海银行股份有限公司
地址：上海市浦东新区银城中路168号
联系人：叶老师
联系邮箱：yerf@bosc.cn
监督邮箱：caigouzhongxin@bosc.cn
采购代理机构：上海机电设备招标有限公司
地址：上海市长寿路285号16楼
联系人：姚远
电话：13918891005
联系邮箱：yyuan@shbid.com
上海机电设备招标有限公司
二〇二四年五月三十日
招标人或其招标代理机构主要负责人(项目负责人): （签名）
招标人或其招标代理机构: （盖章）
附件：
采购内容：
| 序号 | 类别 | 单位 | 数量 |
| 1 | 软件产品 | 套 | 1 |
| 2 | 实施 | 项 | 1 |
★功能要求
| 功能模块 | 细项功能 | 细项功能说明 | 上线批次要求 | 产品原生功能 | |
| 消息组件通用能力 | 数据集成和数据管道 | 提供数据集成和构建数据管道的工具。 | 其他批次 | 可实施 | |
| 消息可靠存储 | 具备多种存储方案以保证消息完全可靠不会丢失。 | 第一批次 | 是 | ||
| 不同的刷盘方式 | 提供同步落盘和异步落盘两种形式。 | 其他批次 | 可实施 | ||
| 多种部署架构 | 具备单机、集群和多中心等多种部署架构能力 | 第一批次 | 是 | ||
| 多种部署环境 | 需具备多种部署环境能力，包括单机部署、分布式部署、容器部署等 | 其他批次 | 可实施 | ||
| 多种消息机制 | 支持多种消息机制包括顺序消息、同步消息、异步消息、定时消息、延时消息、事务消息、重试机制等。 | 第一批次 | 是 | ||
| 可视化管理工具 | 具备可视化管理工具，通过该工具可以简易的监控消息组件的各项参数。 | 第一批次 | 是 | ||
| 云原生支持 | 可以与容器化、微服务架构无缝集成 | 其他批次 | 可实施 | ||
| 兼容支持多种协议或客户端 | 平台需要兼容常见的消息中间件协议或客户端，必须包括以下协议：ROCKETMQ和KAFKA，或客户端。 | 第一批次 | 是 | ||
| 平台需要兼容常见的消息中间件，包括以下协议：RABBITMQ等。 | 其他批次 | 可实施 | |||
| 高可靠消息组件能力 | 可靠性传输 | 消息组件需要保证消息可靠性传输，做到不重、不漏。 | 其他批次 | 可实施 | |
| 持久化可靠存储机制 | 支持持久化机制将消息存储到可靠的存储介质中。 | 第一批次 | 是 | ||
| 集群部署高可用 | 支持两地三中心的容灾部署模式，实现消息数据的异地备份存储。 | 第一批次 | 是 | ||
| 消息重试与重发 | 当网络出现故障时，自动进行消息重试与重发，直到消息成功投递为止 | 第一批次 | 是 | ||
| 消息幂等性 | 消费端对重复的消息进行幂等消费处理，即使处理多次也不会影响数据一致性。 | 其他批次 | 可实施 | ||
| 分布式部署和扩展性 | 支持以分布式的方式部署在多个服务器上，可以根据业务需求和数据量动态调整系统规模和容量。 | 第一批次 | 是 | ||
| 多种消息消费模式 | 支持多种消息消费模式，包括广播模式和集群模式，可通过消费者分组进行指定消费者消费消息。 | 其他批次 | 可实施 | ||
| 流量控制和流量削峰 | 流量控制可以平滑流量,保证系统稳定，通过设置消息生产和消费的速率限制,避免突发流量冲击 | 其他批次 | 可实施 | ||
| 分布式事务消息 | 提供分布式事务消息的支持，用于在分布式环境下实现消息的原子性和一致性。 | 第一批次 | 是 | ||
| 客户端负载均衡 | 防止单点过载。避免资源浪费,根据消费能力分配消息数量。 | 第一批次 | 是 | ||
| 消息轨迹管理 | 提供丰富的消息轨迹管理功能 | 第一批次 | 是 | ||
| 消息过滤 | 只将符合条件的消息发送给消费者，提高消费者的效率和系统的性能。 | 其他批次 | 可实施 | ||
| 消息重试和死信队列 | 当消费者无法正常处理消息时，MQ需自动进行消息重试，若重试次数达到上限，消息将被发送到死信队列，便于后续处理。 | 第一批次 | 是 | ||
| 消息过期处理 | 根据消息的时间戳或过期时间来自动删除已经过期的消息，避免过期消息堆积,节省存储资源。降低消费者处理无效消息的系统开销，同时提高有效消息的处理效率。 | 第一批次 | 是 | ||
| 安全性 | 限制不同用户或角色对消息队列和主题的访问权限，保护消息传递过程中的安全性和隐私性。 | 其他批次 | 可实施 | ||
| 批量消息处理 | 支持批量发送和消费消息，可以将多条消息打包成一个批次进行处理，提高系统的吞吐量和效率。 | 第一批次 | 是 | ||
| 高性能消息组件能力 | 高性能 | 消息组件需保证符合性能要求 | 第一批次 | 是 | |
| 支持消息批量发送和消费 | 支持消息的批量发送和消费，避免了频繁的小包开销，提高了消息传递的效率。 | 第一批次 | 是 | ||
| 内存优化和零拷贝技术 | 采用内存优化以及零拷贝技术，减少了数据复制与传输的开销，提高了数据传输的效率。 | 其他批次 | 可实施 | ||
| 消息压缩传输 | 支持消息压缩传输技术，降低了网络IO，提高了数据传输的效率。 | 第一批次 | 是 | ||
| 消息预取和缓存机制 | 支持消息预取与缓存机制，可以提前加载热点数据到内存中，提高数据的访问速度； | 其他批次 | 可实施 | ||
| 弹性横向扩展能力 | 能够按需增加处理能力，以应对业务的高并发、高吞吐需求 | 第一批次 | 是 | ||
| 并行处理和流式计算 | 支持消息并行处理和流式计算，充分利用多核资源，提高数据处理的效率和性能； | 其他批次 | 可实施 | ||
| 实时日志收集和分析 | 支持实时消费并进行日志存储、分析或监控。从而实现高效的日志收集与处理 | 其他批次 | 可实施 | ||
| 流式数据处理 | 支持实时的数据处理和分析。可以及时地对大规模数据进行计算、分析和处理，支持实时决策和业务响应。 | 其他批次 | 可实施 | ||
| 海量日志存储与检索 | 支持高性能的日志存储和检索系统，支持快速地查询和分析大规模的日志数据。1K消息传输场景下，高可靠消息组件客户端>=50kTPS，高吞吐消息组件客户端>=100kTPS. | 其他批次 | 可实施 | ||
| 数据缓冲和削峰填谷 | 保护后端服务免受突发流量的冲击，并提高系统的可伸缩性和稳定性。 | 其他批次 | 可实施 | ||
| 数据备份和数据复制 | 通过设置合适的副本因子和复制策略，实现数据的冗余存储和故障恢复，提高数据的安全性和可靠性。 | 第一批次 | 是 | ||
| 数据流控和数据分发 | 根据业务需求和规则，将不同类型或优先级的消息分发到不同的主题中，实现数据的按需分发和灵活处理。 | 其他批次 | 可实施 | ||
| 实时监控和告警 | 对系统运行状态进行实时监控，并在发生异常或超出预设阈值时发送告警通知。 | 第一批次 | 是 | ||
| 消息SDK能力 | 订阅模式 | 消息PULL模式 | 消费端根据自身的消费能力拉取消息，且支持消息体自动类型转换。 | 其他批次 | 可实施 |
| 消息PUSH模式 | 消息组件具备推送消息给对应的订阅客户端实例的能力 | 其他批次 | 可实施 | ||
| 场景消息 | 同步发送 | 消息SDK需要支持同步消息，确保消息的可靠发送。 | 第一批次 | 是 | |
| 异步发送 | 消息SDK需要支持异步消息。 | 第一批次 | 是 | ||
| 事务消息 | 消息SDK需要支持事务消息的解决方案，确保消息发送和本地业务逻辑处理的原子性。 | 第一批次 | 是 | ||
| 延迟消息 | 消息SDK需要支持延迟消息。 | 第一批次 | 可实施 | ||
| 顺序消息 | 消息SDK需要支持顺序消息的解决方案。包括支持全局顺序消息，局部顺序消息。 | 第一批次 | 是 | ||
| 定时消息 | 消息SDK需要支持定时消息。 | 第一批次 | 可实施 | ||
| 多种消费确认模式 | 支持消费的自动确认；支持消息同步/异步消费确认，异步模式提供确认回调 | 第一批次 | 是 | ||
| 手动消息确认模式 | 支持消费的手动确认；消息确认中，手动模式支持单笔和批量消费确认。 | 其他批次 | 可实施 | ||
| 可靠消息、幂等处理 | 消息的可靠性发送及幂等处理 | 可靠消息发送：对消息生产提供数据库持久化操作，并提供强一致的事务特性，可以保证生产消息和业务事务的同步提交/回滚，当业务执行成功，但是生产消息异常时，会进行重试发送。消费幂等处理：对消息消费进行幂等处理，防止消息的重复消费。 | 其他批次 | 可实施 | |
| 多版本运行 | 多版本运行 | 支持版本切换时期，双版本或多版本平滑切换。 | 其他批次 | 可实施 | |
| 典型业务场景功能 | 按业务类型划分消息通道 | 支持按业务类型划分消息通道。 | 其他批次 | 可实施 | |
| 消息加密传输功能 | 保护消息内容的机密性，通过加密可以防止未经授权的第三方直接读取消息内容。确保消息完整性，加密可以检测消息在传输过程中是否被非法修改。 | 其他批次 | 可实施 | ||
| 消息批量发送功能 | 支持发送大批量小额交易消息,不会阻塞而影响吞吐。 | 其他批次 | 可实施 | ||
| 消息内容筛选功能 | 支持基于消息内容筛选订阅,仅接收匹配的消息类型。 | 第一批次 | 可实施 | ||
| 回调和确认功能 | 提供回调和确认机制,确保关键交易流程的可靠交付。 | 其他批次 | 可实施 | ||
| 消息平台能力 | 环境管理 | 系统管理功能 | 消息平台支持展示自身平台版本信息、所依赖底层组件信息等。 | 其他批次 | 可实施 |
| 消息平台支持展示组内物理节点信息，包括CPU、硬盘、内存等信息。 | 其他批次 | 可实施 | |||
| 节点管理 | 消息平台支持在总体资源池建设中可以新增物理节点用来丰富总体资源池。 | 第一批次 | 是 | ||
| 消息平台可以给资源池中的节点进行分组，做到组间物理隔离。 | 第一批次 | 是 | |||
| 资源池管理 | 消息平台支持对所创建的消息组件进行资源分配，包括CPU、内存、磁盘。 | 其他批次 | 可实施 | ||
| 消息平台支持对所创建的消息组件进行资源删除，并可以将相关CPU、内存和磁盘回收入资源池。 | 其他批次 | 可实施 | |||
| 消息平台支持对所有资源池中的资源进行统一监控，包括已使用资源和未使用资源。具体资源内容为CPU、内存和磁盘。 | 其他批次 | 可实施 | |||
| 存储管理 | 本地存储 | 消息平台应可以进行本地文件系统存储。通过文件系统去访问资源池中的硬盘空间进行消息存储。 | 第一批次 | 是 | |
| 消息平台支持对所创建好的集群进行管理，包括文件系统本地存储的更改和删除。需要将节点上的可用磁盘映射成存储设备来使用和管理。 | 第一批次 | 是 | |||
| 需提供开箱即用的监控指标采集和告警提醒能力。开启平台监控组件后，可从存储集群、存储性能和存储容量等方面进行监控和告警，且支持配置通知策略。 | 第一批次 | 是 | |||
| 数据库存储 | 消息平台应可以进行数据库系统存储。通过数据库系统去访问资源池中或外部的硬盘空间进行消息存储。 | 其他批次 | 可实施 | ||
| 消息平台支持对所创建好的集群进行管理，包括数据库系统存储的更改和删除。 | 其他批次 | 可实施 | |||
| 需提供开箱即用的监控指标采集和告警提醒能力。直观呈现的监控数据可用于为运维巡检或性能调优提供决策支持，完善的告警机制也将帮助保障存储系统的稳定运行。 | 其他批次 | 可实施 | |||
| 分布式存储 | 消息平台应可以进行分布式存储系统存储。分布式存储需要实现自动管理、自动扩容、以及自动修复的分布式存储能力。 | 其他批次 | 可实施 | ||
| 接入平台内其他业务集群的分布式存储资源，确保存储和业务隔离便于管理和维护。 | 其他批次 | 可实施 | |||
| 同一存储集群中支持同时使用文件存储、块存储等不同类型的存储池，以支持不同业务需求。 | 其他批次 | 可实施 | |||
| 消息平台支持对所创建好的集群进行管理，包括分布式存储系统的更改和删除。 | 其他批次 | 可实施 | |||
| 分布式存储提供了开箱即用的监控指标采集和告警提醒能力。启用监控与告警功能后，可从存储集群、存储性能及存储组件等方面进行监控和告警，且支持配置通知策略。 | 其他批次 | 可实施 | |||
| 运维中心 | 平台运维监控 | 消息中心支持针对平台整体进行运维监控包括各组件实例信息监控。 | 第一批次 | 是 | |
| 平台监控支持接入第三方监控平台。例如Prometheus+Grafana，zabbix等。 | 第一批次 | 可实施 | |||
| 组件运维监控 | 消息中心支持针对单独组件进行监控 | 第一批次 | 是 | ||
| 组件监控支持接入第三方监控平台。例如Prometheus+Grafana，zabbix等。 | 第一批次 | 可实施 | |||
| 日志格式 | 对接行内的日志平台的日志标准，无缝对接行内的日志要求。 | 其他批次 | 可实施 | ||
| 告警 | 告警模板是一组针对同类资源的告警规则及通知策略的组合。通过告警模板，可以方便、快捷地为平台上的集群、节点或计算组件创建告警策略。 | 第一批次 | 是 | ||
| 支持为不同级别的告警配置全局发送间隔，以限制发送消息频率，同时，支持为内置的监控组件配置告警通知策略，当检测到自身组件异常时触发告警并通知，方便用户了解内置告警组件状态。 | 第一批次 | 是 | |||
| 基于平台的监控、事件数据，并结合平台的通知功能，为集群及集群下节点、计算组件、服务创建指标告警、自定义告警、事件告警（仅计算组件）、黑盒告警（仅集群）类型的告警策略，当告警策略针对的资源发生异常或监控数据达到规则设定的预警状态时，即可自动触发告警并发送告警通知 | 第一批次 | 是 | |||
| 基于日志的告警策略，当告警策略针对的资源发生异常或监控数据达到规则设定的预警状态时，即可自动触发告警并发送告警通知 | 其他批次 | 可实施 | |||
| 通知 | 通知策略支持以邮件、短信、接口回调的形式发送通知，例如：发送平台资源运行异常的告警通知。 | 其他批次 | 可实施 | ||
| 通知联系组是一组具有相同逻辑特征的通知对象，是接受通知消息的一类实体。例如：邮件列表、短信列表、行内IM。 | 其他批次 | 可实施 | |||
| 通知模板是一个由自定义内容、内容变量和内容格式参数组成的标准化的结构体。用于为通知策略，标准化定制告警通知消息的内容及格式。 | 其他批次 | 可实施 | |||
| 事件 | 记录资源的重要状态变更及各种运行状态变化的事件，并且提供了存储、查询、可视化能力。 | 其他批次 | 可实施 | ||
| 平台健康状态 | 平台健康状态页面，需呈现平台已部署功能的健康状态统计数据。当您的账号拥有平台管理、平台审计相关权限时，您还可以查看指定组件的详细健康数据。 | 第一批次 | 是 | ||
| 组件管控能力 | 组件商店 | 版本管理：平台支持对组件商店中的各类消息组件进行统一的版本管理。 | 其他批次 | 可实施 | |
| 包管理：平台支持对组件商店中的各类组件包进行维护。 | 其他批次 | 可实施 | |||
| 升级更新：根据组件功能更新、安全漏洞修复等情况，支持对组件的版本升级、补丁升级操作。 | 其他批次 | 可实施 | |||
| 平台支持依照模板创建组件配置，用户可以自行保存模板共后续使用。 | 其他批次 | 可实施 | |||
| 部署管理 | 用户可从此处进行组件SDK及相对应传输IP和端口的申请，通过SDK以及传输IP和端口可以进行消息的收发。 | 其他批次 | 可实施 | ||
| 平台支持提供组件回收和调整能力。 | 其他批次 | 可实施 | |||
| 组件管理 | 虚机部署完成之后，可以通过一键启动对所有已部署节点进行快速启动和停止。 | 其他批次 | 可实施 | ||
| 可以查看并修改节点配置。 | 其他批次 | 可实施 | |||
| 平台可以查看组件的操作日志和启动日志。 | 其他批次 | 可实施 | |||
| 平台可以监控组件的健康状态和资源使用情况。 | 第一批次 | 可实施 | |||
| 集群管理 | 消息组件采用集群部署模式部署服务。该模式相较于单机部署在性能和负载能力上有了进一步的提升。 | 第一批次 | 可实施 | ||
| 通过多中心完成同城灾备集群的部署以及监控，应展示同城机房的互备关系，运行监控等。 | 第一批次 | 可实施 | |||
| 通过多中心完成两地三中心集群的部署以及监控，应展示各个集群的互备关系，运行监控等。 | 其他批次 | 可实施 | |||
| 日志管理 | 平台支持展示所记录的所有平台级相关日志，包括登录信息，执行操作等。 | 其他批次 | 可实施 | ||
| 平台支持对所产生的平台级日志进行日志审计。 | 其他批次 | 可实施 | |||
| 用户角色管理 | 用户管理 | 支持拥有平台管理权限的用户，通过平台创建本地用户，并为用户添加角色。 | 第一批次 | 是 | |
| 平台管理员可以为自己账号之外的指定的用户添加角色，使用户拥有相应角色的权限； | 第一批次 | 是 | |||
| 平台需提供灵活的用户管理方式，支持对指定的单个用户进行管理。 | 第一批次 | 是 | |||
| 用户组管理 | 通过在平台上创建本地用户组，对平台上的多个用户（任一来源）实现基于角色的访问权限控制。 | 第一批次 | 是 | ||
| 支持具有平台管理权限的用户管理本地用户组的成员。 | 第一批次 | 是 | |||
| 支持具有平台管理权限的用户管理用户组的角色。 | 第一批次 | 是 | |||
| 支持更新和删除用户组。 | 第一批次 | 是 | |||
| 角色管理 | 支持具有平台角色权限的用户根据实际使用场景创建小于等于自身角色权限的自定义角色。 | 第一批次 | 是 | ||
| 包括更新自定义角色基本信息、更新自定义角色权限信息、复制已有角色为新角色、删除自定义角色。 | 第一批次 | 是 | |||
| 通过导入/移除角色成员，灵活实现角色权限的下发/回收。 | 第一批次 | 是 | |||
| 更新用户安全策略 | 为确保用户登录安全，平台支持设置用户安全策略，包括密码安全、用户禁用、用户锁定、用户通知、访问控制策略。提升用户密码的安全性，降低恶意攻击风险。 | 第一批次 | 是 | ||
| 数据同步 | MySQL/TDSQL数据库CDC | 数据同步过程中，获取需要同步的数据，并将数据经过国密加密传输，进入消息中间件，进行后续同步处理。 | 其他批次 | 可实施 | |
| 全量数据对比 | 针对突发数据量较大时binlog丢失情况下的数据同步，支持对源库表与目的库表的数据进行全量对比。 | 其他批次 | 可实施 | ||
| 主备切换时数据同步处理 | 数据库底层主备切换时进行数据同步的场景，保证目的库表的日志与主备切换后的源库表日志一致。 | 其他批次 | 可实施 | ||
| 数据库分片的CDC支持 | 支持数据库采用分片功能场景下的数据同步。 | 其他批次 | 可实施 | ||
| 数据ETL | 针对不同类型数据库之间的数据同步，支持数据增量同步、数据处理、数据插入、多份数据库核对等功能。 | 其他批次 | 可实施 | ||
| 审计日志管理 | 消息中心应提供各个维度的审计日志，方便开发运维进行问题的快速分析、排查、管控端操作的监控留痕。审计日志根据季度归档。 | 其他批次 | 可实施 | ||
★产品原生功能标注为是的，为投标软件产品的必备功能，投标人应出具投标产品具备上述功能的承诺函，并在投标文件中提供投标产品功能清单，同时对投标产品功能是否满足产品原生功能的要求进行逐一说明；产品原生功能标注为可实施的，接受以实施方式满足。
三、技术、业务及服务要求:
（一）源码和文档要求：本项目涉及的相关软件产品的源代码、客户化源码和采购人要求的文档应提供给上海银行（其中软件产品源代码应在进场时立即交付），客户化源码和文档的版权和知识产权归上海银行所有，并进行相应的知识转移和相关培训。
（二）项目进度要求：本项目第一批次功能上线应于2024年7月12日前完成，完整功能上线（包含第一批次及其他批次功能）应于第一批次上线后6个月内分批上线完成。（功能所属的上线批次要求以采购内容（功能要求）为准）。
（三）技术要求：
软件产品需支持在全国产化环境运行（包括但不限于国产化服务器、数据库、中间件等）。遵循上海银行技术架构规范和标准。标准错误码管理、统一渠道、全局流水、子交易序号等全行统一技术架构规范要求。
1、架构要求
（1）后管及运维平台采用B/S架构，消息SDK及消息中心采用C/S架构。若存在多个软件模块实现消息中间件的全部能力要求，后管软件必须在单一站点内统一管理所有模块的参数、数据、权限和运行状态。第一批次上线时应在上线范围内满足以上架构要求。
（2）操作系统：支持Windows操作系统、Linux操作系统包括开源操作系统（CentOS、Ubuntu等）、国产化操作系统（统信、麒麟等）、支持国产化要求。
（3）数据库：支持多种数据库接入包括TDSQL、UPSQL。
（4）应用服务器需支持鲲鹏ARM、海光X86等架构的国产芯片服务器。
（5）JDK要支持国产如KonaJDK8及以上版本，和OpenJDK17两个版本。
（6）同城双活，全年可用率99.999%，同城RTO接近于0（1分钟内），RPO=0。异地RTO<30分钟，RPO<5分钟。
（7）IE版本兼容性：兼容IE8及以上版本，兼容火狐、谷歌、微软Edge。
（8）稳定性：系统稳定可靠，保证7×24小时连续运行
（9）安全性
a) 要求提供全面的安全设计，确保数据的保密性，如数据权限的分级管理、系统操作日志管理等。消息中心支持多租户，以进行租户间的数据隔离。消息组件支持读写权限的分配，对于不同的主题配置不同的读写权限，确保数据的正确安全传输。消息中心需提供对国密的支持，确保消息的安全传输。
b) 消息中间件和SDK应能通过身份认证确保访问安全，若消息中间件和SDK使用多种软件模块实现，应保证一个应用进程在没有特殊隔离要求的情况下可以只使用一个认证信息实现与所有消息中间件的认证。后管系统设置权限时应能够对唯一身份信息配置任意消息中间件的访问权限。
（10）消息中间件和消息SDK的身份认证必须若存在本地存储的认证信息，应采取符合国密要求的加密方式加密认证信息防止认证信息明文落地。
（11）代码开发和代码管理：提供产品源代码和实施部分源代码给采购人，代码管理、版本控制采用采购人的工具和平台，完全适配采购人现有 DevOps 平台，支持一键化打包、换版、启停和切换等。
（12）系统对接：全部消息中间件和消息SDK模块应对接采购人监控、日志等体系。
（13）同时支持在容器环境和虚机及采购人的云上或云下环境部署。
（14）提供明确的系统逻辑图及部署架构图。
2、性能要求
（1）平台性能：
1）并发用户：后管平台支持500人同时操作，并行管理多个中间件集群。
2）响应时间：前端页面最大响应时间不大于800毫秒。
（2）消息组件性能：
1）吞吐量：1KB大小的消息传输场景下，高可靠消息组件客户端>=50000TPS，高吞吐消息组件客户端>=100000TPS。
2）消息组件支持高并发连接，支持10000并发以上。
（3）数据同步组件性能：
1）处理能力：常见关系型数据库环境下，每分钟同步的数据量不少于3G。
（四）人员要求：
1、项目团队各成员须全程全职投入本项目，并根据采购人要求以驻场方式提供服务，不得兼职从事其他项目。
2、项目团队人数和资格要求：
项目经理1人、架构师1名、开发工程师10人、测试人员3人、上线后维护人员2人。
需提供拟参与本项目人员的工作简历、项目角色、相关基本情况（户籍、居住地、学历等）。项目人员须出具全日制专科（含）以上学历、公司正式员工证明材料。
项目人员参与本项目前应获得采购人认可
- 项目经理：须具备5年以上项目管理从业经验，管理过10人以上的系统开发团队。具备优秀的沟通协调能力，能较好把握项目整体实施风险及进度；
- 架构师：须具备5年以上系统整体设计及优化从业经验，能够准确把握采购人对软件系统的要求，并能在此基础上给出业内参考及合理化建议；
- 开发工程师：须具备3年以上软件开发从业经验，对自行编写的文档质量、代码质量以及运行效率负责。配合项目经理做好代码管理、配置管理、环境管理、文档管理等工作。熟悉并具备Java、C、C++、.NET、 B/S架构开发经验，熟悉SSM架构，MySQL数据库。
1） 前端开发人员：熟悉js,css，vue等。有基于多系统实时接口交互的开发经验，熟悉MySQL数据库SQL编写。
- 测试人员：须具备3年以上测试从业经验。
- 维护人员：须具备2年以上系统维护从业经验。包括性能优化、快速故障处理、日常巡检、补丁升级、版本升级等。
3、项目团队成员驻场前须经过采购人项目工作小组认可。若非采购人原因发生项目成员人员变动，应经采购人事先书面同意并提前一个月安排好同等或以上资历人员做好交接工作，接替人员须经采购人项目工作小组同意。
4、供应商应根据采购人实际项目进度要求、面试情况、使用满意度、服务水平要求等情况及时增派或调整采购人项目工作小组认可的人员。
5、采购人所需人员须自项目启动或人员调整触发的1周内准备完毕并到场。
6、项目团队如驻场工作，应由采购人根据《上海银行技术服务驻场支持人员管理约定》进行管理。
7、项目实施过程中应确保人员的稳定，任何人员如须请假，须提前2周告知采购人，予以批准后方可休假；
8、供应商应对工作安排A、B角技术服务人员，以满足业务连续性服务的目标要求；
9、平衡所安排的服务人员工作饱和度，以保证服务过程中不会出现服务水平下降的情况；
10、针对项目服务过程中发生人员流动频繁、人员不足、服务质量下降、项目进度缓慢等影响采购人利益的情况，采购人可对供应商进行一定的罚款。
文章推荐：
更多商机查看，下载保标APP
扫码关注小程序，获取商机更容易
