WebAssembly组件模型使数据服务外部化成为一种可能 ， 而且不需要特殊的中间件层或外部服务 。 相反 ， 在启动时 ， WebAssembly运行环境会自动选择正确的组件来满足开发者指定的界面要求 。 面向对象的开发者可能会从接口/类的角度考虑这个问题 ， 但有一个关键区别 ， 选择实现一个接口是运行时一个操作 ， 而不是开发者代码的一部分 。
这个由WebAssembly带来的可能性有助于对微服务进一步的理解 ， 帮助开发人员重新思考对分布式计算的理解 。
将分布式计算推进一步
曾经的分布式计算在实践时显得非常混乱 。 单片机应用在这方面展现出笨拙的一面 。 但现在这一切都发生了变化 。 容器成为了一种新兴事物 ， Go语言等在很大程度上借鉴了CSP等分布式计算概念 。 更重要的是 ， 微服务架构的出现挑战了分布式计算很难 ， 以及对它应该如何完成这两个假设 。
时代发展 ， 旧的教条退去了 。 开发人员开始把分布式计算看做事一个新问题 ， 而关于这个问题可以通过小型和狭义的网络服务、REST-ful应用程序以及对无状态计算的投入组合来解决 。 Kubernetes为部署微服务架构提供了一个强调无状态方式的协调框架 。
分布式计算似乎并不是一个很难实现的目标 。 但开发人员需要做出的架构决策却被推到了风口浪尖上 。 因此 ， 我觉得需要认真的思考下微服务应该如何实现结构化 ， 以实现正确的网络拓扑结构 。 有意思的是 ， 当Go将CSP融入自身时 ， Kubernetes也将CSP融入了基础设施中 。 而开发者不得不在两个不同的抽象层次上思考同一个模式 。
而WebAssembly是为开发人员提供的另一种实现分布式计算的方法 ， 它可以减少开发分布式应用的认知开销 。 而组件模型正是实现这一目标的关键 。 在上面 ， 我们把组件看成是将外部服务嫁接到微服务的一种方式 。 但并没有真正的谈及组件是什么这个问题 。 因为其中很重要的一点是 ， 接口的定义使得实际的实现细节和开发者无关 。 而且其中一些实现实际上是底层主机运行时带来的功能 。 这些功能在运行时被挂到了WebAssembly二进制文件中 。
但是一些其他的实现却不是主机运行时的一部分 。 它们只是其他的WebAssembly模块 ， 在启动时被链接到了一起 。 这样一来 ， 它们对开发者来说就像是一个库 。 但在平台上却是作为一个独立的WebAssembly模块被执行 。 它们有自己的内存空间 ， 并与开发者的代码相互隔离 。 当开发者与这个外部组件交互时 ， 感觉起来像是调用了一个函数 ， 但行为上看起来更像一个RPC 。
这也正是分布式计算有趣的地方 ， 在运行时 ， 不是开发者在处理计算的分布 。 就开发者而言 ， 它只一个对库的调用 。 运行时可以选择在哪里运行该组件 ， 且与开发者的代码相邻 。 开发者对它唯一关心的就是功能是否被正确的、安全的、可靠的执行 ， 仅此而已 。 分布式计算不再是第一代微服务的复杂拓扑结构 ， 它是编写微服务新方法中的一个事实细节 。
结论
微服务架构一直是以云为中心开发的主要推动力 ， 这一点是毋庸置疑的 。 而虚拟机开启了微服务架构的可能性 。 在微服务的第二波浪潮中 ， 容器生态系统将分布式计算与微服务编撰为云计算的“新常态” 。 而在这一过程中 ， 遇到了一些困难 。 这使得我们暂停下来并重新思考一些假设 ， 关于安全、关于设计、关于与外部服务合作的假设 。
当我们思考这些假设时 ， 看到了WebAssembly带来的可能性 。 我们可以以此来减少开发人员在关键层面安全上花费的时间 。 而且还减少了微服务开发者必须撑到的代码数量 。 与此同时 ， 还可以改善日志和指标 ， 同时简化管路外部服务的过程 。 而提供这些优势机制——WebAssembly组件模型 ， 为我们提供了一个光明的分布式计算未来版本 。