【51CTO.com快译】分布式计算最基本的概念之一是端点。可以通过输入和输出来了解每一个软件片段——对象、微服务、应用程序，而这些都被称之为交互端点。
在分布式计算的历史上，端点有多种形式：套接字、IP地址、接口、Web服务和入口等。无论它们的性质如何，其他软件必须能够找到合适的端点，连接或绑定它们，并与它们交互。
端点也代表攻击面中的漏洞，因此保护它们也是至关重要的。在最基本的情况下，端点是物理分布式计算架构的一部分。但是，如果只是处理物理端点，就几乎没有灵活性，因此，如果可编程性有限，并且它们的可用性受到严重限制。由于这些原因，很多企业多年来就采用了许多抽象端点的方法，如今在构建云原生基础设施时延续了这一趋势。
然而，在新的云原生计算模式中，抽象的端点具有新的含义。
抽象端点层
事实上，抽象端点既平凡又普通。DNS服务器抽象IP地址，其分配可以根据需要重新分配域名。负载均衡器可以将请求定向到不同的服务或应用程序端点，而请求者并不知道。
表述性状态传递(REST)的核心是使用URL来抽象端点和它们支持的操作。底层基础设施可能会利用Web服务器、负载平衡器或API网关(或某些组合)来解析URL，并将流量定向到适当的物理端点。
REST场景强调了抽象端点的一个重要原则：通常情况下，一条消息可能会遍历几种不同的技术，每个技术都将不同的抽象端点层添加到组合中。虽然这些层增加了架构的复杂性，但为端点消费者增加灵活性和简单性的好处通常会超过这种复杂性的成本。
云原生计算中的抽象端点
云原生计算需要其他形式的分布式计算不需要的额外抽象端点。
这种额外复杂性的原因是Kubernetes本身目标的基础：在容器、Pod和集群级别提供快速而无限的水平可扩展性。
服务网格使用代理在特定微服务实例之间路由“东西向”流量，即使请求的微服务通常也不知道在特定时间点有多少实例可用或它们的IP地址是什么。
换句话说，服务网格在入口点提供抽象端点，这对于使用在Kubernetes上运行的微服务至关重要。
当请求者位于相关微服务域之外时，同样的原则适用于“南北向”流量。在这些情况下，API网关处理抽象端点。
实现这些抽象端点的底层技术是不同的：东西向流量的Sidecar和代理以及南北向流量策略驱动的安全API网关。
云原生零信任
为抽象端点提供足够和适当的安全性给基础设施和安全团队带来了新的挑战。考虑到Kubernetes部署的动态特性及其对混合IT场景的支持，零信任方法将所有端点视为不可信，除非证明是可信的。
只有一个问题：“传统的”零信任方法无法胜任这项任务。这种零信任的原始方法将端点与人类用户相关联，因此传统的身份和访问管理技术仅适用于管理与端点关联的人类身份。
相比之下，在云原生世界中，端点可能是微服务、API、智能手机、物联网传感器或任何数量的其他类型的技术。因此，不再可能利用人类身份来访问大多数抽象端点。云原生零信任需要不同的方法。
连接与集成
云原生计算中的抽象端点使任何其他端点(消费者/请求者、消息源或接收者等)能够在给定基础设施的场景中找到并绑定到该端点。该基础设施可能包括Kubernetes、服务目录或其他支持技术。
这种能力称之为端点连接。事实上，“连接性”这个术语本身就代表一种抽象，利用现有的端点抽象使这些端点能够根据定义抽象的策略相互交互。
然而，连接性并不等同于集成。集成端点当然需要连接性，但也需要在端点之间移动消息的机制。在Kubernetes之前的世界中，集成技术还提供了各种“智能”功能，包括数据转换、安全性、流程逻辑执行等。
依赖于这种集成中间件来完成这项繁重工作的架构就是所谓的“智能管道、哑端点”架构。企业不仅在大部分工作中利用集成技术，而且除了遵守各自的契约(例如，Web服务的WSDL契约或RESTful端点的互联网媒体类型)之外，不必依赖端点来完成更多的工作。
面向服务架构(SOA)时代最重要的教训之一是智能管道方法过于集中，因此不是特别适合云计算。随着分布式计算架构转向云计算，现在转向云原生，人们将繁重的工作从中间件移出，转而依赖轻量级排队技术和其他开源集成方法。
如果管道以这种方式从智能变为非智能，那么端点只会从非智能变为智能。在某种程度上，只要所说的智能端点是抽象端点，它们就必须如此。毕竟，物理端点可能仍然是IP地址、API或URL。人们不希望此类协议和技术比以往更智能。
与其相反，人们依赖于抽象的端点基础设施来了解如何处理数据转换、安全性、策略实施，以从企业服务总线(ESB)和其他传统中间件所需的所有其他功能——现在才抽象出Kubernetes的可扩展性和临时性环境。
也可以抽象集成吗?
假设一个端点是物联网传感器，另一个是基于云的API。如果充分抽象了这些端点，那么就为它们提供了连接性。
但是仍然必须物理地将消息从一个传输到另一个——例如，这项任务可能包括5G、专用MPLS链路、某种中间件以及进入选择的云平台。
在理想的云原生世界中，人们将根据既定策略自动处理此类集成的配置、管理和安全性，使人们能够抽象集成以及端点本身，从而能够出于性能或成本原因，在最终用户不知情的情况下，将一项技术转换为另一项技术。
其结果就是基于意图的集成。利益相关者将表达端点之间交互的业务意图(延迟、数据主权、可靠性和其他要求)，基础设施将自动、动态地选择最佳路由拓扑和集成技术，以持续地符合该意图。
SD-WAN等技术提供了部分解决方案，但这种基于意图的集成的全部范围仍主要在绘图板上(尽管开源NATS项目正在顺利实现这一愿景)。然而，没有理由进行等待。抽象端点在今天已成为现实，因此了解如何在云原生场景中实现它们对于兑现Kubernetes的承诺至关重要。
请求/回复
这篇文章中使用了请求/回复示例，因为它们比异步交互更易于解释和理解。事情的真相是，异步、实时的流交互更像是云原生计算的规范，而请求/回复模式则是一个特例。
因此，重要的是要指出，抽象端点对于异步流用例也同样重要。事实上，有一类新的“事件网格”技术概括了当今服务网格处理异步流数据流的能力——既适用于东西向流量，也适用于南北向流量。
当然，处理流数据流的策略执行、安全性和可靠性会带来一系列挑战，例如提高抽象端点重要性的标准。
随着边缘计算的成熟和流数据越来越成为企业计算的规范，而抽象集成以及端点对于保持云原生计算所承诺的可扩展性、灵活性和弹性将变得越来越重要。
原文标题：Cloud-Native Essentials: Abstracted Endpoints，作者：Jason Bloomberg
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
