云原生：服务网格从何说起?

Posted 2021-04-03 开源拾椹

“ 如果用一句话来解释什么是服务网格(Service Mesh)，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关心服务之间的那些原本通过服务框架实现的事情，比如 Spring Cloud、Netflix OSS 和其他中间件，现在只要交给 Service Mesh 就可以了。从原理上来讲，Service Mesh为每个服务提供了统一协议的网络代理进行通信。为了说清楚服务网格，前提是要明白云原生的理念。”

01

—

什么是云原生(Cloud Native)

  云计算基金会(CNCF)对云原生的定义：“分布式系统应该具备有扩展到成千上万台节点的能力，并且这些节点具有多租户和自愈能力”，

  

 云原生的定义在社区内一直不断重新定义，因为云原生是未来软件开发的必然趋势，各大云厂商也一直处于不断探索的方向，其本质必然是所有基础服务下沉，让软件开发变得更简单，高效。开发者只需要关心上层应用逻辑，不需要关心资源的扩容，缩容以及分配。

   云原生的目的在于将运维下沉到基础服务，就是云计算服务，由云计算厂商给开发提供统一的API和操作流程来使用云计算的基础服。

   说到这里，大家可能理解了云计算的本质，就是讲计算资源基础服务下沉，让应用逻辑基于云计算基础服务(IaaS)运行，

02

—

Cloud Native的目的是什么？

速度：各种规模的公司现在都看到了快速行动，把想法变成产品并快速的投放到市场所带来的好处。根据这个定义，我们把想法付之于实现的周期从数月到数天，甚至是数小时。这个实现的一部分是商业文化的转变，把过于庞大的项目变成持续的改进。另一部分是关于管理的风险。最好的做法是降低风险的同时加速变革，因此这会让公司变得积极的放权和更加敏捷。

规模：随着业务的增长，支持更多的用户数变成了战略的必须，更多的地点，更宽的网络流量，同时保持及时地响应速度，成本管控，并具有容灾能力。

利润：在IaaS的世界里，策略的目的就是在需要的时候，也就是在有客户上线的时候，才去采取、购买资源。支出的方式从预先的CAPEX（按对需求的预估购买新的设备）到OPEX（按实际发生的需求购买）。而且这不是全部，因为机器能及时地买到但并不会被有效的利用。

Cloud Native的另一个优点是在主机上花费更少。它核心战略是减少技术风险。过去，我们理解的避免危险的方法是慢速和小心。Cloud Native的方法是快速前进但是采用的是小的，可逆的和低风险的步骤。这可以是非常强大的，但它不是免费的而且不容易。这是一个巨大的哲学和文化的转变，也是一个技术挑战。

  

03

—

Cloud Native如何工作？

Cloud Native的基本原理被描述为容器包装，动态管理和微服务架构，这听起来好像有点复杂，那么什么是它的实际意义和真正价值呢？我们认为Cloud Native可以升级架构的5个方面：

使用IaaS：运行的服务器可以灵活的按需分配。

使用或演变为微服务架构设计系统：每个组件都很小并且互相解耦。

自动化和编码：取代用人工去执行脚本和代码。

容器化：把应用进行封装处理，使他们测试和部署时更加容易。

编排：使用现成的管理和编排工具抽象化生产环境中的服务器个体。

04

—

Service Mesh源起

  在云原生模型里，一个应用可以由数百个服务组成，每个服务可能有数千个实例，而每个实例可能会持续地发生变化。这种情况下，服务间通信不仅异常复杂，而且也是运行时行为的基础。管理好服务间通信对于保证端到端的性能和可靠性来说是无疑是非常重要的。所以Service Mesh作为一种基础服务下沉到云原生，使用经典的RPC框架DUBBO时难免遇到以下问题：

网络波动：网络波动势必影响服务稳定性；

部分服务的DUBBO版本不一致：可能会导致网络协议不一致；

部分服务的使用的语言不同：如果一个服务为java应用，一个服务go应用，可能会导致语言的差异造成通信BUG；

