内容来自演讲：曾祥龙 | DaoCloud | 解决方案架构师
摘要
本文探讨了金融企业在实施云原生体系时面临的挑战，包括复杂性、安全、数据持久化、服务网格使用和高可用容灾架构等。针对网络管理复杂性，文章提出了Spiderpool开源项目，旨在优化传统网络方案，兼顾性能与自动化。此外，文章还提出了Egress解决方案，通过精确控制访问外部资源的权限来降低安全风险和提高网络管理效率。在安全方面，文章强调了安全左移的重要性，并在集成开发环境、测试阶段和软件发布过程中进行安全监测。为确保制品在跨环境流转中的安全性，文章提到了分布式镜像扫描和可信镜像安全分发的解决方案。
此外，文章还介绍了与明道云的合作，通过其零代码开发平台提升软件开发和部署的安全性。在存储解决方案上，文章提出需要提供主流的原生存储方案，并介绍了与华为合作的跨数据中心存储解决方案。文章还讨论了服务网格在金融行业的落地和利用Ray框架将传统业务转化为适合分布式计算的任务。最后总结了全面的技术架构图为大模型场景的实施提供参考。
一、金融企业网络的复杂性挑战
我们根据CNCF的调研报告列出了在金融行业客户中实施云原生体系时所遇到的一些挑战，并整理了其中排名靠前的几点，包括复杂性、安全、数据持久化、服务网格的使用，以及企业关注的高可用容灾架构等。
在金融行业的内部管理中，网络管理是最关键的部分。因此，复杂性的首要关注点就是网络管理。网络管理涉及到不同的基础设施和各种类型的应用。例如，交易类应用对延时非常敏感，需要实现极速型交易；银行和金融机构内部的网络管理非常严格，会划分不同的业务区域；此外，对防火墙的管控、跨集群或跨数据中心的网络管理要求也非常高。
1.传统的主流网络方案
为了解决这些网络复杂性问题，业内主流方案有两种：Underlay和Overlay。通俗来说，Underlay网络方式类似于我们目前使用的虚拟机管理方式，即由网络管理员手动分配IP地址给业务系统。这种管理方式虽然直观，但可能面临扩展性和灵活性的限制。且对人的要求比较高，后续的运维工作要就非常多。而Overlay网络方式则提供了一种自动化的网络管理模式，人工干预的时间非常少，但是对比Underlay的方式性能又差了一些。两种方式各有优劣。
因此，在金融行业中，这两种网络方案在实际应用中可能各有其特定的适用场景。例如，对于对延迟高度敏感的业务，如交易类应用，可能会选择采用更适合低延迟Underlay方案。而针对那些对自动化运维有较高要求，但对延迟敏感度不高的业务，完全自动化运维的网络方案则更为合适。
2.取长补短的Spiderpool网络方案
针对当前行业现状，我们做了一个开源项目。上面提到的两种网络方案，Overlay网络方案虽然是全自动化运维，但是比较简单，而Underlay的方式又太过于依赖人工，导致在网络管理方面存在诸多能力缺失，存在明显局限性。我们的开源项目目标在于克服这些挑战，优化现有性能良好但需人工管理的网络方案，通过运用开源方案将其增加自动化管理能力。例如，把IP冲突检测、IP地址自动分配以及IP地址池划分等功能整合到平台上。这样一来，我们弥补了传统网络方案中需要人工干预的短板，为未来的企业提供了更加高效和自动化的网络管理解决方案。
当然，我们的方案涵盖了一些非常实用的场景。例如，多个网络协同。一项业务可能需要一种特定的网络设置，而另一项金融业务可能需要另一种网络环境。在这种情况下，如何在银行内部的数据中心中实现多个网络的协同工作，进行统一的运维管理，保障网络间的连通性，就成为一个挑战。
- Spiderpool： 多个 Underlay CNI 协同形态
我们的网络解决方案提供了一种协同工作机制。通过这种方式，我们可以实现高效的网络管理效果。具体来说，就像在一个业务系统中插入多张网卡一样，我们可以为每个业务分配特定的网络资源。一张网卡用于连接内部管理网络，另一张网卡用于对接特定业务。通过这样的方式，能够将企业的多项业务利用同一网络技术体系进行统一联动和管理，从而实现网络资源的优化配置和高效运行。
- Spiderpool： 跨 CNI 的 IPAM
我们的解决方案还包括IPAM（IP自动化管理）功能。例如，我们前面说通过软件自动化实现IP地址的分配、冲突检测以及地址回收等任务，取代了以往需要人工干预的过程，极大地减轻了用户的运维压力。
在我们与浦发银行的合作某个项目中，他们起初采用的是Underlay网络模式。然而，随着业务系统的扩展，应用使用的IP数量超过了一万个，这导致他们的IP管理运维压力非常大。在这样的情况下，他们急需采用自动化工具来提升网络管理的效率。
- Spiderpool： Overlay CNI 与 多个 Underlay CNI 协同形态
在解决了IP自动化管理之后，我们还需要对网络流量进行管理。因此，我们的网络解决方案还包含了流量治理功能，比如说传统的网络监控抓取和数据分析能力，这些都是在云端环境中常用的方案。
二、Egress解决方案
在一个由10台服务器组成的集群中，如果只有一个特定业务需要连接外部数据库，按照传统方式，可能需要为10台服务器开启到该数据库的策略。然而，这种做法并不理想，因为并非所有的云上业务都需要访问该数据库。
为了解决这个问题，我们采用了Egress方案。通过这种方式，我们可以将所有需要访问数据库的应用用标签进行筛选，并将其指向一个特定的Egress IP。然后，我们只需要为这个Egress IP开放对数据库的策略，就能有效地进行管控。这样，我们就能够精确地控制访问外部资源的权限，降低安全风险，同时提高网络管理的效率和准确性。
三、kdoctor巡检
除此之外，我们在网络管理方面也开发了许多类似于巡检的工具。例如，我们使用像kdoctor这样的工具在集群上运行，以监控各个集群以及业务的网络连接状态。通过这种方式，我们可以有效地进行巡检，及时发现并解决问题。当出现任何问题，如业务响应变慢、联动延迟、访问缓慢或接口超时等情况时，这些工具能够进行有效检测，为我们的运维排障工作提供有力支持。
四、DevOps 落地金融企业带来的安全风险
作为一个 DevOps 团队，它的上线流程通常如下图所示从一开始开发团队提交代码到代码仓库，到最后部署交付到生产集群。各个环节都应有部署对应的安全监测能力，检查潜在的安全风险。下图中每个标记的位置上，都存在风险爆发的可能性。
1.安全左移
虽然前面提到的网络策略解决了部分安全性问题，但现在的主流方式是将安全措施向左移，即从事后防御转向事前预防。
传统的安全措施多为事后防御，例如在构建云环境后实施各类安全防护措施，当业务出现问题时进行排查和修复。然而，当前主流的新兴安全模式更倾向于预先做好防范工作，在开发应用或者写代码之前，就提前做好充分的安全预防措施。
这意味着在程序设计和编写阶段，我们就已经考虑到并实施了多种安全预防措施，以确保在问题发生之前就能够有效降低风险。这种提前布局的安全策略极大地降低了后续业务侧的安全管理压力，提高整体安全水平，减少潜在的安全隐患。
在集成开发环境（IDE）中，我们可以集成安全工具，确保代码编写阶段就考虑到安全性。在测试阶段，我们会进一步集成安全工具进行检测，确保软件的质量和安全性。
当软件打包成安装包后，我们会对安装包进行安全扫描和检测，以识别并消除潜在的安全隐患。在软件制品准备发布到运行环境时，我们还可以去做一些安全管控，包括扫描和检测，以验证这个全检是否能够发布到黄精，如果检测到有问题，可以随时阻断发布过程。
除此之外，在传统安全领域我们也已经覆盖，如部署安全。软件在环境中运行时，我们会持续监测其安全状况，发现问题时及时进行修复。
总的来说，我们的安全管理策略是从右向左逐步前移，从源头就开始把控安全质量。这样的做法能够最大限度地减少后期工作中可能出现的安全问题，从而极大地减轻后续的运维压力和风险。
2.为流水线设计的分布式镜像扫描
另外，考虑到制品可能涉及到跨环境的流转，例如从开发环境到测试环境，再到生产环境，甚至可能涉及跨数据中心和多个集群的场景，因此在安全方面我们需要考虑分布式安全的一些因素。这要求我们对整个流水线以及制品分发的路径进行安全设计，确保在各个环节都能保障安全性。
3.可信镜像安全分发
此外，对于可信镜像安全分发，例如Java应用所依赖的基础镜像，如JDK或Tomcat等，传统的做法是在公网中拉取标准镜像，然后开始部署应用。但现在，我们倾向于为所有内部应用制定一套安全规范标准。例如，对于所有的JDK的镜像，我们首先在内部制定好安全的镜像。然后，开发者可以基于这些安全镜像来开发应用，这样整个镜像的安全体系就能够得到有机的提升。在未来，如果底层软件进行代码升级或漏洞修复，我们只需要更新底部镜像。所有应用都将基于更新后的底部镜像通过流水线自动化打包，从而实现安全管理的高度自动化。
4.全流程镜像阻断
在这个过程中，有一些安全阻断流程。在整个制品和软件发布的过程中，无论哪个环节出现问题，我们都有能力及时对其进行阻断，确保最终发布到环境中的应用真正符合安全标准和内部客户的安全要求。
5.云原生安全实践参考框架
这里有一个安全实践的参考框架，涵盖了集群安全、软件开发交付安全、软件配置安全管理、运行节点安全、网络通信安全以及运行服务之间的安全等多个方面，从整体来考虑安全。
五、与明道云的联合解决方案
我们与明道云合作推出了企业级别的联合解决方案。先前我们提到的软件开发、业务开发以及部署开发中的诸多功能流程，在明道云的零代码开发平台中得到了整合。该平台本身内置了许多针对软件代码管理的安全机制，其软件产品本身就内嵌了安全设计。因此，基于明道云开发的应用最终发布到我们的底层云平台时，它们从一开始就原生具备了安全保障。
前面我们提到的，从软件开发设计阶段到软件测试阶段，再到软件发布的全流程安全体系。在这个过程中，当应用部署到实际的物理机或虚机环境时，我们的平台将进一步提升和强化安全能力，从而构建一个更为全面的安全体系。
其中，我们采用无代码的方式提升软件安全的交付流程，具有典型的优势。例如，无代码平台内嵌了安全标准，用户无需自行搭建。核心在底层，我们在云原生底层平台可以再做一层，进一步确保安全性。
目前，我们与明道云不仅在解决方案联合发布方面合作，还在汽车、金融和制造业等领域实现了落地案例。并且，双方产品的兼容性已经通过认证测试，可以预见，未来双方的合作将更加深入。
六、主流云原生存储解决方案
前期上线的绝大部分业务可能对数据存储的要求比较低，但随着业务的深入发展，对有状态数据或者说跟数据库强关联的业务都会搬到我们的平台上去。因此，我们需要提供一种主流的原生存储方案，以满足这些业务的数据存储需求。
这种存储方案是将各种底层存储技术，如分布式存储、块存储和文件存储等，有效地提供给上层业务系统使用。为此，我们做了一个统一接入的存储平台，预先对接了业内常见的各种存储系统，以实现无缝集成。对于应用来说，只需在应用代码中添加一条存储配置，就可以便捷地使用底层的各种存储。
我们考虑到许多用户目前是基于物理服务器搭建系统，而物理服务器本地磁盘的存储资源有很多会被浪费。为此，我们可以将物理服务器上本地磁盘的存储整合，构建一个存储池供用户使用，从而提高存储资源的利用率。
我们的平台还兼容特定高性能数据聚合场景的存储平台对接。例如，我们与华为合作提供了跨数据中心的存储解决方案。在这种方案中，我们的平台负责处理上层业务，而华为的存储系统则负责管理底层数据。
当业务出现故障需要迁移到另一个数据中心时，华为的存储系统会自动将数据同步到另一个数据中心，确保数据的实时性和完整性。这样，通过我们的平台和华为双活存储方案的无缝对接，我们可以实现整个业务的双活运行，极大地提高了业务的连续性和可靠性。这样一来，无论哪个数据中心发生问题，都能确保业务的正常运行和数据的安全性。
七、服务网格的金融行业落地
网格技术是当前服务治理领域中一种广泛应用的框架，对于微服务治理而言尤为关键。传统的微服务体系主要以Java体系为主，网格技术并不限制于特定的技术语言。无论是Python、Go，都可以借助网格治理体系实现统一的服务治理。
我们提供的这套方案具有以下特点：首先，支持跨集群服务治理，包括云上云下统一或内部多个数据集群的管理。其次，具备数据分析能力，通过一张图表可以清晰地展示正常业务访问流程。在未使用网格加速技术的情况下，业务访问过程中会涉及多个串行的通信环节，而采用网格加速技术后，能够大幅度缩短内部通信链路，提升网络效率。
特别是在金融行业的一些高性能或极速交易场景中，这种网络加速技术能够显著提高业务间访问的网络效率。此外，我们的网络加速方案不仅包括纯软件加速方式，还支持硬件级的加速技术。对于对网络延时要求敏感的业务，可以通过软硬件结合的方式进一步提升网络效率。
在可维护性方面我们也做了考虑，每次网络改动或升级都可能对业务造成影响，这样的网络架构肯定是不合理的。我们在设计整个网络方案时，采用了松耦合或解耦的架构方式。这样，当我们进行网络插件升级时，就不会对业务产生任何影响。
同时，为了方便用户将传统业务迁移到我们的网络加速的方案中，我们提供了一种便捷的工具。这套工具可以实现灵活和平滑的迁移过程，使得用户的业务系统能够通过这个过渡方案快速、无缝地从传统的模式升级到云原生的网格模式。
八、云原生时代业务连续性需求
现今，大多数企业在构建数字化架构时都会考虑跨数据中心的容灾或双活方案。这类架构需要考虑跨数据中心的容灾与，包括基础的数据备份和恢复，基于主从切换的跨集群灾备以及云原生时代的双活。这不仅要求上层业务具有灵活的架构，而且底层平台、数据以及数据库存储的全方位设计也必须考虑在内。
对于双活架构，我们将其分为多个层次：接入层、应用层、数据层以及存储层。在每个层次，我们都考虑了双活设计架构，以确保业务的稳定性和可靠性。
九、如何通过分布式架构对预模型进行调优
自从LLAMA大模型开源后，大模型领域出现了大量的开源项目，并在企业化落地方面取得了显著进展。然而，要将大模型应用到企业内部，关键在于如何将传统业务转变为适合分布式计算的任务。这里涉及一个关键技术——Ray框架，它是一个分布式计算框架，只需几行代码即可将内部的传统业务转化为分布式业务。分布式业务的优势在于能够进行并行计算，突破单台服务器在计算性能和存储方面的瓶颈。
在我们的解决方案中，我们特别增强了队列能力。当大模型运算任务到云原生环境中运行时，会做队列管理，使得模型计算变得更加便捷和高效。此外，大规模性能测试在分布式计算中至关重要。我们有一个开源项目，专门用于大规模计算的性能测试。这项技术同样被OpenAI等机构采用。
最终，我们整理出了一张全面的技术架构图，为企业内部实施大模型场景提供了参考。这张图涵盖了从底层云平台到上层大模型框架的所有支撑技术。
