构建基于 Spring Cloud 向 Service Mesh 框架迁移的解决方案及思路

2401_83915450

于 2024-04-22 05:55:18 发布

阅读量873

点赞数 26

本文链接：https://blog.csdn.net/2401_83915450/article/details/138055871

版权

本文探讨了从Spring Cloud向Service Mesh框架迁移的解决方案和思路。Service Mesh作为服务间通信的基础设施层，解决微服务治理问题，提供服务注册、路由、治理等功能，实现业务与通信层的解耦。文章介绍了Sidecar模式，强调了Service Mesh的无侵入、多语言支持等特点，并对比了不同Service Mesh框架。提出了在容器化改造、微服务平台搭建和应用迁移过程中的步骤和注意事项，旨在帮助开发者理解并实施数字化转型。

摘要由CSDN通过智能技术生成

实际上即便如此，它仍然有一些不足之处。

这些公共库 SDK 存在较为陡峭的学习成本，需要耗费开发人员一定的时间和人力与现有系统集成，甚至需要考虑修改现有代码进行整合。
这些公共库 SDK 一般都是通过特定语言实现，缺乏多语言的支持，在对现有系统整合时有一定的局限性。
公共库 SDK 的管理和维护依然需要耗费开发者的大量精力，并需专门人员来进行管理维护。

1.2.3 Sidecar 模式

有了上面公共库 SDK 的启发，加上跨语言问题、更新后的发布和维护等问题，人们发现更好的解决方案是把它作为一个代理，服务通过这个透明的代理完成所有流量的控制。

这就是典型的 Sidecar 代理模式，也被翻译为边车代理，它作为与其他服务通信的桥梁，为服务提供额外的网络特性，并与服务独立部署，对服务零侵入，更不会受限于服务的开发语言和技术栈，如下图所示。

以 Sidecar 模式进行通信代理，实现了基础实施层与业务逻辑的完全隔离，在部署、升级时带来了便利，做到了真正的基础设施层与业务逻辑层的彻底解耦。另一方面，Sidecar 可以更加快速地为应用服务提供更灵活的扩展，而不需要应用服务的大量改造。Sidecar 可以实现以下主要功能：

服务注册。 帮助服务注册到相应的服务注册中心，并对服务做相关的健康检查。
服务路由。 当应用服务调用其它服务时，Sidecar 可以帮助从服务发现中找到相应的服务地址，完成服务路由功能。
服务治理。 Sidecar 可以完全拦截服务进出的流量，并对其进行相应的调用链跟踪、熔断、降级、日志监控等操作，将服务治理功能集中在 Sidecar 中实现。
集中管控。 整个微服务架构体系下的所有服务完全可以通过 Sidecar 来进行集中管控，完成对服务的流控、下线等。

于是，应用服务终于可以做到跨语言开发、并更专注于业务逻辑的开发。

1.2.4 Service Mesh

把 Sidecar 模式充分应用于一个庞大的微服务架构系统，为每个应用服务配套部署一个 Sidecar 代理，完成服务间复杂的通信，最终就会得到一个如下所示的网络拓扑结构，这就是 Service Mesh，又称之为“服务网格“。

至此，迎来了新一代微服务架构——Service Mesh，它彻底解决了传统微服务架构所面临的问题。

1.3 什么是 Service Mesh

在开始进入主题之前，我认为有必要再对 Service Mesh 进行统一的阐述，这样将有助于理解它，更加便于阅读接下来的内容。

1.3.1 Service Mesh 介绍

Service Mesh翻译为“服务网格”，作为服务间通信的基础设施层。轻量级高性能网络代理，提供安全的、快速的、可靠地服务间通讯，与实际应用部署一起，但对应用透明。应用作为服务的发起方，只需要用最简单的方式将请求发送给本地的服务网格代理，然后网格代理会进行后续的操作，如服务发现，负载均衡，最后将请求转发给目标服务。

**Service Mesh****目的是解决系统架构微服务化后的服务间通信和治理问题。**服务网格由Sidecar节点组成，这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦。具体到微服务架构中，即给每一个微服务实例同步部署一个Sidecar。