- 1、本文档共30页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
????
???
基于容器技术构建一站式业务支撑平台方案
???
?
?
?
?
???
???
?
???
?
?
?
【导读】本方案是“2020容器云职业技能大赛”团队比赛冠军团队的作品。为大家呈现了容器平台较全面的体系化建设的方方面面:包括承载应用运行时的集群建设,多集群管理平台的架构,PaaS服务的建设,DevOps应用全生命周期管理,以及为标准化与大规模推广服务的规范指引的建设。每个部分都有详细的设计与介绍,为企业建设一站式业务支撑平台提供了一个好的参考。
1建设背景
随着互联网的兴起,互联网企业依托互联网,特别是移动互联网为公众提供越来越多方便快捷、稳定高效的服务,对传统业务带来了很大冲击。作为应对,传统行业也在业务上不断创新,带来对IT基础设施和应用架构方面进行转型升级的要求。例如为了支撑电商促销活动对带来的高峰期海量支付请求,某银行很早就对支付渠道相关业务应用进行微服务架构改造,由此带来了容器技术的研究和运用。经多年实践证明,采用容器技术平台很好地支撑了新的业务模式和业务容量。
基于业务发展的需要,和快速进步的金融科技技术,越来越多的传统企业开始思考自身的互联网战略、上云规划等。其中重要内容之一,是希望从技术层面更有效地支持业务创新,如微服务架构、更好的灵活性、扩展性、高可用性、更高效的业务上线效率等,因此跟上云计算技术发展的趋势,建设并推广适合自身的基于容器技术的云平台是关键任务。
2需求分析
2.1业务需求
2.1.1应用架构改造需求
某银行的客户交互渠道系统存在以下两点架构问题,制约了其快速迭代,影响了用户体验:第一,竖井式系统架构,各模块各自开发和管理基础功能,存在大量重复开发工作;第二,非分布式架构,横向扩展效率低。
为了缩短系统的迭代周期,增强横向扩展能力,该渠道需要运用DDD思想,重构一套使用微服务架构的新系统。本文设计了一套基于容器的一站式业务支撑平台解决方案,用于部署该渠道系统的微服务版本。
2.1.2应用架构概要设计
基于微服务架构的新系统,将服务端在逻辑上分为业务域和通用服务域,业务域是面向客户的交互界面,主要功能是整合微服务向前端提供统一的交互视图;通用服务域是从各业务领域提炼出来的通用服务的集合,与业务域解耦,只提供单一的服务输出即原子服务,业务域可整合不同的通用域服务单元完成相应的业务逻辑处理,同时通用域还包含与业务无关的后台处理模块。
图1业务设计示意图
2.2建设企业级容器平台
容器平台作为企业的新一代IT基础设施,不仅需要为基于微服务架构的新业务提供容器化运行和管控平台之外,还必须非常重视安全需求。因此建设容器平台的需求时,需要考虑包括的方面有:
◎管理大规模容器集群能力,包括:提供容器所需的高可用集群、资源池管理、网络通信方案、存储方案、编排调度引擎、微服务运行框架、镜像管理、事件告警、集群监控和日志收集等。
◎为满足安全要求,平台需要考虑应用的高可用性和业务连续性、多租户安全隔离、不同等级业务隔离、防火墙策略、安全漏洞扫描、镜像安全、后台运维的4A纳管、审计日志;如果容器平台还对公网提供访问,那么还需要考虑访问链路加密、安全证书等。
另外,一个重要方面是,容器平台通常是企业IT整个复杂系统中的一部分,因此容器平台还要遵从企业
已有IT技术规范和运维要求,例如可能还需要考虑:
◎支持企业自身的应用发布体系、持续集成系统、应用建模规范、高可用管理策略。
◎对接云计算底层资源池(例如IaaS),遵从云计算资源的统一管理和分配。
◎对接或改造容器平台的网络,以满足容器平台中应用与传统虚拟机、物理机中旧业务系统的相互通信,避免或尽可能减少对企业现有网络管理模式的冲击。
◎对接统一身份验证、和整个金融云其它系统采用统一的租户定义、角色定义、资源配额定义等。
◎对接漏洞扫描、集中监控系统、日志分析系统等已有周边系统。
2.3基于容器平台构建DevOps体系
业务市场竞争加剧,业务部门要求业务快速交付,业务系统就要充分复用其它业务应用系统服务:
◎作为业务部门,综合着眼关注业务进度,不关注需求之外的其它交付内容。
◎作为开发部门,期待资源得倒满足,需求明确,交付内容清晰,项目计划到位,资源充足,时间充裕;如何以更有效的方法进行需求调研,更好的架构进行开发,更有效率的测试策略及项目管理方式。
◎云资源交付部门,期待资源容量评估、架构评估、交付内容完整、时间宽裕、安全合规。
◎安全部门,所有各个阶段严格按照网络规范实施交付,并配以持续监测和更新到最新安全机制。
◎运维部门,期待支撑所有交付均考虑运维体系完备性,基于主机和服务两个维度、不同对象目标的运维体系完备;所有运维数据均可以共享互访并使用。
关注在业务场景下,对于容器
文档评论(0)