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

云端服务当道，接连掀起了服务器虚拟化、容器化、微服务化的风潮，应用系统的开发、整合、测试、上线的速度有了迅速的提升，承载应用系统的平台发生量变与质变，在企业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