ServiceMesh(服务网格) 概念在社区里头非常火,有人提出 2018 年是 ServiceMesh 年,还有人提出 ServiceMesh 是下一代的微服务架构基础。

那么到底什么是 ServiceMesh?它的诞生是为了解决什么问题?企业是否适合引入 ServiceMesh?

微服务架构的核心技术问题

在业务规模化和研发效能提升等因素的驱动下,从单块应用向微服务架构的转型 (如下图所示),已经成为很多企业 (尤其是互联网企业) 数字化转型的趋势。

在微服务模式下,企业内部服务少则几个到几十个,多则上百个,每个服务一般都以集群方式部署,这时自然产生两个问题 (如下图所示):

一、服务发现: 服务的消费方 (Consumer) 如何发现服务的提供方 (Provider)?

二、负载均衡: 服务的消费方如何以某种负载均衡策略访问集群中的服务提供方实例?

作为架构师,如果你理解了这两个问题,也就理解了微服务架构在技术上最核心问题。

三种服务发现模式

服务发现和负载均衡并不是新问题,业界其实已经探索和总结出一些常用的模式,这些模式的核心其实是代理 (Proxy,如下图所以),以及代理在架构中所处的位置。

在服务消费方和服务提供方之间增加一层代理,由代理负责服务发现和负载均衡功能,消费方通过代理间接访问目标服务。根据代理在架构上所处的位置不同,当前业界主要有三种不同的服务发现模式:

模式一:传统集中式代理

这是最简单和传统做法,在服务消费者和生产者之间,代理作为独立一层集中部署,由独立团队 (一般是运维或框架) 负责治理和运维。常用的集中式代理有硬件负载均衡器 (如 F5),或者软件负载均衡器 (如 Nginx),F5(4 层负载)+Nginx(7 层负载) 这种软硬结合两层代理也是业内常见做法,兼顾配置的灵活性 (Nginx 比 F5 易于配置)。

这种方式通常在 DNS 域名服务器的配合下实现服务发现,服务注册 (建立服务域名和 IP 地址之间的映射关系) 一般由运维人员在代理上手工配置,服务消费方仅依赖服务域名,这个域名指向代理,由代理解析目标地址并做负载均衡和调用。

国外知名电商网站 eBay,虽然体量巨大,但其内部的服务发现机制仍然是基于这种传统的集中代理模式,国内公司如携程,也是采用这种模式。

模式二:客户端嵌入式代理

这是很多互联网公司比较流行的一种做法,代理 (包括服务发现和负载均衡逻辑) 以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合,服务启动时自动注册到注册中心并定期报心跳,客户端代理则发现服务并做负载均衡。

Netflix 开源的 Eureka(注册中心)[附录 1] 和 Ribbon(客户端代理)[附录 2] 是这种模式的典型案例,国内阿里开源的 Dubbo 也是采用这种模式。

模式三:主机独立进程代理

这种做法是上面两种模式的一个折中,代理既不是独立集中部署,也不嵌入在客户应用程序中,而是作为独立进程部署在每一个主机上,一个主机上的多个消费者应用可以共用这个代理,实现服务发现和负载均衡,如下图所示。这个模式一般也需要独立的服务注册中心组件配合,作用同模式二。

阿里、微博、摩拜、唯品会等公司都在积极探索Service Mesh的架构模式,只是在实践中一般具备一定开发能力的公司都会选择基于Istio进行二次开发,如目前阿里开源的SOFAMesh/SOFAMosn两个项目。

Service Mesh(服务网格)

Service Mesh又称为服务网格,本质上就是我们前面介绍过的模式三。之所为称之为服务网格是因为按照模式三的结构,每个主机上同时运行了业务逻辑代码和代理,此时这个代理被形象地称之为SideCar(业务代码进程相当于主驾驶,共享一个代理相当于边车),服务之间通过SideCar发现和调用目标服务,从而形成服务之间的一种网络状依赖关系,然后通过独立部署的一种称之为控制平面(ControlPlane)的独立组件来集中配置这种依赖调用关系以及进行路由流量调拨等操作,如果此时我们把主机和业务逻辑从视觉图上剥离,就会出现一种网络状的架构,服务网格由此得名。

