微服务自 2014 年 3 月由 Martin Fowler 首次提出以来, 在 Spring CloudDubbo 等各类微服务框架的帮助下, 以燎原之势席卷了整个 IT 技术界, 成为了最主流的分布式应用解决方案但仍然还有很多问题没有得到根本性的解决, 比如技术门槛高多语言支持不足代码侵入性强等如何应对这些挑战成为了下一代微服务首要回答的问题直到服务网格 (Service Mesh) 被提出, 这一切都有了答案
1 微服务之殇
时光回到 2017 年初, 那时所有主流的微服务框架, 不管是类库性质的 FinagleHystrix, 还是框架性质的 Spring CloudDubbo, 本质上都归于应用内解决方案, 都存在以下三个问题:
技术门槛高: 随着微服务实施水平的不断深化, 除了基础的服务发现配置中心和授权管理之外, 团队将不可避免的在服务治理层面面临各类新的挑战, 包括但不限于分布式跟踪熔断降级灰度发布故障切换等, 这对团队提出了非常高的技术要求
图片出处: Service Mesh: 下一代微服务
多语言支持不足: 对于稍具规模的团队, 尤其在高速成长的互联网创业公司, 多语言的技术栈是常态, 跨语言的服务调用也是常态, 但目前开源社区上并没有一套统一的跨语言的微服务技术栈
代码侵入性强: 主流的微服务框架 (比如 Spring CloudDubbo) 或多或少都对业务代码有一定的侵入性, 框架替换成本高, 导致业务团队配合意愿低, 微服务落地困难
这些问题加起来导致的结果就是, 在实施微服务的过程中, 小团队 Hold 不住, 大公司推不动
2 另辟蹊径
如何解决上述三个问题呢? 最容易想到的是代理模式, 在 LB 层 (比如 NginxApache HTTP Server) 处理所有的服务调用, 以及部分服务治理问题 (比如分布式跟踪熔断降级) 但这个方案有两个显著的缺点, 第一, 中心化架构, 代理端自身的性能和可用性将是整个系统的瓶颈; 第二, 运维复杂度高, 业务团队笑了, 运维团队哭了
难道这就是桃园吗?
服务网格 (Service Mesh) 应运而生! 自 2016 年 9 月 Linkerd 第一次公开使用之后, 伴随着 LinkerdEnvoyIstioNGINX Application PlatformConduit 等新框架如雨后春笋般不断涌现, 在微服务之后, 服务网格和它的边车 (Sidecar) 模式引领了 IT 技术界 2017 一整年的走向
3 服务网格
3.1 元定义
首先, 我们来看一下服务网格的提出者 William Morgan 是如何描述它的
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. Consists of a control plane and data plane (service proxies act as "mesh"). - William Morgan, What's a Service Mesh? And Why Do I Need One?
上面这段话非常清晰的指明了服务网格的职责, 即处理服务间通讯, 这正是服务治理的核心所在而
a dedicated infrastructure layer
这几个单词将服务网格和之前所有的微服务框架 (framework) 划清了界限, 也即服务网格独立于具体的服务而存在, 这从根本上解决了前文提到的老的微服务框架在多语言支持和代码侵入方面存在的问题并且, 由于服务网格的独立性, 业务团队不再需要操心服务治理相关的复杂度, 全权交给服务网格处理即可
那你可能会问, 这不跟之前提到的代理模式差不多吗? 区别在于服务网格独创的边车模式针对每一个服务实例, 服务网格都会在同一主机上一对一并行部署一个边车进程, 接管该服务实例所有对外的网络通讯 (参见下图) 这样就去除了代理模式下中心化架构的瓶颈同时, 借助于良好的框架封装, 运维成本也可以得到有效的控制
图片出处: What's a Service Mesh? And Why Do I Need One?
3.2 演化史
追本溯源, 服务网格从无到有可分为三个演化阶段 (参见下图) 第一个阶段, 每个服务各显神通, 自行处理对外通讯第二个阶段, 所有服务使用统一的类库进行通讯第三个阶段, 服务不再关心通讯细节, 统统交给边车进程, 就像在 TCP/IP 协议中, 应用层只需把要传输的内容告诉 TCP 层, 由 TCP 层负责将所有内容原封不动的送达目的端, 整个过程中应用层并不需要关心实际传输过程中的任何细节
图片出处: Pattern: Service Mesh
3.3 时间线
最后, 再来回看一下服务网格年轻的历史虽然服务网格的正式提出是在 2016 年 9 月, 但其实早在 2013 年, Airbnb 就提出了类似的想法 SmartStack, 只不过 SmartStack 局限于服务发现, 并没有引起太多关注, 类似的还有 Netflix 的 Prana 和唯品会的 OSP Local Proxy2016 年服务网格提出之后, 以 Linkerd 和 Envoy 为代表的框架开始崭露头角, 并于 2017 年先后加入 CNCF 基金(Cloud Native Computing Foundation), 最终促使了一代新贵 Istio 的诞生 2018 年, Istio 将发布 1.0 版本, 这也许意味着微服务开始进入 2.0 时代
图片出处: Service Mesh: 下一代微服务
4 小结
以上就是我对服务网格的一些简单介绍, 欢迎你到我的留言板留言交流, 和大家一起过过招下一篇我会教大家如何在本地从零搭建一个基于 Istio 的服务网格, 敬请期待
5 参考
- What's a Service Mesh? And Why Do I Need One?
- Pattern: Service Mesh
- Awesome Service Mesh
Service Mesh: 下一代微服务
解读 2017 之 Service Mesh: 群雄逐鹿烽烟起
来源: https://juejin.im/post/5ac07d63f265da238d50da8a