APP下载

基于微服务的业务平台架构重构研究

2020-11-25韩丹

电子技术与软件工程 2020年18期
关键词:容器运维部署

韩丹

(中海油信息科技有限公司 北京市 100010)

微服务能够帮助各家企业合理解决诸多发展问题,这是因为微服务平台架构可以服务化地切分各种复杂的应用,从而使复杂问题被划分成若干既简单又小的问题。平台架构的服务间,其核心即业务,可以帮助企业建立健全自动化以及独立化的工作制度,最终使服务的集中管理得以被有效实现。

1 微服务概述

1.1 微服务架构

所谓微服务即具有自治性、协同性、高内聚性且较小一类的服务,按照业务边界可以对其边界加以明确。除此之外,微服务属于独立性较高的实体,能够于PaaS 上被独立部署。系统内各项服务的互相通信主要经由网络的合理调用来实现,这便会使服务隔离性被有效强化。

从整体上来看,微服务的平台架构能够划分单一的应用程序,使之被细分为若干小服务,并且确保各服务能够互相配合与协调。各服务能够在相应独立进程里落实,相互间的沟通主要会借助轻量级通信机制。构建各服务时,主要会以实际业务为中心,同时可以在相应环境中实现独立部署。与此同时,构建此类服务架构的时候,需要防止管理制度呈现集中化、统一化的特征,并且结合相关业务、有效工具与语言展开科学构建[1]。

1.2 微服务架构的应用优势

1.2.1 维护风险

单体架构相对复杂、规模较大﹐同时也有较大业务量,维护一方面极易影响总体,因此有较高风险。总体来看,若某项组件在微服务的平台架构中出现故障,并不会影响到其余进程,单项服务的故障能够被有效隔离,继而使维护风险下降。

1.2.2 系统的组件化

通常微服务被视作组件,然而其有别于传统组件的一点在于,其能够使系统实现组件化,将传统单一服务细分成若干小服务,且保证相互间互不干扰。微服务架构将系统以组件化的方式分解为多个服务,服务之间松耦合且独立,改变其中单一的功能时仅需对有关服务展开重构即可。

1.2.3 更丰富的技术

以往对服务平台进行开发时,常规构建方式即某一项特定技术对整体应用加以构建。而微服务业务平台架构的构建,主要会借助去中心化软件,继而确保各项服务能够结合市场发展规律以及自身实际需要展开合理判别,最后甄选出最合适的技术。

1.2.4 复杂性下降

经由将整体服务分解为若干小服务,能够确保平台有效管控服务的复杂性,防止数据孤岛的出现。若功能不发生改变,则会将整体应用细分成若干可控服务,以模块化形式呈现出服务功能,并且有效实现以往单体架构应用的形式无法实现的各项功能[2]。

2 基于微服务的业务平台发展现状

如今物联网技术水平越来越高,其发展势头极为迅猛。对于有关部门来说,怎样在网络当中提升平台市场竞争水平,和合作方展开有效合作,如何对市场实际需要予以相应快速的反应属于其应当着重思考的关键问题。当前的传统平台不具备多样化的能力,且平台并非为统一团队、厂商开发,因此无论从接口协议、技术类型还是开发语言等层面来看,各类软件间的差异性相对较大,而相应模块也基本属于紧耦合,此类架构难以有效展现出云的高效性、弹性以及经济性,其内部各平台许多功能有重合或者重复工作,与时代快速发展下高效运维以及高频发布等实际需求并不相符,急需革新。

3 平台架构的重构方向

3.1 应用层

确保资源能够可选和可视,同时能提供智慧化的服务,并且能够对业务平台的创新开发以及逻辑模式等予以高度关注,另外需要更少的研发人员,使平台能够更快上线与迭代更新,最终使营运研发的一体化得以实现。

3.2 资源层

确保资源层更为简洁化,使相应CPU 的利用率全面提升、超过50%,同时全面提高资源申请级别,使之自以往的分钟级最终提高到秒级,并且精细化资源管理,使其能够有效提供容器级别的资源,另外实现能够主动对资源进行主动分配。

3.3 能力层

使能力层更为开放、集约,保证基础平台能够基于当今最为主流的软件被有效构建,使通用类的服务得以被有效实现,并且最大化地集约组件,另外实现各平台间服务能够实现更为简洁、标准的共享[3]。

