gydtep

API 应该是被优先设计的：我们知道用户需求是复杂多变的，比如从桌面到移动端，应用的展现方式和操作流程都有可能不同；然而业务逻辑的概念模型和服务交互是相对稳定的。相对而言，API 的接口是更加稳定的，而具体的实现是可以迭代实现和持续变化的。定义良好的 API 可以更好保障应用系统的质量。

gydtep

但是 EDA 架构依然存在很多挑战。

1、分布式的松耦合架构大大增加了应用基础设施的复杂性。基于云的部署交付方式和云服务（消息队列、函数计算服务等）可以使得该架构的稳定性，性能和成本效益进一步提高。

gydtep

在 Kubernetes 中，业务应用可以提供一个 liveness 探针，可以通过 TCP、HTTP 或者命令行方式对应用就绪进行检测。对于 HTTP 类型探针，Kubernetes 会定时访问该地址，如果该地址的返回码不在 200 到 400 之间，则认为该容器不健康，会杀死该容器重建新的容器；

gydtep

系统化的稳定性需要在软件架构，运维体系和组织保障等方面全局考虑。在架构层面，阿里经济体有着非常丰富的经验，比如防御式设计、限流、降级、故障隔离等，而且也向社区贡献了Sentinel、ChaosBlade等优秀的开源项目。

gydtep

实现绑定：由于微服务框架代码库通常由特定语言实现，难以支持多语言（polyglot）实现。随着业务的快速发展，异构系统之间的集成逐渐成为挑战。

gydtep

首先是“Failures can and will happen”，我们需要提升服务器的可替换性。在业界有一个非常流行的隐喻：“Pets vs. Cattle”，宠物和家畜。我们面对一个架构选择：对于应用所在服务器我们是需要精心伺候，防止系统宕机，出现问题后不惜一切代价抢救 （Pet）；还是倾向于出现问题后，可以通过简单抛弃和替代进行恢复（Cattle）。

gydtep

熟悉传统企业架构的同学可能发现，传统的 Java EE (现在改名为 Jakarta EE )应用服务器的目标也是解决类似的问题。一个典型 Java EE 应用服务器的架构如下图所示：应用生命周期由各种应用容器管理，如 Web 容器，EJB 容器等。

gydtep

Serverless 的机遇与挑战
在上一篇文章中，我已经对 Serverless 应用基础设施，如函数即服务（FaaS）， Serverless 容器做了介绍。本文谈谈函数即服务 FaaS 应用在架构方面的一些思考。

gydtep

WebAssembly 则是另外一个令人激动的技术。WebAssembly 作为一个面向现代 CPU 体系架构设计的，安全的、可移植、高效率的虚拟机沙箱，可以在任何地方（服务器、浏览器、IoT等等）、任何平台（不同操作系统，不同CPU体系架构下）安全运行应用。

gydtep

上图是Tunnel总体功能的表格。现在有两套API，分批量数据通道和流式数据通道。
批量数据通道目标的场景单并发的吞吐量很大，这种理想的场景是传量大的数据，一次一批，QPS和并发都不能特别高，但是单并发的吞吐量可以做得很大，这个在API上也有一些优化。