Marco Palladino https://konghq.com/blog/author/marco/
Service Mesh 从何而来?
在过去几个月里, Service Mesh 是行业内毋庸置疑的焦点. 关于 Service Mesh, 关于软件架构未来的文章观点, 围绕着不同的技术供应商而高度分化, 不过有一点共通的事, 对于如何在企业中使用 API 的快速转换, 以及这对于我们流量的拓扑意味着什么.
服务 API 主要是作为将组织外部开发人员与内部系统连接起来的边缘接口, 以及将这些内部系统 (微服务) 绑定到功能整体的 "粘合剂" 存在的. 因此, 面向微服务体系结构不可避免会出现数据中心内部通信增加的情况. tongguo 的不可避免的结果之一是数据中心内的 内部通信将增加. Service Mesh 作为一种潜在的解决方案出现了, 它通过提供一个不同的框架来部署现有技术, 从而解决了东西部流量增加带来的挑战.
Service Mesh 是一种模式, 而非技术
正如微服务是一种模式而不是一种特定的技术一样, Service Mesh 也是一种模式. 区分这两者听起来比实际要复杂得多. 如果我们从面向对象编程 (OOP) 的角度来考虑这个问题, 一个模式描述的是接口, 而不是实现.
在微服务的背景下, Service Mesh 部署模式能够通过 sidecar 代理, 更好地管理东西流量. 当我们拆分系统并使用微服务构建新产品时, 我们流量的拓扑结构也正在从外部为主转向内部流量的持续增长. 数据中心里的东西通流量增长, 缘于我们用网络调用替换过去的函数调用, 这意味着我们的微服务必须通过网络来相互通信. 但我们都知道, 网络有可能是不可靠的.
通过使用不同的部署模式, Service Mesh 希望解决东西流量增加带来的挑战. 虽然对于传统的南北流量来说, 100ms 的中间件处理延迟虽然并不理想, 但也不是不能接受, 不过在东西流量的微服务架构体系中, 这样的延迟就不能容忍了. 原因是服务之间从东到西的流量增加会增加延迟, 当跨不同服务的 API 请求链被执行和返回时, 可能会导致 700ms 的延迟.
为了减少这种延迟, 引入了与微服务进程一起运行的 sidecar 代理, 以删除网络中的额外跳转. Sidecar 代理, 对应于我们请求执行路径上的数据平面, 也提供了更好的弹性, 因为我们不再有单点故障. 值得注意的是, sidecar 代理承担了为我们的微服务的每个实例都有一个代理实例的成本, 这需要一个很小的占用空间, 以最小化资源损耗.
从功能的角度来看, API 管理产品已经提供了多年来所提供的 Service Mesh. 诸如可观察性, 网络错误处理, 健康检查等功能是 API 管理的标志. 这些功能本身并不构成任何新颖的功能, 但作为一种模式, Service Mesh 引入了在我们的体系结构中部署这些功能的新方法.
传统的 API 管理方案已经跟不上了
为什么大多数传统的 API 管理解决方案不允许这种新的部署选项? 因为他们 "出生在一个单一的世界".
事实证明, Docker 和 Kubernetes 出现之前构建的 API 管理解决方案本身就是一个整体, 并没有被设计成在新兴的容器生态系统中有效工作. 传统 API 管理解决方案所提供的重量级运行时和较慢的性能在传统的边缘 API 用例中是可以接受的, 但是在微服务体系结构中, 延迟会随着时间的推移而通过增加东西方向的流量活动而增加. 从本质上讲, 传统的 API 管理解决方案最终都过于重量级, 难以自动化, 并且太慢, 无法有效地协调与微服务固有的不断增加的通信.
由于开发人员理解这一点, 在容器出现之前诞生的遗留 API 管理解决方案引入了他们所谓的 "微网关" 来处理东西流量, 避免重写他们现有的, 臃肿的, 单一的网关解决方案. 问题是, 这些微网关虽然更轻量, 但仍然需要遗留解决方案与它们一起运行, 以便执行策略强制. 这不仅意味着在堆栈中保持原来的重型依赖关系, 还意味着每个请求之间的延迟增加. 这就不难理解, 为什么 Service Mesh 感觉上像是一个全新的类别, 因为过去的 API 管理方案已经无法支持需求了.
总结
当我们在 feature-set 背景下理解 Service Mesh 时, 我们会发现它与传统 API 管理解决方案在南北流量方面所做的工作并没有太大的不同. 大多数网络和可见性功能在南北流量和东西流量用例中都是有用的, 改变的是部署模式, 它使我们能够将网关 / 代理作为轻量级, 快速的 sidecar 容器运行, 而不是底层的特性集.
Service Mesh 提供的特性集是 API 管理解决方案多年来一直提供的特性集的一个子集, 特别是在使网络可靠, 服务发现和可观察性方面. Service Mesh 的创新之处在于它的部署模式, 它能够运行与轻量级 sidecar 进程 / 容器相同的特性集. 我们的行业常常会混淆 -- 有时还会推动 -- 一种特定模式等同于底层技术的观点, 就像很多关于 Service Mesh 的讨论一样.
关于 Rainbond
> Rainbond 是一款以应用为中心的开源 PaaS, 由好雨基于 Docker,Kubernetes 等容器技术自主研发, 可作为公有云或私有云环境下的应用交付平台, DevOps 平台, 自动化运维平台和行业云平台, 或作为企业级的混合云多云管理工具, Kubernetes 容器管理工具或 Service Mesh 微服务架构治理工具.
Rainbond 项目网站 https://www.rainbond.com/
试用 Rainbond 公有云 https://www.goodrain.com/* 注册或使用 Demo 账号 / 密码登录: rainbond-demo/rainbond-demo
Github https://github.com/goodrain/rainbond
码云 https://gitee.com/rainbond/Rainbond
文档 https://www.goodrain.com/docs/stable/
微信群: 添加微信 "zqg5258423" 并接受邀请入群
来源: http://www.tuicool.com/articles/6baYvaB