1、信用卡应用系统上云实践招商银行 纪克丁背景介绍策略与思路过程和经验云后架构演进最初的云原生技术生态主要集中在容器、微服务、CI/CD、DevOps 等技术领域。如今的技术生态已扩展至底层技术、编排技术、安全技术、监测分析技术、大数据技术、人工智能技术、数据库技术以及场景化应用等众多分支，初步形成了支撑应用云原生化、构建应用全生命周期技术链。CNCF 的云原生开源版图（部分）金融交易云是基于互联网的高并发，高可用交易类场景搭建的基于云架构的专用交易平台。金融交易云主要承载招行借记卡、信用卡核心、零售转账、快捷支付、数字人民币等稳态业务，保障核心交易稳定运行。招行采用“双路径”模式，建立了招行云平

2、台。一条路径是通过金融交易云替代主机，解决海量交易及数据的性能容量和主机不可持续升级等问题；另一条路径是通过原生云将传统的IT能力打造为原生云服务，支持快速创新。原生云平台提供包括虚拟机、容器平台、数据库、大数据、AI、PaaS、存储、网络、计算等一系列云服务。原生云主要承载渠道类、业务处理类、客户经营类等敏态业务，可以快速响应业务发展和变化。云开发框架是为了开发人员更好的和更方便的应用云基础设施的能力。在应用快速开发，应用的可用性和可观测性方面提供低侵入接入方式。招行建立了端到端的DevOps交付工具体系。从需求提出到设计开发、从测试验收到上线发布，再到投产运维监控，每个阶段都有便捷的、自动

3、化的支持工具。云原生化InCloud 统一的云原生基础设施 软件云原生架构 以“应用”为中心云化OnCloud 统一的云海资源池 软件迁移上云 以“资源”为中心服务器OutCloud 碎片化物理设备管理 软件与硬件割裂 以“设备”为中心第一个转变：资源自动化第二个转变：应用自动化从传统架构向云架构转型的三个阶段：第一个阶段是服务器阶段，即上云前系统所处的阶段；第二个阶段是云化阶段。应用系统通过持续不断的架构演进、优化改造，以满足云上部署的要求。第三个阶段是云原生阶段，该阶段是应用上云后，继续不断的通过架构演进、优化改造，使得应用演化为云原生架构。三个阶段，需要两个转变过程来实现：第一个转变：实

4、现从以“设备”为中心向以“资源”为中心的转变，也就是实现资源自动化。第二个转变：是实现从以“资源”为中心向以“应用”为中心的转变，也就是实现应用自动化。应用系统上云既是一项具体的、技术上的工作，也是一个需要提升认识的工作，需要学习云、了解云、掌握云，了解传统应用架构向云架构转型的阶段和转变。信用卡客户综合服务系统是信用卡领域的CRM渠道，承载的功能有900余项，是信用卡中心客户运营服务的兜底渠道，系统监控级别属于TOP50系统。客户综合服务系统一年实现2.5亿次左右的客户服务交互。如果系统可用性出现问题，会导致7*24的客服服务能力中断，严重损害招行声誉。信用卡客户服务系统未上云时的开放部署架

5、构：应用部署在WAS集群，数据库采用DB2，通过CTG与主机系统进行交互。应用部署架构整体采用异地双活架构实现系统的高可用。该架构是信用卡开放平台系统在未上云时典型的部署方式。根据招行“双路径”上云的思路，核心系统要实现从主机平台100%迁移上金融交易云；外围系统要实现100%迁移到原生云平台。信用卡客服系统的目标是100%迁移到原生云平台。上云策略新增应用上云领域驱动微服务架构RESTAPI已有应用上云缓存消息队列应用可观测适配改造特性开关适配外部系统适配数据上云数据上云分类迁移异构存储多源比对通过新增应用上云过程熟悉、了解、掌握云的应用；通过引入缓存、消息队列、云开发框架进行已有应用架构解

6、耦，实现云上部署和应用可观测；通过引入特性开关进行应用改造，适配外部系统和数据上云，适配改造贯穿上云的全过程。数据上云在应用上云的基础上，通过分类迁移、异构存储和多源比对实现。领域驱动设计微服务架构RESTful接口设计通过领域驱动设计为方法论，对系统的领域进行重新梳理和划分；通过微服务架构和REST API方式落地应用云上部署。达到学习云、了解云、掌握云的目标，同时为已有应用上云改造提供应用解耦方案和架构演进路径。领域驱动设计是一套方法论，可以比较好的指导我们将复杂问题进行拆分、通过拆分各个子系统及分析子系统间的关联关系，了解整体系统是如何运转的，帮助我们解决大型的复杂系统在落地中遇到的问题

