1. 背景 微服务架构下，服务与服务的依赖关系复杂。在开发过程中，多个服务之间经常需要联调。此时有两种方式: 将服务部署到线上开发环境 Kubernetes 集群 使用 telepresence 打通本地与线上集群的通信，这样能获得一个比较稳定的联调环境。 缺点是，需要生成足够权限的凭证、需要研发人

1. 业务背景 当企业达到一定规模时，完全依赖于公有云基础设施，IT 成本会很高。 采购物理机器的成本可以摊薄到未来 3~5 年，之后机器并不会报废，而是会继续超期服役。私有云需要配比一定运维人员、购买专线带宽、机房费用等，IT 服务达到一定规模才能有效降低成

1. HPA VS KEDA HPA 也实现了: 自定义指标的弹性 Scale to Zero 这些与 KEDA 相比较，并不算劣势了。 真正的差别在于 HPA 只能利用监控数据进行伸缩，而 KEDA 可以利用更多数据来源进行伸缩，比如队列消息、数据库、Redis 等，当然也包括监控数据。 从 Kubernetes-based Event Driven Autoscaler (KEDA) 项目的名字就可以看出，K

1. WebAssembly 简介 跨平台性，可以在任何支持 WebAssembly 的平台上运行，包括 Web 浏览器、服务器、移动设备等 高性能，采用了一种紧凑的二进制格式，可以在浏览器中快速加载和解析，从而提高应用程序的性能 安全性，采用了一种沙箱模型，可以隔离运行在其中的代码，从而保护系统免受恶

1. 基于容器的 Serverless 无法支撑下一代应用的形态 如上图，我们正经历着一次运行时态的变革。 从裸金属机到虚拟机，应用不在受限于本地服务器的数量、机房稳定性，具有更好的弹性和可用性。 从虚拟机到容器，应用不再受限于操作系统、配置漂移，具有更好的可移植性和可扩