案例分享：某保险客户的统一服务治理方案

背景

近年来，保险行业正经历着数字化转型的浪潮，这一转型主要是由金融科技的快速发展和日益增长的数据处理需求所驱动。核心变化在于从传统的集中式 IT 架构转向更灵活、高效的分布式架构。这种转型不仅有助于降低成本和提高系统的灵活性，还能应对越来越大的交易量和数据量。同时，随着数据保护法规的加强，保险公司越发重视 IT 系统的安全性和合规性，尤其在处理客户敏感数据方面。

分布式架构现在已经在许多互联网公司中得到广泛应用，并逐渐在保险行业中获得关注。随着这种架构的采用，保险公司面临着系统适配和技术升级的挑战。为了成功实施这种转型，统一服务治理变得至关重要。这需要一个能够在各种技术环境下运行的平台，以实现服务的有效管理和监控。这样的平台不仅能保证服务的安全和合规，还能支持业务的扩展和变化，确保系统的持续稳定运行。

应用场景

跨平台统一服务治理

在现代 IT 架构中，企业通常同时使用虚拟机和容器化技术来部署和管理应用。每种技术都有其优势和特定的使用场景，但同时也带来了治理上的挑战。这些不同的环境可能导致服务管理碎片化，难以实现统一的监控、安全性和合规性管理。

• 服务发现：在跨平台环境中，服务发现机制使得不同的服务（无论是在虚拟机还是容器中）可以相互识别和通信。这种动态的服务发现和注册功能对于确保服务间的高效互联至关重要。
• 身份识别和访问控制：统一的身份认证和访问控制机制对于确保只有授权用户和服务可以访问特定的微服务至关重要。这不仅涉及到用户身份验证，还包括服务间的相互认证。
• 数据收集能力：跨平台的统一数据收集和分析能力，使得组织可以从一个集中的位置监视和分析来自不同服务的数据。这对于优化性能、监控健康状况以及做出基于数据的决策至关重要。
• 安全管理能力：统一的安全管理能力确保了在所有平台和服务中一致地实施安全政策和标准。这涉及到加密通信、安全漏洞管理以及安全事件的响应。
• 审核授权能力：有效的审核和授权机制保证了企业能够遵守相关的合规要求，并对服务访问进行适当的控制和记录。

访问控制

• 组织粒度的服务访问控制：对不同组织（租户）内的服务访问进行精确控制，可以定义哪些组织可以访问本组织内的服务，从而保证服务间的安全边界。在多租户环境中实施有效的隔离和权限管理，确保数据和资源的隔离性，防止未经授权的数据访问或服务调用。
• 按照服务端点粒度的访问控制：对服务内各个端点进行更细粒度的访问控制，确保只有合适的服务能够访问特定功能。这种精细化的访问控制对于保护敏感端点、限制高风险操作以及实施严格的安全策略至关重要，尤其是在处理涉及敏感数据或关键业务逻辑的服务时。

图形用户界面

在复杂的服务治理环境中，如跨虚拟机和容器平台的环境，需要一个能够简化操作、提高效率且易于理解的用户界面。用户界面的设计应该使得非技术用户也能方便地管理和监控他们的服务，同时为技术专业人员提供必要的高级功能。

• 租户管理：允许用户创建和管理不同的租户，并管理租户间的访问。
• 审核授权：提供一个审计和授权机制，使管理员能够轻松管理用户访问权限，确保安全和合规性。
• 权限配置：允许用户灵活地配置权限设置，适应不同的业务需求和安全策略。
• 软负载配置：提供一个直观的界面来配置和管理软件负载均衡器，优化流量管理和系统性能。
• 统一存储管理：所有配置信息和管理数据统一存储于关系型数据库中，确保数据的一致性和安全。

案例

该客户致力于成为国内寿险业银保合作的第一品牌，专注于产品创新和服务创新，以满足客户的保险需求，并积极服务于和谐社会建设。自成立以来，该客户业务发展迅速，市场排名稳步提升，市场份额逐渐扩大，多次获得行业大奖，并在监管评价中被评为 A 类公司。

随着公司业务的增长以及数字化建设的发展，多种架构下的服务数量也在不断增长，为了维护生产系统的稳定性，各部门、业务线所管辖的服务有必要进行统一的治理，建立可控有序的服务治理能力。