7、。是每个微服务组件都是简单灵活的，能够独立部署。可以由一个小团队负责更专注专业，相应的也就更高效可靠。微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。无状态协议HTTP，具备先天优势，扩展能力很强。JSON报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。语言无关，各大热门语言都提供成熟的Restful API框架，拥有完善的框架生态。应用系统通过增加缓存实现以空间换时间，来提升应用上云后的系统性能。对于缓存的应用，可以采用多级缓存策略，构建对应用透明的多级缓存体系。通用的消息队列引

8、入，可以实现日志类数据处理的解耦，实现应用业务处理和数据处理的异步操作。将业务处理应用中数据处理部分解耦出去，作为生产者新增对接队列的功能，新增消费者应用进行业务数据的入库处理 对于已有的、正在运行的系统：1)首先通过增加缓存、消息队列的方式，逐渐实现系统架构架构解耦，引入云研发框架适配云环境应用系统的可观测要求，达到迁移部署上云的要求，实现系统上云。在系统上云后，完成新旧系统流量切换，推动旧系统下线。2)然后再根据领域驱动设计方法明确的业务领域和微服务架构，对已有系统进行不断的业务功能拆分的竖向拆分和不断增加新的微服务的横向拆分，最终实现从传统的单体架构向微服务架构的持续演进。分类迁移 配置

9、类：通过缓存进行解耦 日志类：通过队列进行解耦 业务类：应用改造支持双发验证异构存储 MySql：普通业务 Oracle:重要业务 ES：历史数据+当前数据多源比对 准实时比对：技术实现准实时比对 异常告警：多源入库不一致告警 手工修数：快速定位问题，进行手工修数业务无感 特性开关：随时切换及异常回退 分类切换：细化业务类型进行切换 高保障：支持多源查询特性开关除了适配内部系统数据迁移上云，也是适配外部系统上云切换，是实现业务无感切换的思路。数据上云过程需要考虑不停机、不停业、客户无感，达到这些目标需要考虑将数据进行分类分类迁移迁移，以分析不同类型数据迁移过程的业务影响范围和迁移策略；通过异构

10、存储异构存储以应对云环境弱稳定的特性，实现系统数据上云后的高可用；通过多源比对多源比对实现技术面的迁移过程比对，以校验迁移过程的准确性；通过特性开关特性开关实现应用兼容新旧数据随时切换，做到对业务的无业务的无感感。单体架构巨石应用应用6000集群部署数据库6000部署OnCloud阶段二OnCloud阶段一-2020OnCloud阶段三-2018OutCloud单体架构+微服务架构应用垂直拆分、分层架构应用X86集群部署+ACS容器数据库6000部署前后端分离单体架构、微服务架构引入缓存、消息中间件应用ACS容器+ACS虚拟机数据库6000部

11、署前后端分离单体架构、微服务架构引入缓存、消息中间件应用ACS容器+ACS虚拟机部署应用云上部署+数据库云上部署前后端分离微服务架构微前端框架资源云上申请应用为中心、云上部署向InCloud迈进2023至今系统上云主要分为三个阶段：新增应用上云阶段、已有应用上云阶段和数据上云阶段。应用系统上云，也是对系统进行重构的时机。利用领域驱动设计的方法论，通过对客服领域的问题进行分析和推演，形成不同的问题域，为后序限界上下文划定提供了依据。领域逻辑层面：确定了领域模型的业务边界，维护了模型的完整性与一致性,从而降低系统的业务复杂度。技术实现层面：确定了系统架构的应用边界，保证了系统层和上下文领域层各自的

12、一致性，建立了上下文之间的集成方式，从而降低系统的技术复杂度。团队合作层面：确定了开发团队的工作边界，建立了团队之间的合作模式,避免团队之间的沟通变得混乱，从而降低系统的管理复杂度。限界上下文负责对其对应的问题进行解决，承载了对应问题中的业务知识及规则。通过绘制服务地图，形成解决业务问题的微服务关系。通过推演问题域，识别了客服领域的上下文、形成了服务地图。结合分层架构，形成客服微服务架构。该架构为已有系统上云的架构演进提供了路线图。云平台提供应用所需云服务自动化申请，提供服务监控基础能力，如统一日志、链路追踪、数据库监控；DevOps工具链完成应用的CICD。应用层面关注业务逻辑的实现和应用的

