容器原生应用服务

越来越多的应用服务成为云原生架构不可或缺的组成部分。 这在一定程度上解释了为什么我们看到应用服务的责任从 IT 运营转向 DevOps。

我们在应用服务状况研究中追踪了 30 多种不同的应用服务。 还有更多，每年我们都会审查列表以确定删除什么和添加什么。

2020 年，我们将多项应用服务整合到更广泛的类别中。 例如，网络防火墙、反垃圾邮件、IPS/IDS 和垃圾邮件缓解被汇总到“通用安全服务”中。  我们决定采用这种方法有两个原因。 首先，因为六年的数据表明应用服务的分组部署率非常相似。 其次，因为我们想为新兴的应用服务腾出空间，并且不想让已经非常有耐心的受访者群体感到压力过大。

这些新兴的应用服务几乎都是容器原生的应用服务。 它们通常（但并非总是）作为交付云原生应用所需操作环境的一部分进行部署。 考虑入口控制、服务发现和服务网格。 API 网关也通常与云原生应用s紧密耦合，尽管它们的用法与任何基于 API 的应用大致一致。

鉴于它们对于交付现代云原生应用程序的重要性日益增加，以及我们所看到的令人难以置信的部署率，现在似乎是介绍这些云原生方法拥护者的好时机。

入口控制

2020 年application服务部署状况： 入口控制

入口控制是 Kubernetes 世界引入的一个概念，用于对 HTTP 请求进行切分。 它允许操作员轻松地将 URI 映射到特定的 Kubernetes 服务。 这使得入站（入口）请求能够路由到正确的微服务实例。

这不是一个新概念。 热心的读者会记得，我经常称赞 HTTP（第 7 层）路由的优点，特别是作为旨在协助更有效的扩展策略的架构组件。 如果你不记得了或者刚刚加入我们，这个主题演讲可以作为一个很好的复习： 那么你认为你可以扩大规模吗？

新颖之处在于“地图”的管理方式。 入口控制器需要根据容器集群内部的当前情况动态更新。 这意味着入口控制器需要了解集群的当前状态。 这意味着通过其操作 API 与适当的 Kubernetes 组件集成。

这种集成将入口控制与环境绑定在一起，从而将其融入到应用程序架构中。 功能齐全的入口控制器本质上是“容器原生的”，因为它是扩展和操作云原生应用所需的基础设施的一部分。 

服务发现

2020 年application服务部署状况： 服务发现

关于云原生applications的一个有趣的事实是其组成部件的寿命。 容器集群内部可扩展性的动态特性必然意味着“容器”处于不断变化之中。 Sysdig 的最新数据显示，流量不断增加，39％的容器存活时间少于一分钟，54％的容器存活时间少于五分钟。

问题在于其他组件需要能够找到这些容器。

这就是服务发现组件的存在理由。 这些组件在容器集群内部运行，作为服务的“权威源”。 感兴趣的各方可以查询该组件来发现如何连接和与给定的服务进行通信。 通过实时跟踪服务，服务发现组件解决了集群的波动性并使其他组件（如入口控制）正常运行。 

服务网格

2020 年application服务部署状况： 服务网格

服务网格可能是容器原生应用服务中最具争议的。 这并不是因为它的概念价值，而是因为实施偏好。 服务网格旨在解决容器集群内的可见性、规模和安全性问题。 它们被实现为超连接代理（边车或每个应用程序），并为开发人员和运营商提供各种功能。

服务网格不是您在容器集群之外可以找到的应用服务。 与发现和入口控制一样，服务网格与容器环境紧密集成。 这也使其成为容器原生应用服务。 

容器原生应用服务

我们（行业和企业我们）从来没有这样对应用服务进行过分类。 当然，我们根据它们的主要用途进行分类：安全性、可用性、性能、移动性和身份。 但这些都是广泛的使用类别，并且都不是应用程序架构所特有的。

但是，与云原生架构的集成和依赖可能使得这些应用服务（以及将来可能出现的任何其他服务）必须这样做。 这是因为一个（应用服务）的增长清楚地表明了另一个（应用架构）的增长，反之亦然。 这是一种独特的情况，其中应用服务和应用程序紧密交织在一起，因此两者的部署率非常相似。 

就像我们区分移动 IOS 和 Android 应用程序一样，我们可能会发现将那些设计为仅在容器化环境中运行的应用服务标记为“容器原生”而不是在其他地方运行的应用服务很有价值。

无论我们如何对它们进行分类，它们以及依赖它们的应用程序无疑正在崛起。