本文以某农村商业银行敏态微服务建设为背景,探讨了敏态服务建设在农商行体系建设的难点与建设方案,提供了一条可落地的技术架构路线,旨在敏态微服务建设的路线上给大家提供下思路及建议,如有不足,希望大家能留言指出。
近年来,随着金融行业业务的快速发展,高并发、大流量的业务场景不断涌现,行内业务系统也面临着严峻的挑战。本人所在农商行(下文称本行)原有的基础架构、技术架构已无法有力支撑不断迭代与升级的互联网业务系统。如何跟随云原生的脚步实现敏捷化,并为应用提供有效的技术架构及底层平台支撑,显得尤为重要。
基于此背景,本行于 2020 年启动了敏态分布式研发运行平台的建设。基于微服务架构体系,通过容器云平台作为敏态转型应用运行的核心载体,建设一体化的敏态应用全生命支撑平台,从开发、运维、运行多个形态提供全方位的应用管理能力。
业务架构是业务与系统的纽带,可以帮助企业完成全面的数字化转型,使企业通过技术将内部、业务与 IT 深刻的连接起来,成为高效的数字化企业。而随着业务的发展壮大,业务系统与 IT 架构之间的边界已经日益模糊,急需通过技术手段来帮助科技人员理清两者的关系。
数字化转型的首要任务是依据云原生路线,建设微服务化体系,而微服务化的体系又依赖于微服务开发、运行观测的架构管理,基础设施、资源调度的云计算设施,以及统一发布、统一运维。因此 , 行内在仅有一部分微服务业务系统的情况下,就尽早启动了微服务化体系的建设。
建设时首先考虑微服务架构的选择、相关组件选的选型,并制定统一的开发、运维和运行规范,以便于微服务业务系统的统一管理;其次是资源维度,在原有的 IAAS 平台 能力上, 基于容器化技术建设 PAAS 平台,以提供应用服务的弹性伸缩能力,保障业务系统的高稳定性和高可用性;最后是行内大量的存量业务系统,在数字化转型的过渡期,做好存量业务的兼管,以及增量业务的快速接入,实现统一治理。
图:业务架构和 IT 架构的关系
目前行内已有部分业务系统采用微服务架构,架构使用情况多数是 SpringCloud ,但是版本有所不同,另外注册中心也有差异: Eureka 、 Nacos 等未统一,还涉及到其他的治理组件,如配置相关、监控相关、日志相关的组件,均未统一设计建设。
微服务的管理几乎没有专门的管理平台,全部是基于开源组件,很多没有管理页面,更莫论统一管理。另外,各类中间件分别建设也导致资源浪费严重、微服务优势不能体现,流量控制不能灵活配置生效,管理及其不便。
从运维、管理者的角度来看,之前的所有微服务系统,后台运行情况基本上都处于黑盒,既无法获知其运行状况,更难定位其运行故障,着实难以管理。尤其现在这部分微服务的系统,再次改造将面临极大的阻力,因此对于异构微服务的统一管理将较为困难。
行内之前一直采用 GXP 作为老一代的服务总线,伴随着业务系统增多,监控和治理能力渐感不支。此外,如何保障新老应用间的通讯,简化网络策略的运维管理,提高企业级网关的高可用,也成为必须要解决的难题。
目前行内存在多网络区域,并且有外联的业务需求,在建设微服务的同时还需要考虑存量业务之间的通信,尤其在与 GXP 的兼容和替代的过渡阶段,如何实现不同协议、不同报文的通信,如何实现跨网络区的调用,如何实现灵活的访问控制和流量控制,都将落实在 API 网关的建设中。包括微服务自身的 API 网关在内,多种类型,多种运用的网关的总体建设、统一管理将是部署架构和业务架构不得不考虑的问题。
目前,各家厂商都有自己的独特的网络方案,如何既满足行内本身业务架构体系的诉求,又满足业务人员的需求,是 我们需要解决的 主要痛点。
从运维管理角度,运维人员更倾向于采用二层网络模型:在主流的二层组网的数据中心中,受限于硬件能力、运维人员的能力和管理复杂度等需求,大部分运维人员不希望引入 BGP 等三层路由概念,希望采用大部分运维人员比较熟悉的二层网络方案。
从网络角度考虑, 业务通信需要 容器云内部网络与外部网络互联互通:业务应用往往会在容器云平台内外同时部署, 因此业务通信需要 平台内外网络能够直接打通, POD 与虚拟机 / 物理机同等地位,也更有利于与已有的云产品无缝整合。此外,还需要支持 Pod 固定 IP 地址:应用互访跨防火墙的等场景下,需要 POD 具备固定 IP 地址,避免 pod 重启后,运维人员频繁手动更新配置防火墙策略。还需要考虑管理网络和业务网络分离; IPV6 支持;高性能,低抖动;灵活的网络隔离:强安全性的硬件隔离和灵活的软件隔离等。
银行对系统运行的可靠性和安全性要求极高,因此在建设之初需要充分考虑各类因素:
基于以上背景,我行通过组织专门团队对微服务化和容器云建设进行了深入学习,对各类容器云和微服务产品进行深度分析,对行业内相关厂商产品、技术和服务能力进行了对比,最终选定在微服务和容器云建设方面具备成熟产品、先进技术和大量实践经验的本土厂商博云来提供转型建设方案。
基于以上背景,本行于去年启动了敏态分布式研发运行平台的建设。整个平台的建设范围如下图所示:
建设基于微服务架构和弹性容器云的敏态分布式研发运行管理平台,提供开发、运维、运行等多形态的应用全生命周期管理。项目整体包括弹性容器云平台、敏态分布式运行平台、敏态分布式开发平台三个部分。其中,弹性容器云平台作为敏态业务的运行底座,为敏态业务提供底层运行态的能力支撑。敏态开发平台提供了前后端的开发脚手架,辅助业务快速开发,快速上线,降本增效。敏态运行平台实现了应用的微服务治理,实现了微服务管理的统一,增强业务运行态的精细化运维能力。
在部署架构方面,是一地两中心设计,双活部署,两个数据中心上层有 F5 。两中心距离 20 公里,网络延迟 1-2ms 。主中心副中心(生产)环境集群,其中生产环境集群包含多个业务区域,如:业务一区(核心),业务二区(应用), OA 区(办公)功能区,外联 DMZ 区等。主、副中心的多个网络区域,网络侧需要策略才可互相访问,敏态平台整体部署 如下图所示:
由于目前行内很多系统的技术栈不同、产品定位不同、厂商利益不同,导致各套系统都只做了该套系统体系内的独立自治,因此基于原有组件架构是无法做到统一治理的。同时各套系统的自建设造成了资源浪费、难以运维的局面。
为了解决这个问题,实现服务治理平台化,本行设计了微服务架构与组件统一建设的方案。将微服务框架( SpringCloud )、注册中心( Nacos )、监控中心( SkyWalking 、 Prometheus )、配置中心( Apollo )统一建设。
微服务框架需要在开发阶段做好依赖和规范,本行为了做统一的治理,将所有的开发所需要依赖的框架、配置、日志、治理等 SDK 统一封装,在微服务研发时作为标准规范引入。另外现有的微服务系统,通过两种兼容方案,一种是做轻量的 SDK 替换改造,一种是在统一管理平台中兼容其版本和组件,实现异构微服务的管理。
建设全行级统一的注册中心,考虑行内存在多个网络区域,且有主中心、副中心的多活场景,需要建设高可用的注册中心,并在每个网络区域、每个主副中心均部署注册中心的节点,通过网络策略打通,以便于数据的同步。
在主中心和副中心的多个网络区域分别部署一套 skywalking 、 prometheus ,由于外网区域没有机器就没有 Prometheus ,只部署一套 skywalking 。每个网络区域都有监控采集节点,监控数据集中存储。
在主中心、副中心的每一个网络区域中都建设一套配置中心,其中配置中心的配置管理端在主中心的某一网络区域中,所有配置中心的数据都统一存储到该网络区域下的 MariaDB 中,同时,配置管理端的数据给到敏态微服务运行平台上。
敏态分布式研发运行平台的管理对象是各个应用系统,因此,设计一套方案实现微服务应用和非微服务系统的快速接入至关重要。
平台需要对接的业务系统可以分为两种类型:
①存量的异构系统,包括基于 GXP 的服务、单体的业务应用
②增量的微服务化的业务系统
针对这两种类型的业务系统,本行定制了统一的接入引擎( NSHSDK/NSHSideCar )。对于存量的未能改造的业务系统,采用 SideCar 的方式接入平台,对原有的代码无侵入性,采用这种边车代理的方式实现该类业务系统的快速接入。对于增量的微服务化业务系统,只需在研发阶段导入 SDK 工具包,后期只需正常进行编码、测试,即可完成业务系统的上线。
本行原有的消息总线为 GXP ,伴随着业务系统的增多,监控和治理能力渐感不支。同时, GXP 原有的单点部署的方式不具备高可用,急需拿出新的方案来完成 GXP 的替换。
我们将行内下一代网关分为三类,即微服务网关、内联网关和外联网关。所有类型网关都是具有替代 ESB 能力的企业级网关。微服务网关面向传统应用,内联网关面向微服务应用,外联网关面向外联专线 DMZ 区,放在不同位置则出现不同角色。我们采用这种分布式的网关来逐步替换原有的 GXP 系统,在不同的网络区域、不同的业务区域进行了建设。
同时,因存量系统架构不统一,通信协议不统一,导致增量的微服务系统与存量的系统通信出现障碍。因此, API 网关还需要实现协议的转换、报文的转换,以及编码格式的转换,以保证服务间畅通,这一点至关重要。
通过采用博云的 BeyondFabric 网络方案,将容器管理网与应用业务进行分离,业务网络与管理网都为实际物理层面的二层网络,可以让容器的 IP 直接对外提供访问。 BeyondFabric 完全满足 CNI 协议规范,结合社区提供的工具和 kubernetes job 等网络测试套件,我们对 BeyondFabric 进行了长时间的测试,测试结果证明 BeyondFabric 具备生产可用能力。
关于容器资源层的选择 ,在众多的容器云建设方案中,我们选择了目前最成熟、最普及的解决方案,即 docker+k8s 。
docker 容器技术有几大优势,首先是内核级的虚拟化,隔离性高,安全可靠,并且资源利用率更高。其次是 docker 打包镜像的方式是将应用及应用运行所需的依赖进行打包,使得镜像极其轻量,能够快速部署,快速启停,快速扩容缩容,天生具备开发运维一体化的特性。
K8s 是开源的容器编排调度引擎,用于容器的编排和自动部署,实现对容器批量调度,在谷歌内部经历了多年的平稳运行,并且拥有壮大的开源技术社区。但随着 k8s 与 docker 的解绑,后续的维护成本也是要考虑的痛点及难点之一。
为敏态应用提供完整闭环的能力支撑,从项目的创建管理 → 资源准备 → 依托开发框架快速研发 → 利用运维平台实现发布管理 → 利用运行平台对服务运行态进行监控治理 → 通过开放银行将业务能力提供给外部服务。为行内基于云原生的数字化转型奠定了基础,真正的迈出了数字化转型的第一步,解决了微服务建设难以下手、不明方向的问题,为行内敏态未来指明了方向。
分布式架构的学习需要较大的成本,博云提供的脚手架能力,规避了这个问题。在开发过程中,脚手架的使用让研发人员只关注业务代码的程序编写,提高了研发效率;在统一管理方面,脚手架对微服务架构的推广、微服务系统的接入,提供了标准和便利。
通过内联网关、外联网关、微服务网关的建设,保证了跨网络区域下,不同类型应用之间的通讯问题,解决了新型网关和传统 ESB 落地过程中的过渡与结合的问题。同时,微服务和 API 网关的治理功能,也解决了由于通信流量过大而引起的服务不可用、故障频发,保证了服务运行的健康问题。
架构的统一建设,减少了组件重复建设造成的资源浪费,减轻了运维人员的压力,有利于行级统一的微服务管理平台集中管理了不同网络区域下不同架构独立自治的微服务体系。
依据行内集中管理的监管要求,博云提供的统一管理平台建设,避免了多个管理平台切换跳转的复杂操作,以此降低了客户的管理成本。
本行的敏态分布式研发运行平台是基于云原生技术构建的完整闭环的 PaaS 层能力平台。本次主要分享了平台建设相关的实践经验,后期将从以下方面来持续完善和扩展平台能力。
最终利用敏态分布式研发运行平台,完成 PAAS 技术中台与业务场景深度融合,实现我行业务的数字化转型。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞7
添加新评论1 条评论
2022-10-01 21:12