应用程序网络功能将走向何方，这可能会如何影响我们未来设计和处理分布式应用程序的方式？这些启示可能会让你感到惊讶。让我们探索应用程序网络的转移，重点关注随着应用程序云的兴起，网络问题的移动。解开透明、同步和异步网络的复杂性，让我们在现代分布式架构的背景下研究这些方面的迁移和转换。

　　透明的网络下降到平台

　　分布式应用程序由多个组件组成，这些组件使用网络相互交互。这些交互可以在运行时通过服务网格和其他类似技术透明地控制到应用程序，或者通过点对点集成、事件驱动或基于编排的交互等显式实现模式从应用程序内部控制。

　　在这里，我定义了透明网络作为控制和监控机制，可以添加到应用程序相互交互的行为中，而无需让开发人员和应用程序实现意识到。想想Kubernetes在不了解其如何完成的情况下执行的服务发现或负载平衡。想想交通转移，以及弹性功能，如Istio的侧车执行的重试和断路。想想mTLS、身份验证和授权，或者网络跟踪和可观察性，您可以通过Cylrium基于eBPF的实现从Linux内核获得。

　　所有这些功能都可以在运行时添加到分布式应用程序中，而无需更改应用程序代码，也无需开发人员在应用程序中实现一行代码。

　　这些担忧曾经由应用程序层的开发人员通过Java生态系统中的Apache Camel或Spring Cloud Netflix等特定语言库来解决，但今天，它们越来越多地被委托给Dapr等多语言运行时，或通过Envoy等透明侧车委托给平台层，甚至在eBPF技术和闭源网络云服务的情况下与计算平台深入嵌入。

　　远离应用程序的同步网络

　　应用程序之间的同步交互不需要任何类型的中介持久状态存储，例如消息代理将请求卸载到应用程序中间介质中。因此，我在这里描述的同步交互通常会阻止客户端应用程序发起的交互，并在同一调用中到达目标服务。这里考虑的应用程序责任类型是各种外部API的连接器、解决方案中服务之间的调用和协议转换。这还包括基于内容的路由、过滤和请求的轻度转换、将多条消息聚合为一条消息或将一条大消息拆分为多条消息。最后一组可以用持久的状态存储来完成，但在这里，我考虑的是当它实时完成时，没有持久性。总的来说，这些应用程序网络问题包括“企业集成模式”一书中列出的消息路由和消息转换模式。

　　虽然这些关注点传统上是从应用程序内部实现的，并且主要在Java生态系统中很受欢迎，例如Apache Camel和Spring Integration等项目，但今天我们可以看到这些功能转移到专用的即插即用运行时，可以与许多多语言应用程序一起使用。这些例子包括Dapr sidecar、Apache Kafka Connect、Knative Event Sources、NATS和各种基于云的托管连接器和流量路由服务，如用于路由流量的AWS API Gateway或用于路由事件的AWS EventBridge等。

　　在所有这些示例中，应用程序将消息传递给一个单独的运行时，其中执行消息路由和转换逻辑，并将结果传递回应用程序或转发给另一个应用程序。应用的路由、过滤和转换逻辑会影响数据的形状及其流入的目标。

　　与运营团队在应用程序实施后可以应用的透明功能不同，开发人员使用同步网络功能，应用程序的设计和实现必须考虑到这一点。

　　因此，我们可以看到同步网络功能不会透明地沉入平台，而是从库转换为专门构建的可重用运行时和云服务，这些服务可以插入任何应用程序并在需要时进行交换，而不会影响应用程序的实现。后者可以通过使用六边形架构原则设计应用程序，并通过采用的开放标准将其与外部依赖项脱钩。

　　今天，在这个空间中没有单一的普遍采用的标准或实现，但有一些常用的消息模式（如过滤器、基于内容的路由器、窃听、聚合器和拆分器）作为一种普遍理解的语言。这些模式通常通过特定于域的语言或使用通用表达式语言规范实现，并处理在HTTP或gRPC协议上的CloudEvents包装器中格式化的JSON或ProtoBuf数据。

　　异步网络向云的提升

　　异步网络允许应用程序在与其他服务交换数据之前将状态存储到外部系统中供自己使用或作为临时存储。例如，开发人员可以使用外部状态存储（如Redis）进行键/值访问，或使用对象存储（如AWS S3）来存储状态并使服务无状态。应用程序可能会使用Apache Kafka等消息代理来发布其他服务可能感兴趣的事件。应用程序可以启动存储在持久工作流引擎（如Conductor）中的业务流程，该引擎需要协调与其他服务的交互。当我们查看源服务和目标服务之间的端到端交互时，在与其他服务交换之前，中间系统中会持续存在一种状态。这些异步网络交互风格使用一些众所周知的方法，如pub/sub、键/值访问、编排、cron作业、分布式锁等，以可预测和可靠的方式在参与者之间分配状态。

