XX运营商公司应用上云架构指导意见方案分享

《XX运营商公司应用上云架构指导意见方案分享》由会员分享，可在线阅读，更多相关《XX运营商公司应用上云架构指导意见方案分享（10页珍藏版）》请在装配图网上搜索。

1、XX运营商公司应用上云架构指导意见、背景和目标XX公司支撑网私有云整体建设取得阶段性成果，IAAS层基础能力已经具备，PAAS 层相关能力逐步按照规划建设推进中，资源池相关资源也初具规模，与此同时资源与能 力运营的相关体系也已经初步建立，并经过一年多的试行，推动相关流程和模式的不断 完善，XX公司融合资源池使用指导意见、XX公司融合资源池管理办法XX公司 大数据平台运营管理办法等管理制度与规范相继发布。随着资源两级管理运营模式有序开展，各租户资源使用规模逐步扩大，上云的应用 或系统也越来越多，在租户对于资源的使用过程中，发现较多不合理使用资源，或者不 合理的架构设计，造成云上系统的诸多问题，无

2、法获得系统云化带来的优势与便捷，反 而给系统使用和维护造成不便和问题，基于这些因素，信运部组织专家团队，总结以往 在私有云上相关系统、项目的建设、设计、部署、运维相关工作的经验，特此编制此指 导意见，旨在指导云上应用系统的架构设计，系统集成和部署，充分发挥系统云化特性， 提升系统和应用服务能力，提高资源利用合理性，发挥资源规模效应和平台优势，提升 私有云总体效益。、总体原则1. XX公司私有云上承载的应用系统，只能在私有云提供的能力，组件，技术，资源下， 按照相关技术特点和要求，构建其应用系统。2. 云上应用系统构建，采用的技术、组件应最大程度考虑通用性和标准化，系统架构 应符合云计算演进方向

3、，核心技术优先选择主流技术路线，最大程度考虑应用业务， 系统组件，与平台资源的解耦。3. 原有传统应用系统的上云，要避免简单粗暴的系统资源迁移，即原有物理机部署的 简单迁移至虚拟机部署，必须根据原有系统情况，挑选合适组件和技术，综合考虑 架构适应，迁移复杂度和风险，以及资源需求，合理有序进行上云迁移工作。4. 架构设计合理适配，既不能架构能力不足，造成业务中断，数据丢失，或者扩容繁 琐，资源浪费等问题，也不能过渡设计，例如无实际场景需求的容灾配套，造成建 设成本的浪费。架构设计需要自上而下，从业务应用需求出发，根据业务场景和相 关指标要求，综合考虑功能需求和非功能需求，架构设计时选择合适合理的

4、技术， 以较小的成本满足应用业务场景相关的功能和非功能需求。5. 应用系统上云后，由于资源、技术等一些变化，需要提前考虑系统相关运营运维流 程的变化，对原有相关流程环节进行评估和确认，以避免上云后原有运营运维工作 流程出现不匹配或不适应的情况。三、上云架构设计要件1. 性能质量本条目主要从应用业务场景出发，综合考虑业务、运营、故障、维护等情况下，如何提 升系统服务性能，提高系统运营和运维质量。1.1 分层异步处理设计对于前端使用具有较高业务响应时限要求的场景，例如面向最终客户，或者一线业务人员使用的web类、app等业务系统，在前后端访问，前后台接口调用的设计时，应考虑分层异步处理的设计，并且

5、结合端到端服务指标的要求，合理设置各环节的超时阈值， 以达到快速响应、快速返回、快速失败的要求，满足整体业务场景中前端使用人员服务 质量，提升使用友好度。1.2 分层分级缓存机制对于前端使用具有较高业务响应时限要求的场景，如果前后端调用，数据流转，事物处 理等环节，存在处理逻辑复杂，数据交互量大， IO 量大或者频繁等风险影响服务性能的 情况，可以采取分层分级缓存的机制，来降低10或数据处理的时延，提升前后端调用 响应速度。但是，对于动态实时缓存的设计，特别还需要注意数据一致性问题，避免前 端，缓存，与固化数据交互过程中的异常情况造成的数据不一致，从而引起业务问题。1.3 分级数据管理对于存在

