服务网格是一种众所周知的集成微服务和迁移到云基础设施的架构模式。 如今，在云容器世界中，没有它是非常困难的。 市场上已经有几种开源服务网格实现，但它们的功能、可靠性和安全性并不总是足够，特别是当涉及到全国大型金融公司的要求时。 这就是为什么我们 Sbertech 决定定制 Service Mesh，并想谈谈 Service Mesh 的优点、缺点以及我们将采取的措施。
随着云技术的普及，Service Mesh 模式越来越受欢迎。 它是一个专用的基础设施层，可以简化不同网络服务之间的交互。 现代云应用程序由数百甚至数千个此类服务组成，每个服务可以有数千个副本。
这些服务之间的交互和管理是Service Mesh的关键任务。 事实上，这是一个由许多代理组成的网络模型，集中管理并执行一组非常有用的功能。
在代理级别（数据平面）：
- 分配和分发路由和流量平衡策略
- 密钥、证书、令牌的分发
- 收集遥测数据，生成监控指标
- 与安全和监控基础设施集成
在控制平面层面：
- 应用路由和流量平衡策略
- 管理重试和超时、检测“死”节点（熔断）、管理注入故障并通过其他机制确保服务弹性
- 呼叫认证/授权
- 删除指标（可观察性）
对这项技术的开发感兴趣的用户范围非常广泛——从小型初创公司到大型互联网公司，例如 PayPal。
为什么企业部门需要 Service Mesh？
使用服务网格有许多明显的好处。 首先，它对于开发人员来说只是方便：用于编写代码 技术平台出现，由于传输层与应用程序逻辑完全隔离，因此显着简化了与云基础设施的集成。
另外， 服务网格简化了供应商和消费者之间的关系。 如今，API 提供商和消费者可以更轻松地自行就接口和合同达成一致，而无需涉及特殊的集成中介和仲裁者（企业服务总线）。 这种方法显着影响两个指标。 将新功能推向市场的速度（上市时间）加快了，但同时解决方案的成本也增加了，因为集成必须独立完成。 业务功能开发团队使用 Service Mesh 有助于保持平衡。 因此，API 提供商可以专注于其服务的应用程序组件，并将其简单地发布在 Service Mesh 中 - API 将立即可供所有客户端使用，并且集成的质量将是生产就绪的，并且不需要单个行附加代码。
下一个优点是 使用 Service Mesh 的开发人员仅关注业务功能 ——关于产品而不是其服务的技术组成部分。 例如，您不再需要考虑这样的事实：在通过网络调用服务的情况下，某个地方可能会发生连接失败。 此外，Service Mesh 有助于平衡同一服务副本之间的流量：如果其中一个副本“死亡”，系统会将所有流量切换到剩余的实时副本。
服务网格 - 这是创建分布式应用程序的良好基础，它向客户端隐藏了提供内部和外部服务调用的详细信息。 使用 Service Mesh 的所有应用程序在传输级别都与网络和彼此隔离：它们之间没有通信。 在这种情况下，开发人员可以完全控制其服务。
必须指出的是 在服务网格环境中更新分布式应用程序变得更加容易。 例如，蓝/绿部署，其中有两个应用程序环境可供安装，其中一个应用程序环境未更新且处于待机模式。 发布不成功时回滚到之前的版本是通过一个特殊的路由器来执行的，Service Mesh 的作用很好地应对. 要测试新版本，您可以使用 金丝雀发布 — 仅将来自试点客户组的 10% 的流量或请求切换到新版本。 主要流量流向旧版本，没有任何中断。
还 Service Mesh 为我们提供实时 SLA 控制。 当其中一个客户端超过分配给它的配额时，分布式代理系统将不允许服务失败。 如果 API 吞吐量有限，那么没有人能够用大量事务压倒它：Service Mesh 站在服务前面，不允许不必要的流量。 它只会在集成层进行反击，而服务本身将继续工作而不会注意到它。
如果公司希望降低集成解决方案的开发成本，Service Mesh 还可以帮助： 您可以从商业产品切换到其开源版本。 我们的企业服务网格基于服务网格的开源版本。
另一个优点—— 提供一套完整的集成服务。 因为所有集成都是通过这个中间件构建的，所以我们可以管理构成公司业务核心的应用程序之间的所有集成流量和连接。 非常舒服。
最后 服务网格鼓励公司转向动态基础设施。 现在许多人都在寻求集装箱化。 将整体架构切割成微服务，完美地实现这一切——这个话题正在兴起。 但当你尝试将一个已经生产多年的系统转移到一个新平台时，你立即会遇到许多问题：将其全部推入容器并部署到平台上并不容易。 而这些分布式组件的实现、同步和交互又是另一个非常复杂的话题。 他们将如何相互沟通？ 会不会出现连锁故障？ Service Mesh 可以帮助您解决其中一些问题，并方便从旧架构迁移到新架构，因为您可以忘记网络交换逻辑。
为什么需要Service Mesh定制？
在我们公司，数百个系统和模块共存，运行时负载非常大。 因此，一个系统调用另一个系统并接收响应的简单模式是不够的，因为在生产中我们需要更多。 您还需要企业服务网格提供什么？
事件处理服务
让我们想象一下，我们需要进行实时事件处理——一个实时分析客户行为并可以立即向他提供相关报价的系统。 要实现类似的功能，请使用 称为事件驱动架构 (EDA) 的架构模式。 当前的服务网格本身都不支持此类模式，但这非常重要，尤其是对于银行而言！
比较奇怪的是，Service Mesh 所有版本都支持远程过程调用（RPC），但对 EDA 并不友好。 因为Service Mesh是一种现代分布式集成，而EDA是一种非常相关的架构模式，可以让你在客户体验方面做独特的事情。
我们的企业服务网格应该可以解决这个问题。 此外，我们希望看到它使用各种过滤器和模板来实现有保证的交付、流媒体和复杂的事件处理。
文件传输服务
除了 EDA 之外，如果能够传输文件就好了：在企业规模上，通常只能进行文件集成。 特别是使用了 ETL（提取、转换、加载）架构模式。 通常，每个人都专门交换文件：使用大数据，推送单独的请求是不切实际的。 企业服务网格中原生支持文件传输的能力为您提供了业务所需的灵活性。
编排服务
大型组织几乎总是有不同的团队生产不同的产品。 比如在银行，有的团队做存款，有的团队做贷款产品，这样的案例还不少。 这些是不同的人、不同的团队，他们制造自己的产品、开发自己的 API 并将其提供给其他人。 通常需要组合这些服务，并实现顺序调用一组 API 的复杂逻辑。 为了解决这个问题，您需要集成层中的一个解决方案来简化所有这些复合逻辑（调用多个 API、描述请求路由等）。 这是企业服务网格中的编排服务。
人工智能和机器学习
当微服务通过单个集成层进行通信时，服务网格自然知道有关每个服务调用的所有信息。 我们收集遥测数据：谁打电话给谁、何时、多长时间、多少次等等。 当有数十万个这样的服务和数十亿次调用时，所有这些都会累积并形成大数据。 可以使用人工智能、机器学习等来分析这些数据，然后可以根据分析结果做一些有用的事情。 将集成到服务网格中的所有网络流量和应用程序调用的控制权至少部分移交给人工智能是合适的。
API网关服务
通常，服务网格具有在可信范围内相互通信的代理和服务。 但也有外部交易对手。 这群消费者对暴露的 API 的要求要严格得多。 我们将这个任务分为两个主要部分。
- 安全。 与 ddos、协议漏洞、应用程序、操作系统等相关的问题。
- 规模。 当需要向客户端提供的API数量达到数千甚至数十万时，就需要某种针对这组API的管理工具。 您需要不断监控 API：它们是否正在工作、它们的状态是什么、有哪些流量、有哪些统计数据等。 API 网关应该处理此任务，同时使整个过程易于管理且安全。 借助此组件，企业服务网格学会轻松发布内部和外部 API。
针对特定协议和数据格式的支持服务（AS网关）
目前，大多数服务网格解决方案只能在本机上使用 HTTP 和 HTTP2 流量，或者在 TCP/IP 级别以简化模式工作。 企业服务网格与许多其他非常具体的数据传输协议一起出现。 一些系统可能使用消息代理，其他系统则在数据库级别集成。 如果公司有SAP，那么它也可以使用自己的集成系统。 而且，所有这些都是有效的，并且是业务的重要组成部分。
你不能只是说：“让我们放弃遗留系统并创建可以使用 Service Mesh 的新系统。” 为了将所有旧系统与新系统连接起来（在微服务架构上），可以使用 Service Mesh 的系统将需要某种适配器、中介、网关。 同意，如果它和服务一起装在盒子里就好了。 AC 网关可以支持任何集成选项。 想象一下，您只需安装 Enterprise Service Mesh，它就可以与您需要的所有协议进行交互。 这种方法对我们来说非常重要。
这大致就是我们想象的企业版Service Mesh（Enterprise Service Mesh）。 所描述的定制解决了尝试使用集成平台的现成开源版本时出现的大部分问题。 服务网格架构仅在几年前推出，目前仍在不断发展，我们很高兴能够为其发展做出贡献。 我们希望我们的经验对您有用。
来源： habr.com