转向无状态微服务是否会消除网络中的状态？
提高服务和应用程序可扩展性的方法之一是“无状态”。这样做的原因有很多，但总的来说，通过消除单个客户端和单个应用程序或服务实例之间的映射，您就不需要资源来管理应用程序中的状态（开销）并提高可分发性（我可以编造词如果我想要的话）跨实例池的请求。后者的发生是因为会话不需要闲逛和消耗可用于服务其他请求的资源。从理论上讲，分布应该更均匀并且能够实现更好的可预测性。一个请求需要一秒钟的时间来响应。就是这样。
这对“网络”很重要，因为有状态服务需要特定类型代理的特别关注。例如，负载平衡。选择一个实例来为第一个请求提供服务后，来自该客户端的所有后续请求都必须路由到同一实例。这也要求“网络”保持状态。
因此，当我们开始采用微服务及其无状态方法时，人们想知道这是否会向上游扩展，也进入“网络”。
答案是肯定的，也不是。
-
HTTP
这是应用层。如上所述，通过维护客户端和应用程序/服务之间的通信来维护此处的状态。 -
TCP
这是传输层。 TCP 是建立连接的方式。维护此处的状态以确保在客户端和应用程序/服务之间可靠地传递数据。 -
SSL
这是 TCP 和 HTTP 之间的无家可归层，提供数据的机密性。此处的状态得以维护，因为加密和解密依赖于客户端和应用程序/服务之间的连接所特有的信息。
现在。根据微服务的最佳实践，我们假设应用程序和/或服务是无状态的。这意味着无需在网络中维护 HTTP“状态”。所以它可以消失。噗！
但这还剩下 TCP 和 SSL（或 TLS，如果您愿意的话）。这些问题的答案取决于您的架构选择。如果您的负载均衡器（因为您有一个，我保证）正在终止 SSL/TLS，则网络中仍然需要状态。在架构上，您希望终止服务器上游的 SSL/TLS，以消除不仅在 Web 服务器上处理 SSL/TLS 所需的开销和重量，而且还消除与跨一组弹性 Web 服务器管理证书相关的成本和开销。
同样，如果您的负载均衡器根据 HTTP 层信息分发请求，它可能会终止 TCP。这意味着必须在网络中维护状态，至少在负载均衡器中。如果您使用任何类型的 Web 应用程序防火墙来检查数据（入站和出站），那么它也会终止 TCP 连接，从而保持状态。当然，如果您的负载均衡器正在执行任何类型的应用程序层 DDoS 保护（它应该这样做），则必须维护状态，因为它是检测过程的一部分。
所以这个问题的答案最终是“也许”。
最终，网络中的状态与微服务部署的架构选择有关，而不是微服务本身的性质。