　　每种异步网络模式在状态之上都提供了独特的交互风格。键/值和对象存储通常从同一应用程序访问的卸载状态。消息代理用于在发布者服务和一个或多个收件人服务之间进行异步通信。工作流用于协调多个应用程序之间的复杂状态交互，或在基于时间的间隔上触发服务端点。

　　还有其他状态应用程序基础设施的专门示例：例如，从中央配置存储区分发应用程序配置、分发机密、使用分布式锁相互排斥地访问资源等。这些交互对应用程序来说是显而明确的，开发人员需要以与这些专业系统交互的方式开发应用程序。有许多API正在成为每个领域广泛采用的标准。例如，Redis、MongoDB和Amazon Web Services (AWS) S3是用于键/值和文档访问的流行API示例。Apache Kafka、AMQP、NATS是异步交互协议的例子。Camunda、指挥和Cadence是状态编排引擎的例子。

　　虽然这些项目专注于单一类型的有状态交互，并提供实现和API，但Dapr项目专注于为不同的交互风格提供统一的API，并将其插入现有的后端实现中。例如，Dapr statestore API可以与Redis、MongoDB、PostgreSQL等一起使用。Dapr pubsub API可以与Kafka、AWS SQS、GCP Pub/Sub、Azure EventHub等一起使用。其配置、秘密和分布式锁API还插入现有的基础设施系统，并提供基于gRPC的统一多语言高级HTTP和gRPC协议来抽象这些后端。

　　为了应对管理状态的固有复杂性，该行业正在经历一个显著的转变，异步网络功能越来越多地作为SaaS解决方案提供。这种过渡简化了采用过程，简化了可扩展性，并增强了这些服务的可管理性。

　　Apache Kafka是一个广泛使用的消息代理，现在可以作为Apache Kafka（MSK）的Confluent Cloud和AWS托管流访问。同样，传统上由内部管理的Redis和MongoDB等密钥/价值存储已经演变为云服务。Redis Labs的完全托管云服务和MongoDB Atlas具有集成资源和工作负载优化的全球可用服务证明了这种转变。

　　有状态工作流系统也已进入SaaS领域，简化了开发人员在应用程序之间编排复杂的有状态交互的任务。AWS Step Functions、Temporal Cloud、Orkes和Diagrid Cloud正在引领这一演变。这种有状态网络项目的SaaS转型是由抽象状态管理复杂性的愿望驱动的。它使开发人员能够专注于业务逻辑，而不是复杂的异步交互。

　　应用程序网络的发散路径

　　分布式应用程序由多个组件组成，这些组件分布在多个进程中，这些进程通过网络相互交互。分布式应用程序（如更快的发布周期和可扩展性）的主要优势在于不同的网络模式如何以可预测的方式促进依赖项的隔离和参与者之间的状态分布。然而，网络在分布式系统编程模型、可靠性、安全性和可观察性方面带来了新的挑战。与容器采用如何将重要的应用程序责任从开发人员转移到运营团队类似，我们也可以观察到不同类型的网络问题发生了变化。

　　透明的网络功能虽然功能有限，但随着它们被集成到平台产品中，它们正变得越来越普遍。有了合适的平台功能，开发人员不再需要担心网络安全、可观察性和流量管理。

　　无状态交互将网络与数据格式和消息转换逻辑知识相结合。通过标准连接器和作为专用分布式系统中间件实现的企业集成模式，这种交互越来越容易重用。开发人员不必在每种语言和应用程序堆栈中不断重新发明轮子，而是在运行时将这些功能插入到他们的应用程序中。如果有足够的时间，这些网络模式将成为可重用库、专用框架和侧车，并最终过渡到基于云的API。

　　异步交互具有更高的复杂性，因为它们需要幕后状态管理。这些网络交互通常作为专门的独立软件或托管服务提供，最好由广泛采用的API提供。与沉入计算层并主要由运营团队使用的透明API不同，异步网络交互出现在为应用程序开发人员创建的云产品中。

　　预计网络责任的这种发展将推动透明的运行时和网络功能进一步进入计算平台。与此同时，显式功能将继续整合，形成通用API，并作为无处不在的无服务器功能提升到云端。适当地将职责下放给不同层，并为不同的网络任务选择适当的标准化API，这变得越来越重要。因此，这一大趋势将使开发人员能够专注于实现业务逻辑，透明地或通过普遍认可的便携式API集成其他功能。