面对客户的痛点和诉求，Flomesh 以其在软负载和服务网格方面的深厚经验，提供了一个理想的解决方案。Flomesh 的技术方案能够优雅地应对功能不一致、高改造成本、服务割裂和管理复杂性等问题。特别是在统一服务治理方面，Flomesh 的平台展现了卓越的灵活性和扩展性，不仅适应了客户不同的服务架构需求，还提供了可视化的治理工具，极大地简化了服务的监控和管理。

痛点

该客户目前采用的是一种混合型架构，涵盖了虚拟机平台和容器平台（使用 K8s 发行版 Openshift）两种不同的技术栈，并在这两个平台上维护着两套独立的 SpringCloud 微服务系统。这种双平台策略使得客户能够在保持现有业务稳定运行的同时，快速适应市场变化和技术进步，有效地平衡了创新和稳定性的需求。但这种混合性架构也带来了如下挑战：

• 功能不一致：环境中存在着有各种各样的服务和应用，它们是在不同时间、由不同团队开发，运行在不同的技术栈上。服务治理能力不统一，整体服务治理变得复杂和分散。
• 改造成本高：传统的微服务治理改造成本高，侵入大、高耦合，治理的实施和旧系统的迁移时间消耗大，提高了项目的总体成本。
• 服务割裂：当前环境中虚拟机服务和容器服务之间存在割裂，导致管理困难。
• 管理复杂性：随着服务数量的增长和云计算的推广，服务管理变得越来越复杂，尤其是在资源管控和变更频率方面。
• 缺乏直观的服务监控：缺乏一个平台来直观有效地了解整体服务、接口的调用状态，以及服务间的相互依赖关系。
• 服务间细化管理的需求：内部服务间的调用需要更进一步的细化管理，以提升效率和可控性。

诉求

• 统一服务治理：随着服务数量的增长，客户需要一个统一的平台来管理这些服务，确保它们在多种架构下的稳定运行。
• 服务架构适应性：平台需要能够支持公司内部不同的服务架构，包括虚拟机和容器服务。
• 服务治理可视化：随着云计算的推广和 IT 资源管理的复杂化，客户迫切需要可视化的服务治理能力。
• 增强组织和业务权限管理：需要提高对不同组织和业务权限的管理能力，以更好地控制和监管服务。
• 协同和低侵入性：客户希望平台能够支持多服务协同应用场景，同时对现有服务框架保持低侵入性。

目标

• 建设统一服务治理平台：建立一个能够统一管理各类服务的平台，以提升治理效率和系统稳定性。
• 确保平台性能和可扩展性：平台应具备优秀的性能，便于日常管理和功能升级，同时提供持续性保障。
• 生产系统稳定性：通过以上措施确保生产系统的稳定运行，减少运维风险。

技术方案

中心化配置和分布式软负载

整个架构分为控制平面和数据平面两个主要部分，实现了高效的网络流量管理和配置的动态更新。

控制平面负责配置的下发和管理，包括流量处理规则和控制策略等，同时收集数据平面的节点信息，并将这些配置持久化到关系型数据库（RDBMS）中。这不仅确保了配置信息的安全性，也提高了系统恢复的能力。

此外，控制平面还会与微服务注册中心建立连接，实时同步服务的注册信息并将其连同配置下发到数据平面，实现统一的纳管。

数据平面（sidecar 代理）则拦截和处理进出的应用流量，根据控制平面的指令执行相应动作，如路由和负载均衡，同时上报节点状态信息回控制平面以助于系统监控和优化。此外，产生的可观测数据（例如性能指标和日志）被发送到 NoSQL 存储系统，用于后续的数据分析和系统监控。整个架构的设计旨在提高网络流量管理的灵活性和效率，同时保证系统配置的一致性和整体网络的稳定性。

应用流量拦截

应用流量拦截是整个技术方案的核心，通过拦截应用的流量来实现服务的治理。

鉴于客户采用了虚拟机和容器化两个平台，并面临 OpenShift 版本太低和安全限制，传统的服务网格以及基于 iptables 的流量拦截机制，因为版本、安全策略和技术限制而不适用。因此在本方案中引入了一种更加灵活的 localhost 流量拦截机制。

