关于后端:service-mesh演进过程

50次阅读

共计 809 个字符,预计需要花费 3 分钟才能阅读完成。

第一阶段:管制逻辑和业务逻辑耦合

此形式耦合重大,不得不在业务逻辑中退出网络管制逻辑代码

如下:

管制逻辑和业务逻辑齐全耦合在了一起,使得业务代码凌乱不堪,代码难以了解和保护

第二阶段:公共库

把管制逻辑全副集中在一起组成一个公共的工具包,这样就能够把网络管制逻辑和业务逻辑离开,保障业务逻辑的清晰和明确,这些公共库如 Spring Cloud 的 Netflix 组件。

公共库的益处:

  • 解耦
    业务代码和网络管制逻辑代码解耦
  • 打消反复
    不必每个微服务都编写网络控制代码

公共库的毛病:

  • 侵入性
    以 Spring Cloud/Dubbo 为代表的传统微服务框架,是以类库的模式存在,通过重用类库来实现性能和防止代码反复。但在以运行时操作系统过程的角度来看,这些类库还是浸透进了打包部署之后的业务应用程序,和业务利用程序运行在同一过程
  • 跨语言
    框架和类库是语言强相干的,当批改公共库时须要批改对应不同语言的版本,开发和保护老本太大

第三阶段:代理

公共库和业务代码不是部署在一起了,而是独自部署一个代理服务,由代理服务去蕴含网络管制逻辑,这样就齐全和利用解耦,如 Nginx、Apache 等 HTTP 反向代理。

然而这些 Proxy 的性能十分简陋,比方服务发现甚至是通过配置文件来实现。性能不够,然而思路和想法很有参考意义:客户端和服务器端应该隔离,局部性能下沉到中间层来实现申请转发。Proxy 模式的摸索为日后 Service Mesh 的呈现奠定了根底。

第四阶段:边车模式(sidecar)


什么是边车?
维基百科定义:一个单轮的工具附着在自行车上独特组成了一个三轮的交通工具


在业务旁边部署一个 Sidecar, 由这个 Sidecar 来解决所有的网络申请,解决实现之后再把申请转发给利用自身

第五阶段:Service Mesh

一个 pod 由应用程序和 Sidecar 组成


一个零碎由很多微服务组成,而每个微服务都随同这一个 Sidecar, 这些 Sidecar 组合起来一个网络就是 service mesh

正文完
 0