13、解耦。前后端分离：前端采用Vue/低代码平台，采用乾坤微前端框架。后台微服务：Spring Boot/SpringCloud/ZA21应用整洁分层架构，将微服务应用的代码结构分为接口层、应用层、领域层、基础设施层；形成统一的代码风格。使用SWAGGER统一进行接口管理，建立接口管理平台对众多微服务的接口进行管理，便于查询众多微服务接口。云服务 ACS容器 ACS虚拟机 KAFKA REDIS MySql Oracle ES架构演进 领域驱动设计 微服务改造 前后端分离 数据库解耦 消息中间件 分层架构适配上云 对接统一日志 对接北斗 应用健康探测 引入缓存 引入消息中间件 特性开关 应用跨域访

14、问投产运维 投产试运行 流量切换 运维监控 问题排查 旧应用下线 灰度无损发布通过DDD的设计和微服务的架构，给出了已有应用的演进路径。通过加入缓存、消息队列、应用云开发框架，实现了架构解耦及适配上云部署的改造；通过特性开关，完成适配其他系统上云和适配数据迁移上云。1.投产试运行：应用改造后通过DevOps工具发布到生产环境，选取试点功能进行试运行，验证业务功能。2.流量切换：试运行通过后，进行流量切换，通过不断监控流量切换的情况，关注上云后系统的运行。3.监控并下线旧系统：通过流量监控，可以发现旧系统的流量留存情况，分析相关入口后，可以进行后续下线处理。试运行遇到的问题：内存使用率：内存使用

15、率情况在无业务流量的情况下95%，需要调整内存参数。全局变量：某个应用使用了全局变量进行缓存，导致业务功能报错。流量切换的问题：未知内容：迁移容器后应用系统IP地址变更，触发网络流量问题，对业务操作造成影响。已知内容：会话保持参数的设置，导致业务系统响应时间成倍增长（100ms-400ms）。所有上云的应用，都对接了分布式链路追踪和统一日志平台。行内的发布管理平台大禹集成了日志平台和分布式链路追踪信息，可以便捷的查看链路信息和异常日志信息。上云后项目迭代开发进度加快，投产发布频次增加，投产风险增大。灰度发布可以有效的解决系统投产过程中的风险，有效降低生产缺陷带来的影响。应用通过Redis进行了

16、参数类数据的解耦，数据迁移过程不影响业务系统。需要做新旧库数据同步Redis的校验。应用通过队列进行了日志类数据解耦，数据迁移过程不影响业务。只迁移历史数据，库中数据通过实时入库进行补数，待数据满足业务系统要求时，进行特性开关切换。1.与业务操作紧密相关的数据会实时更新，无法做到对业务完全无感。2.在数据迁移过程中，对系统进行友好提示，影响时间为数据迁移时长。正式迁移前，在生产环境进行演练，预估迁移影响时间。3.建立双发机制，新库迁移后，进行双发验证，有问题可以回退。通过上云，系统架构从ALL-IN-ONE通过竖向切分和横向切分，逐渐演进到了微服务架构。通过上云的过程，研发方式从开发模式、技术

17、架构、开发技能、团队协作、部署、运维的多个角度实现了从传统开发向适应云原生开发的演进。通过系统全面上云工作，跨进了云的大门，实现了上云的第一步。上云后，从技术、人员和资源三个方面来看，都提出了新的挑战。技术资源人员云上的技术非常复杂，面临许多的技术难题，比如云环境弱稳定问题，数据碎片化、应用碎片化导致的数据质量问题。上云后，技术栈更加复杂，对系统相关人员的技术能力提出了更高的要求上云后分布式的微服务架构使得软硬件资源消耗更多收敛系统复杂性云开发范式转型提升应用高可用提升资源利用率缺少及时的重构导致系统极度复杂的重要原因。借助DDD、面向对象编程、设计模式等手段，对应用进行抽象、解耦、整合及重构

18、。清理上云的特性开关逻辑，包括应用逻辑分支和数据面的分支。将应用的旅程分为设计态、开发态、运行态。通过解构降低设计复杂度，建立团队协作沟通共识。让应用适应云的架构、实现资源的高效利用、实现应用的高效开发和应用的安全稳定运行、更快的响应业务的发展变化。在弱稳定的云环境下，需要应用系统对弱云环境具有适能力和容错能力。应用端需要通过进一步架构分层，进行应用、业务、数据面的解耦。需要建立更加灵敏的监控体系和系统异常情况下的应对措施，以此提升系统的可用性。在云环境下，各种资源的获取更加方便，但也存在资源浪费的情况。从应用端，需要考虑应用与资源消耗的匹配性。相同的资源消耗如何支持更多的业务，便是需要开发人员不断通过技术手段去解决的问题。Thanks开放运维联盟高效运维社区DevOps 时代荣誉出品