Service Mesh初识
什么是Service Mesh？
为什么需要Service Mesh？
Service mesh 特点：
Service Mesh 基本原理
Service Mesh架构
方案
Istio 介绍
Linkerd 介绍
最后
什么是Service Mesh？
根据Linkerd CEO William Morgan定义，Service Mesh是用于处理服务间通信的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh通常是一组与应用一起部署，但对应用透明的轻量级网络代理。
Service Mesh与传统基础设施层不同之处在于，它形成了一个分布式的互连代理网络，以sidecar形式部署在服务两侧，服务对于代理无感知，且服务间所有通信都由代理进行路由。
为什么需要Service Mesh？
“Smart endpoint and dumb pipes”是微服务架构在集成服务时采用的一个核心理念，这一理念改变了过去臃肿集中的ESB（企业服务总线），无疑是正确方向上的一大进步，但同时也给我们出了一些难题——多智能才不会过于智能，而服务轻重大小的程度如何拿捏？我们应该如何处理微服务系统中服务间交互的复杂性？放在服务内部还是外部？如果是内部，如何处理业务逻辑关系，或者应该与基础设施更为相关？如果是外部，如何避免重蹈ESB的覆辙？
皮的不谈，先来看看处理服务间通信时需要关注的点：
- 服务发现
- 负载均衡
- 路由
- 流量控制
- 通信可靠性
- 弹性
- 安全
- 监控/日志
似乎都是老生常谈，存在于任何需要处理网络的分布式系统之中，区别在于，当所涉及微服务数量呈指数级增加，这些问题也会被相应放大。
一个已经被广泛应用的解决方案是利用api网关来处理服务外部和服务之间的请求，提供例如服务发现、路由、监控、流量控制等。
然而，api网关有一个比较致命的缺陷，它容易出现单点故障并且实践不当很有可能会变得异常臃肿。另一方面，api网关核心是面向用户，也就是说它可以解决从用户到微服务的流量问题，但不能解决所有问题，而我们需要的是一个完整的方案，或者至少是一些能够与api网关互补的方案和工具。
另一种选择是在网络堆栈的较低层级（4/3）进行可靠性、监控、流量控制等方面处理。这种选择的问题是，在较低较低的操作难易满足应用层的问题。联想end-to-end（端到端）的理论，我们前面提到的那几个关注点实际上还是集中在应用层，也只能在应用层成功实现。
像Netflix、Twitter等SOA/微服务的早期采用者，他们通过建立内部库的方式处理这些问题，然后提供给所有服务使用。这种方法的问题在于，把库扩展到成百上千个微服务中难度极高，而且这些库相对来说是比较”脆弱“的，我们很难保证他们可以适应所有的技术堆栈选择。
程度上来说，Service Mesh与这些库很类似，但Service Mesh是与服务相邻的独立进程。服务连接到代理，代理反过来又与其他代理（HTTP1.1/2、GRPC）进行通信。它们是相对独立的进程，在应用层或应用层之下分布和运行，进而解决了上述两个方案存在的缺陷。
Service mesh 特点：
- 应用程序间通讯的中间层；
- 轻量级网络代理；
- 应用程序无感知；
- 解耦应用程序的重试、超时、监控、追踪和服务发现；
Service Mesh 基本原理
如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
Phil Calçado 在他的这篇博客 Pattern: Service Mesh 中详细解释了 Service Mesh 的来龙去脉：
- 从最原始的主机之间直接使用网线相连
- 网络层的出现
- 集成到应用程序内部的控制流
- 分解到应用程序外部的控制流
- 应用程序的中集成服务发现和断路器
- 出现了专门用于服务发现和断路器的软件包/库，Twitter’s Finagle和 Facebook’s Proxygen。这时候还是集成在应用程序内部
- 出现了专门用于服务发现和断路器的开源软件，如：NetflixOSS ecosystem
- 最后作为微服务的中间层Service Mesh出现
Service Mesh 的架构如下图所示
Service Mesh架构
Service Mesh由data plane构成，其中所有服务通过sidecar代理进行服务通信。（所有代理相互连接形成一个Mesh，Service Mesh由此得名）网格同时包含一个control plane——可以将所有独立的sidecar代理连接到一个分布式网络中，并设置网格还包括一个控制平面——它将所有独立的sidecar代理连接到一个分布式网络中，并设置由data plane指定的策略。
Control plane定义服务发现、路由、流量控制等策略。这些策略可以是全局的，也可以是限定的。Data plane负责在通信时应用和执行这些策略。
方案
目前社区Service Mesh的开源解决方案有：Buoyant 公司推出的 Linkerd 和 Google、IBM 等厂商牵头的 Istio。Linkerd 更加成熟稳定些，Istio 功能更加丰富、设计上更为强大，社区相对也更加强大一些。所以普遍认为 Istio 的前景会更好，但是毕竟还处于项目的早期，问题还很多。
Istio 介绍
Istio是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语，意思是”起航“。官方中文文档地址：https://istio.doczh.cn
Istio架构图：
Istio架构分为控制层和数据层。
- 数据层：由一组智能代理（Envoy）作为sidecar部署，协调和控制所有microservices之间的网络通信。
- 控制层：负责管理和配置代理路由流量，以及在运行时执行的政策。
Istio架构各个组成部分。
- Envoy：Istio使用Envoy代理的扩展版本，该代理是以C++开发的高性能代理，用于调解service mesh中所有服务的所有入站和出站流量。
- Mixer：Mixer负责在service mesh上执行访问控制和使用策略，并收集Envoy代理和其他服务的遥测数据。
- Istio Manager：Istio-Manager用作用户和Istio之间的接口，收集和验证配置，并将其传播到各种Istio组件。
- Istio-auth：Istio-Auth提供强大的服务间和最终用户认证，使用相互TLS，内置身份和凭据管理。
Linkerd 介绍
Linkerd 是开源网络代理，设计为以服务网格部署：用于管理，控制和监控应用程序内的服务与服务间通讯的专用层。
Linkerd 架构图
Linkerd 基本功能 原文链接
- Load balancing：负载均衡算法，它们使用实时性能指标来分配负载并减少整个应用程序的尾部延迟。
- Circuit breaking：自动熔断，将停止将流量发送到被认为不健康的实例，从而使他们有机会恢复并避免连锁反应故障。
- Service discovery：服务发现后端集成，通过删除特定的(ad-hoc)服务发现实现来帮助您降低代码的复杂性。
- Dynamic request routing：动态请求路由和重新路由，允许您使用最少量的配置来设置分段服务(staging service)，金丝雀(canaries)，蓝绿部署(blue-green deploy)，跨DC故障切换和黑暗流量(dark traffic)。
- Retries and deadlines：在某些故障时自动重试请求，并且可以在指定的时间段之后让请求超时。
- TLS：可以配置为使用 TLS 发送和接收请求，您可以使用它来加密跨主机边界的通信，而不用修改现有的应用程序代码。
- HTTP proxy integration：可以作为 HTTP 代理，几乎所有现代 HTTP 客户端都广泛支持，使其易于集成到现有应用程序中。
- Transparent Proxying：在主机上使用 iptables 规则，设置通过 linkerd 的透明代理
- gRPC： 支持 HTTP/2 和 TLS，允许它路由 gRPC 请求，支持高级 RPC 机制，如双向流，流程控制和结构化数据负载。
- Distributed tracing：分布式跟踪和度量仪器，可以提供跨越所有服务的统一的可观察性。
- Instrumentation：支持分布式跟踪和度量仪器，可以提供跨越所有服务的统一的可观察性。
最后
总结来说，Service Mesh是“时间的产物”，Docker、Kubernetes等容器技术直接推进了对于Service Mesh的需求，让复杂的系统可以被轻松部署和管理。
未来Service Mesh将如何发展还未可知，或许会像TCP/IP一样形成标准，或许不同工具和平台会独具一格……但有一点是确认的，Service Mesh对于微服务生态的价值令人难以忽视，能够将繁重的服务治理工作变得简单高效，何乐而不为？
相关阅读:
- 极客时间：什么是Service Mesh
- 极客时间：Service Mesh深度解析
- 极客时间：解读2017之Service Mesh：群雄逐鹿烽烟起
- kubernetes-handbook
- Jimmy Song
- Service Mesh 在华为公有云的实践
参考资料：
- Service Mesh 服务网格
- Pattern: Service Mesh
- What’s a service mesh? And why do I need one?
- linkerd.io
- Linkerd官方文档中文版
- Istio官方文档中文版
Service Mesh初识相关推荐
- Service Mesh 是新瓶装旧酒吗？
点击下载<不一样的 双11 技术:阿里巴巴经济体云原生实践> 本文节选自<不一样的 双11 技术:阿里巴巴经济体云原生实践>一书,点击上方图片即可下载! 作者 | 李云(花名: ...
- 聊聊Service Mesh：linkerd
[编者的话]随着企业逐渐将传统的单体应用向微服务或云原生应用的转变,虽然微服务或者云原生应用能给企业带来更多的好处,但也会带来一些具有挑战的问题,如怎么管理从单体应用转向微服务所带来的服务间通讯的复杂 ...
- 下一代 Service Mesh -- istio 架构分析
前面的分享中,我们讲到,出于性能和稳定的考虑,我们没有采用以 istio 为代表的第二代 service mesh技术,而是直接使用了 Envoy 搭配自己的 xDS 服务. 然而我们还是有必要去了解 ...
- 百度大规模Service Mesh落地实践
导读:百度过去基于rpc框架的服务治理存在各种框架能力层次不齐.业务自身服务治理效率低.全局可观测性不足等诸多问题.本文介绍了百度内部落地service mesh的实践过程,以基础稳定性能力治理和流量 ...
- 基于Service Mesh构建更现代的服务架构
点击上方蓝色字体,选择"设为星标" 优质文章,及时送达 前言 传统业务模型中,客户端和服务端之间放置一个负载均衡器,比如nginx.我们的客户端可以是移动程序或者web系统. 当服 ...
- 实施Service Mesh前，你需要考虑这几个问题
随着我们需要治理的微服务数量越来越多,我们必须开始着手解决服务间通信的复杂性问题,而Service Mesh(服务网格)的出现恰逢其时,作为基础设施层,它能够以透明代理的形式提供安全.快速.可靠的服务 ...
- Service Mesh是大方向，那Database Mesh呢？
在微服务和云原生大潮的卷席之下,服务化一直以来是人们关注的重点.但服务化之后,真正绕不开的数据访问却鲜有论道.尽管目前的关系型数据库远达不到云原生的要求,并且对分布式的不友好在长期以来也饱受诟病,但不 ...
- 十问 | 关于Service Mesh 和Kubernets的最前沿思考
小蚂蚁说: 在7月6日ArchSummit全球架构师峰会2018深圳站上,蚂蚁金服平台数据技术部的杨冰.Service Mesh布道师敖小剑.蚂蚁金服技术专家毛小云和来自阿里大文娱UC基础部的曾彬,四 ...
- Service Mesh：调度千军万马微服务，2.0妥妥的
冠望 发自 凹非寺 量子位 报道 | 公众号 QbitAI 过去一年,继Kubernetes风靡,Service Mesh已成功上位变成当之无愧的技术网红. TA不但可以极大简化用户使用体验,还将大中 ...
最新文章
- 2019/2/23研究日志
- 玹疯：这些年我走过的弯路
- 苹果春季新品发布会来了：将推iPhone13 Pro系列紫色版
- eclipse里面配置热部署,tomcat配置
- 又是骗补贴的？清华虚拟学生华智冰翻车：AI换脸铸就人工智能
- javascript简单性能问题及学习笔记
- 【Keras】使用数据生成器（data generators）解决训练数据内存问题
- 用于Visio的官方cisco 图标库下载地址
- QIIME 2教程. 22命令行界面q2cli(2021.2)
- PMBOK第6版 项目管理过程组与知识领域(15至尊图)
- 谷歌浏览器提示Flash版本过低，要求更新或运行一次
- Uint8 Uint16等的区别
- idea 2019.2顶部菜单栏隐藏的恢复办法
- _EPROCESS结构简单了解！
- IPFS发展前景真有说的那么好么？
- 学习mysql_day3_高级查询1(聚合查询,聚合统计)
- AI 之 OpenCvSharp 大图找小图（案例版）
- Syclover战队专访 | 年度终局之战，键指圣诞狂欢
- 【C语言】C语言概述
- 深度学习论文: BAM: Bottleneck Attention Module及其PyTorch实现