江苏龙网

  1. 首页 > 资讯 > 科技 > >

云计算|Service Mesh：调度千军万马微服务，2.0妥妥的


冠望 发自 凹非寺
量子位 报道 | 公众号 QbitAI
过去一年 ， 继Kubernetes风靡 ， Service Mesh已成功上位变成当之无愧的技术网红 。
TA不但可以极大简化用户使用体验 ， 还将大中型企业的Kubernetes落地引向“实处” 。
对于绝大多数使用容器的企业来说 ， 似乎一夜之间 ， Service Mesh就成长为完善容器部署的功能担当 ， 不容小觑 。
并被一度当作云原生技术栈的关键组件之一 ， 人称“新一代微服务架构” ， 即2.0版本 。
从逻辑出发 ， 如果想聊透Service Mesh ， 还是要先谈谈微服务的 。
用维基百科的话说 ， 所谓微服务 ， 可被定义为一种软件架构风格 。
这个风格比较专注单一责任与功能的小型区块 ， 利用模块化的方式组合出复杂的大型应用程序 。
在此过程中 ， 各功能区块的使用与语言无关的API集达成相互通信 。
简单来说 ， 在云原生微服务的模式下 ， 哪怕是单个应用也可能由数百个服务组成 。
此基础上 ， 每个服务又包含多达上千个实例 。
如果你真想抽丝剥茧一下下 ， 其实每个实例又很有可能被像 Kubernetes 这样的服务调度器不断调度 ， 而产生千变万化的形态 。
尽管形态复杂多样 ， 但端到端通信的可靠性与性能优势却始终至关重要 。
这时候Service Mesh就派上了用场 。
本质上就是将服务间的通信从无法发现与控制的基础设施中分离出来 ， 并达成监控、管理与控制的目标 。
显而易见 ， 关于Service Mesh的定义 ， 广泛被接受的一种 ， 是控制应用程序不同部分彼此共享数据的方式 。
云计算|Service Mesh：调度千军万马微服务，2.0妥妥的
本文插图

作为一个专门让服务与服务之间的通信变得安全、快速以及可靠的基础设施 ， Service Mesh确实可以做到通过服务通讯 ， 让整个架构更为先进和Cloud Native 。
在某些方面 ， 这有点儿像网络七层模型中的第四层 TCP 协议 。
但与TCP不同的是 ，TA想要达成的目的不仅仅是正常的网络通讯 。
还着力为应用提供了统一的 ， 可视化的以及可控制的控制平面 。
如果追根溯源 ， Service Mesh 并不算是什么新技术；如果一定要说创新的话 ， 更多则是功能所在位置的改变 。
实践证明 ， Service Mesh确实可高效做到屏蔽分布式系统通信的复杂性 ， 只关注业务逻辑 。
对于服务语言没有限制 ， 只需和Service Mesh通信即可 。
更重要的是 ， 对应用透明 ， 组件可单独升级 。
止步于开源 ， 那些鼎鼎大名的service mesh项目数一数
从2016年1月 ， 业内第一个开源项目Linkerd发布 ， “Service Mesh”首次在公开场合被使用；到控制平面概念及作用被人们认可并接受以至于到今天 。
我们发现热闹归热闹 ， 虽然如火如荼 ， 但还尚未出现完全现成的商业产品 。
大部分的Service Mesh仅仅止步于开源项目 ， 例如现在比较知名的Linkerd、Istio 等 。
1、2、3 ， 那就从Linkerd说起吧！
Linkerd最初是由Buoyant团队在2016年打造的一个服务网格项目 。
从Twitter开发的library中分离出来并由Scala语言编写 ， 设计理念是支持基于主机（物理主机或者虚拟节点）的部署模式 ， 算是开源项目中资历比较深厚的 。
有关资料显示 ， Conduit ， 也是该领域另一位颇具影响力的选手 ， 多年前已成功合并到Linkerd项目 ， 并在2018年7月发布为Linkerd 2.0 版本 。
关于Conduit的研发初衷 ， 很多人总结为是由于最初版本的内存占用问题广受诟病 ， 所以Conduit确实表现更加轻量级 ， 为Kubernetes定制 ， 用Rust和Go语言编写 ， 但与当下广泛提及的Istio相比 ， 依旧不在一个数量级别上 。
但更多人认为 ， Buoyant 是意识到继续同时支撑 Linkerd1.x 和 Conduit 两条产品线已经不合时宜 ， 此外Linkerd1.x无论是在数据平面还是控制平面上表现都很堪忧 。


推荐阅读


上一篇：|怎样度过第一份编码工作的艰难时期？

下一篇：五道口的颜学姐|科学遇到日食会怎样？永恒的美丽，聊聊一次跟爱因斯坦有关的日食