G行云计算之全栈云应用上云篇

作者： 金鑫 2022-01-11 07:44:27

云计算 G行从自身业务发展战略出发，通过制定务实的上云目标、选取合理的上云策略和分析多维的上云视角，从而推导出现阶段应用上云的总体指导性原则。

本文转载自微信公众号「匠心独运维妙维效」，作者金鑫。转载本文请联系匠心独运维妙维效公众号。

引言

2018年国家工信部印发《推动企业上云实施指南(2018-2020年)》的通知中，明确指出：“到2020年，力争实现企业上云环境进一步优化，行业企业上云意识和积极性明显提高，上云比例和应用深度显著提升，云计算在企业生产、经营、管理中的应用广泛普及，全国新增上云企业100万家，形成典型标杆应用案例100个以上，形成一批有影响力、带动力的云平台和企业上云体验中心。”由此可见，企业上云已上升为国家政策。

G行从2012年开始积极探索云计算前沿技术，历经多年的持续建设，建立了贯穿基础设施、技术中台、业务平台多层次的安沃云工程体系。从最初面向资源敏捷的私有云阶段(IaaS)，到面向技术赋能的平台云阶段(PaaS)，再到如今面向安全可控、业务使能的全栈云阶段(IaaS + CaaS + PaaS + SaaS)，“应用上云”始终是G行的重点研究方向。作为G行123+N数字化银行发展体系中基础技术平台的云计算平台，全栈云平台于2021年正式投产运行，下面本文将着重结合全栈云的上云规划和上云设计，分享下G行应用上云的理论方法和实践经验。

一. 应用上云总体规划思路

G行从上云原则、上云设计和上云执行三个层级展开应用上全栈云的总体规划设计，其中上云原则主要指企业在开展应用上云工作前为实现应用上云目标而制定的一系列指导性策略意见，上云设计是指围绕上云原则设计的全量可落地执行的上云指导方案，上云执行是指遵照上云指导方案围绕应用上云开展的一系列生产行为活动。总而言之，上云原则用于指导应用上云的总体规划，上云设计用于指导应上云的方案制定，上云执行用于支撑上云原则及上云设计的最终执行落地。

图1 应用上云规划体系

二. 上云原则

G行从自身业务发展战略出发，通过制定务实的上云目标、选取合理的上云策略和分析多维的上云视角，从而推导出现阶段应用上云的总体指导性原则。

1所有应用类系统“应上尽上”全栈云

原则上所有应用类系统都要上全栈云，并优先使用容器化上云方式。针对不能上云的业务系统要一事一议，分析不能上云的原因，如果是全栈云平台支持能力、兼容性等导致不能上云，可以单独备案，如果是应用系统自身的问题，需要进行相应的改造之后上云。

2不允许自建全栈云已有的服务能力

全栈云平台提供种类丰富、规格多样的IaaS及PaaS类云服务，应用类系统在上云的过程中应该优先调用全栈云平台提供的云服务能力，原则上不允许自建相关组件，如安全、备份、容灾、关系型数据库、容器等，若全栈云平台无法提供业务系统所需要服务能力，允许备案后自建。

3按需申请全栈云资源

应用类系统在申请全栈云的服务资源时，应遵循“最小规格、按需使用”的基本原则，根据业务系统所处理的业务量、用户数、并发用户数等因素综合考虑，合理申请资源的规格和数量。

三. 上云设计

1开展上云调研

对于新建系统上云，调研重点在于应用架构设计和服务能力需求。应用在架构设计及研发过程中，应与全栈云平台架构适配，并充分利用其提供的云服务能力，避免出现上层应用与底层平台架构不适配或平台能力重复建设。

对于存量系统上云，需对存量系统现状做全面的分析和收集，从业务需求出发，分析应用系统上云的必要性、可行性和难易度，包括系统现状调研、架构、资源梳理等，具体流程可参照下图。首先，评估系统迁移是否符合监管要求，并确认是否存在相关的技术架构要求，以及该要求能否被满足;其次，应考虑系统迁移的难度、时间、成本以及资源需求(包括计算、网络、存储、安全和运维等);最后，综合考虑应用系统的架构、流程、边界、资源和非功能来制定迁移策略和方案。

图2 上云调研流程图

2识别关键技术变化

图3 传统环境与全栈云环境对比图

全栈云体系下的云服务，无论是产品特性或者使用方法，都与现有平台存在极大差别，导致传统的应用上云解决方案无法适用于全栈云场景，这对适应并习惯了传统上云解决方案的开发和运维人员提出了极大的用云挑战。具体差异体现以下几方面：

2.1大二层网络VS三层网络

G行目前采用标准的两地三中心灾备体系架构，传统网络通过DCI Overlay封装技术将同城两个物理数据中心二层拉通整合为一个逻辑数据中心，业务可以实现跨中心同网段部署。而全栈云体系下，各数据中心的网络架构相互独立，通过云汇聚交换机实现数据中心间的三层互联，即不同数据中心内部署的应用实例不再处于同一网段，这一变化直接导致浮动IP实现跨中心主备切换、F5实现跨中心负载均衡等原有的技术解决方案失效。

