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

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

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

如下:

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

第二阶段:公共库

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

公共库的益处:

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

公共库的毛病:

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

第三阶段:代理

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

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

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


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


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

第五阶段:Service Mesh

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


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

本文由乐趣区整理发布,转载请注明出处,谢谢。

You may also like...

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据