提供永久免费的API接口，查看更多API接口，如果您有其他免费API资源，请联系我们，造福人类。

定制开发，免费评估，免费咨询，价格便宜，售后保障，前往开发服务中心或联系开发客服中心

在云本机环境中，虚拟化是通过容器和应用程序实现的，通过微服务触发，实施安全性的最佳级别在哪里？几周前，ZDnet的同事Steven J.Vaughan Nichols报道了一家通过代理在操作系统级别提供服务的提供商。

现在，另一家初创公司寻求在微服务级别解决这一问题，其方法是分离API网关和服务网格之间的差异。

传统上，API网关是应用程序的集中点在应用层管理连接。它们管理客户端和微服务之间的流量，通常被称为南北流量，因为它通常来自数据中心之外的客户端。

相比之下，服务网格依赖代理，在分布式环境中，在应用程序和传输层管理连接方面获得了吸引力。它们通常在Kubernetes集群或数据中心内处理所谓的东西向流量。如果设计得当，每个代理都会对微服务可以相互对话的规则进行编码。

在某些情况下，服务网格会将一些应用程序连接管理委托给充当连接子层的API网关。是的，关于这一主题的电子书已经出版。

Solo.io的创始人看到了一个迫在眉睫的问题，这是由于Anthos和OpenShift等Kubernetes平台，服务网格开始获得吸引力。他们看到的挑战是管理的可伸缩性：每个代理的策略或规则必须逐个开发。它们无法跨多个代理进行管理。对于治理或安全，这些平台通常需要外部网关或操作系统级替代方案来实施策略，每个主要云上的K8s服务也是如此。

这些工作的劳动强度可能会削弱云本机部署的主要优势：简化的控制平面，由于K8s等事实上的标准，它承诺了更大的灵活性，使其成为第二天性向上或向下扩展云本机群集。

Solo.io最初开发了一种基于特使代理的产品，该代理在Istio服务网格中充当API网关，用于管理客户端和Kubernetes群集之间的流量。他们最近扩展了一个更全面的企业产品，可以跨一个或多个Kubernetes集群管理多个服务网格。其理念是，虽然策略的实施可能分布在多个代理上，但可以集中一致地管理，而无需对每个代理单独编码。

Gloo Mesh Enterprise通过增强可观察性，增加了Istio的控制平面，以便随时间对行为进行监控和故障排除；将外部证书提供商与现有PKI基础设施集成；并支持发现每个托管服务网格的入口路径。

这是开源世界中解决此问题的一些活动。网络服务网格旨在提供用于解决连接性、安全性和可观察性的通用API。它将允许单个K8s吊舱跨集群或云安全地联网；但是这个项目仍然在云计算的基础上。p>

我们对基于K8s的云平台出现的看法是，它们是基于标准构建的，这意味着在构建允许集群上下伸缩的动态粘合剂时，组织不必重新发明轮子。但我们也相信，对于大多数缺乏构建自己私有云的复杂资源的组织来说，K8s开发不应该在家里完成。好消息是，有一些像Solo.io这样的初创公司开始解决一些管理缺口。

Bigeye将目光投向数据可靠性工程

HVR会成为Fivetran进入企业的门户吗？

Fivetran收购了HVR，增加了565美元的资金

DataStax将Astra DB serverless扩展到多个地区

2023-03-22 10:04:44