流量突发增大,如何扛住压力,微服务实现弹性部署与标准化运维

云端服务当道,接连掀起了服务器虚拟化、容器化、微服务化的风潮,应用系统的开发、整合、测试、上线的速度有了迅速的提升,承载应用系统的平台发生量变与质变,在企业IT环境里的工作负载除了支撑日常关键应用系统的稳定运行,也面临更多极端的需求,例如持续时间不长、负载量却超高的应用服务越来越常出现,该如何应对这样挑战?

在iThome主办的Kubernetes Summit大会当中,今年就有两家台湾电信从业者谈到他们导入容器服务平台的经验,中华电信就是其中之一,他们目前是将这样的架构用在既有的预购系统上,而且创建平台是企业级软件──红帽的OpenShift Container Platform,不过即便如此,他们在系统搬迁过程中,仍经历了预期以外的状况,有意采用这类环境的企业,若能及早掌握可能影响搬迁操作的各种细节,应能减少出错机会。

先拿预购系统开刀,因其服务特性很适合移植到云端环境

身为成立时间最久的台湾电信企业,中华电信所经营的各种通讯、网络与加值服务,背后都由信息系统支撑,当中有许多都是十年以上的老旧系统,因此,他们近期开始思考把这些系统搬到云端服务的环境,而预购系统的搬迁就是率先进行的工程。

为什么是这套系统先行?中华电信信息处工程师黄昭文表示,传统预购系统最大问题就是瞬间的抢订压力,许多网站往往承受不住,为了解决问题,业界提出的作法是运用分布式架构,但同时也须面对一些问题,例如网络管理、多台设备管理、数据库系统负荷能力、储存管理,创建这些环境的成本也很高。

第二个考量是预购系统的另一个特性:使用时间很短。一般而言电信行业的预购系统,运行时间并不长,可能上线为期三天、一周,之后就会下架,若要创建专属环境,不敷成本效益。

这是一般电信行业预购系统的运行架构,在设计上,是以分布负载的方式来考量,希望能够妥善消化瞬间抢购的压力,但需要针对网络管理、设备管理、储存管理、高可用性的需求,来配置IT资源,搭建成本相当高,而且这类系统服务时间并不长,之后又需要撤下、回收,想要以更经济的方式快速扩展(缩回)应用系统规模,相当不容易。(图片来源/黄昭文)

这是中华电信创建的容器服务平台,他们采用的是Red Hat OpenShit Container Platform,在Kubernetes Summit大会上,他们首度揭露目前系统的架构。(图片来源/黄昭文)

历经容器化、解构,进入微服务

在系统搬迁的操作时程上,中华电信规画了下列3个阶段。

第一阶段:原貌搬迁

系统搬迁初期,他们对应用系统的调整幅度不大,优先考量服务正常运作。此时主要的工作,是将应用程序的执行环境从实体服务器、虚拟机器,搬到OpenShift。过程当中他们先把虚拟机器当中的应用程序放到Docker container,再将容器搬到OpenShift。以耗费时间而言,从VM转到Docker较短,从Docker到OpenShift较久。

关于这阶段的搬迁,黄昭文列出7大工作重点。首先是盘点程序行为,因为当应用程序改到OpenShift执行之后,开始会有一些横向扩充(Scale out)的活动,可能就会相互冲突;其次是参数需重新设计,若能用对参数、改变参数发送方式,对于K8s的操作比较友善。

第二阶段:系统解构

此时,中华电信开始执行预购系统的解构,提高逻辑的清晰度。相较之下,前一个阶段他们是把整个应用系统包进容器当中,但在这个阶段,则是开始进行合理拆解,导入微服务的概念,让系统上下游之间可通过RESTful API去串接,应用程序当中的不同部分可以横向扩充规模。同时他们也选用轻量的Web应用程序框架,例如Spring Boot来进行改写,而不再采用WebLogic这类应用程序服务器。

关于Kubernetes平台的使用上,黄昭文也特别提醒,要注意Pod的串接数量。他们发现串连路径越长,效能折损越大。所谓的Pod是指一群容器的代称,对于K8s环境而言,是最小的组件模型单位。

他也秀出效能测试的图表,当Pod串接到两个站点时,网络呼叫的效能就会瞬间降至低点。若要增加效率,他提出以下几个建议:我们可以在应用系统上游的呼叫端,导入共享连线(Connection Pool),或是运用异步作业的机制,也可以在应用系统下游的服务端采用高效能的应用程序框架。若需要非常高的效能,我们可以多个相关的容器封装在同一个Pod里面,如此可以大幅减轻网络流量的负担。

第三阶段:微服务、DevOps

在预购系统的搬迁进入最终阶段之际,中华电信期望可以跨入微服务、DevOps的应用。

在此之前,黄昭文呼吁企业应评估自身体质是否适合,确认应用系统架构的调整,究竟是想要还是必要。同时也要注意单位组织分工的变化,如果是横向切割,未来在DevOps的流程当中彼此合作会更为密切,在系统运维的惯性上,IT人员也要有心理准备,因为复杂度可能会提升。

在资料处理的结构与流程,这时也可能需要重新设计。例如,应用程序连接的数据库系统可能需要拆解,才能支持微服务的存取需求,而拆解之后的资料内容同步也需要注意。

事实上,这个阶段的目标更为宏观,希望达到独立开发、高效率部署、运维标准化的要求。黄昭文坦言,其实在中华电信内部有太多系统,每一套系统都有不同运维方式,对于经验传承、未来招募新人而言都是困难的地方,于是他们希望应用系统的开发与运维,从需求管理延伸到交付部署,都有一模一样的流程,对于企业而言,不论是成本或管理考量,都会比较简单、稳定。

 

掌握不同环境差异,可少走冤枉路

除了规画三大阶段,黄昭文也列出多项过程当中需注意的技术细节。首先是底层环境,有些商用软件的登录密码或授权,会捆绑处理器或服务器的型号,如果没有处理好系统搬移到另一个环境时可能无法启动。

软硬件的相依性上,由于部分软件授权有处理器核心数量授权限制,因此若搬迁到新环境,提供的处理器核心数量很多时,也可能无法启动系统。

系统软件本身也有一些相依性的议题,那就是与操作系统核心(Kernel)版本之间的捆绑。举例来说,若底层服务器的操作系统更新核心,应用系统可能就会受到影响而停摆。

在容器的部份,黄昭文建议,每个容器里面不要放置太多处理程序,否则当多个容器同时执行,可能会相互干扰。

接着要注意的部份,在于容器的执行权限,以及Kubernetes或OpenShift本身的环境变量,在配置上,应避免与其冲突,因为若发生这样的状况,原本自定的部份,将会被系统覆盖。

容器的Volume设定也要关照一下,当我们包好容器或采用他人的容器之后,请记得打开里面的组态,例如查看Dockerfile,确认储存Volume挂载的位置,以防出现信息遗漏的状况。

在Kubernetes的部份,我们要注意ConfigMap的唯读限制,有些应用程序需要修改设定时,若没有考虑到这个因素的影响,可能就无法启动。对于实体储存配置上,也要关注可用空间的多寡,因为若出现容量不足的状况,Kubernetes系统会停用Pod。

参考:https://www.ithome.com.tw/news/133297

K8S中文社区微信公众号

评论 抢沙发

登录后评论

立即登录