今天我們來聊一下,一個Teams app的infrastructure,我在考慮LuckyDraw的主要出于這么幾個出發點:
-
可管理性。因為這是一個個人產品,以后維護工作也只有我一個人,所以我希望整個infrastructure簡單、易管理,不要太花我時間
-
高可用。Teams的用戶遍布全世界,所以LuckyDraw的用戶來自不同時區,這個基礎架構要能很好的支持7x24小時高可用
-
高可擴展。Office365的用戶有1B,所以LuckyDraw的用戶可能會在某個時間點爆發(只是可能)。這個架構需要能快速的擴展成支持上百萬的用戶
-
低成本。一個字:窮。我窮啊
下面這張圖展示了LuckyDraw整體的基礎架構(構建在Azure上)
中間是Azure App Service,運行著Bot,由Bot Service打通我的Bot和Teams之間的通道。數據庫使用的是Table Storage。Key Vault里保存著連接字符串,bot密鑰等等。Log Apps用來出發抽獎(每個抽獎都在某個指定的時間點被觸發),Application Insights用來存儲日志,Availability Test(它實際上屬于Application Insights)用來確保我的LuckyDraw Bot的高可用。
接下來我就一個個具體說一下我為什么要這么設計:
App Service:
選用App Service主要是因為它可以非常方便的向上擴展和水平擴展,而且還支持auto scale,當他檢測到cpu占用與高于某個閾值時,自動水平擴展,這樣我就很容易管理了,不需要擔心機器是否夠用。而且App Service和Azure里的其他資源非常容易整合。最最關鍵的是它有Free版本,雖然free版本有一些限制,但是也足夠用于DEV和UAT環境了。
實際上下個版本,我準備把App Service Plan從Windows換成Linux,這樣我的生產環境可以更加便宜,而且可以看到B1系列的linux還有優惠,便宜到爆
Table Storage
選用Table Storage主要是因為:便宜!太便宜了,我計算過一次抽獎算他平均5KB的數據,也就是一百萬次抽獎一個月才0.225美金,人民幣按照6.8來算,才1.53元。而且我還可以吧已經結束的抽獎移到Archive Storage,才6分人民幣每個月每一百萬次抽獎。是不是覺得便宜到不可相信的地步?
當然,使用Table Storage也不是沒有缺點的,不然那些SQL老大哥們怎么活啊。使用Table Storage有幾點需要注意:
- 目前沒有成熟的自帶的備份方案,但可以自己寫腳本實現
- 每row數據,每個column的數據有大小限制
- 開發是不能使用EF,Dapper等成熟的ORM庫
Logic Apps
當時為了找一個timer的方案,很是頭痛,我并不希望把我的bot的服務做成stateful,這樣會影響它的scalability。然后我又研究了Azure Durable Function,Azure Scheduler等方案,最后在好友Ares的建議下,研究了Logic Apps,發現這個用來做Timer是一個很好的方案。
而且它還有自動的retry機制,而且一旦出錯,也非常容易查找當時出錯的原因。
Availability Test
這個是Application Insights里的一個功能,可以從選定的機房往你指定的Service上發送請求,并且監控是否請求成功和網絡延遲。下圖就是從我選定的5個region給我的bot服務發送請求。延遲最大的是美國東部,因為我的bot服務部署在香港,所以美國東部距離最遠。
Key Vault
Azure的Key Vault可以很好的幫助我們保存密碼,密鑰,連接字符串之類的。而且MSI很好用,我可以只給我的Bot服務有訪問Key Vault的權限,我連我自己的azure賬號都不給訪問權限,真正的安全啊。
環境
上面的全套基礎架構只是一個環境,我在整個開發流水線中,一共有三個環境,分別是DEV,UAT和PROD,使用Azure DevOps來完成CI/CD。都是微軟自家產品,所以AzureDevOps和Azure完美結合。我后面會另外再寫一篇關于我如何使用AzureDevOps來自動部署整個infrastructure的文章。
下圖就是運行了9天的生產環境的成本,一共是12澳幣,大約60元不到的人民幣,主要是花在了App Service Plan,因為我需要開啟Always On功能。以后改成Linux的App Service Plan后會便宜不少。
這個是UAT環境運行18天左右,才花了3澳分,相當于人民幣1角5分不到。所以如果你對Azure的服務十分了解,并且你的服務是Cloud Native的,真心便宜啊。而且整個架構是高度可擴展的。