使用 MongoDB Atlas無服務器實例更高效地開發應用程序

身為開發者，數據庫并不一定需要您來操心。您可不想耗費時間來預配置集群或調整集群大小。同樣地，您也不想操心因未能正確擴展而導致經費超標。

MongoDB Atlas 可為您提供多個數據庫部署選項。雖然您可以選擇預先配置的共享或專用集群，但為了能夠以最佳方式滿足需求，您仍然不得不持續確定數據庫資源的規模并作出相關估算，以及負責隨之而來的集群容量管理。盡管預先配置集群并非什么壞事，但若是您的開發處于閑置狀態，或者開發的增長期或下滑期頻繁出現，預先配置可能就沒有意義了。此時，您完全可以轉為選擇無服務器實例來協助減輕容量管理的負擔，騰出時間來專門編寫代碼。無服務器實例為您的應用程序提供按需數據庫端點，該端點將根據應用程序需求自動擴展或縮減到零，并且只根據您的使用情況向您收費。

在這個簡短但貼心的教程中，我們會探索如何輕松應用 MongoDB Atlas 無服務器實例，以及如何以其為參照開發應用程序。

部署 MongoDB Atlas無服務器實例

我們首先來看如何部署新的 MongoDB Atlas 無服務器實例。完成 MongoDB 部署的方法有很多，但在本文的示例中，我們將始終使用 Web 儀表盤和一些點擊操作。

在 MongoDB Atlas儀表盤中，單擊“創建”按鈕。

選擇“無服務器”以及應當存儲此實例的云供應商。

如果可能，請選擇與您的應用程序所在位置相匹配的云供應商。這樣可確保您的數據庫和應用程序之間的延遲最低。

選擇單擊“創建實例”按鈕后，實例即已準備就緒！

不過，這些操作還不夠。要想在 Web 儀表盤之外的位置使用 Atlas 無服務器實例，就需要先創建一些數據庫訪問規則和網絡訪問規則。

我們先來添加一個新數據庫用戶。

選擇對您來說最合理的身份驗證類型。為了使本教程簡單明了，我建議選擇“密碼”選項。

涉及到用戶權限時，您當然可以使用“內置角色”，但對于任意應用程序，最好還是根據應允許用戶執行的操作來定義“特定權限”。在這個項目中，我們將使用一個“示例”數據庫和一個“人員”集合，因此只授予該數據庫和集合 readWrite 訪問權限才是合理做法。

在創建用戶及定義訪問權限時，請運用自己的最佳判斷力。

創建用戶后，我們就可以處理網絡訪問的相關內容。完成最后這一步后，我們就能夠以數據庫為參照開始開發工作。

在“網絡訪問”選項卡中，添加應允許訪問的 IP 地址。如果您像我一樣在本地開發和測試，只需添加您的本地 IP 地址即可。請務必記得在必要時為您的服務器或云供應商添加 IP 范圍。如果需要，您還可以使用專用網絡。

數據庫和網絡訪問的設置已經完成，我們現在應獲取將在本教程下一步中使用的 URI 字符串。

在“數據庫”選項卡中，單擊無服務器實例對應的“連接”按鈕。

選擇要使用的編程語言并記下 URI。

使用熱門編程技術與 Atlas 無服務器實例交互

到這里，您應該已經部署了 Atlas 無服務器實例。我們會花一點時間利用應用程序代碼來連接實例，并進行一些交互，例如基本的 CRUD。

對于此特定示例，我們將搭配使用 JavaScript 與 MongoDB Node.js 驅動程序，但相同的規則和概念會繼續應用，只是與您希望使用的編程語言存在語言差異。

在本地計算機上，創建項目目錄，并使用命令行導航到該目錄。在它成為您的工作目錄后，您就需要執行以下命令：

通過上面的命令，我們完成 Node.js 項目初始化，安裝了 MongoDB Node.js 驅動程序，并創建了一個包含我們的代碼的 main.js 文件。

