旅行者保險公司是美國最大的商業(yè)、財產(chǎn)和意外保險承保人之一。作為一名資深架構(gòu)師，我目睹了該行業(yè)在過去10多年中的巨大發(fā)展，數(shù)據(jù)需求推動靜態(tài)數(shù)據(jù)需求的增長，隨后是動態(tài)數(shù)據(jù)，最后是消費(fèi)中的數(shù)據(jù)。

如今，董事會要求企業(yè)管理者利用技術(shù)重新設(shè)計生產(chǎn)和銷售，并最終提高公司的生產(chǎn)力和效率。

按理說，軟件可以減少企業(yè)發(fā)展瓶頸，這意味著我們需要更好地持續(xù)構(gòu)建和交付軟件應(yīng)用。雖然我們認(rèn)為自己是敏捷狂熱者，精通微服務(wù)，但我們并沒有一覺醒來突然改變數(shù)據(jù)庫。

事實上，我們用了數(shù)年進(jìn)行數(shù)據(jù)庫技術(shù)迭代，才最終用文檔數(shù)據(jù)庫取代了底層關(guān)系數(shù)據(jù)庫，使我們能夠捕捉到使用微服務(wù)的價值，并提高開發(fā)人員的工作效率和速度。

通過運(yùn)行數(shù)據(jù)存儲變得更加敏捷

起初，我們的目標(biāo)是為我們的經(jīng)紀(jì)人構(gòu)建一個單一視圖的應(yīng)用程序，因為他們需要登錄12個不同的服務(wù)，以滿足單一用例的要求。關(guān)系數(shù)據(jù)模型一直阻礙著我們。

在當(dāng)今的軟件開發(fā)實踐中，你需要根據(jù)簡短的業(yè)務(wù)功能描述來構(gòu)建軟件。游戲的關(guān)鍵在于保持輕便和不斷迭代。這與傳統(tǒng)的瀑布式方法不同，在瀑布式方法中，可能要花費(fèi)六個月的時間進(jìn)行需求分析，才能編寫一行代碼。在瀑布式方法中，這沒有問題——你知道了最終狀態(tài)，才能創(chuàng)建數(shù)據(jù)庫對象。但是，如果采用敏捷方法，就無法做到這一點(diǎn)，因為根本無法根據(jù)太簡短的業(yè)務(wù)需求建立數(shù)據(jù)模型?，F(xiàn)實情況是，你需要不斷修改數(shù)據(jù)庫。

在旅行者公司（Travelers），我們在 2014 年推出了單一視圖應(yīng)用程序，盡管它仍然依賴于 ETL、具有單一的代碼庫，并面臨持續(xù)的集成挑戰(zhàn)?，F(xiàn)在，我們每年要部署五次軟件，這對我們來說非常重要，并在內(nèi)部營造了重新設(shè)計的應(yīng)用程序?qū)I(yè)務(wù)影響的氛圍。

我們意識到，如果工程團(tuán)隊需要加快交付速度，我們就必須放棄關(guān)系數(shù)據(jù)庫。

再見表格，你好 JSON！

2017 年，我們決定使用 MongoDB Atlas 這種文檔模型數(shù)據(jù)庫。然而，要想取得成功，我們需要做的不僅僅是學(xué)習(xí)如何針對不同的數(shù)據(jù)庫進(jìn)行編程。對于一家從未使用過關(guān)系數(shù)據(jù)庫以外其他任何東西的公司來說，這是一次巨大的變革。要想取得成功，我們不僅需要實現(xiàn)技術(shù)的現(xiàn)代化，還需要實現(xiàn)企業(yè)文化的現(xiàn)代化。

在我們的開發(fā)人員開發(fā)軟件的同時，我們還與許多其他團(tuán)體建立了關(guān)系，讓他們也參與到我們的旅程中來。

• 我們這樣做是為了確保能夠利用他們的專業(yè)知識
• 讓噪音安靜下來
• 教會每個團(tuán)隊如何使用 JSON 建立數(shù)據(jù)模型

與表格相比，用 JSON 建模讓許多人大開眼界，他們認(rèn)識到我們可以更快地將軟件交付到生產(chǎn)中。

很快，隨著我們的開發(fā)團(tuán)隊更快地將功能交付到生產(chǎn)中，業(yè)務(wù)產(chǎn)品負(fù)責(zé)人的工作積壓開始減少。這創(chuàng)造了一個飛輪勢頭。隨著我們的業(yè)務(wù)部門正在做的事情在內(nèi)部傳開，我們開始看到其他團(tuán)隊對我們的成果產(chǎn)生了極大的興趣。

現(xiàn)在是微服務(wù)

盡管我們的開發(fā)人員在首次發(fā)布之前沒有使用 MongoDB 的經(jīng)驗，但我們?nèi)匀荒軌蛟?8 周內(nèi)將產(chǎn)品投入生產(chǎn)，消除了 600 多行代碼，并在時間和預(yù)算范圍內(nèi)完成了任務(wù)。

此外，反饋表明，文檔數(shù)據(jù)模型有助于消除數(shù)據(jù)映射和建模等繁瑣的關(guān)系數(shù)據(jù)庫工作。這樣，開發(fā)人員就有時間重新專注于高度優(yōu)先的項目。

我們剛開始使用 MongoDB 時，生產(chǎn)中只有兩個集合。一年后，我們在生產(chǎn)中部署了 120 個集合，每天編寫 1000 萬個文檔。如今，每個團(tuán)隊都擁有自己的依賴關(guān)系，并擁有自己專用的微服務(wù)和數(shù)據(jù)庫，從而為應(yīng)用程序和數(shù)據(jù)庫的變更提供了單一的管道?？傊?，這些變化以及不重構(gòu)數(shù)據(jù)模型所節(jié)省的時間，讓我們將部署時間從幾小時甚至幾天縮短到了幾分鐘。

引領(lǐng)未來創(chuàng)新

如果在關(guān)系型數(shù)據(jù)庫中使用得當(dāng)，就會有很多表格；如果數(shù)據(jù)建模得當(dāng)，即使是最簡單的使用案例，也會有很多對象。一旦我們發(fā)現(xiàn)數(shù)據(jù)庫拖慢了我們的速度，我們就知道是時候做出改變了。

我們轉(zhuǎn)向文檔模型數(shù)據(jù)庫的決定最終對公司產(chǎn)生了深遠(yuǎn)影響，MongoDB 已成為軟件開發(fā)的事實標(biāo)準(zhǔn)。在此過程中，我們采用了精益產(chǎn)品思想，并為我們的開發(fā)團(tuán)隊成功縮短交付時間做好了準(zhǔn)備。

原文標(biāo)題：Why our agile journey led us to ditch the relational database