服务网如何简化微服务的可观察性
可观察性是一把大伞，涵盖了几个移动的部分。服务网格覆盖了很多地方，而不需要我们写一行代码。
服务网格和可观察性是微服务社区的热门话题。在这份趋势报告中，我们将详细探讨服务网格以及良好的可观察性堆栈如何帮助我们克服使用微服务时面临的一些最紧迫的挑战。
常见的微服务挑战
采用微服务是很难的。调试并确保它们持续运行更是难上加难。微服务以第2天操作的形式引入了大量的开销。让我们深入了解一下使微服务工作变得困难的几个方面。
分布式系统中的错误调试是一场恶梦
微服务的分布式性质使得调试错误变得困难。在单体系统中，仅仅通过日志和堆栈跟踪就足以确定错误的根本原因。当涉及到微服务时，事情就不那么简单了。在错误的情况下，挖掘微服务的日志可能不会直接指向准确的问题。相反，它可能只是提到一个错误存在于从依赖的微服务收到的请求和/或响应中。
换句话说，我们将不得不跟踪整个网络跟踪，以找出哪个微服务是问题的根源。这是一个极其耗时的过程。
识别系统中的瓶颈并不容易
在单体中，识别性能瓶颈就像剖析我们的应用程序一样容易。剖析通常足以弄清你的代码库中哪些方法消耗了最多的时间。这可以帮助你把优化工作集中在代码的一个小部分。不幸的是，弄清楚哪个微服务导致整个系统变慢是具有挑战性的。
当单独测试时，每个微服务可能看起来是高性能的。但在现实世界中，每个服务的负载可能有很大的不同。可能有某些核心的微服务，而其他的微服务又依赖于这些微服务。这样的场景在一个孤立的测试环境中是非常难以复制的。
维护微服务的依赖树是困难的
微服务的全部意义在于我们可以敏捷地发布新软件。说到这里，需要注意的是，在发布微服务的时候，可能会有一些下游影响。某些经常破坏功能的事件是：
- 在上游依赖性之前发布一个依赖性的微服务
- 移除遗留系统仍然依赖的已废弃的API
- 释放一个破坏API兼容性的微服务
当微服务之间没有明确的依赖树时，这些事件就难以避免。依赖关系树使我们更容易通知相应的团队并更好地计划发布。
可观察性。微服务问题的解决方案
我上面提到的所有问题都可以通过可观察性来解决。根据Jay Livens的说法，可观察性是根据系统产生的指标和日志来捕捉系统的当前状态的做法。它是一个帮助我们监控应用程序健康状况的系统，在故障情况下产生警报，并在问题发生时捕捉足够的信息来进行调试。
图1：可观察性堆栈的组成部分与开源实例
任何可观察性堆栈都会有以下几个部分：
- 指标/日志的来源--我们用来生成数据的代理或库
- 度量**/日志运送器**--将数据运送到存储引擎的代理；通常嵌入在度量源中
- 采集器/存储器--一个有状态的服务，负责存储生成的数据
- 仪表盘--使数据易于解释和消化的花哨的图表
- 警报管理器--负责触发通知的服务
幸运的是，有一些强大的开源工具可以帮助我们简化建立可观察性堆栈的过程。
引入服务网格
可观察性的一个主要方面是捕获网络遥测数据，拥有良好的网络洞察力可以帮助我们解决我们最初谈到的很多问题。通常情况下，生成这种遥测数据的任务是由开发人员来实现的。这是一个极其繁琐和容易出错的过程，在遥测时并没有真正结束。开发人员的任务还包括实现安全功能和使通信对故障有弹性。
理想情况下，我们希望我们的开发人员能够编写应用程序代码，而不是其他。微服务网络的复杂性需要被推到底层平台上。实现这种解耦的更好方法是使用Istio、Linkerd或Consul Connect等服务网。
服务网是一种架构模式，用于控制和监控微服务网络和通信。
让我们以Istio为例来了解服务网状结构的工作原理。
图2：典型的服务网状结构
资料来源。图片改编自 Istio文档
一个服务网状结构有两个主要部分：数据平面和控制平面。数据平面负责管理我们的微服务将产生的所有网络流量。为了实现这一目标，服务网状结构会在每个微服务旁边注入一个边车代理。这个挎包，通常是Envoy，负责透明地拦截所有流经服务的流量。另一方面，控制平面只是负责配置代理。任何应用流量都不会到达控制平面。
如图2所示，服务网状结构可以帮助你抽象出我们前面谈到的所有复杂问题。最重要的是，我们不用写一行代码就可以开始使用服务网状结构。服务网在管理基于微服务的架构的多个方面帮助我们。其中一些显著的优势包括。
- 获得流量流动方式的完整概览
- 控制网络流量的流动
- 确保微服务通信的安全
获得流量流动的完整概览
在图3中，应用程序A正在向应用程序B发出请求。由于坐在每个应用程序旁边的Envoy代理正在拦截该请求，它们对流经这两个微服务的流量有完全的可见性。代理机构可以检查这些流量，以收集信息，如正在进行的请求数量和每个请求的响应状态代码。
换句话说，服务网可以帮助我们回答以下问题。
- 哪个服务在与哪个对话？
- 每个微服务观察到的请求吞吐量是多少？
- 每个API的错误率是多少？
图3：服务网可以帮助收集指标
控制网络
服务网不只是一个沉默的旁观者。它可以积极参与到所有网络流量的塑造中。作为侧车使用的Envoy代理是HTTP感知的，由于所有的请求都流经这些代理，因此可以配置它们来实现一些有用的功能，比如。
- 自动退订--只要遇到网络错误，就能够重放请求
- 断路--将停止响应的上游微服务的不健康的副本列入黑名单
- 请求重写--当满足某些条件时，能够设置头文件或修改请求的URL
图4: 服务网可以塑造网络流量
而且这还没有结束。代理人还可以根据一定的权重来分割流量。例如，我们可以配置代理机构，将95%的传入流量发送到服务的稳定版本，而其余的可以重定向到金丝雀版本。这可以帮助我们简化发布管理过程，为金丝雀部署等高级实践提供动力。
确保微服务通信安全
使用服务网的另一个巨大优势是安全。我们的挎包代理可以被配置为使用相互TLS。这可以确保所有的网络流量在传输过程中自动加密。管理和轮换mTLS所需的证书的任务由服务网状结构控制平面完全自动化。
服务网状结构也可以通过有选择地允许哪种服务与哪种服务对话来协助访问控制。所有这些都可以帮助我们完全消除一系列的安全漏洞，比如中间人攻击。
图5：服务网可以保证网络流量的安全
服务网如何帮助实现可观察性？
我们刚刚看到了服务网是如何捕获遥测数据的。让我们再深入了解一下，这些数据可以为什么样的用例提供支持。
分布式跟踪
我们已经讨论了调试微服务的难度。解决这个调试问题的方法之一是通过分布式跟踪--捕获请求的生命周期的过程。仅仅一个图就可以使找出问题的根本原因变得非常容易。
大多数服务网格会自动收集和发送网络跟踪信息给Jaeger等工具。你所需要做的就是在你的应用程序代码中转发一些HTTP头信息。这就是了
流量指标
服务网可以帮助我们收集四个黄金信号中的三个，一个必须监测以确定服务的健康。
- 请求吞吐量--每个微服务所服务的请求数
- 响应错误率--失败请求的百分比
- 响应延迟--微服务响应所需的时间；这是一个直方图，你可以从中提取延迟的n个百分点
服务网收集的指标还有很多，但这些是迄今为止最重要的指标。这些指标可以被用来支持一些有趣的用例。其中一些包括。
- 启用基于高级参数的扩展，如请求吞吐量
- 启用高级流量控制功能，如速率限制和电路中断
- 执行自动化的金丝雀部署和A/B测试
网络拓扑结构
服务网状结构可以帮助我们自动构建网络拓扑结构，它可以通过结合跟踪数据和流量指标来构建。如果你问我，这是一个真正的救世主。网络拓扑结构可以帮助我们一目了然地看到整个微服务的依赖树。此外，它还可以突出我们集群的网络健康状况。这对于识别我们应用中的瓶颈是很有帮助的。
总结
可观察性是一个广泛的保护伞，包括几个移动的部分。对我们来说，幸运的是，像服务网格这样的工具覆盖了很多地方，而不需要我们写一行代码。简而言之，服务网格可以帮助我们。
- 产生分布式跟踪数据以简化调试工作
- 充当关键指标的来源，如微服务监控的黄金信号
- 生成网络拓扑结构
