网络营销是什么的具体应用,seo网络推广知识,广州的互联网公司,如何发布自己做的网页内容来自演讲#xff1a;曾祥龙 | DaoCloud | 解决方案架构师
摘要
本文探讨了金融企业在实施云原生体系时面临的挑战#xff0c;包括复杂性、安全、数据持久化、服务网格使用和高可用容灾架构等。针对网络管理复杂性#xff0c;文章提出了Spiderpool开源项目#xff0c;…
内容来自演讲曾祥龙 | 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
我们的解决方案还包括IPAMIP自动化管理功能。例如我们前面说通过软件自动化实现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等机构采用。
最终我们整理出了一张全面的技术架构图为企业内部实施大模型场景提供了参考。这张图涵盖了从底层云平台到上层大模型框架的所有支撑技术。