4 平台架构的重构思路

4.1 重构基础平台

以现有平台为基础展开全面改造与升级,将其扩展成网络化业务平台架构,并以Istio、Docker 以及Kubernetes 为基础开发全新的架构。所重构的基础平台包含了持续交付、管理容器、开放能力、自动运维以及治理服务等,实际重构过程中主要分阶段对各项功能按照既定规划展开建设:

(1)第一阶段:借助ETCD、Docker 以及Kubernetes 等对微服务的承载系统以及相应容器加以构建,管理容器功能能够确保容器可控、适用以及可视化;而治理服务功能能够时服务的注册、网关、负载与治理等得以实现;对于开发门户来说,可以使以往的资源申请转向全程管理发布应用;架构中间件将均衡负载、数据库、信息队列以及缓存等重要服务提供给开发方,此外用户标签、短信、通信以及定位等功能也将同时被提供给开发方;对于自动化运维服务来说,其基础容器指标与统一收集的系统等重点对流处理技术加以应用,可以实现动态汇集应用日志与平台信息,随后按照相应规则得到业务指标的相关数据信息,同时设计后置的驱动板块,使合理转换、配置指标执行、监控与判定得以实现。除此之外,基础平台将借助先进的大数据以及云技术来大幅提升运维精准度与效率,结合以往发展规律来预测指标,并且经由网关日志对服务画像展开研究。利用分析数据模块全面分析历史信息数据,进一步预测指标发展方向。另外,经由统计流量日志,对微服务相应网格服务的具体画像进行绘制,便于运维工作者详细掌控和分析平台服务的实际工作状况。

(2)第二阶段:将持续交付系统、Istio 架构以及分布式的追踪体系应用于架构当中,使微服务的系统建设得以完善,从而全程跟踪事物,实现局和分析容器、调用链以及业务应用等重要的资源日志;将机器学习法应用到平台当中,使故障报警、容器的智能扩缩以及重启服务等功能得以实现,继而使平台运维工作得以被全面加强。

4.2 重构业务平台

(1)微服务化所有功能:即经由剥离整体应用服务模块,借助微服务平台架构进行重构,并且容器化平台。同时,直接利用微服务来开发集成独立新平台或者新业务,使独立升级、替换微服务应用模块得以实现,最终落实持续部署与交付功能。

(2)去状态化:即所应用的程序只确保商业逻辑得以有效工作,让外部储存服务来保存数据信息,保证能够随时扩展应用。去状态化原本的系统,并且将其向容器中迁移,最终借助容器技术将弹性伸缩、资源隔离与限制等提供给应用系统。

(3)微服务化去除一些功能的模块:即剥离出个别业务模块,并且借助微服务平台架构对模块进行重构,同时容器化此架构。按照业务模块运维频次、模块的关键性及其和其余模块实际耦合度等确定是否要进行剥离操作。

4.3 资源有效分配

4.3.1 储存层面

结合机房实际状况,借助GlusterFS 将储存服务提供给架构,并将其装设到制定虚机的相应挂载磁盘当中,形成若干相应的服务节点。此配置的主要模式为哈希与复制的结合,且每个群组主要包含两台节点,使复制能够在相同群组里实现,而对于不同的群组而言,主要采用哈希运算,这样不仅可以借助分布式的文件使架构性能提高,还可以确保数据信息的安全性。除此之外,借助页面配置便能在启动服务的时候将GlusterFS 文件系统自动挂载于本地容器文件系统内部。在应用服务发生缩容、扩容或者故障转移的时候,储存模块会被挂载至目录当中,在后续使用的时候即类似对本地磁盘进行操作。

4.3.2 分配资源层面

重构时可以对业务平台的资源池展开全面划分,即将其细分成若干子区域。从本质上来看,新业务往往会对公共资源池加以应用,然而若有特殊需求,比如有较多单一资源的需求时,若想防止进一步干扰相同宿主机内各项服务应用,重构系统应按照不同资源需要、业务性质以及保障等级于基础资源池内部对子区域进行划分,使业务调度更加合理。

4.3.3 配置层面

