API 应该是被优先设计的：我们知道用户需求是复杂多变的，比如从桌面到移动端，应用的展现方式和操作流程都有可能不同；然而业务逻辑的概念模型和服务交互是相对稳定的。相对而言，API 的接口是更加稳定的，而具体的实现是可以迭代实现和持续变化的。定义良好的 API 可以更好保障应用系统的质量。
但是 EDA 架构依然存在很多挑战。
1、分布式的松耦合架构大大增加了应用基础设施的复杂性。基于云的部署交付方式和云服务（消息队列、函数计算服务等）可以使得该架构的稳定性，性能和成本效益进一步提高。
在 Kubernetes 中，业务应用可以提供一个 liveness 探针，可以通过 TCP、HTTP 或者命令行方式对应用就绪进行检测。对于 HTTP 类型探针，Kubernetes 会定时访问该地址，如果该地址的返回码不在 200 到 400 之间，则认为该容器不健康，会杀死该容器重建新的容器；
系统化的稳定性需要在软件架构，运维体系和组织保障等方面全局考虑。在架构层面，阿里经济体有着非常丰富的经验，比如防御式设计、限流、降级、故障隔离等，而且也向社区贡献了Sentinel、ChaosBlade等优秀的开源项目。
实现绑定：由于微服务框架代码库通常由特定语言实现，难以支持多语言（polyglot）实现。随着业务的快速发展，异构系统之间的集成逐渐成为挑战。
首先是“Failures can and will happen”，我们需要提升服务器的可替换性。在业界有一个非常流行的隐喻：“Pets vs. Cattle”，宠物和家畜。我们面对一个架构选择：对于应用所在服务器我们是需要精心伺候，防止系统宕机，出现问题后不惜一切代价抢救 （Pet）；还是倾向于出现问题后，可以通过简单抛弃和替代进行恢复（Cattle）。
熟悉传统企业架构的同学可能发现，传统的 Java EE (现在改名为 Jakarta EE )应用服务器的目标也是解决类似的问题。一个典型 Java EE 应用服务器的架构如下图所示：应用生命周期由各种应用容器管理，如 Web 容器，EJB 容器等。
Serverless 的机遇与挑战
在上一篇文章中，我已经对 Serverless 应用基础设施，如函数即服务（FaaS）， Serverless 容器做了介绍。本文谈谈函数即服务 FaaS 应用在架构方面的一些思考。
WebAssembly 则是另外一个令人激动的技术。WebAssembly 作为一个面向现代 CPU 体系架构设计的，安全的、可移植、高效率的虚拟机沙箱，可以在任何地方（服务器、浏览器、IoT等等）、任何平台（不同操作系统，不同CPU体系架构下）安全运行应用。
上图是Tunnel总体功能的表格。现在有两套API，分批量数据通道和流式数据通道。
批量数据通道目标的场景单并发的吞吐量很大，这种理想的场景是传量大的数据，一次一批，QPS和并发都不能特别高，但是单并发的吞吐量可以做得很大，这个在API上也有一些优化。
