不过 ， 也需要做一些架构上的思考 。 因为在这种模式里 ， 应用程序的启动速度成了一个关键 。 需要的启动速度要低至微妙甚至是毫秒的程度 ， 而基于容器的服务启动速度一般都倾向于15-120秒 。 虽然很多人都对“无状态微服务”口诛笔伐 ， 但现在它是一个真正需要达到的要求 。
我们有WebAssembly！
容器生态系统以及之前的虚拟机生态系统的只要好处是隔离 。 虚拟机提供了一个隔离工作负载的有效方式 。 而容器的出现再次完善了它 。 上面谈论的从本质上消除Web服务器来减少微服务的代码数量是一个非常好的想法 。
但又出现了一个新问题 ， 还能实现所期待的隔离水平吗？对于这个问题可以毫不犹豫的回答：当然可以 ， 因为我们有WebAssembly 。
WebAssembly最初被认为是一个浏览器执行环境 ， 是超越Java的一步 ， 是做Java Applets和ActiveX曾经试图做的事情的更好方法 。 但事实证明 ， 在目前的情况下 ， 浏览器的沙盒模型正是需要的沙盒模型 。 虽然它在运行时不信任（或沙盒）二进制文件 ， 但通过能力模型 ， 它确实会有选择地给沙盒中的代码提供功能 。 而其中启动速度是最重要的 ， 毕竟用户不喜欢缓慢的网站 。 另外 ， 主机的架构和操作系统不必与开发者的主机和操作系统相同 ， 这也是云计算的一个优势 。 此外 ， WebAssembly格式被设计为许多编程语言的编译目标 。
WebAssembly所具备的能力正是微服务的新迭代所需要的 。 开发人员可以用任何想要的语言 ， 例如Rust、C、Java、Python等等 ， 去编写HTTP处理程序 ， 然后将其编译为WebAssembly 。 这样当主机运行时就会提供必要的功能 ， 如文件系统（高度沙盒化的）、出站HTTP、键/值存储等 。 可以把微服务集中在处理离散的问题上 。 而底层平台可以用来管理所有的HTTP、SSL/TLS等等 。
Fermyon就正在研究一个这样的平台 ， 它与一组可插拔的组件相结合 ， 将安全地提供微服务所以需要的能力 。 而在这个过程中他们还发现了这种工作方式的一些额外的优势 。
工具标准化
当网络服务器被外部化 ， 或将组件作为能力注入到运行当中时 ， 开发人员对代码进行检测就会获得一些好处 。 这些好处表现为对运行代码的调试、诊断和监控方面的改进 。
例如 ， 可以通过提供标准化的指标和入职作为开始 。 将其植入到平台中去 。 因为每个请求的计时都是随时可以使用的 ， 所以不需要浪费时间开发 ， 还有正常运行时间、可用性和故障报告也是一样的道理 。 所有的这些都是平台自带的功能 ， 因此不需要开发 。
还有更令人开心的事 ， 当你开始在应用程序中记录日志时 ， 平台可以将日志信息转化为日志分析器喜欢的结构化格式 。 而这些信息与更广泛的平台日志紧密的联系在一起 。 这也就意味着 ， 开发者过去需要做的无聊的杂事之一 ， 现在可以交给平台来处理了 。 而且可以更轻松的做日志分析并获得丰富的指标 。
当然还可以让做到眼不见 ， 心不烦 ， 平台可以将指标和日志组件带入WebAssembly二进制文件中 。 在这种情况下 ， 开发人员能够轻松的利用模块中的函数调用来插入指标数据 ， 并将这些信息直接发送到平台的指标工具中 。 这不能让这项工作更简单 ， 仅仅是让其变得不可见了而已 。
实现细节和数据服务的外部化
有时开人员关心自己的键/值是否Redis ， 有时却又漠不关心 。 Fermyon平台确保了对键/值存储、对象存储、文件系统、环境变量等功能 ， 只提供一个实现 。 本地文件只能使用平面文件 。 服务器版本可以使用Redis、Minio和NFS 。 云版本可以使用托管版本 。 但是对于开发者来说 ， API是一样的 。 调用一个函数来指定一个键和值 ， 调用另一个函数来传递键和值 。 其实只要核心功能按照预期工作 ， 实现细节就无关紧要 。