6、数据收集、处理、分发、留存的业务场景，包括但不限于业务记录、报表、日 志、多媒体对象等，在对数据做存储和管理设计时，应按实时 /异步，明细/汇聚，年/ 月/日等维度对数据的收集和使用进行分级管理，并对相应数据的存储做分层管理，并 配套规划相应的创建、保护（备份和加密）、访问、迁移、归档和销毁机制，实现数据 和信息的生命周期管理。从而提高数据的存储、使用和维护的效率，系统运营质量。1.4 系统组网边界清晰在业务系统架构方案时，特别是组网架构上，应明确系统边界，做到结构合理、边界清晰。对于业务系统内部的交互，应全部在边界内部完成，业务系统对于外部的出和入，都应单独设计的暴露机制，根据业务场景对于暴

7、露能力需求建立相应的能力指标，系统 投产前根据指标要求进行相应的压力测试。一般边界不清晰系统的情况，对于主动出去访问外部系统的，对端可以看到本系统暴露接口之外的资源，诸如系统其他内部节点、主机名、域名、IP、MAC等等；对于被动接 入外部系统访问的，对端可以访问到本系统暴露接口之外的资源，诸如统其他内部节点、 主机名、域名、IP、URL、端口、服务等等1.5 数据一致性对于存在数据交互的业务场景，如果是分布式组件，或者采用前后端调用、异步事物处 理、动态缓存等机制时，应在流程设计时考虑到数据一致性的问题，通过数据稽核审计、 或者流程内部的校验机制来保障前后端、缓存、固话数据之间的数据一致性，避

8、免由于 数据不同步造成的业务问题。按数据一致性的实现方式，分为通过流程设计保证数据一 致性，通过稽核审计保证数据一致性，通过流程设计+稽核审计实现数据一致性三类。2. 灵活和便捷性在系统方案设计时，应充分考虑架构、组网、数据流转、选用组件等方面，根据不同业 务功能和非功能需求的要求，满足系统在部署、扩容、业务运营、系统维护等场景下的 灵活性和便捷性。2.1 产品、方案与系统、组件耦合度对于云上的业务系统，应从产品选型、方案设计、系统逻辑、组件选择方面考虑通用性和便捷性。对于同样功能点的组件，应设计为能够支持多种通用性产品，或多个通用版 本，避免对特定产品和特定版本的依赖。如应用对操作系统环境的

9、要求应适配通用的 linux 版本，中间件当支持 tomcat、 nginx、 httpd 等多种产品，数据库可兼容 oracle、 mysql、 pg 等，并支持组件的多个常见通用版本。2.2 配置化程度对于云上的业务系统，从灵活便捷的角度，建议考虑在集成部署、运维管理、业务运营、业务服务四个层面，根据实际场景需要，设计可配置化的机制。以此增强系统对于不同 底层环境、网络环境、操作系统、组件、业务环境、管理流程和机制等方面的外部环境 有更好的适配度和兼容性，满足云资源池不同组件和环境下的承载需要。2.3 弹性伸缩弹性伸缩即根据需求或者预定策略，快速调整计算资源，且对系统运行和业务服务没有 重

10、大影响。例如，可通过设置定时、周期或监控条件策略，自动或手动调整组件实例、 进程或者服务资源配置，使云资源能够灵活的分配到业务需求的应用上去，降低服务成 本。根据弹性伸缩设计的机制，可分三类，一是在线进行，即手动配置部署组件、进程、 服务等方式，不中断业务服务情况下进行资源伸缩；二是半自动化，即通过一键式或者 一个脚本方式，实现快速资源伸缩，对比第一类资源伸缩达成速度更快（秒级）；三是 全自动化，即根据预定义策略，根据时间、业务量、监控阈值等无人工干预的实现资源 伸缩。2.4 无状态化对于云上的业务系统，阻碍服务处理能力平行扩展的最大制约在于状态的处理。状态化 的系统会将业务逻辑、系统配置、调

