沉默的海
作者沉默的海2023-02-17 09:47
系统工程师, 某金融单位

企业基于集中交换模式的信息系统服务网格化实践

字数 3131阅读 5438评论 0赞 3

一、 背景

传统的企业信息系统体系多采用集中交换架构,它结构简单,部署方便,但故障容错能力及弹性扩展能力不足。随着业务的不断发展,用户增加,并发访问量和交易量呈爆发式增长,业务逐渐精细化拆分,业务需求更明确更专业,对业务需求的响应更敏捷,传统的集中式架构无法满足我们的业务发展,通过信息系统分布式服务化转型来快速响应需求已成为必然趋势。由传统的集中交换模式向分布式点对点交换模式转变,体系上发生了巨大的变化,同时也面临巨大的调整和风险。本文将结合某企业级分布式服务平台项目实践,提出一套适合传统企业的信息系统服务网格化转型实施路径。

二、 服务网格技术介绍

近年来,以 Spring Cloud 、 Dubble 、 Service Mesh 服务网格 为代表的微服务框架成为业界主流。 Spring Cloud 、 D ubble 等微服务框架 为 J ava 强绑定,基于 SDK 模式需侵入到应用的业务逻辑代码当中。 Service Mesh 服务网格则另辟蹊径,基于代理模式对服务进行管理,不入侵应用逻辑,不关注具体实现。

企业级应用信息系统服务网格化过程中, 集中交换式 应用系统普遍面临以下几个难点:

  1. 技术多样性:多种开发语言和技术框架并存: C++ 、 Java 等 ,无法采用某一种 SDK 实现多平台的服务集成
  2. 集成复杂性:系统业务逻辑复杂,系统间多层关联依赖,采用 SDK 式模式会进一步增加应用代码复杂度
  3. 基础能力共性化: 避免各系统服务化改造涉及的服务注册发现、 服务鉴权、服务流控、灰度发布、链路跟踪等基础服务能力重复建设

基于 以上难点,我们 选定 Service Mesh 作为 集中交换式系统进行服务化改造整合 的 技术 基础 。

Service Mesh 是用于处理服务间通信的基础设施层,用于在原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中, Service Mesh 是一组与应用一起部署,但对应用透明的轻量级网络代理。 Service Mesh 是通过独立的进程代理方式帮助应用程序建立稳定的通信机制,业务所有的流量都转发到 Service Mesh 的代理服务中,同时 Service Mesh 还承担了微服务框架所有的功能,包括服务注册、发现、负载均衡、限流熔断、鉴权、缓存等,除此之外,还承担了上报日志、监控的责任。


(绿色表示服务,蓝色表示代理,由代理形成了一个服务之间通讯的网络)

目前,业界主流的 Service Mesh 相关的框架有两个,分别是 Google , IBM , Lyft 都参与其中的 Istio ,以及 Bouyant 公司下的开源 Service Mesh 框架 Linkerd 。其中 Istio 由于众多大厂商和大型社区的支持,应用更为广泛。

三、 分布式服务平台实践

本项目通过引入基于服务网格技术的 Istio 实现构建分布式服务框架,同时增加服务治理中心、服务运营中心和服务交换网关 ,提供应用由集中交换模式到分布式服务架构转型的基础支持 。整个分布式服务平台的逻辑架构如下:

1 )分布式服务框架
分布式服务框架采用以 Istio 框架为核心的 ServiceMesh 技术体系基础支撑(包括 Envoy 数据面、 Pilot 控制面和以 Consul 为统一服务注册中心),实现服务的互联互通和运行期状态实时管理与监控。

在应用节点上部署代理,这些代理跟应用之间没有技术上的强绑定,开发人员只需按照原有的方式去开发,将服务暴露成 HTTP 协议,分布式服务代理基于流量劫持技术来完成 服务鉴权、限流、路由 等与业务无关的工作,这样就形成了一个网格的网络。分布式服务平台在日常运行过程当中只关心服务心跳的更新及一些控制信息的下发,应用将服务调用请求发送给代理,代理根据路由规则将请求发送给被调服务的某个实例,通讯实际上是由代理到代理之间直接发生的。

