江苏龙网

  1. 首页 > 资讯 > 科技 > >

服务|围观KubeCon 2020丨火了 2 年的服务网格究竟给微服务带来了什么？( 三 )


注意 ， 这里提到了一个词“大部分” ， SDK 中往往还需要保留协议编解码的逻辑 ， 甚至在某些场景下还需要一个轻量级的 SDK 来实现细粒度的治理与监控策略 。 例如 ， 要想实现方法级别的调用链追踪 ， 服务网格则需要业务应用实现 trace ID 的传递 ， 而这部分实现逻辑也可以通过轻量级的 SDK 实现 。 因此 ， 从代码层面来讲 ， 服务网格并非是零侵入的 。
第二 ， 异构系统的统一治理 。 随着新技术的发展和人员更替 ， 在同一家公司中往往会出现不同语言、不同框架的应用和服务 ， 为了能够统一管控这些服务 ， 以往的做法是为每种语言、每种框架都开发一套完整的 SDK ， 维护成本非常之高 ， 而且给公司的中间件团队带来了很大的挑战 。 有了服务网格之后 ， 通过将主体的服务治理能力下沉到基础设施 ， 多语言的支持就轻松很多了 。 只需要提供一个非常轻量级的 SDK ， 甚至很多情况下都不需要一个单独的 SDK ， 就可以方便地实现多语言、多协议的统一流量管控、监控等需求 。
此外 ， 服务网格相对于传统微服务框架 ， 还拥有三大技术优势：
可观察性 。 因为服务网格是一个专用的基础设施层 ， 所有的服务间通信都要通过它 ， 所以它在技术堆栈中处于独特的位置 ， 以便在服务调用级别上提供统一的遥测指标 。 这意味着 ， 所有服务都被监控为“黑盒” 。 服务网格捕获诸如来源、目的地、协议、URL、状态码、延迟、持续时间等线路数据 。 这本质上等同于 web 服务器日志可以提供的数据 ， 但是服务网格可以为所有服务捕获这些数据 ， 而不仅仅是单个服务的 web 层 。 需要指出的是 ， 收集数据仅仅是解决微服务应用程序中可观察性问题的一部分 。 存储与分析这些数据则需要额外能力的机制的补充 ， 然后作用于警报或实例自动伸缩等 。
流量控制 。 通过 Service Mesh ， 可以为服务提供智能路由（蓝绿部署、金丝雀发布、A/B test）、超时重试、熔断、故障注入、流量镜像等各种控制能力 。 而以上这些往往是传统微服务框架不具备 ， 但是对系统来说至关重要的功能 。 例如 ， 服务网格承载了微服务之间的通信流量 ， 因此可以在网格中通过规则进行故障注入 ， 模拟部分微服务出现故障的情况 ， 对整个应用的健壮性进行测试 。 由于服务网格的设计目的是有效地将来源请求调用连接到其最优目标服务实例 ， 所以这些流量控制特性是“面向目的地的” 。 这正是服务网格流量控制能力的一大特点 。
安全 。 在某种程度上 ， 单体架构应用受其单地址空间的保护 。 然而 ， 一旦单体架构应用被分解为多个微服务 ， 网络就会成为一个重要的攻击面 。 更多的服务意味着更多的网络流量 ， 这对黑客来说意味着更多的机会来攻击信息流 。 而服务网格恰恰提供了保护网络调用的能力和基础设施 。 服务网格的安全相关的好处主要体现在以下三个核心领域：服务的认证、服务间通讯的加密、安全相关策略的强制执行 。
服务网格带来了巨大变革并且拥有其强大的技术优势 ， 被称为第二代“微服务架构” 。 然而就像之前说的软件开发没有银弹 ， 传统微服务架构有许多痛点 ， 而服务网格也不例外 ， 也有它的局限性 。
增加了复杂度 。 服务网格将 sidecar 代理和其它组件引入到已经很复杂的分布式环境中 ， 会极大地增加整体链路和操作运维的复杂性 。
运维人员需要更专业 。 在容器编排器（如 Kubernetes）上添加 Istio 之类的服务网格 ， 通常需要运维人员成为这两种技术的专家 ， 以便充分使用二者的功能以及定位环境中遇到的问题 。
延迟 。 从链路层面来讲 ， 服务网格是一种侵入性的、复杂的技术 ， 可以为系统调用增加显著的延迟 。 这个延迟是毫秒级别的 ， 但是在特殊业务场景下 ， 这个延迟可能也是难以容忍的 。
平台的适配 。 服务网格的侵入性迫使开发人员和运维人员适应高度自治的平台并遵守平台的规则 。


推荐阅读


上一篇：小米手机|雷军罕见官宣，小米10Pro+定档8月！120W旗舰真的来了

下一篇：极光|极光为华硕ROG 3搭建符合统一推送联盟标准的推送系统