将影响范围、隔离等因素运用到实施的初期,优先部署小型资源的少量单元,统一业务虚机节点相应原则,随后按照各虚机对应应用到工作的具体状况来升级资源配额,在此过程中应使单一的节点能够承载较多服务应用。

4.3.4 网络层面

在此层面,重构的平台应当默认根据业务服务来隔离网络,而在默认状况下,往往不允许各类服务访问彼此。除此之外,重构的平台允许操作人员对隔离规则进行单独设定。对于此平台的网络访问形式而言,应该囊括独立以及统一的负载。

4.3.5 应用层面

(1)对中小型的应用来说,允许其对平台相应统一负载的服务加以应用,当对外部的访问入口进行申请的时候,重构平台将随机三级域名配置给这些应用,另外应用也可以自行对域名进行申请,并且在指定的平台IP 上来绑定应用,当完成审核时,这些应用便能对相应域名进行使用,继而实现经由统一入口来访问这些应用。

(2)架构中往往存在一部分有较大网络流量的应用,而这部分应用能够对具有独立性的负载进行申请,与此同时,重构的平台还能够单独为应用创建相应的负载服务。

5 重构的效果

5.1 部署更加高效

因为重构的基础平台所用模式为容器结合微服务,这便能够确保将更多容器技术优势展示出来,尤其可以全面提升部署各项应用的整体效率。以镜像为基础来部署容器,其对应的仓库能够对容器的镜像展开有效储存与管理,能够对镜像文件展开集中储存。因此,在用户完成镜像的创建后,就能够借助push 命令向仓库上传文件,之后将此镜像应用于其余机器的时候,仅需自仓库当中将其pull 下就可以使秒级的部署得以被有效实现,重构的基础平台能够界面化此流程,仅需简单点击界面就能使部署软件的操作完成,这可以使部署软件的整体效率全面提升。例如某平台,该平台当中存在甲、乙、丙、丁等不同小区域,倘若根据以往人工对全部网元的单节点进行部署,部署每个小区通常都会花费约1 天的时间,该周期比较长;但是若能以容器镜像的自动化部署模式对上述分区进行重新部署,在通常情况下,每次增设1 个区域,仅仅需要半个小时便能完成部署工作。由此可见,全新的部署模式能够使此项工作的最终效率得以被大幅度提高[4]。

5.2 全面展开智能化运营

架构当中有时会存在偶发业务低谷或者业务峰值,内部的调度系统一般不会花费较长的时间便实现快速反应,从而使有效调度相应服务得以被顺利实现,并且可以均摊其中的压力负荷,继而确保节点负载更加稳定、合理,最终防止单节点存在过闲或者过忙的状况。在重构的基础平台与“大资源池”概念相结合。经由相应自动缩容、扩容的功能,可以使以往扩容模式被改良:当出现业务峰值的时候,平台结合相应配置自动进行扩容操作,而在峰值消失的时候平台会自动执行缩容操作,此时资源的利用率能够被有效提升。

5.3 利用资源更加合理

通过观察重构平台的资源占用可知,重构前后平台占用资源的状况有所改变,在重构之后,平台CPU 以及内存的利用率分别提高了约243%以及62%。经由集约建设平台服务与改良微服务,能够确保复用大部分组件,且不需要重复部署与构建,而在逐步扩大部署的规模之后,平台对资源的利用率将大幅度提高。

重构之前,平台虚机进行申请的时候若想确保业务峰值相应资源需要得到满足,往往会对固定的资源进行申请,如此便会出现许多的闲时浪费。重构之后,平台可以借助自动伸缩以及弹性调配等提前将诸多空闲的资源事先分配出来,以便防止出现难预测峰值。除此之外,平台可以借助科学调度来有效利用、分配集群资源。

6 结论

总体而言,经由重构基础与业务平台,合理配置相关资源等可知,笔者所提及的重构思路具有一定的可行性,能够将微服务优势充分展现出来。事实证明,通过重构平台架构,能够确保平台部署更加高效,使其智能化运维水平更高且使平台对资源的利用更加合理。

猜你喜欢

容器运维部署
Different Containers不同的容器
一种基于Kubernetes的Web应用部署与配置系统
晋城:安排部署 统防统治
部署
难以置信的事情
运维技术研发决策中ITSS运维成熟度模型应用初探
部署“萨德”意欲何为?
基于ITIL的运维管理创新实践浅析