刘志-多云融合架构下中小银行的建云、上云和用云指南

刘志 公司职位长沙银行数据中心生产运营中心经理 负责长沙银行整体运维体系建设规划，推动长沙银行运维数字转型的进程，参与长沙银行云原生规划与设计，是长沙银行从传统运维到数字化运维的见证者与参与者 为 何 要 走 “ 融 合 ” 目录 怎 么 去 融 合 多 云 如 何 “ 融 会 贯 通 ” 几 点 思 考 为何要走“融合” 选择驱动 面对自主可控信息技术产业建设及应用国产化创新改造的新浪潮,“云”被视为金融数字化转型的新基建、新连接，是金融科技输出的关键窗口。在高新技术自主可控、自立自强的大背景下，基于国产基础软硬件的云平台建设成为金融领域云计算建设发展的重中之重。在国产创新的浪潮和行业内部数字转型需求下，摆在多数金融同业面前的，不外乎如下几种场景： A、已有云，但非国产创新架构 B、已有云，目前只兼容C86 在国产创新要求前，已经建设有较为完整云计算平台，但是不兼容国产创新架构，需引入国产XC架构或投入资源改造。 C86走到头亦或投入资源引入ARM，作相应的兼容适配。----“单押or双押”？ C、没有云，还在虚拟化 D、已有云，异构兼容 c86+ARM兼容并续，双栈并举，提前开启下一阶段的热点技术方向的研究，国产GPU、如AI+等。 还在X86虚拟化阶段，在国产创新发展浪潮下，需要建设相应的全栈国产云平台，并进行业务系统的云化迁移。 不同的“故事”背景，相同的两条路线 一“芯”一栈，单栈建设 抛弃原有技术路线或者技术底座，集中力量建设单云单栈。绑定单一技术厂商，单一芯片架构。 面临的痛点 运营管理 资源规划 两朵云怎么高效的运营管理，上云应用如何形成统一的运维规范，怎么同已有的观测体系、应急切换体系融合。 A云/B云资源池每年如何规划，如何盘活存量资产 技术路线 应用上云 应用上云面临多种选择，且选择不同的云底座，所使用的云服务特性和容灾架构设计又有所不同，怎么减少应用上云的复杂度。 单一技术路线和厂商产品捆绑问题，避免“黑盒交付”和商业绑定，怎么提升云平台自主可控能力。 面临的痛点 破局点 问题思考： 多云该怎么用？ 如何建云？ •云底座及其承载应用技术架构演进方向如何统一•云运营工具如何统一•多云技术底座如何提高运维效率•硬件资源投入上如何均衡 Ø云网融合 Ø算力统筹 如何上云？ Ø双栈贯通 Ø统一运营 •在国产创新条件下如何盘活“旧云”？•如何提升云平台自主可控能力，规避单一平台/技术风险？•如何让应用无感知底层差异，轻松用云？ 怎么去融合“多云” A云架构 A云提供计算/块存储/对象存储/负载均衡等IaaS能力，未使用全栈提供的数据中台、PaaS级服务。 双中心网络架构为大三层，底座产品相对较轻，应用同底层IaaS服务建基本解耦。其承载应用多部署在全行级的PaaS平台上（非华为cce），全国产创新底座，算力池多元。 B云架构 B云提供计算/块存储/对象存储/负载均衡等IaaS能力以及移动金融/数据库等PaaS级产品服务和流计算/实时分析等DaaS产品服务。网络架构为大二层设计，底座产品重，与业务耦合度高。其承载的应用包括手机银行、风控平台、移动中台、数据中台等，多数为x86架构，少量ARM架构；算力池结构目前较为单一。 IaaS层建设思路 l分层解耦：底层基础设施资源按业务场景需求向上提供API接口级能力，整体与PaaS乃至SaaS层松耦合，应用层架构不强依赖于底层基础设施。l注重云服务资源能力建设：建设云平台的各项基础服务能力，例如数据库容灾、大数据平台、机器学习/训练资源等通用接口能力l基础资源层面：提升基础资源纳管能力；资源池分级分类，面向业务应用从多维度规划设计多元计算资源架构 融合要点 面向应用层，利用云原生，推动双栈在应用领域“贯通” 跨 云 部 署 屏 蔽 网 络 架 构 差 异 应 用 可 以 根 据 需 要 无 缝 进 行 跨 云 部 署 ， 同 一 制品 在 不 同 云 底 座 上 部 署 ， 甚 至 双 架 构 兼 容 应 用 在 架 构 设 计 、 容 灾 切 换 设 计 上 无需 考 虑 两 朵 云 层 级 结 构 带 来 的 差 异 屏 蔽 云 底 座 差 异 和 芯 片 差 异 持 续 部 署 能 力 一 致 不 会 因 为 多 云 融 合 ， 而 使 原 有 的C D体 系 能 力减 弱 应 用 部 署 时 ， 底 层 硬 件 架 构 对 其 透 明 。应 用 可 以 基 于 环 境 进 行 部 署 。 融合方式 双云融合 云网融合 下放云内网络管理边界，融合云网和DC网络架构、贯通“多云”算力边界。解决不同芯片、不同底座、云与非云的网络区划壁垒问题。 利用PaaS横跨“多云”，整合“多云”资源，深度贯彻IaC（Infrastructure asCode）理念，将应用与底层基础设施彻底解耦。 CD增强 统一算力 在原有基于制品+配置文件的基础上，运用GitOps，实现基于环境蓝图的编排及投产，进一步提升CD能力。 两朵云统一以ARM为主，C86为辅；GPU建立专有的算力池，通用AI算力由K8s+slurm进行管理。 如何“融会贯通” 云网融合 两个融合 u云网一体融合：将VPC边界下放，与传统网络边界拉平，将云网东西流量和南北流量解耦拆分，全面提升了云网的可扩展性、观测性、稳定性；避免云内网络的“黑盒”，统一网络建设标准。uPaaS网络同IaaS底座网络融合：通过不同CSI插件实现对底层不同IaaS网络架构的适配，组网形式按集群划分，兼顾底层特点；k8s service和ELB or SLB形成联动，对应用层无感衔接。 算力统筹 Ø通过引入国产GPU及适度扩容存量小模型需要的英伟达GPU，构建专用完善的智能算力池。以国产适配路线为主，在云上探索AI、大模型等业务场景落地Ø标准化资源供给、提高自动化能力，提升供给效率 本地磁盘 部署、分配、管理自动化，提升发放和运维效率。 对基础资源池化并尽可能大范围共享，提升利用效率、扩展能力。 对具备不同能力和适用范围的计算、存储、网络资源进行分级分类；实现资源合理利用和标准化管理。 •服务器自动化•存储自动化•网络自动化 •计算/存储资源池化共享•灾备与测试复用（计算、网络共享) 双栈贯通 将云原生的先进理念，从应用延展到整体架构治理维度，创新性的利用PaaS横跨“多云”，整合“多云”资源，将应用与底层基础设施彻底解耦，实现“一云多芯，多云融合”的部署架构。 双栈贯通-双架构镜像 •利用BuildX组件+manifest构建双架构兼容镜像，减少多云多芯带来的研发侧成本，实现一套应用镜像（同版本、同tag）在不同架构集群同时部署，践行Build Once, Run Anywhere的原则。 双栈贯通-Overlay VS Underlay Underlay网络模式（B云） Overlay网络模式（A云） Ø使用geneve协议封装的隧道网络，可灵活添加、扩容子网，并和现有经典网络保持独立； Ø基于terway插件，虚拟子接口配置IP地址与MAC地址和IaaS网络直接打通，提供更高的性能和吞吐量； Ø支持Pod运行在不同vlan网络中，可通过子网实现隔离 Ø子网和主机无关，容器IP地址可以在整个集群漂移 适用场景： Overlay模式：在A云二层网络无法满足多ip宣告的条件下，用PaaS层的overlay组网可以发挥容器层网络的自有灵活性，但需要接受一定的性能损失；Underlay模式：适用于经典网络扁平，应用有PODip对外的需求，有较高的网络性能要求。 技术难点： B云（阿里云）IaaS组网也是基于VPC的SDN组网，如何通过CNI插件拉通IaaS网络资源，需要基于CNI接口规范作双向融合。同时，需要从用户视角出发，让用户无法感知两种不同组网结构带来的差异。 统一运营—OAM应用 GitOps解决了资源在不同环境流转的一致性的问题，但刚刚提到的环境特性如何合规安全的注入？我们通过引入OAM模型，来解决环境流转过程中的“环境特征”注入的问题，最终通过OAM+GitOps方式进行应用发布，简化YAML资源编排、降低开发及运维人员的认知负荷，有效提高交付标准统一度 注：现阶段上云应用数量较少，不足以归纳抽象应用运维特征，可作为平台长期规划考虑 统一运营--多云多环境应用交付体系 以应用为中心，基于GitOps+OAM技术的应用交付体系，具备资源编排、应用编排、环境编排、应用发布等一站式能力，实现多云多环境的统一运营，即一个平台+一套交付体系+一套交付标准。让多云运营效率不打折扣。 统一运营--因云制宜，指明上云路径 总体原则 优先PaaS，增量必上、存量选上、应上尽上。A云B云不同业务属性定位，利用好底座原有的技术特点。 A云： A云&B云： •行内关键交易类应用系统、办公类系统、业务中台类系统•互联网入向代理 •对于行内极为重要的业务系统，为规避单一云平台技术风险，增强业务系统高可用性，进一步提高对外业务连续性水平，进行双云部署。 B云： •大数据应用、手机银行、营销类应用、风控类、子公司业务•云内非国产创新架构的存量业务系统改造入云 统一运营--规范引领、轻松上云 上云的制度、规范和约束的提出，能够减少应用团队上云时的认知复杂度与平台团队的管理难度，做到有序上云。 新浪潮下，云去往何处？ 多 云 是 未 来 的 趋 势 ？ 云 是 否 真 的 降 本 增 效 ？ 云 计 算 的 “ 新 质 生 产 力 ” ？ 国产创新背景下的“多云”是否值得？ •“多云”是不得不面临的阶段，只有跨过，才可知价值。 不一定降本，但确实增效 效 能 增 加 ， 用 过 都 说 好 成本未减，需持续投入 部署和运营效率提升 构建工作流串联，其中容器化构建平均日执行254.37次，相较于传统构建方式效率提升69%。同时，平台服务覆盖从业务开发至投产运营的全生命周期，按需使用。 新业务上线效率提升 业务应用发版效率提升 云平台公共服务能力可将平均部署时间由原来的1个工作日缩短到1小时，部署所需时间降低了87.5%。 单应用单模块投产时间由原来的20分钟以上缩短至2分钟以内，投产所需时间缩减90%。 提前进化“新质生产力”—探索基于云原生的LLMOps •云向AI智能化的进化发展既践行了云服务应用、服务业务的理念，又符合当下AI应用快速“爆发”的趋势的，未来两年，云和AI的结合可能从GPU算力的融合、高效调度以及MLOps体系的融入等关键点上进行。 █支持GPU碎片化调度-GPU拓扑自动感知-支持碎片调度和整卡调度，提高GPU资源的利用率-对用户程序无侵入，用户无感 █GPU、CPU融合计算架构-自动调度GPU应用到GPU节点-充分利用GPU主机的CPU资源 █MLOps -人工智能模型训练工具-人工智能推理发布工具-提供产品级技术兜底 感谢大家观看