在云原生技术加速金融企业数字化转型的过程中，为了不断提升企业私有云平台业务敏捷响应能力和服务效率以应对竞争激烈的市场环境，私有云平台业务系统混合部署是不容忽视的重要环节。从现阶段生产实践来看，不少企业仍习惯采用单业务系统单集群部署模式，这种类似虚拟机的“传统”部署方式虽然具有运维流程相对简便、集群生命周期较易管理的特点，但却存在集群资源利用率低、集群数量快速增长管控困难，环境配置难以一致、高可用和容灾能力受限等诸多潜在风险。
混合部署策略无疑是一剂缓解上述常见“症状”的良药，鉴于金融企业在数据管控、安全合规等方面的要求较高，在实施过程中势必存在重重困难，比如：按照何种维度划分业务共享集群；多个业务系统之间如何做到彼此有效的资源隔离和分配；不同系统之间的用户安全访问和权限控制设计原则；集中化日志的有效收集与存储。可靠实施混合部署策略能够大幅提升私有云平台基础资源利用率，避免硬件过度采购和闲置浪费，有效降低基础设施运营成本，为保障系统可靠性与业务连续性提供关键技术支撑。
twt 社区组织多位在金融行业生产环境有丰富业务系统混合部署经验的专家参与线上交流，聚焦设计原则、资源隔离与分配、安全访问、日志采集、配套服务建设等核心议题，对金融行业混合部署策略的重难点与解决方案进行深入探讨并进行全面总结，变挑战为机遇，助力更多的金融企业成功落地多业务系统混合部署策略。
主稿嘉宾：
nicolg 华夏银行 基础架构工程师
答疑嘉宾：
ljosef 某股份制银行 系统架构师
feng5371 某银行 云计算研发工程师
Steven 某金融企业 IT顾问精选会议研讨内容>>>
问题一、企业私有云容器集群上混合部署多套业务系统，需要依据什么设计原则？
1、基础设施的维度，开发测试与生产隔离、安全网络分区一般是不能突破的，容器集群的部署应避免跨传统网络区域的设计。除非有特定的场景下，具有配套安全制度的支持。针对商业全栈云的场景，需要考虑多租户模式带来的影响，企业内多租户与传统公有云多租户相差较大，产品设计上，容器集群的部署应避免跨越IaaS云租户的边界。2、故障域的纬度，应考虑容灾的因素，容器集群应支持跨机房的容灾架构部署，包括管理面及业务节点，通过容器集群的调度策略完成应用部署的支持。特殊场景下，采用独立机房独立集群的模式，这种设计下，需要设计跨集群的应用调度能力，隔离应用多机房部署的复杂度。3、集群规模的维度，应尽可能支持集群节点的横向扩展规模，降低单一节点故障的影响。支持容器应用在多节点反亲和运行。4、应用运行级别的考虑，应尽可能将在离线业务、相同等级的业务运行在同一集群内。在测试网络区中，建议一般不需要再区分灾备/等保级别，尽量减少云集群的数量，尽量多发挥单个集群的资源纳管能力，便于管理和资源充分共享，提高资源利用率。同时，可以区分业务系统类型，比如核心系统和非核心系统。在生产网络区中，建议根据灾备/等保级别进行网络区域划分，并在每个网络区域中建立单独的云集群。由于业务系统类型也是评估灾备/等保级别的因素之一，因此可以不单独考虑业务系统类型。比如内部管理类系统，一般等保级别较低，而面客类交易系统等保级别较高。如果技术能力允许，也可以一云多芯，将多种芯片架构的服务器纳管到同一个集群中。云首先有租户的概念，通过租户可以隔离不同系统、组织、环境等。从云的视角，云是一个大的网络，企业私有云部署面临的一个问题就是私有容器云网络和传统安全域网路之间的矛盾和冲突。在合规等要求下，可能需要在多个安全域部署容器集群，现实上集群之间是隔离的。系统部署如果有高可用、灾备等要求，需要考虑多集群、多数据中心的部署方案，私有容器云集群的部署也需要考虑跨数据中心的问题。通常是基于实际的业务系统需求和合规、安全等要求来确定部署方案。一个容器集群可以部署多套系统，或者一套系统的多个环境（开发、测试、UAT等），也可以多套系统的多个环境，基于集群的资源多少和部署、合规、安全等需求来决定。容器私有云实际应用中，往往随着应用的深入会调整前期的方案，因为每种方案都是只解决一部分问题，需要不断的实践、总结和优化。
问题二、多套业务系统在同一集群中混合部署，如何做到有效的资源隔离和资源分配？
在多个业务系统同时运行于同一集群的情况下，需要采取一些措施来实现有效的资源隔离和资源分配。其中一种常见的方法是使用容器化技术，例如Docker或Kubernetes等工具。通过将每个业务系统打包成独立的容器，并为其分配特定的CPU、内存和存储资源，可以确保各个系统之间不会相互干扰，从而实现有效的资源隔离。此外，还可以利用Kubernetes等容器编排平台来动态地调整各个系统的资源分配，以满足不同的负载需求。容器是利用了 Linux 内核的一些相关特性对容器做封装。因为容器都是运行在一个共享的 Host Kernel上，如果有一个容器进程被恶意程序攻击，就有可能造成容器逃逸，轻则会对当前的容器造成破坏，重则会对 Linux 内核造成崩溃，导致整个机器宕机，这在安全生产环境中往往是不能接受的。于是业内衍生出了安全容器的技术，也就是现在的 Kata 容器，Kata容器采用了多种安全机制，包括内核隔离、用户空间沙箱、网络隔离等，能够有效防止容器逃逸攻击和其他安全威胁。同时也有其他厂商的一些技术演进，比如红帽的BootC项目，通过可启动容器映像将Linux内核，initrd，引导装载程序等打包到容器镜像中实现将容器转换为虚拟机（VM）、USB 启动盘或 RAW 镜像。除了容器化技术外，还可以采用虚拟化技术，例如VMware或VKM等工具，来实现更细粒度的资源隔离和分配。在这种情况下，每个业务系统会被虚拟机上的操作系统所承载，而虚拟机则会为其分配隔离的硬件资源，例如CPU、内存和磁盘空间等。无论采用哪种技术，都需要在设计和配置阶段就考虑到资源隔离和分配的问题，以确保整个系统的稳定性和可靠性。同时，在实际运营过程中也需要定期监控各个系统的资源使用情况，以及及时调整资源配置，以保证系统的最佳性能。同一容器云平台上部署的多套业务系统，一般是共享集群资源池中的资源，也应充分共享。特殊情况下可独占计算节点，比如GPU服务器。为了确保有效的资源隔离和资源分配，应为每套业务系统设置资源配额，并每个pod的request须小于limit，也可设置request与limit的默认比例，如20%。当配额用满，应有资源扩容流程，让业务系统运维方可申请扩容。同时，需对业务系统的资源使用情况进行统计，可作为资源申请审批的判断依据。也可以为容器云配套资源的自动弹性伸缩能力，结合对业务系统交易量、资源使用率等多种指标，设定好规则，对分配业务系统的资源进行自动调节，可进一步减轻运维压力，发挥更大资源效能。kubernetes提供了命名空间、资源配额等对象来实现资源隔离和分配。资源隔离有多个层次，首先是租户的资源隔离、集群的资源隔离、命名空间的资源隔离、服务的资源隔离等。Kubernetes中资源配额ResourceQuota和限制LimitRange的机制 直接使用这些机制就好了。企业如果要使用k8s，可以考虑商业的方案，能比较快的搭建环境，快速上手，比较容易有效管理资源、应用系统和有效隔离和配额管理等。
问题三、多套业务系统在同一集群中混合部署，在安全访问策略、控制权限方面如何进行合理规划设计？
应用系统间通过namespace进行隔离，同一集群内的同一业务系统，服务间互访可不出集群，可通过service名直接访问。系统间或集群间服务互访则通过对方系统的域名进行访问。对于业务系统间互访，建议还是要多从应用系统架构层面进行设计和控制，比如从管理上制定原则，并建立第三方管理系统，通过接口的注册和订阅实现互联的授权和管理。技术上，可在消费方嵌入互联组件负责与授权中心通讯获取服务方接口的访问授权，在服务方进行令牌校验和审计记录，以实现服务的安全访问。应围绕namespace进行划分，通常情况下，可以有如下参考：1、在namesapce的权限管理上，使用k8s原生的rbac能力2、管理平台对k8s apiserver的调用可以使用高权admin。3、共享集群下，k8s租户内对k8s资源的访问，应使用namespace级别的资源权限。5、管理平台对于系统应用开发及运维人员应建立二级安全访问及控制权限，并基于行内已有的模型完成鉴权，鉴权后可获得系统对应k8s namesapce的操作权限。6、管理平台应具备访问控制拦截、操作审计记录及防篡改的能力。出于安全考虑，一个容器集群通常是不跨网络安全域的。在同一个网络安全域内，集群内部默认东西向不设置访问控制。如果有特别的安全需求需要做东西向的网络访问控制，可以考虑使用网络微格离技术，目前已经有相关的成熟商业产品。南北向防护方面，也可以使用微格离，实现细粒度的隔离能力。控制权限方面，需要按照namespace粒度做权限的明细控制，利用k8s的RBAC机制，只让某个namespace的授权人员可以访问相应的namespace，可以针对不同角色设置不同的访问权限，如读写、只读，或者只是针对特定对象的操作。容器云同一集群内多系统部署，可以通过租户或namespace隔离，同一个租户内的服务可以相互访问，不同租户间服务可以限制访问。k8s服务的暴露方式有多种，例如clusterip， nodeport，ingress、externalip等。如果在一个集群内部，可以通过service访问，不过通常不用这种方式，因为这是k8s内部的机制。而用springcloud等框架通常有个注册发现中心，通过注册发现中心进行查找服务和访问调用服务。不过这里有个问题是，如果用三层容器网络，pod ip只能在同一个集群内访问，跨集群就不可达。也有公司通过额外组件打通了两个集群的三层overlay网络，目的是为了方便跨集群调用，不过我个人观点，其实是不建议的。同一集群内，通常不做过多认证等访问控制。不同系统之间的访问调用，往往需要经过服务网关，在网关上实现访问控制，可以配置访问策略，认证权限，流量控制，路由等规则。
问题四、不同业务系统在同一个集群中混部，势必产生大量日志，如何对日志进行有效区分收集和存储？
日志包括容器云平台组件的日志、应用日志、中间件日志、OS日志等。这些日志对于异常分析和定位都非常重要。若想有效区分，就要分类，根据实际需要进行划分。可以遵循一些建议，也可以根据实际确定。日志收集通常是把日志打印到标准输出（不要把日志写文件），filebeat等工具采集日志到es等平台存储、查询和分析等。应用日志很关键的一个问题是调用链路，这是需要提前定义好日志的格式、关联方式等。在查询和分析时能按调用链路进行展示（系统时间可能不同步，不能用时间排序）。es上本身也可以根据索引来区分不同的应用系统，关键在于各个业务系统打印日志的格式要规范统一起来。各个业务系统打印日志需要调用统一的中间件来做，不要各自为政。集中化日志收集的核心在于将分散在不同服务器、应用程序和服务中的日志数据汇总到一个集中存储系统中。这种做法不仅可以提升日志数据的可访问性和可用性，还能大大简化日志的管理和分析过程。集中化收集常使用的技术包括ELK（Elasticsearch、Logstash、Kibana）堆栈和Splunk等工具。
问题五、多业务系统混合部署的大集群，周边配套服务系统需要注意做好哪些功能点改造？
这个问题相对复杂，主要依赖行内已有的管控流程进行实现。不过IT经过多年发展后，烟囱式、高耦合往往是工具实现的常态。因此工具集成不可避免，与是否混合部署关联度不大。1、容器集群自身要做好高内聚的设计，容器集群（含节点）、k8s原生资源、k8s插件（含网络、存储、监控、日志、运行时）等需要有完整的生命周期管理。2、通过接口调用或者数据推送的方式，完成与现有告警体系、日志体系、CMDB数据的集成。3、面向行内统一的云管平台或者流程平台，通过提供标准化接口或者页面集成的方式，实现集成及一体化的行内用户体验。首先网络访问控制层面，可以支持按照namespace或者更细粒度的deployment做访问控制，通常需要网络具备微格离能力。其次对于混部集群，需要在宿主机kernel层面具备区分高优、低优线程并给与不同资源支持力度的能力，这个能力需要和k8s联动，为不同优先级的Pod设置不同的kernel层面资源调度优先级，这样做可以确保低优业务的突发负载不会影响高优的业务。另外最好是在kernel层面具备对节点上所有低优负载进行资源总量控制的能力，限制节点上所有低优Pod使用的CPU/内存/网络不超过某个阈值，避免占用过多资源影响高优业务。如果混部场景涉及大数据批量作业，还需要对大数据批量作业做改造，使其具备将作业调度到k8s集群的能力，同时具备弹性队列能力，支持在不同时间段设置不同的队列配额，避免在线业务高峰期进来太多大数据作业，对在线业务产生冲击。其它配套能力和独占节点的方式基本一致。云管平台、ITIL平台、CMDB平台 等这些其实关系不大。云管平台可以侧重提供基础设施资源服务，比如提供虚拟机自动申请创建等维护能力，从而实现资源弹性。容器云周边配套系统包括认证、权限、配置、注册发现、API网关、日志、监控告警、存储等。需要实现对接。比如这些配套系统是否能够实现同一的权限控制，也就是一套权限API。大部分企业也就做到单点登录，做不到同一的权限管控。因此，这些基础组件能够做好准备也使容器云落地是否顺利的重要方面。
本次活动聚焦于帮助金融企业加快落地私有云上业务系统混合部署的难点痛点问题，逐条深入分析，总结来看主要包括了业务系统混合部署设计维度，有效资源隔离与分配、用户安全访问及权限控制、日志监控中心建设、配套系统服务建设等5个关键问题：
1、业务系统混合部署设计原则
金融企业范围覆盖较广，包括银行、证券、保险、基金、期货、信托等，每个行业云平台建设标准和监管要求不同，企业应该结合自身业务需求和监管要求制定多系统共享容器集群的有效策略，有些通用设计原则可供借鉴参考：开发测试与生产环境、不同网络区域划分、业务系统类型、业务系统运行等级或灾备等级、容器集群规模及数量等维度，商业全栈云还应考虑多租户模式的维度，同时容器集群的部署应该避免跨越传统网络区域、IaaS层云租户的边界，当然部署策略不是一成不变的，随着混合部署应用的深入会调整前期方案，需要在实践中不断总结和优化。
2、有效的资源隔离与分配
充分利用kubernetes原生命名空间、资源配额（ResourceQuota）、资源限制（LimitRange）等技术，从租户、集群、命名空间、服务等多层次实现资源隔离，特殊需求如GPU应用可以考虑独占计算节点。实时监控分析各业务系统资源使用情况，为集群配置资源弹性伸缩能力，适当调整资源占比，确保多业务系统共享集群的安全稳定与可靠运行。
3、用户安全访问及权限控制
同一集群内多个业务系统需要通过租户、命名空间（namespace）、RBAC机制设置不同角色用户的对象访问权限，同一租户或者业务系统服务之间可以通过service等实现相互访问，不同租户、不同系统或集群间的服务往往需要限制访问。同一系统如果采用springcloud框架可以通过配置内部注册发现中心，通过接口注册和订阅实现查找、调用服务的授权和管理。不同系统之间服务互访，往往需要经过服务网关（Gateway），在网关上设置访问策略，认证权限等规则。
4、集中式日志中心建设
私有云平台日志包括容器组件、应用、中间件、OS等各类日志，需要做好有效区分，应用日志最好统一规范日志格式，便于集中管理和分析。建立集中化日志收集中心的意义在于将分散在不同服务器、应用程序和服务中的日志数据汇总到一个集中存储系统中，有利于提升日志数据的可访问性和可用性，简化日志的管理和分析过程。选择合适的日志收集工具Logstash、Filebeat、Fluentd实时收集各种来源的日志数据，经过初步的处理过滤通过网络传输到Elasticsearch、Splunk等集中存储系统，利用Kibana、grafana等流行的监控和分析工具实现日志数据个性化展示，同时做好日志的访问控制与数据加密，定期归档与清理工作。集中式日志中心涵盖日志采集、传输、存储、分析全链条工作，显著提高开发、运维人员的日志查询效率。
5、周边配套系统功能建设
首先容器集群自身做好高内聚的设计，容器集群内部各类资源对象实现完整生命周期管理。通过提供接口调用、数据推送方式或界面集成完成与单位现有云管平台、认证鉴权、注册发现、API网关、监控告警、ITIL平台、CMDB平台等有效对接，实现一体化集成的用户体验。周边配套系统最好能够实现统一的用户权限控制。
综上所述，在推进业务系统混合部署的过程中，金融企业需要紧紧围绕自身业务特点和科技水平，在成本、效率和技术复杂度等方面做出精准权衡。从顶层设计入手，兼顾传统基础设施特点统筹考虑单位业务域、网络域、安全域、故障域等多个维度，管控安全边界，合理规划多业务系统共享私有云容器集群资源的方式。在资源隔离与分配方面，通过私有云多租户模式以及kubernetes原生的命名空间、资源限制与配额等功能实现灵活精细化的资源隔离，确保多业务系统共享稳定可靠的容器集群，最大程度发挥资源能效；在访问策略和权限管控方面，大多可以借助用户多级权限控制模型，容器集群原生RBAC机制、微服务网关等技术实现集群内外部的流量访问限制；统一标准化容器集群的日志输出格式，同时定期针对各种业务系统日志做好分类标记、分级筛选、优化归档工作，利用云原生时代日志工具ELK、EFK、Splunk等构建可共享复用的集中式日志中心。上述诸多难点需要金融企业周密决策，灵活掌握方法策略，应用系统工程思想逐一攻克技术和管理方面难题，充分发挥混合部署技术在助力企业云原生数字化转型中的关键作用。
如有任何问题，可点击文末阅读原文，到社区原文下评论交流
觉得本文有用，请转发或点击“在看”，让更多同行看到
欢迎关注社区 "私有云" 技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。地址：http://www.talkwithtrend.com/Topic/4315
下载 twt 社区客户端 APP
![]()
![]()
长按识别二维码即可下载
或到应用商店搜索“twt”
![]()
*本公众号所发布内容仅代表作者观点，不代表社区立场