图中，为了方便理解将 sidecar 代理从逻辑上分成了 eureka 代理、inbound 代理和 outbound 代理。

1. 通过环境变量修改服务的注册中心地址，将其配置为本地 sidecar 代理 http://localhost:8761/eureka。
2. sidecar 代理将服务的注册和发现请求转发注册中心。
3. sidecar 代理收到注册中心的服务发现响应后，为注册中心的每个服务分配回环地址（127.0.x.x，在 Linux 内核中这种 IP 会使用 loopback 网卡处理）并在本地维护回环地址与服务的映射；同时为服务维护一份端点的列表；服务实例的真实端口做一定的偏移，比如服务的监听端口为 8080，偏移之后的端口为 8090。8090 也是服务的 sidecar 代理监听的入站端口。
4. 服务获取到的是分配的回环地址，端口则是本地 sidecar 代理监听的出站端口。

可以理解为回环地址解决了出站流量的拦截，而端口偏移解决入站流量的拦截。

相比 iptables 的拦截方式，localhost 的拦截方式在用户空间完成，且方式更加灵活，无需特权权限安全性更高。同时服务的原生端口也仍暴露出来，毕竟迁移的过程中原生端口也还要继续对外服务。

注入 sidecar 代理

Sidecar 代理的注入可以通过两种方式实现：手动和自动。

手动注入适合于虚拟机环境，其中需要手动设置环境变量和控制平面地址，并启动代理进程，这允许细致的控制和定制。与 CICD 平台集成，实现虚拟机环境的自动化注入。

自动注入则适用于容器化环境，特别是在 Kubernetes 中，通过动态准入 webhook 实现自动化的代理注入，极大简化了部署和集成过程。这两种方式确保了 Sidecar 代理能够灵活适应不同的应用场景，同时高效处理服务的网络流量。

实践

服务迁移

在服务迁移过程中，通过精心设计的 Sidecar 代理注入和应用配置控制策略，可以实现对服务流量的灵活拦截和精准导向，从而使新迁移的服务顺利接入现有的网络架构。这种方法的关键在于，它允许服务的原生端口继续对外提供服务，同时处理那些尚未迁移的服务请求，确保服务的无缝运行和业务的连续性。

这种策略实现了平滑、细粒度且可控的服务迁移，确保迁移过程中不会对现有服务造成任何中断或影响。总的来说，这种方法提供了一种高效且低风险的服务迁移途径，特别适用于那些需要在不间断服务的前提下进行系统升级或迁移的场景。

收益

实施 Flomesh 方案后，客户显著提升了业务效率和系统稳定性，同时实现了成本效益的优化。主要收益包括：

• 成本节约：通过简化的微服务治理和自动化流程，客户显著降低了系统改造和维护的成本。Flomesh 方案的低侵入性和弹性扩展能力进一步减少了额外资源需求，为客户节省了显著的投资。
• 安全性和合规性提升：Flomesh 的高级身份管理和细粒度授权机制显著增强了系统的安全性，确保了敏感数据的保护。同时，详细的访问日志记录和有效的审核授权功能使客户能够轻松遵守严格的数据保护法规。
• 运维效率提高：客户通过 Flomesh 方案实现了服务的透明化接入和按需纳管，大大提高了运维效率。问题排查变得更加直观快捷，服务间调用关系的清晰展示减少了故障定位时间。
• 个性化需求满足：通过 sidecar 代理的自定义脚本，客户得以轻量化地满足特定的微服务治理需求，增强了业务的灵活性和市场响应速度。
• 自动化与 DevOps 整合：Flomesh 的自动化部署特性与客户的 DevOps 流程紧密结合，进一步降低了技术门槛，简化了操作流程，减轻了工作负担。

总结

面对从传统集中式架构到灵活、高效的分布式架构的转变，Flomesh 提供了一个跨平台的解决方案，有效管理虚拟机和容器化技术下的服务。还实现了服务的透明化接入和灵活的纳管，顺利完成了服务迁移，确保了系统的平滑过渡和稳定运行。最终，该方案为保险客户的持续发展和市场适应性提供了坚实的技术支持。