最近在研究istio相关知识,正好做个知识梳理,从小白的角度学习istio,这篇的内容是关于Service Mesh的发展史,服务网格究竟是如何一步步发展起来的。
首先,我们先了解下什么是微服务
微服务(英语:Microservices)是一种软件架构风格,它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模组化的方式组合出复杂的大型应用程式,各功能区块使用与语言无关 (Language-Independent/Language agnostic)的API集相互通讯。 --来自维基百科
简单来说,就是将服务拆分为更细粒度的‘微服务’,各个服务之间功能更聚焦,且服务间使用语言无关的API进行通讯,比如RPC。
1、抽象的调用关系下图来表示:
2、实际的情况如下图所示,服务除了要做自己的功能外,还要负责流量控制的一部分‘额外’功能,但服务其实本身不应该关注,所以需要把流量控制这一块摘出去
3、网络层的功能摘出来,通过网络协议来解决,也就是TCP协议,来帮我们做了流量控制的功能
4、第一代微服务,随着技术发展,出现了分布式系统,随后出现了例如负载均衡、服务认证、网络授权等功能,这些也是服务所不关注的。
5、那下一步就是将这些功能抽象到框架,不需要每个服务自己管理。
6、但是框架管理仍然存在问题,引入额外的框架,引入了多余的复杂度、维护成本,排查问题比较困难,于是乎,第一代Service Mesh 出现了。
以Linkerd,Envoy,NginxMesh为代表的代理模式应运而生,通过代理模式,将流量全部接入进来,在Sidecar内部做比如流量限制、负载均衡等操作
7、但是使用后,仍然存在单机维护各自的服务网格,那我们还需要一层抽象,也就是现在的Service Mesh,通过一个控制平面来管理所有的sidecar,代表产品为Istio,关于每个组件的详解我们放到后面去一一讲述。
官方文档:序言 · Istio Handbook - Istio 服务网格进阶实战 by ServiceMesher(服务网格社区)
看完了发展史,个人总结一下几点:
一、为了保证服务的功能单一性,不要让服务关心它自身功能外的其他功能
二、抽象,将一些公共模块抽象出来,通过统一的框架、组件来维护
三、可扩展性、可维护性、出问题易于排查。
后续会逐步更新每个模块的详解。