服务网格——模式还是技术？
原文：Service Mesh – A New Pattern, Not A New Technology?
原作者：Marco Palladino
Service Mesh 是什么？从何而来？
近几个月，你会注意到围绕服务网格以及未来软件架构的业内讨论如火如荼。这些讨论围绕着几个供应商，呈现出一种部落战争的态势。这种党争虽然司空见惯，但是其中一些共同话题还是很有意义的——例如企业中 API 应用的快速转型，以及服务网格对流量拓扑的意义。
服务 API 最初用于在组织边界提供访问内部系统的接口，供外部开发人员访问；这种情况并未持续很久，很快，服务 API 就变成将内部系统连接在一起的粘合剂。而微服务架构的发展，带来了一个无法回避的后果：数据中心内的内部通信持续增长。服务网格适时出现，提供了一种面向现有技术的部署框架，可能成为应对东西向流量增长问题的一个解决方案。
作为 Kong 的 CTO，我也很热衷于参加这些对话，我注意到对服务网格的认知有一个普遍误解。为了消除误会，升级对话，首先我想要明确提出：服务网格是一种模式，而非技术。
服务网格是一种模式，而非技术
微服务是模式而非技术，服务网格也是一样。这两种概念的区别貌似很难理解。如果我们从 OOP 的角度来看，模式描述的是接口，不是实现。
服务网格这样的部署模式能够利用 Sidecar 增强东西向的流量管理，能给微服务提供强大支援。既然已经对单体应用进行了解耦，并用微服务构建了新的应用，我们的流量模型中，内部流量就会与日俱增。数据中心内，东西向的流量增长原因是我们将单体应用中的函数调用换成了网络调用，这意味着我们的微服务必须融入网络，互相消费。然而地球人都知道——网络靠不住。
面对日益增长的东西向流量，服务网格通过新的部署架构进行应对。传统的南北向通信中，100 毫秒的延迟虽不够理想，但也在可接受范围之内；但在东西向通信中，这就无法忍受了。这是因为服务间的相互调用会使延迟倍增，跨越多个服务的 API 调用和返回，会造成延迟时间的大幅增加。
为了降低延迟，引入了独立运行的 Sidecar，这种代理服务器会伴随微服务进程一起运行，用来移除多余的网络跳跃。Sidecar 在请求的执行路径上担任数据平面的角色，并且避免了单点失败，从而提供了更好的应用弹性。然而，每个微服务进程都配合一个代理进程，势必会造成资源的损耗，但同时他也降低了资源耗尽的肯能性。
经过细致观察不难发现，服务网格中的很多功能，都已经在多年前的 API 管理产品中实现了。比如可观测、网络故障处理和健康检查等功能都是 API 管理的基本配置。这些特性并不新鲜，但服务网格作为一种新的模式，用新思路来完成了这些功能。
传统 API 管理方案瞠目其后
微服务和容器大潮迫使人们更多的关注轻量级进程，服务网格提供的轻量级进程，同时承担了代理和反向代理的角色，伴随微服务进程一同运行。为什么传统的 API 管理方案不采用这种新的部署方案？这是因为他们生于单体时代。这些早于 Docker 和 Kubernetes 面世的 API 管理系统本身就是单体应用，并不适用于新兴的容器生态圈。传统 API 管理方案往往具有重量级的运行时和低下的性能，这些问题在过去的边缘 API 用例中尚可承受，但是对于微服务体系来说，东西向调用量越多，中间环节的延迟就越大。究其根本，传统 API 管理方案的重量大、难度高以及速度慢的缺点是难以满足微服务世界的要求的。
开发人员了解了这些，传统的 API 管理方案引入了称之为 "microgateway"（微型网关）的技术，用来处理东西向的流量，并且避免重写现存的臃肿的单体网关方案。问题是这些所谓的微型网关虽然自身变轻了，但还是要依赖传统方案伴行，用于提供策略实施等能力。这不仅是留下陈旧组件的问题，还意味着增加了延迟。如此种种，服务网格就令人耳目一新了——对手太旧了。
结语
传统的 API 管理方案在南北向流量管理中耕耘多年，服务网格的功能相对来说并不新鲜。多数网络方面以及观测方面的能力对东西向和南北向的流量都是通用的，服务网格让我们有机会运行轻量快速的 Sidecar 代理来完成这些通用功能，改变的是部署模式，不是底层功能。
传统 API 管理方案的功能是服务网格功能的超级，某种意义上来说，普及了可靠性、服务发现和观测能力。服务网格是一种部署模式，用轻量级的方式获得同样的功能。业界经常混淆——有时还加重了这种混淆——很多服务网格方面的讨论，都混淆了特定部署模板和底层技术的界限。