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

《企业基于集中交换模式的信息系统服务网格化实践.docx》由会员分享，可在线阅读，更多相关《企业基于集中交换模式的信息系统服务网格化实践.docx（5页珍藏版）》请在第一文库网上搜索。

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

2、势。由传统的集中交换模式向分布式点对点交换模式转变，体系上发生了巨大的变化，同时也面临巨大的调整和风险。本文将结合某企业级分布式服务平台项目实践，提出一套适合传统企业的信息系统服务网格化转型实施路径。二、服务网格技术介绍近年来，以SpringC1oudDubboServiceMesh服务网格为代表的微服务框架成为业界主流。SpringC1oud、Dubbo等微服务框架为Java强绑定，基于SDK模式需侵入到应用的业务逻辑代码当中。ServiceMesh服务网格则另辟蹊径，基于代理模式对服务进行管理，不入侵应用逻辑，不关注具体实现。企业级应用信息系统服务网格化过程中，集中交换式应用系统普遍面临以

3、下几个难点：1技术多样性：多种开发语言和技术框架并存：C+、Java等，无法采用某一种SDK实现多平台的服务集成;2 .集成复杂性：系统业务逻辑复杂，系统间多层关联依赖，采用SDK式模式会进一步增加应用代码复杂度；3 .基础能力共性化：避免各系统服务化改造涉及的服务注册发现、服务鉴权、服务流控、灰度发布、链路跟踪等基础服务能力重复建设。基于以上难点，我们选定ServiceMesh作为集中交换式系统进行服务化改造整合的技术基础。ServiceMesh是用于处理服务间通信的基础设施层，用于在原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，ServiceMesh是一组与应用一起部署，但对应用透

4、明的轻量级网络代理。ServiceMesh是通过独立的进程代理方式帮助应用程序建立稳定的通信机制，业务所有的流量都转发到ServiceMesh的代理服务中，同时ServiceMesh还承担了微服务框架所有的功能，包括服务注册、发现、负载均衡、限流熔断、鉴权、缓存等，除此之外，还承担了上报日志、监控的责任。服务网格小忌图（绿色表示服务，蓝色表示代理，由代理形成了一个服务之间通讯的网络）目前，业界主流的ServiceMesh相关的框架有两个，分别是Goog1e,IBM,1yft都参与其中的IStiO,以及Bouyant公司下的开源ServiceMesh框架1inkerd。其中IStiO由于众多大厂

5、商和大型社区的支持，应用更为广泛。三、分布式服务平台实践本项目通过引入基于服务网格技术的IStio实现构建分布式服务框架，同时增加服务治理中心、服务运营中心和服务交换网关，提供应用由集中交换模式到分布式服务架构转型的基础支持。整个分布式服务平台的逻辑架构如下：服务交换网关0M-IffiI史分析-s1w111t1-1）分布式服务框架分布式服务框架采用以IStiO框架为核心的ServiceMesh技术体系基础支撑（包括Envoy数据面、Pi1ot控制面和以Consu1为统一服务注册中心），实现服务的互联互通和运行期状态实时管理与监控。在应用节点上部署代理，这些代理跟应用之间没有技术上的强绑定，开发

6、人员只需按照原有的方式去开发，将服务暴露成HTTP协议，分布式服务代理基于流量劫持技术来完成服务鉴权、限流、路由等与业务无关的工作,这样就形成了一个网格的网络。分布式服务平台在日常运行过程当中只关心服务心跳的更新及一些控制信息的下发，应用将服务调用请求发送给代理，代理根据路由规则将请求发送给被调服务的某个实例，通讯实际上是由代理到代理之间直接发生的。2）服务治理中心服务治理中心为企业级服务治理的支撑工具，规范服务数据标准。推动制度规范建立、组织流程建设、管理流程优化。主要包括四部分的管理：1 .服务目录管理：支持服务的定义，服务间依赖关系等管理功能，提供多维度的服务检索视图。2 .元数据管理：

7、服务的接口管理及接口的合约管理。3 .服务生命周期管理：支持服务从定义，上线，变更，下线过程中的生命周期管理。4 .服务S1A管理：支持服务的S1A定义及审计等相关管理功能。3）服务运营中心服务运营中心用于服务鉴权、路由和限流的配置管理以及服务运行时监控。可以监控实时交易量请求成功率及实例状态的相关信息，通过调用链分析每一个环节在每一台服务上所消耗的时间，可以提高和优化现有的运维和应急处置能力。4）服务交换网关集中式交换向分布式交换转变必然是一个持久的过程，两个体系必然长期共生共存。在这个过程中，分布式交换体系下的服务必然会与集中交换体系下的系统存在关联，此时我们通过服务交换网关来完成两个体系

8、间的互联互通，通过在服务交换网关实现两个交换体系间的通讯协议和报文格式的转换。四、应用系统集成模式针对传统集中交换IT系统不同的架构模式、节点规模以及自身的改造规划，结合分布式服务平台部署灵活、无侵入性的特点，应用可选择以下三种服务网格集成方案：1）直接集成直接集成模式即将分布式代理直接安装到应用节点上。主要针对架构简单、服务成熟度高、服务的节点数小于4个的服务。2）应用网关集成应用网关集成模式即在应用部署的同时部署应用网关，在应用网关节点安装代理。应用网关作为对内部服务访问的统一出入口，可对内外部的通讯协议进行转换，屏蔽服务内部的复杂度。此集成模式主要针对结构复杂、服务成熟度不高、服务节点数

9、大于4个的情况。由于服务内部复杂或服务成熟度不高，后期可能会对服务进行拆分和调整，使用应用网关集成模式，对服务调用方的影响较小。3）服务交换网关集成服务交换网关集成模式，主要针对对集中交换模式依赖较重、暂时无法进行服务网格化的应用系统，通过服务交换网关与分布式服务平台内的系统进行交互。服务交换网关对接收的报文信息进行协议转换和报文格式转换，为分布式体系和集中交换体系充当中间媒介。五、平台应急处置方案分布式服务体系下点对点交换消除了集中交换不可避免的单点故障，天然具备高可用优势。但是分布式服务平台建设过程中引入了大量的新技术和新产品，这些技术和产品本身也在快速迭代和更新中，同时系统服务化后应用节

10、点几何级增长，对运维提出了更高的要求。平台集中服务注册管控和分布式通讯代理如果出现故隙，将对分布式体系安全运营造成影响，必须做好极端情况下的应急处置响应。一方面，平台设计上各组件均采用集群高可用部署，通讯代理启用本地缓存，在网络故障无法与平台通讯时仍然能保持服务访问通讯能力。另一方面，我们要求所有服务在集成接入时，虚拟机服务预留F5应急访问能力，容器云服务预留IngreSS应急访问能力，当服务代理出现故障甚至极端情况下整个分布式服务平台不可用时，通知各服务请求方切换到通过服务提供方的F5或IngreSS进行访问。对于同时接入集中交换体系和分布式服务体系的历史存量系统，当分布式服务体系出现故障时，原集中交换体系下继续对外提供服务的能力不受影响。六、总结及展望通过本次信息系统服务网格化实践，能够支持业务实现的多样性和敏捷性，做到对原有业务代码零入侵，在完成分布式服务集成的同时对业务功能无任何影响，终有可能成为企业级信息系统服务化的标准路径。