打開 main.js 文件并添加以下 JavaScript 代碼：

那么，上面的代碼發生了什么？

首先，我們會使用無服務器實例的 URI 字符串來定義客戶端。這個字符串與您在本教程前面記錄的字符串相同，其應該包含用戶名和密碼。

在客戶端中，我們可以建立連接并獲得對要使用之數據庫和集合的引用。在運行應用程序之前，數據庫和集合不需要存在。

接下來，我們將使用 MongoDB 查詢 API 執行三種不同的操作。首先，向我們的集合插入一個新文檔。插入完成后，在 try/catch 塊沒有發現錯誤的情況下，我們會找到姓氏匹配的所有文檔。對于此示例，應該只有一個文檔，但您完全沒法知道您的代碼是什么樣子。如果找到一個文檔，它就會被打印到控制臺。最后，我們將刪除姓氏匹配的任何文檔。

最后，若您跟著我的示例執行所有步驟，那么您的集合中不應該存在任何文檔。然而，您的集合中（在某個時間點）確實存在過一個文檔，只不過我們將它刪除了。

我們通過一個基本示例了解了如何圍繞按需數據庫構建應用程序，但這個示例并沒有真正凸顯出如此操作的好處。怎么改變這個情況呢？

使用合理的應用場景推送Atlas 無服務器實例

我們知道，預先配置和無服務器集群能夠穩定運作。從開發的角度來看，使用相同的代碼最終會得到相同的結果。

讓我們來設想一個場景：Atlas 中的無服務器實例可以降低開發成本、減少擴展負擔以滿足需求。假設您有一個不是常規類型的網上商店。這家網上商店大部分時間的客流量都很少，但由于您主營閃電式交易，每周五上午 9 點到中午 12 點之間的客流量會激增 1000%。

我就不贅述較低的客流量，但 1000% 的流量增長不容小覷，很可能需要每周五對預先配置的集群進行某種擴展干預才行。否則，您就需要付費使用更大型的數據庫。

讓我們使用下面的 Node.js 代碼具象化這個示例：

在上面的示例中，我們采用了由 Express 框架提供技術支持的 Web 應用程序，其中有兩個端點函數。一個端點用于獲得交易，另一個端點則用于創建購買。其余內容，請自行想象。

要對流量會突發的這款應用程序執行負載測試并模擬無服務器實例的潛在價值，我們可以使用 Apache JMeter 等類似工具。

使用 JMeter 后，您可以定義它在發出 HTTP 請求時使用的線程數和迭代次數。

請記住，我們在此示例中模擬的是一種突發情況。如果您確實決定要嘗試 JMeter，且面對突發情況時過度操作，您收到的帳單或許會讓您哭笑不得。如果您有興趣了解無服務器的計費方式，請查看文檔中的定價頁面。

在 JMeter 線程組中，您需要定義每個線程或迭代所發生的活動。在本例中，我們向 Node.js API 發送 HTTP 請求。

由于 API 需要 JSON，我們可以定義請求的標頭信息。

取得線程信息、HTTP 請求信息和標頭信息后，您就可以運行 JMeter，最終會看到同時參照 Web 應用程序和數據庫而推進的大量活動。

同樣，此示例的很多內容都會留給您自行想象，因為要想看到無服務器實例的擴展優勢，您就需要開發過程中難以模擬的大量突發流量。無論如何，這個示例應該能給您帶來一些啟發。

結論

從上面的示例可以看到，利用 MongoDB Atlas 開發可以多么快速，其還能為您免去親自調整集群大小的負擔。使用 MongoDB Atlas 無服務器實例后，您的數據庫能夠適當擴展以滿足應用程序需求，且您只需為具體需求付費。這樣就不必為不間斷運行且大小并不合適的集群付費。它還能為您節省時間，不必對集群進行大小調整。

無論您使用的是 Atlas 無服務器實例還是預先配置的共享或專用集群，此示例中的代碼都能發揮應有作用。