在新一代的Service Mesh架构中服务消费方和提供方的主机(或容器)两边都会部署代理SideCar,此时SideCar与服务所在的主机又称之为数据平面(DataPlane),与我们前面说到的用于依赖关系配置和流量调拨操作的控制平面相对应

Istio

通过上述的内容,我们从概念上应该是大概理解了什么是Service Mesh。而具体要落地Service Mesh只有概念是远远不够的,相反,如果没有一种可落地执行的开源框架,这个概念也不会这么快被大家所接受。

Istio就是目前受Google/IBM 等大厂支持和推进的一个 ServiceMesh开源框架组合。它解决了开发人员和运维人员在整体应用程序向分布式微服务体系结构过渡时所面临的挑战。我们知道无论是基于SpringCloud的微服务架构体系还是目前我们说到的Service Mesh,随着微服务规模的增长会带来很多的复杂性,如服务发现、负载均衡、故障恢复、监控,甚至A/B测试、访问控制等。而要对涉及这些问题的微服务架构体系进行管理,如果没有成熟的组件的话,就会需要耗费很多的精力去开发一些运维工具,而这个成本是非常高的。

而Istio则提供了一个完整的解决方案来满足微服务应用程序的各种需求。下图是Istio官网(https://istio.io)所展示的关于Istio的一张架构图:

在这张架构图中Istio服务网格在逻辑上还是分为数据平面控制平面。数据平面中的SideCar代理是由一款叫做Envoy的组件来承担的,它是一款用C++开发的高性能代理,用于协调服务网格中所有服务的入站和出站流量。

Envoy提供了很多内在的特性如:

  • 动态服务发现

  • 负载均衡

  • TLS终止

  • HTTP/2和gRPC代理

  • 熔断器

  • 健康检查

  • 基于百分比的流量分割

  • 故障注入

  • 丰富的指标

从上面的特性上看实际上Envoy已经提供了很完备的SideCar的功能,只是由于其采用的是C++开发的,目前在国内的落地实践中会有不同的取舍和选择,如蚂蚁金服内部在实践的过程中就没有使用Istio默认集成的Envoy,而是用 Golang 开发了新的 Sidecar,已经开源的SOFAMosn,来替代 Envoy。

 

在Istio控制平面中的各个组件的作用如下:

  • Mixer:负责收集代理上采集的度量数据,进行集中监控;

  • Pilot:主要为SideCar提供服务发现、智能路由(如A/B测试)、弹性(超时、重试、断路器)的流量管理功能;

  • Citadel:负责安全控制数据的管理和下发;

以上就是关于Istio及其组件的一些介绍,具体如何使用Istio进行服务开发及安装操作,大家可以看看Istio的官网另外需要强调的是kubernetes是目前 Isito 主力支持的容器云环境。

Service Mesh的优势

 

事实上Service Mesh这种架构模式并不新鲜,很早就有公司进行过尝试,之所以最近又火起来的原因,主要还是因为模式一、模式二的确有一些固有的缺陷,模式一相对比较重,有单点问题和性能问题

模式二则有客户端复杂,支持多语言困难,路由、熔断、限流等服务操作无法集中治理的问题。而Service Mesh则正好弥补了二者的不足,它是纯分布式的,没有单点的问题,性能也比较优秀并且与开发语言无关,还可以集中进行治理。

此外,随着微服务化、多语言和容器化的发展趋势,很多公司也迫切需要一种轻量级的服务发现机制,加上一些大厂如Google/IBM的助推(如kubernetes与Docker的容器之争),正好Service Mesh迎合了这种趋势,所以才有今天火热的局面。

微服务架构基础之Service Mesh的更多相关文章

  1. 大规模微服务架构下的Service Mesh探索之路

    小结: 1. 第一.二代Service Mesh meetup-slides/敖小剑-蚂蚁金服-大规模微服务架构下的Service Mesh探索之路.pdf https://github.com/se ...

  2. Java架构技术进阶之:从分布式到微服务,深挖Service Mesh

    自从几十年前第一次引入分布式系统这个概念以来,出现了很多原来根本想象不到的分布式系统使用案例,但同时也引入了各种各样的新问题. 当这些系统还是比较少比较简单的时候,工程师可以通过减少远程交互的次数来解 ...

  3. 微服务架构之「 下一代微服务 Service Mesh 」

    Service Mesh 被大家称为下一代的微服务,是微服务领域的一颗新星,被大家讨论的非常多. 我在大家的讨论中,还看到有人说 “目前的微服务架构我都没学会呢,现在又来一个下一代微服务,真学不动了” ...

  4. Go微服务容错与韧性(Service Resilience)

    Service Resilience是指当服务的的运行环境出现了问题,例如网络故障或服务过载或某些微服务宕机的情况下,程序仍能够提供部分或大部分服务,这时我们就说服务的韧性很强.它是微服务中很重要的一 ...

  5. 浅谈微服务架构、容器技术与K8S

    关注嘉为科技,获取运维新知 企业应用系统:从单体应用走向微服务架构:从裸金属走向容器. 如果在诸多热门云计算技术诸如容器.微服务.DevOps.OpenStack等之中,找出一个最火的方向,那么可能非 ...

  6. 几种常见的微服务架构方案简述——ZeroC IceGrid、Spring Cloud、基于消息队列

    微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果.虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合 ...

  7. 几种常见的微服务架构方案——ZeroC IceGrid、Spring Cloud、基于消息队列、Docker Swarm

    微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果.虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合 ...

  8. 微服务架构 技能图谱skill-map

    # 微服务架构 技能图谱 ## 理论基础### 概念#### 多微合适 - 非代码函数 - 非重写时间 - 适合团队最重要 - 独立业务属性 - 全功能团队 #### 进程隔离 - 服务运行在独立的进 ...

  9. .NET Core微服务系列基础文章索引(目录导航Final版)

    一.为啥要总结和收集这个系列? 今年从原来的Team里面被抽出来加入了新的Team,开始做Java微服务的开发工作,接触了Spring Boot, Spring Cloud等技术栈,对微服务这种架构有 ...

随机推荐

  1. GitHub 优秀的项目地址

    Type LibDescription   LibLocation Android SlidingMenu   https://github.com/jfeinstein10/SlidingMenu ...

  2. js判断页面在pc端打开还是移动端打开

    js判断页面在pc端打开还是移动端打开,分别跳转不同的index.html window.addEventListener('load', function() { // true为手机,false为 ...

  3. JQ方法实用案例///鼠标移动到div和修改ipt中弹窗、CSS鼠标变小手、JQ获取元素属性、JQ选择器

    今天学习了jQ,jQ对js的帮助很大,菜鸟教程上也有属性.可以查看 js 和 jquery主要的区别 在 dom    想用jquery  必须先引入(顺序问题)        先css 再js:   ...

  4. 学习笔记CB009:人工神经网络模型、手写数字识别、多层卷积网络、词向量、word2vec

    人工神经网络,借鉴生物神经网络工作原理数学模型. 由n个输入特征得出与输入特征几乎相同的n个结果,训练隐藏层得到意想不到信息.信息检索领域,模型训练合理排序模型,输入特征,文档质量.文档点击历史.文档 ...

  5. Comedi的安装

    1.comedi的安装:(需要注意的是comedi和comedilib安装顺序随意)    1.comedi与大多数2.2,2.4和2.6Linux内核配合使用,不支持2.6-2.6.6的内核,对2. ...

  6. java基础-arrayList

      ArrayList: 结构之钱了解了,ArrayList()会构造出一个初始容量=10的空的列表: ArrayList()的增加和删除都是拷贝数组到新的数组(如果当前数组容量不足的话),把数组内的 ...

  7. TensorFlow - 在 windows 系统上安装

    安装方式: 1.pip (将介绍) 2.Anaconda 我采用的是本地 pip 方式 需提前安装 Python - Python 3.5.x > TF 只支持 Python 3.5.x 版本, ...

  8. zabbix自动发现及其自动注册

    在大企业环境中,不可能在zabbix页面上逐个添加被监控的主机.还好zabbix自带自动发现和自动注册功能 被监控端安装zabbix客户端之后,将配置文件配置指向服务器端ip即可.红色箭头改为zabb ...

  9. SoapUI测试WebService接口

      Getting Started Getting started with some ad-hoc testing of a SOAP service is straight forward; se ...

  10. 黄聪:Windows2012-IIS8安装SSL证书

    开始菜单->右上角搜索按钮-> mmc 弹出窗口 关闭控制台会提示保存 打开iis新建站点,为了兼容不支持sni的浏览器,绑定默认https