2.2网络安全域隔离VS虚拟私有云(VPC)隔离

G行目前主要通过划分网络安全域配合网络安全控制策略及防火墙设施，实现全行网络的安全防护，尽管跨网络安全域的访问请求由防火墙严格限制，但实际上不同网络安全域之间地址相互可达。而全栈云采用虚拟私有云(VPC)实现系统间的隔离，由于VPC内的网络地址为私有地址，与VPC外的地址间默认互不可达，因此不同VPC之间网络天然隔离。

2.3物理网络通信地址VS虚拟机私有网络地址

G行的传统网络环境中，IP地址全部为真实物理地址，地址间通信无需进行复杂的地址转换。全栈云上应用目前使用的云网络主要为VPC私有网络，同一VPC内的网络地址默认相互可达，VPC内同VPC外的地址默认互不可达，通常只能通过EIP进行NAT转换实现VPC内外的网络地址通信。

2.4服务访问使用IP地址VS服务访问使用DNS域名

G行的传统大二层网络，支持使用跨中心的浮动IP地址或负载均衡IP地址实现统一入口访问，因此传统环境中应用更倾向于使用IP地址实现数据库、缓存、批量等服务集成。而全栈云为三层网络架构，各数据中心内的服务实例不再处于同一网段，因此大多数情况下必须使用DNS域名实现服务访问的统一入口。

3上云方案设计

应用上云主要指应用系统运行所依赖的全部或部分资源载体(物理机、虚拟机、容器、基础软件、中间件、数据库等)由云平台供给、调度和管理。根据全栈云体系中的资源载体类型，可将应用上云的方式分为容器化上云、虚拟机上云、裸金属(物理机)上云和混合上云，具体的上云设计方案说明如下：

3.1容器化上云

容器化上云是指将应用接入层(Web服务器)，应用逻辑层(即应用中间件层，包括JAVA环境、中间件、应用程序包)打包在容器中，通过云平台进行自动化部署和发布。如果采用容器化上云方式，系统需实现本地持久化数据转存，即业务逻辑和业务数据解耦，该系统所有的非结构化数据、缓存数据、结构化数据均不能位于本机或本地，应保存在共享存储或数据库中。

图4 容器化上云示意图

如上图所示，代理服务层可用全栈云弹性负载均衡器对应现有环境的负载均衡器;应用服务层可用全栈云上的容器平台部署一些体量较小、需要快速发布、弹性伸缩和故障自愈等功能的服务模块，如Web服务、小程序服务等;应用运行依赖的中间件全部使用全栈云供给的中间件PaaS服务或云主机部署中间件;数据服务层可用全栈云上的分布式云数据库或云主机部署数据库软件对应现有环境的数据库;存储服务层可用全栈云的块存储服务、对象存储服务和文件存储服务对应现有的集中式SAN存储和NAS存储。

3.2虚拟机上云

虚拟机上云是指由云平台的虚拟化环境支撑业务系统的IT子系统(计算、存储、网络、负载均衡等)。如果新建应用采用虚拟机上云，应用代码层面与传统方式相比无差别。

图5 虚拟机上云示意图

如上图所示，代理服务层可用全栈云弹性负载均衡器对应现有环境的负载均衡器;应用服务层可用全栈云上的云主机对应现有环境的虚拟机、物理机和小型机;数据服务层可用全栈云上的分布式云数据库或云主机部署数据库软件对应现有环境的数据库;存储服务层可用全栈云的块存储服务、对象存储服务、文件存储服务代替现有的集中式SAN存储和NAS存储。

3.3裸金属上云

裸金属上云类似于虚拟化上云，通过全栈云平台实现物理主机的自动发放，并支持自动化的网络服务和硬盘管理(包括挂载、卸载和扩容)，主要应用于以下场景：

• 核心数据库场景：部分客户要求其关键的数据库业务不能部署在虚拟机上，而是必须通过资源专享、网络隔离、性能有保障的物理服务器承载。
• 高性能计算场景：超算中心、基因测序、图形渲染等高性能计算场景，处理数据量大，对计算性能、稳定性、实时性等性能要求很高，无法承担虚拟化带来的性能损耗和超线程等影响。
• 安全和监管高要求场景：金融、证券等行业对业务部署的合规性要求，以及某些客户对数据安全的苛刻要求，只能采用物理服务器部署，确保资源独享、数据隔离和可监管可追溯。

3.4混合上云

混合上云是指业务系统采用上述两种或两种以上的上云方式上云，主要针对技术架构复杂且单一的上云模式无法满足技术架构要求和业务发展需求的业务系统，可根据不同模块的需求选取各自合适的上云模式，具体不再进行展开说明。

总结

应用上云是一项十分庞大且复杂的工作，并没有所谓的通用解决方案能够适配所有企业的上云需求，因此本文通过G行全栈云的上云规划和上云设计内容，侧重分享了G行关于应用上云的理论方法和实践经验，希望用一些共性的上云方法论，帮助各位读者结合自身上云环境，形成最佳上云实践。