2 )服务治理中心
服务治理中心为企业级服务治理的支撑工具,规范服务数据标准。推动制度规范建立、组织流程建设、管理流程优化。主要包括四部分的管理:

  1. 服务目录管理: 支持服务 的 定义,服务 间 依赖关系等管理 功能 ,提供 多维度的 服务检索视图。
  2. 元数据管理: 服务的接口管理 及 接口 的 合约管理。
  3. 服务生命周期管理: 支持服务从定义,上线,变更,下线 过程中的生命 周期管理。
  4. 服务 SLA 管理: 支持服务的 SLA 定义 及 审计等 相关 管理功能。

3 )服务运营中心
服务 运营中心 用于服务鉴权、路由和限流的配置管理以及服务运行时监控。 可以监控实时交易量请求成功率及实例状态的相关信息,通过调用链分析每一个环节在每一台服务上所消耗的时间,可以提高和优化现有的运维和应急处置能力。

4 )服务交换网关
集中式交换向分布式交换转变必然是一个持久的过程,两个体系必然长期共生共存。 在 这个过程中 ,分布式 交换 体系下的服务必然会与 集中交换 体系 下的系统 存在关联,此时我们通过服务交换网关来完成两个体系间的互联互通,通过在 服务交换 网关 实现两个交换体系间的 通讯协议和报文格式的转换。

四、 应用系统集成模式

针对传统集中交换 IT 系统不同的架构模式、节点规模以及自身的改造规划,结合分布式服务平台部署灵活、无侵入性的特点, 应用 可选择以下三种 服务网格 集成方案:

1 )直接集成
直接集成模式即将 分布式 代理直接安装到应用节点上。主要针对架构简单、服务成熟度高、服务的节点数小于 4 个的服务。

2 )应用网关集成
应用网关集成模式即在应用部署的同时部署应用网关,在应用网关节点安装代理。应用网关作为对内部服务访问的统一出入口,可对内外部的通讯协议进行转换,屏蔽服务内部的复杂度。此集成模式主要针对结构复杂、服务成熟度不高、服务节点数大于 4 个的情况。由于服务内部复杂或服务成熟度不高,后期可能会对服务进行拆分和调整,使用应用网关集成模式,对服务调用方的影响较小。

3 )服务交换网关集成
服务交换网关集成模式,主要针对对集中交换模式依赖较重 、 暂时无法进行服务网格化的应用系统,通过服务交换网关与分布式服务平台内的系统进行交互。服务交换网关对接收的报文信息进行协议转换和报文格式转换,为分布式体系和集中交换体系充当中间媒介。

五、 平台应急处置方案

分布式服务体系下点对点交换消除了集中交换不可避免的单点故障, 天然具备高可用 优势。但是分布式服务 平台建设过程中引入了大量的新技术和新产品,这些技术和产品本身也在快速迭代和更新中,同时系统服务化后应用节点几何级增长,对运维提出了更高的要求。平台集中服务注册管控和分布式通讯代理如果出现故障,将对分布式体系安全运营造成影响,必须做好极端情况下的应急处置响应。一方面,平台设计上各组件均采用集群高可用部署,通讯代理启用本地缓存,在网络故障无法与平台通讯时仍然能保持服务访问通讯能力。另一方面,我们要求所有服务在集成接入时,虚拟机服务预留 F5 应急访问能力,容器云服务预留 In gress 应急访问能力,当服务代理出现故障甚至极端情况下整个分布式服务平台不可用时,通知各服务请求方切换到通过服务提供方的 F5 或 I ngress 进行访问。

对于同时接入集中交换体系和分布式服务体系的历史存量系统,当分布式服务体系出现故障时,原集中交换体系下继续对外提供服务的能力不受影响。

六、 总结及展望

通过本次信息系统服务网格化实践 , 能够支持业务实现的多样性 和敏捷性 ,做到对原有业务代码零入侵,在 完成分布式服务集成 的同时对业务功能无任何影响,终有可能成为企业级 信息系统服务化的 标准 路径 。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

3

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

作者其他文章

相关文章

相关问题

相关资料

X社区推广