11、用关系等应用和系统的状态保存在本地，从而阻碍 架构的快速横向扩展。为保证云上系统的快速横向扩展能力，建议在架构设计时实现系 统配置无状态化，对业务处理逻辑实现无状态，而将状态信息保存到诸如缓存、数据库、 共享存储、消息队列等有状态的组件中。一般无状态化的系统，具备较好的弹性伸缩能 力。2.5 分布式架构对于云上的业务系统，为提高服务性能和业务扩展能力，建议在设计时全部或部分地采 用分布式架构设计。根据分布式组件工作范围，分为整体采用分布式架构设计，核心组 件或部分主要组件采用分布式架构设计，部分组件实现分布式架构设计等情况。3. 服务连续性本条目从云上系统业务服务连续性需求角度出发，对于常见系

12、统架构、机制、组件、节点等方面给予参考意见，以确保系统业务服务满足要求。3.1 服务自启动 云上的业务系统，对于节点、虚机、容器等承载资源服务中断后的恢复，资源之上的系 统、应用、进程、服务、组件等应当能够在自动启动并恢复功能，以适应云计算平台的 运行特性，减少非必要的业务中断。3.2 集群化或主备部署 对于云上的业务系统，建议主要功能节点、组件通过集群化或者主从模式进行部署，避 免出现单点故障。当个别实例或节点故障时，业务应当尽可能无感知地实现接管和切换。 按照接管时的影响情况，分为降级无感知、降级弱感知和手动切换三类。3.3 负载均衡 云上的业务系统建议在前端接入配置负载均衡的机制，以确保

13、服务接入侧的性能扩展能 力和服务高可用性。按接管和切换方式，分为无感知接管，弱感知接管（刷新或者重新 登录）或者手动调整接入（域名调整、路由调整）等类型。3.4 组件和节点间松耦合，调用弱关联 云上的应用方案或系统架构，建议各组件或者节点间采用松耦合方式，系统调用弱关联， 例如使用连接池、集群化、短连接、异步、消息队列等方式降低各环节的耦合性。实现 各个节点、进程、服务均可实现单独配置、启停，特别要避免单个组件或节点的异常恢 复，需要系统各组件按照一定顺序启动的情况。3.5 应急容灾能力 系统根据业务场景需求出发，根据自身服务连续性需要进行容灾或应急能力考虑，在云 环境下从应用架构层面规划和设

14、计应用和系统级的容灾及应急方案。应急容灾能力的实 效性颗粒分为实时和延时。实时容灾或应急能力可以在秒级甚至毫秒级实现系统容灾切 换或应用应急接管。延时容灾或应急能力可以在有限干预的条件下实现系统容灾切换或 应用应急接管工作。一般情况下应急从业务服务层面考虑，容灾是从数据安全和环境安 全层面考虑，容灾系统一般采用异地方式构建。3.6 服务能力降级设计 云上的业务系统应实现服务能力降级设计，当硬件、系统、组件等部件出现异常时，可 提供降级的服务能力，如服务规模的降级，服务功能降级，服务性能降级等。例如，CRM 系统中，部分组件或者硬件故障，不会引起整体系统服务中断，如单个功能业务记录查 询可以查询

15、到部分用户记录，或者可以查询到用户的部分时段记录，再如业务变更、销 账等功能关联组件异常，不会影响到其他开户、充值等业务的服务。4. 维护管理 本条目从运维管理角度对云上的业务系统进行评估，提高系统的可维护性。4.1 监控告警体系 云上的业务系统应实现完整的监控告警体系.可分层分级实现端到端监控，并实现多触点 通告和统一配置处理功能，并提供告警处理手册和标准化的告警接口。4.2 日志管理体系 云上的业务系统应当具备完善的日志管理体系。可分层分级记录应用及系统日志，实现 业务与系统的串联分析，日志目录空间的自循环和统一集中管理。4.3 集中统一的运维管理 云上的业务系统应当具备集中统一的运维管理