服务网格控制应用程序的不同应用彼此共享数据的方式。与其他用于管理此通信的系统不同，服务网格是内置在应用程序中的专用基础结构层。这个可见的基础架构层可以记录应用程序不同部分之间交互的良好程度，因此可以更轻松地优化通信并避免随着应用程序的增长而停机。

Service Mesh图

在服务网格中，请求通过微服务在它们自己的基础结构层中的代理之间路由。因此，组成服务网格的各个代理有时称为“边”，因为它们与每个服务并排运行，而不是在它们内部运行。与每个服务分离的这些边代理一起构成了一个网状网络。

05

—

Service Mesh是如何工作的

   服务网格不会向应用程序的运行时环境引入新功能-任何体系结构中的应用程序始终需要规则来指定请求如何从A点到达B点。服务网格的不同之处在于，它采用控制服务的逻辑-各个服务之间的服务通信，并将其抽象到基础结构层。

   为此，将服务网格作为一系列网络代理内置到应用程序中。代理是一个熟悉的概念，如果工作计算机访问此网页，则很有可能只是使用了一个：

1 当您对此页面的请求不存在时，它首先是由贵公司的网络代理接收的；

2 通过代理的安全措施后，它被发送到托管此页面的服务器；

3 接下来，此页面返回给代理，并再次检查其安全措施；

4 然后它最终从代理发送给您。

如果没有服务网格，则每个微服务都需要进行逻辑编码以控制服务到服务之间的通信，这意味着开发人员不太会关注业务目标。这也意味着通信故障更难诊断，因为控制服务间通信的逻辑隐藏在每个服务中。

06

—

服务网格如何优化通信？

   添加到应用程序的每个新服务，或在容器中运行的现有服务的新实例，都会使通信环境变得复杂，并引入新的可能出现故障的地方。在复杂的微服务架构中，如果没有服务网格就很难定位发生问题的位置。

   这是因为服务网格还捕获了服务到服务通信的各个方面作为性能指标。随着时间的流逝，可以将通过服务网格可见的数据应用于服务间通信的规则，从而产生更有效，更可靠的服务请求。

   例如，如果给定的服务失败，则服务网格可以收集有关重试成功之前花费了多长时间的数据。当有关给定服务的故障时间的数据汇总时，可以编写规则来确定重试该服务之前的最佳等待时间，以确保系统不会因不必要的重试而负担过多。

07

—

服务网格开源项目Istio

Istio是谷歌继K8s之后又一个全球顶级开源项目，它拥有极其出色的架构和模式设计，目前lstio在国内云计算厂商阿里云已经有落地(ASM产品)，lstio完全遵循Service Mesh理念架构设计。

lstio特征：

• HTTP，gRPC，WebSocket和TCP通信的自动负载平衡。

• 通过丰富的路由规则，重试，故障转移和故障注入对流量行为进行细粒度控制。

• 可插拔的策略层和配置API，支持访问控制，速率限制和配额。

• 群集内所有流量的自动指标，日志和跟踪，包括群集的入口和出口。

• 通过强大的基于身份的身份验证和授权，在群集中进行安全的服务间通信。

08

—

结语

  如果你正在构建微服务，则可能会预料到将来的某些需求，例如快速扩展和添加新功能以满足业务需求。最初，在微服务中构建的库可能能够以最小的操作中断来处理服务之间的通信。如果通过增加规模和功能来发挥微服务的潜力，那应该不会长期持续下去。随着时间的流逝，随着服务的请求过载，开发人员花费越来越多的时间为每个服务编码请求逻辑，这可能会导致问题。所以使用服务网格是一个最佳的选择。

开源项目推荐：

RESTdoc文档软件是一个颠覆传统API文档工具(swagger,showdoc,spring rest doc)设计的一个软件，采用不侵入业务，便可以快速测试和文档生成。

如果觉得对您有用的话，动动小手点亮star。

联系我们：[e-mail]