一個工具搞定三朵云？本地多云測試的碎片終結者

　　“如果你的應用只跟AWS打交道，LocalStack 是絕妙的選擇。可一旦服務伸到 GCP 或 Azure，本地開發立刻支離破碎——你得給 AWS 的缺胳膊少腿補上 Moto，用 Azurite 來模擬 Azure Blob，再啟動 gcloud 模擬器對付 Pub/Sub 和 Firestore。三四個工具，三四種配置，零共享狀態，零統一控制臺。”這段吐槽出自 Vyomi 團隊的一篇技術博文，它戳中了許多多云開發者的老傷：在本地重現一朵云都不容易，想要同時測三朵云，拼接式的工具鏈簡直是一場調試噩夢。

　　這種碎片化，不只是安裝幾個工具那么單純。每一個模擬器各自為政，端口號要小心避開，認證憑據要分別配置，想跨云走通一個文件流轉（比如 S3 觸發 GCP Function 寫入 Azure Blob），就得在三個控制臺、三套日志系統之間橫跳，還經常因為模擬行為與生產環境差異而掉進“本地跑通、線上炸裂”的深坑。更麻煩的是，這些工具大多不共享持久化狀態——一旦模擬器重啟，之前創建的資源、寫入的數據就煙消云散，反復重做環境的時間比寫代碼還長。

　　文中引入的 Vyomi，想要當這名碎片終結者。它的核心思路不是“模擬”，而是構建一個多云的“數字孿生”運行時。區別在哪兒？模擬器只是在進程里對 API 回應打個樣，行為常常簡化；而數字孿生在真實后端引擎上運行一份活的副本。換句話說，Vyomi 不會假裝自己是 Amazon RDS，而是真的拉起 PostgreSQL 和 MySQL 作為托管 SQL 的后端；不會假裝是 S3，而是用 MinIO 提供兼容 S3 的對象存儲；至于 DynamoDB，直接跑官方的 DynamoDB-local；密鑰管理則跑動 HashiCorp Vault；事件總線用 NATS；Azure Blob 由 Azurite 承載，GCS 用 fake-gcs-server，Firestore 和 Pub/Sub 也是 Google 官方仿真器的真正運行，而非淺層的 mock。這樣一來，每朵云的 API 后面都是真家伙在跑，行為更貼近生產環境，而且所有狀態——上傳的文件、創建的表、生成的密鑰——都持久存在，重啟不丟。

　　對開發者而言，最大的驚喜或許在于幾乎沒有學習成本。代碼唯一需要修改的地方，就是端點 URL。用 Python 的 boto3 連 S3 時，只需指定 endpoint_url="http://localhost:9000"；換成 Google Cloud Storage 的客戶端也是指向本地地址，Azure Storage Blob 同理，一條連接字符串就跳到了本地運行的多云環境。不單是 SDK，連 aws、gcloud、gsutil、az 這些命令行工具，乃至 Terraform，都可以用完全相同的方式指向本地端口，執行真實的接口調用。想用 Terraform 規劃資源？本地就跟真云一樣運行 plan 和 apply，只不過資源誕生在本地運行的真實引擎上，而不是遠端的賬號里。

　　等本地調試通過，Vyomi 還提供了一條“直通車”：把當前模擬的棧導出成標準的 Terraform HCL 配置。所有你在本地創建的資源——S3 桶、BigQuery 表、Azure 容器實例——都會變成可復制的聲明代碼。拿到這份 HCL，一鍵 terraform apply 到真實的 AWS、GCP 或 Azure 賬號，線上環境就與你剛剛調試的場景完美對標，無需對照控制臺手工重建，也幾乎不用擔心配置漂移。本地到生產，只差一個 export 加一個 apply，不用重寫一行代碼。

　　要想體驗，部署簡單得讓人想哼歌：macOS 下 brew install vyomi-cloud/tap/vyomi && vyomi up 就起跑；或者直接用 Docker 一行命令：docker run -d -p 9000:9000 -p 9443:9443 vyomi/appliance:latest。完全支持離線運行，并提供了免費層級，代碼也在 GitHub 上開放源碼。Vyomi 團隊還專門做了一份與 LocalStack 的逐項功能對比，放在了 vyomi.cloud/compare/localstack，有疑問或者覺得他們對 LocalStack 的理解有偏差，歡迎提 issue 交流。不過，以一身整合真實后端的姿態來看，這種“你理解錯我了”的探討，大概正是多云本地開發從拼接時代走向縫合時代的一個有趣注腳。