16、界面，可通过管理界面实现系统部署，平 行扩容，架构变更，系统配置，上线发布，服务、组件、集群启停，应急管理，数据备 份等运维工作。4.4 备份机制 云上的业务系统应当考虑建立健全的备份机制，从系统备份、数据备份、历史数据归档 等层级分级实现备份功能。并且可定期进行恢复测试验证。5. 信息安全5.1 安全漏洞 云上的业务系统应当及时修复各类中、高危漏洞，业务系统本身不能存在可被利用的安 全漏洞，系统基线配置应符合公司和行业的安全管理要求。5.2 系统安全设计 云上的业务系统在系统设计层面应考虑系统安全因素，对敏感数据的存放、传输等应进 行加密保护。对相应的操作应具备记录和审计管理功能。在日志记录

17、及数据暴露环节应 对敏感数据进行脱敏处理。5.3 敏感数据访问 敏感数据访问应符合相关的管理规范要求。6. 传统非云化系统设计 本条目列举了一些传统非云化的业务类型，此类业务系统并不适合云环境部署。6.1 物理设备或链路要求的业务应用或服务依赖于物理设备或物理链路的业务类型不适合云环境部署。如依赖于USB证 书认证的服务，或者需要物理心跳网络的业务。6.2 有针对物理设备冗余机制的业务 对物理设备本身即具备冗余机制的业务类型不适合部署到云环境。比如对存储环境有多 副本需求的场景，如hadoop集群的三副本机制、access软件定义存储的镜像机制等。6.3 数据密集型业务 本身包含并存储了海量数

18、据的业务类型不适合部署到云环境。如大数据类业务、数据仓 库、海量静态数据、视频类、流媒体业务。四、上云系统架构先进性评估 上云系统架构评估工作，旨在系统架构设计之初，能够根据业务服务、业务运营、系统 运营、系统维护等 IT 系统各环节场景需求，结合云平台资源池资源与服务能力，综合 考虑云化系统各方面设计情况，评估上云系统架构情况与风险，指导后续的系统运营和 业务运营工作。上云架构先进性评估主要分为以下几个步骤开展：1. 上云系统的建设单位，新建系统在立项完成后，老系统迁移上云在计划资源申请之前，由系统建设单位负责，将本指导意见及评估表交系统建设团队或开发集成团队，在系统架构设计，系统整体设计方

19、案时，应充分参考本指导意见的各项内容，在系统整体方案 设计完成的同时，完成上云系统架构评估表的自评部分，并对各项自评评分进行充分的 解释说明。并将系统整体方案与评估表提交私有云运营单位。2. 私有云运营单位收到相关材料后，根据情况对系统架构方案进行评估，给出评分结果 以及评估意见，并组织需求单位、项目建设单位、业务或系统运营单位等相关单位对结 果进行确认。3. 私有云运营单位将上云系统架构先进性评估结果，通过正式流程发送至相关单位，以指 导相关项目的交维、验收等相关工作。五、典型架构案例1、层次化和模块化设计模块化按照应用层、数据层、基础 设施层讲行高 可用谊计-按照功能划分 模块，模块之 间

20、松耦合*要求稳定可靠、 易于扩展、结 构简单、易于 维护.赠屋苛育肯侖Q ；石両 厂一一苛厂一占厂云N iM-j ffii W层次化和模块化设计是上云应用高可用设计的前提，这个模式本身是非常简单而有效的： 每个模块都必须属于某个层次，提供给上层（N+1层）服务，同时委派任务给下层（N-1层） 的模块；任何一个模块都不能逆层次调用：属于第N层的模块都不能调用（耦合）第N+1层或以上层次的模块；任何模块都不能跨层次的模块，不能调用第N-2层或更下层的模块, 如下图所示：向组吟3,1组件3.34L1.22、松耦合及弹性伸缩设计 耦合度与灵活性相反，耦合度越小，扩展性越好，容错能力越大。应用通过负载均衡对外服 务，内部采用松耦合架构，实现弹性伸缩。通过消息解耦将应用拆分独立的模块和节点，互相间无影响，不会因为部分失效导致整体的 不可用。3、一个典型上云架构范例：对热点数据进行缓存，加快数据的访问速度，并减轻数据库的压力通过分布式数据库实现数据库的水平扩容，提升数据访问的并发量使用分层和模块化架构，采用松耦合设计提升高可用性。负载均衡W-R -数据层内存数据库