服务连接不是你的工作，但仍然是你的问题

客座文章最初由Kong联合创始人/首席技术官Marco Palladino在Kong的博客上[1]发表

作为一名开发人员，你的公司雇佣你来开发专注于用户和客户需求的令人难以置信的产品。然而，在微服务时代，生产最好的产品很大程度上依赖于高效的云服务连接。例如，电子商务市场不仅仅是客户通过浏览器访问的前端UI。它需要与多个其他服务保持连接，例如库存管理系统、产品评论和支付处理器等等。

你可以通过在每个应用程序中编写更多的代码来创建智能客户端来解决这个问题，这些客户端可以连接到网络中的其他服务并向其发出请求。

智能客户端可以发现、保护、路由、观察和监视在我们的应用程序中生成的所有请求。但是这就占用了构建应用程序的宝贵时间——这是你真正的工作。相反，你最终将无限期地为应用程序编写和维护服务连接性。这还包括，如果你最终采用了或系统中已经有了不止一个框架或语言，则必须将这些智能客户机复制到不同的语言中。为你创建的每个应用程序这样做将不可避免地导致技术债务、安全风险和潜在的收入损失。

第二个选择是完全忽略这些云连接问题，让架构师团队来考虑它们。

理论上，这是可行的。管理一个现代化的基础设施应该像管理一个城市。建筑师应该建造基础设施、道路和桥梁。然后，当一切就绪时，应用程序团队最终可以专注于构建他们的应用程序（建筑），让其他人来操心如何通过基础设施与其他服务通信。

这样做的问题是，你的架构师团队没有做好他们的工作。如果你不做，没人会做。如果你的云连接失败，你的应用程序就会失败，导致用户和客户的不满。不满意的用户和客户可能会危及你的工作安全和公司。

不幸的是，将云原生应用程序的连接性有自己处理可能弊大于利。当开发者自己管理时，我们发现了两个通常会出现的重要问题：

1. 这创建了一个支离破碎的架构。
2. 从长期来看，这会降低他们的生产力。

幸运的是，还有第三种选择：利用开源服务网格。

我们创建Kuma[2]就是为了以一种易于实现和易于管理的方式为开发人员解决这些挑战。

在本文的其余部分，或者如果你喜欢看下面的CNCF网络研讨会记录，我们将探索一个服务网格如何提高你的生产力，并解决你公司的连接挑战。

提高开发人员的生产力

服务网格从根本上改善了公司架构中不同服务之间的连接。服务网格一词意味着拥有多个服务，这无疑是经常发生的情况。无论你的系统中有多少服务在运行，你仍然可以从所有这些服务之间改进的连接性、可观察性和安全性中受益。它可以是数千个独立的应用程序，一个与数据库对话的单体应用，或者介于两者之间的任何东西。

不要与API管理工具（如API网关）混淆。服务网格和API网关一起工作，但支持不同的用例。

作为服务网格的通用控制平面，Kuma位于一个抽象层上，这个抽象层可以同时在传统基础设施、虚拟机（VM环境）、裸金属、Kubernetes和现代架构上工作。我们在Envoy的基础上构建了Kuma，依靠它的边车代理功能。

通过Kuma服务网格（一个CNCF沙箱项目）你可以部署一个进程外代理（Envoy），它可以与你的服务一起运行。Envoy代理将拦截服务发出的每个传出请求。在第一次部署之后，它将处理该请求。这意味着从开发人员的角度来看，你可以假设特定的请求总是可以工作的，是安全的和可观察的。其他一切都由边车代理负责。

这些进程发生在L4-L7，这意味着使用任何协议的任何数据库、系统或服务的任何流量都可以从该模式中受益。但是你拥有的边车代理越多，配置它们就越困难。你不希望手动重新部署、重新启动或重新配置边车代理。你希望从一个集中的位置进行此操作，然后将该配置推到边车代理。这就是Kuma控制平面[3]的角色。

这个全局控制平面是边车代理必须动态获取或接收或请求执行你想要执行的所有特性的所有配置的真实来源。使用Kuma之前不需要Envoy的专业知识。

通过设计，Kuma已经知道网格中每个数据平面代理和服务的地址，所以没有必要使用第三方服务发现工具或DNS解析器来使用Kuma。

Kuma附带一个RESTful API[4] HTTP接口，一个内置的GUI和一个官方的CLI。你可以很容易地使用它们来检索每个环境中的配置和策略的状态。

在你专注于构建实际产品的同时，Kuma服务网格会完成所有修复和保护连接的工作，以确保请求永远不会失败。

大规模解决连接挑战

除非你在一家小公司工作，否则你可能不是唯一一个面临这些挑战的团队。

避免可避免的连接危机。现在是解决这个问题的最佳时机。随着公司组建更多团队、创造更多产品并支持更多平台，这只会变得越来越困难。它们变得越解耦，越分散，它们发出的请求就越多。

即使你的公司中不同的团队在以不同的速度运行并且使用其他平台，他们仍然可能面临挑战。无论哪种情况，Kuma的通用服务网格都为它们提供了功能。

Kuma来自于我们在Kong与数百家企业组织和企业客户的经验。我们将Kuma作为另一个开源项目，加入我们其他开源项目的大家庭，如Kong Gateway[5]和Insomnia[6]，来解决连接问题。

当我们与客户和用户交谈时，我们收到的最关键的反馈是，现有的服务网格太难操作了。我们不希望为每个团队创建一个新的集群。相反，我们想要实现一个高级的控制平面。在控制平面上，我们希望他们为每组提供不同的措施。

我们鼓励你通过在你选择的平台上免费安装Kuma[7]服务网格来解决你的生产力和连接挑战。

我们相信服务网格的实现[8]并不复杂。看看安装Kuma是多么容易，并开始使用它。

[1]

Kong的博客上: https://konghq.com/blog/service-connectivity-problem

[2]

Kuma: https://kuma.io/

[3]

Kuma控制平面: https://konghq.com/blog/introducing-kuma-universal-service-mesh/

[4]

RESTful API: https://konghq.com/learning-center/api-gateway/what-is-restful-api/

[5]

Kong Gateway: https://konghq.com/kong/

[6]

Insomnia: https://insomnia.rest/

[7]

安装Kuma: https://kuma.io/install/latest/

[8]

服务网格的实现: https://konghq.com/blog/multi-cluster-multi-cloud-service-meshes-with-cncfs-kuma-and-envoy/

点击【阅读原文】阅读网站原文。

CNCF概况（幻灯片）

扫描二维码联系我们！

---

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。 

CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请长按以下二维码进行关注。