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