【云原生】服务网格是什么“格”？

服务网格是什么？在介绍云原生的文章中，常常与微服务、容器、容器编排等概念结伴出现的一个名词便是服务网格，有文章甚至将服务网格与容器、微服务、DevOps 并列为云原生不可不知的四大云原生关键技术，其重要性可见一斑。那么服务网格究竟是什么？

云原生不可不知技术之服务网格

其实服务网格并不是一个独立的概念，可以说是先有了微服务才有了服务网格，谈服务网格我们就得从微服务谈起。

从微服务谈起

简单来说，在我们引入微服务架构并享用它带来的众多好处时，也不可避免地遇到了很多问题。这些问题大多可以归纳为微服务应用之间的通信问题，而服务网格正是针对这些问题应运而生的一个解决方案，用于管理微服务应用程序中各个微服务之间的通信。

微服务架构“天使与魔鬼”般的一体两面

想要弄清楚服务网格是怎样的一个概念，一个正确的路径就是弄清楚它解决了怎样的问题，也就是问：我们转向微服务架构时究竟遇到了怎样的挑战？以至于我们竟然需要一个专门的微服务通信工具！

转向微服务时的挑战

以一个在线商店应用程序为例，该程序由若干个微服务应用组成，例如获取请求的 Web 微服务、实现支付功能的支付微服务、购物车微服务、产品库存微服务、数据库等其他微服务。这些微服务应用程序被部署在一个 kubernetes 集群上。

基于微服务架构的在线商店程序

那么各个微服务需要实现哪些功能才能使得这样一个在线商店应用程序运行成功呢？

微服务架构需要做到

业务逻辑（Business Logic）

首先每个微服务都必须实现自身相应的功能。Web 微服务需要处理用户界面请求，支付微服务需要实现支付功能、数据库需要处理数据。

各个微服务必不可少的业务逻辑

通信配置（ommunication Configuration）

此外为了让我们的在线商店应用程序运行成功，不仅需要每个微服务实现自身相应的功能，还需要各个微服务之间的交流通信。

当用户将商品放入购物车时，此时微服务便需要相互通信，Web微服务接收到请求，然后将其交给购物车微服务，购物车微服务再与数据库通信来持久化数据。

用户向购物车添加商品时微服务的通信

要实现像这样的微服务之间的相互交流，我们便需要为微服务配置相应的信息。因此当我们添加新的微服务时，我们需要为所有需要与之通信的微服务配置信息，比如所有与Web微服务对话的微服务都需要为Web微服务配置相应的信息。而这些配置信息也作为应用程序部署代码的一部分。

添加通信配置实现微服务间的通信

安全逻辑（Security Logic）

微服务应用程序还需要保证安全问题。

通常情况下，在许多项目中我们为 kubernetes 集群设置了防火墙规则。有一个代理作为首先获取请求的入口点，所以集群不能直接访问，因此应用在集群周围具有安全性。但是一旦请求进入集群内部，通信是不安全的。集群内的每个微服务都可以与任何其他微服务通信，所以通信没有任何限制。从安全角度来看，这意味着如果攻击者进入集群内部，那么就可以做任何事情，因为我们内部没有任何额外的安全保障。

集群“内忧”

对于某些小型应用程序来说这也许没问题，因为它们实际上没有任何用户的敏感数据，但对于一些重要的应用程序来说，比如像银行系统这样具有大量个人用户数据的应用程序，数据的安全性是不得不考虑的。因此需要在每个应用程序内部进行额外配置，以保护集群内服务之间的通信。

添加确保集群内部安全的安全逻辑

重试逻辑(Retry logic)

此外为了让整个应用程序更加健壮，还需要为每个微服务添加重试逻辑。也就是说当一个微服务无法访问，或者失去了连接，这个时候需要重新尝试连接。

断联后的重试

因此开发人员需要重试逻辑添加到服务当中。

添加让微服务架构更加强健的重试逻辑

监控（Metrics and Tracing）

当微服务应用程序运行时，我们还需要监控服务的执行情况，比如有哪些http错误、获取微服务接受或发送的请求数量、了解请求需要多长时间来确定应用程序中的瓶颈，因此开发人员还需要为微服务添加监控逻辑。

添加监控逻辑

可以看到，为了使微服务应用程序成功运行，每个微服务的开发团队除了需要处理每个微服务的业务逻辑，还需要为每个微服务添加众多其他与实际业务无关的逻辑，并可能还需要在集群中配置一些额外的东西，这个时候问题就出现了。

问题出现

需要处理众多额外的逻辑，意味着微服务的开发人员无法专心处理实际的服务逻辑，而要忙于为每个微服务添加用于安全、通信的逻辑。对于每个微服务，这大大增加了其复杂性，当微服务数量达到一定数量，为众多的微服务一一配置这些逻辑也几乎成为了不可能的任务。

为众多微服务配置逻辑成为不可能任务

而服务网格正是针对这一问题给出了解决方案。

服务网格给出的解决方案

与其单独为每一个微服务添加众多的逻辑，更加合理的做法是将这些与实际业务逻辑无关的逻辑从微服务中分离出来，放入到它的一个代理程序中，集中处理。这个小程序是个第三方程序，我们可以轻松配置应用程序，而无需担心逻辑是如何实现的。

抽离与业务逻辑的无关逻辑，统一治理

此外开发人员也不必将代理配置添加到微服务的部署文件中，因为服务网格有一个控制平面，它会自动在每个微服务中添加这个代理。所以现在微服务可以通过这些代理相互通信，以实现由控制平面组成的服务到服务通信，而这些代理就是服务网格。因此现在开发人员就可以专注于开发实际的业务逻辑。

服务网格本质上是一张负责微服务之间通信的网络，它将服务治理能力与业务开发解耦，使开发人员更专注在业务开发与创新上。同时将服务治理能力下沉到基础设施，把专业的事情交给专业人去做，治理能力的迭代更新也可以不依赖于业务。在如今微服务架构架构逐渐走向主流的时代，服务网格正为我们更好地实现云原生保驾护航。

（部分图片来自网络，如有侵权，立即删除）