3.4.5　容器环境的计算架构

容器技术作为当下最热门的基础架构解决方案，已经广泛应用于各行各业。基于容器的编排调度引擎能够简化应用部署，实现健康检查和自修复、自动扩容缩容，具备天然的服务发现和负载均衡能力。对于业务上量前应用系统资源利用率不高的场景，它可以显著提高硬件资源利用率。

虽说有着虚拟化无法企及的优势，然而在现有架构下新增一套容器环境却并非易事。容器最适用于轻量级、无状态的微服务化应用系统。与服务总线的调用方式不同，容器也更适合分布式服务框架及Service Mesh等下一代微服务架构。这也表示在原有架构中增加容器环境，需要结合原有服务总线、微服务框架和现有服务网格架构，并且并非所有的应用都适用于容器环境。

如前文所述，容器环境适用于无状态、微服务化的应用系统，银行业容器架构变迁将长期处于混合架构模式，即核心业务的ESB总线架构与容器微服务架构的混合状态。ESB总线与容器微服务的混合架构中的基础能力服务包括核心系统、人行前置等不适用容器，其余外围应用包括网银类、互联网金融类、管理类等均可使用容器。基础能力系统与容器通过ESB总线交互，容器内部使用微服务架构。

在混合架构模式下，应用系统可粗分为以下几类。

▪ 传统产品化业务系统：传统高度产品化的业务系统经历多年的技术发展，技术难称先进，不过贵在成熟稳定，产品功能定型后基本也极少再做改动，多使用成熟的商业化组件支撑其运行。对于中小银行而言，这类业务系统改造的投入产出比过低，所以此类业务系统在此阶段下将保持现状。

▪ 前置系统：包括支付/超网前置系统、电票前置系统、联网核查前置系统、央行会计前置系统等，此类前置系统主要使用人民银行等配套系统，日常版本变更并不频繁，且资源占用不高，不建议进行容器化改造。

▪ 公共服务：包括配置中心、注册中心、镜像仓库等公共服务组件，可以在后续阶段进行容器化改造。

▪ 互联网金融类应用系统：此类多采用分布式及微服务的应用系统可以逐步迁往容器架构，容器环境内部应用调用通过Dubbo等微服务架构实现，也可以通过Service Mesh、Istio等下一代微服务架构实现，达到服务发现、访问控制、服务治理等目的。对于容器环境与外部应用系统的相互调用，也可继续延用ESB服务总线。