当前位置:主页 > 查看内容

不懂Istio架构原理,我被同事Diss了

发布时间:2021-07-15 00:00| 位朋友查看

简介:本文转载自微信公众号「石杉的架构笔记」,作者崔皓 。转载本文请联系石杉的架构笔记公众号。 开篇 在云环境下,技术栈可谓是多种多样,通过不同的技术生成不同的应用。如何能将这些异构的服务或者应用有机地串联起来,成为了服务治理的重大课题,在这样的大……

 

本文转载自微信公众号「石杉的架构笔记」,作者崔皓 。转载本文请联系石杉的架构笔记公众号

开篇

在云环境下,技术栈可谓是多种多样,通过不同的技术生成不同的应用。如何能将这些异构的服务或者应用有机地串联起来,成为了服务治理的重大课题,在这样的大背景下Istio架构为这样应用场景提供了服务治理的功能,Istio提供的流量治理、策略、遥测、访问安全等功能至今都被人津津乐道。

今天就围绕Istio架构的实现原理为大家介绍如下内容:

  • 为什么选择Istio
  • 什么是Istio
  • Istio架构原理
  • Istio服务治理功能介绍

为什么选择Istio

随着业务的复杂度提高,为了应对高并发、大流量,系统架构对服务/应用进行拆分。拆分以后的服务/应用可以进行分布式部署,来应对高并发带来的系统压力以及处理复杂的业务逻辑。

这样的做法会造成系统中存在大量独立的服务或者应用,它们分布在不同的进程、主机上面,在它们之间互相调用的时候就存在服务治理的问题。微服务就是一个典型的例子,微服务的开发和运维对程序员来说是一个挑战。

分而治之的思想使得业务本身的规模和复杂度不降反增。

在分布式系统中,网络可靠性、通信安全、网络时延、网络拓扑变化等都成了关注的焦点,同时服务注册、服务发现、负载均衡、服务间通讯、分布式调用链追踪都是要解决的问题。

为了解决这个问题,把服务治理部分抽象成公共库,让所有微服务都使用这个公共库。如图1所示,在Node 1 和 Node 2 上分别用Service 1 和Service 2两个服务,它们分别针对自己的业务逻辑都有对应的服务治理的SDK,通过这个SDK完成服务治理的服务发现、服务注册等功能。

 图1.将服务治理的逻辑抽象成公共库

如果将图1中的SDK包含到开发框架中(例如:Spring Cloud),当运用这种开发框架后就拥有服务治理的能力了。SDK的模式虽然解耦了业务逻辑和服务治理,由于在一个开发框架中,因此业务逻辑需要和 服务治理的SDK一起编译,发布以后业务逻辑和服务治理的代码在一个进程中运行。这会导致业务代码和 SDK 基于同一种语言,无法兼容其他语言开发的服务。同时,在服务治理升级时,需要升级整个服务,即使业务逻辑没有改变。如果说图1的模式,SDK和业务代码在同一进程,因此需要对其进行解耦,把服务治理从业务代码中剥离出来。如图2所示,红色的部分代替了原来的SDK,其使用了Sidecar模式。在这种形态下,业务逻辑和服务治理在独立的进程下运行。

图2.Sidecar解耦业务逻辑和服务治理

Sidecar的模式使两者代码和运行无耦合。如图3所示,业务逻辑就好像绿色的方块,再其右边的蓝色方块就是Istio提供的Sidecar(边车),也就是通过这个Sidecar与网络中其他服务的Sidecar进行链接,从而实现服务之间的通信。

这样业务逻辑可以使用不同的语言进行开发,升级也相互独立,而其他的服务治理的工作,例如:服务注册、服务发现、负载均衡、通讯等都由Sidecar来完成。

图3.Istio的Sidecar模式

这里通过业务逻辑与服务治理的角度,将使用Istio之前和之后的微服务做区分,从以下三个维度进行对比。

业务逻辑与服务治理
 
使用Istio之前
使用Istio之后
运行进程
两者在同一进程内
两者在不同的进程
技术栈
两者使用相同技术栈
两者使用不同技术栈
服务升级
两者同时升级
两者分别升级


本文转载自网络,原文链接:https://mp.weixin.qq.com/s/VpHJK2VX3a7lcTfvJQo-tg
本站部分内容转载于网络,版权归原作者所有,转载之目的在于传播更多优秀技术内容,如有侵权请联系QQ/微信:153890879删除,谢谢!

推荐图文

  • 周排行
  • 月排行
  • 总排行

随机推荐