Service Mesh杂谈

Service Mesh是一种基础通信设施,它的出现时为了解决微服务之间复杂的通信问题。我们都知道,使用微服务思想去构建系统之后,会出现很多独立的微服务模块。模块之间的服务发现,负载均衡,失败重传等这些考虑因素,是每个模块都需要重复地去解决的,同时复杂性会随着模块数量增多而变大。

解决模块间通信问题之路

在计算机先驱引入了TCP/IP协议后,保证了链路层通信的可靠性。但是随着系统规模的扩大,引入了分布式,微服务这些概念,使一个系统的模块数量变得越来越多,模块间通信的可靠性就是个问题了,分布式通信需要解决下面几个问题:

  • 服务发现。怎么让一个模块感知到其它的模块,硬编码是最简单的方式,但显然不是最好的方式。

  • 负载均衡。一个模块有多台机器运行,怎么在多台机器上做负载均衡?除了手动做IP轮询,需要有更丰富的轮询方式。

  • 失败重传&熔断。当一个模块不可用时,需要能够重试,重试几次还不行就需要熔断机制来保证响应速度,避免请求堆积。

  • 流量监控。日志,请求监控,链路追踪。这些是一个工业级别系统必须具备的基本能力。

  • 流量控制。常见的有访问控制,频率限制,配额控制。

  • 模块鉴权。模块之间的鉴权,入口模块需要具备的能力。

另外分布式系统还有应用生命周期管理的需求(发布,灰度,回滚,扩容,缩容等),这是另外一个维度的事情,后续再另写文章讲述。

为了解决这些问题,业界已经做出了很多努力。下面使用三个阶段来划分。

阶段一,自建服务

自建分布式服务是分布式发展的初级阶段,最开始应该是出现在各大互联网公司。随着互联网的普及,请求的量级开始上来,单机无法承载庞大的请求量,萌芽出来分布式处理的需求。各个互联网公司开始自建一些处理分布式的组件,比如负载均衡,流量监控,日志收集等。

该阶段的特点:

  1. 各个公司基本是自研分布式组件,自给自足

  2. 没有系统性,都是些比较零散的组件

  3. 开源的比较少

这个阶段写出来的实用组件为后续开源的标准框架打下了基础。

阶段二,标准框架

随着各大互联网公司在分布式上的积累和实践,渐渐对分布式系统有了些系统性梳理,从而产生出了一些成熟的分布式框架,下面是几个主流的框架。

这个阶段出现的框架,基本具有如下特点:

  1. 不同程度上解决了分布式通信的问题,各有优劣。具体选择哪种框架建议去详细了解下它们的特点和评价。

  2. 业务实现语言受框架语言限制。框架都是基于某种语言实现,业务代码基本是跟着框架语言走的。

  3. 框架对业务代码有侵入性的。因为为了使用框架的某些特性,必须在业务代码中使用框架提供的通信API和其它特性。这种耦合对代码的复用是有影响的。

这些框架虽然一定程度上简化了解决分布式通信问题的难度,但是显然还是不够灵活,业务代码还是需要去关心如何解决分布式通信问题,无法做到只需要关注业务代码。

下一阶段将讲述目前的最新进展,也就是致力于如何使业务代码只用关心业务的实现,不用去关心分布式通信问题。

阶段三,将通信问题协议化

大家都知道,TCP/IP协议栈的出现,是为了屏蔽链路层和物理层通信的各种细节,为广大程序员们提供一个省心稳定的字节流通道。现在在TCP/IP协议通信的基础上,又出现了了新的问题,那就是分布式通信的各种问题考虑,前面已经罗列了大部分。大神们为了解决这个问题,想到的办法就是把分布式通信的实现作为一种基础通信设施,作为协议栈的一部分提供给广大程序猿们,这样大家就不用重复去考虑实现分布式通信了。这个想法就是Service Mesh(服务网格)。

当然Service Mesh目前的实现不是以协议栈的形式提供的,而是以sidecar(边车)的形式提供。sidecar的意思与我们小时候看到的三轮车很类似,就是主驾旁边的那个副驾。

smsh1561600056.jpg

下图是Service Mesh部署后的示意图,其中蓝色块就代表通信Proxy,通信Proxy就是实现了分布式通信,它作为sidecar与业务Service部署一起。业务Service之间的所有出入通信都会通过Proxy

service-mesh-from-linkerd-to-conduit-cloud-native-taiwan-meetup-18-638.jpg

目前最流行的两款Service Mesh开源软件是IstioLinkerd。其中Istio是由GoogleIBMLyft联合开发的,而LinkerdCNCF成员,两者都有深厚的背景,而目前IstioLinkerd用的还是相对广泛一些。

下面是Istio的架构图

istio-arch.png

其中Proxy还是以sidecar模式提供了可靠的分布式通信实现。其它模块实现了配置和策略检查等功能,后续再另写文章详细介绍。

结语

其实Service Mesh也不是什么高深的概念,说白了就是通过一个专门的agent来代理通信,让业务Service专注于实现业务逻辑,而agent就专注于实现可靠的分布式逻辑。本文通过讲解发展历史的方式来解释了这种思想。

另外文中还没讲到的是目前Service Mesh的应用,大部分都是云原生的,基于容器服务Kubernetes之上实现的。关于容器服务Kubernetes的讲解,可以去参考它的官网资料,或者关注我后期的相关文章。

版权声明:本文为原创文章,版权归 Roper所有,转载请注明出处!

本文链接:https://roperluo.cn/index.php/archives/16/

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,937评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,503评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,712评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,668评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,677评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,601评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,975评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,637评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,881评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,621评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,710评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,387评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,971评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,947评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,189评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,805评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,449评论 2 342

推荐阅读更多精彩内容