rest服务json传递_微服务消息传递：为什么REST并非总是最佳选择

rest服务json传递

微服务是一项大生意。 得益于容器编排，多进程应用程序开发和庞大的用户需求方面的进步，公司正在从传统的单片应用程序向分布式，高可用性的微服务迈进。 将应用程序分成较小的块可获得许多形式的回报。 但是，随着这种分发，出现了新的要求：用于服务间通信的消息传递。

微服务消息传递如何绑定到CI / CD和Codeship产品？ 对开发人员意味着什么？

鞋拔解决方案

最近看来，“如果你只有一把锤子，那么每个问题都像钉子”的古老格言适合微服务消息传递。 由于基于云的应用程序也是基于Internet的应用程序，因此许多不熟悉云技术的开发人员本质上都在将每种服务设计作为微型Web服务器来进行。 由于API级服务的公共接口将REST与JSON数据包一起使用，因此对每个内部服务都采用这种格式也是合理的。

现在，可能只是为应用程序中的每个服务使用基于JSON的REST接口就是正确的选择。 充其量，这可能不是错误的选择，但是通过记住“使用正确的工具来完成工作”，应用程序可以得到简化，更高效，更安全并且更易于维护。 我们知道，数据库，语言甚至服务器提供者都是如此。 那为什么不发送消息呢？

互联网消息传递的要点

Internet消息传递使用网络层上的Internet协议（IP）。 它的作用是管理寻址，并促进从发送地址到接收地址的数据包（称为数据报）的传递。

在该层的正上方是传输层。 这包括TCP（传输控制协议），UDP（用户数据报协议）和鲜为人知的SCTP（流控制传输协议）和DCCP（数据报拥塞控制协议）。 TCP和UDP在Internet数据包传输中无处不在，并且构成了网络上几乎所有数据的外部框架。 后两个是Internet传输层的最新添加。

由于传输层非常靠近网络，因此网络硬件（NAT）必须了解传输数据包的成帧。 由于此类设备尚未广泛理解SCTP和DCCP，因此它们的使用受到抑制，因为新的NAT设备不太可能支持这种广为人知的协议，因此这形成了恶性循环。

下一层是TLS（传输层安全性），它为TCP和UDP提供可选的安全性功能。

最后一层是应用程序层。 这有助于在传输层之上进行额外的框架化，从而提供HTTP，SMTP，SIP等协议。

应用层协议通常位于TCP或UDP帧内。 UDP非常轻巧，非常适合处理大量有损数据。 它对于自定义协议也很有用&#