以通信方式共享内存,不要以共享内存方式通信(2)_微服务 共享内存

继续以“以通信方式共享内存,不要以共享内存方式通信”这句话展开。

从云原生开始。

云原生是面向微服务的架构，而消息传递是微服务交互的媒介，每个工人都接触过关于消息队列的概念，正是消息支撑了云原生微服务。

消息并不封装状态，消息本身无状态，状态通过消息之间的交互来体现。消息交互可自由组合，这是分布式的源泉，而云原生本身就是面向分布式的设计。

一个部署云原生应用的IDC机房就是缩小版的全球TCP/IP互联网，无状态的消息在分布式的微服务之间传递，状态仅由微服务的交互定义和维护。

甚至一台物理主机内部板卡也成了微型版的全球TCP/IP互联网，无状态的消息在分布式的模块之间传递，状态仅由模块之间的交互定义和维护。

共享内存类似总线，大家拥有平等访问权，但写访问时要独占。我们可以从总线和消息交换的关系看共享内存的处境。

曾经，主机主板上很多总线，很多模块都要先争抢获得总线控制权才能与CPU或别的模块通信，但后来PCIe将总线改成了由Hub互联的交换网络，采用消息交换替换了总线仲裁。

以太网在此之前已经走过了同样的轨迹。

近来年被工人们提倡的微内核思想，大致也是这么回事，将对共享数据结构的操作换成了消息传递。

为什么这些都和全球TCP/IP互联网类比呢？因为TCP/IP的基础就是异步的，无状态的，分布式的，消息传递的分组交换网。

总线简单朴素，随着系统规模的扩大，总线争抢带来的时间损耗指数级上升，人们发现总线无法支持高并发及无法物理扩展时，消息传递便替换了总线。大规模系统，消息操作带来的额外延时是可以忽略不计的。

无论内部板卡，局域网，PCI，操作系统都是从局域范围开始的，它们一开始从总线开始便不足为奇。然而互联网一开始就是连接分布式广域端的，一开始就不适合采用总线结构，这反过来说明总线在分布式场景的不适用。

我一向赞美TCP/IP端到端原则，正是它无状态的IP细腰让互联网规模得以任意扩大而不引入额外开销，而细腰也是无状态消息交换的核心，只在发送端和接收端之间定义和维护状态，而不是所有端一起维护共享总线或内存的状态。

因此，消息传递也遵循端到端原则，可以自由扩展规模，总线和共享内存则相反。

以上从局域扩而大之的视角，我们看到了消息传递替换总线的趋势。

反过来，从广域向内缩，规模在渐小，传输延时在渐短，越来越不分布式，无状态消息传递带来的可扩展优势越发无用武之地，其额外封装带来的额外延时逐渐承担了端到端延时的大头。

除去额外的消息封装和传输操作，所有不多的实体直接操作信息所在的内存，最小化端到端延时便成了可观的收益，因此，总线和共享内存便是微缩版系统的极致了。

这就两边都说得通了，从小规模到大规模，总线和共享内存被消息传递替代，从大规模到小规模，总线和共享内存则是消息传递的优化。

就像广义相对论，牛顿力学，量子力学一样，不同的规模尺度有不同的哲学。

浙江温州皮鞋湿，下雨进水不会胖。