為什麼說集中管理資料是個壞主意？

微服務架構是現代應用程式和系統的一個常見模型。其特點是把一個大型應用的業務責任分割成不同的、獨立的元件，可以獨立開發、管理、操作和擴充套件。

微服務架構為應用程式本身的擴充套件提供了一個有效的模型，允許更大的、更不連貫的開發團隊獨立完成他們的部分工作，同時仍然參與大型應用程式的構建中。

在一個典型的微服務架構中，單獨的服務被建立，該服務包含了一個特定的業務邏輯子集。當相互連線時，整個微服務集形成一個完整的、大規模的應用程式，包含完整的業務邏輯。

這種模式對程式碼來說是很好的，但對資料呢?通常，為特定業務邏輯建立單獨服務的公司覺得有必要把所有的應用資料放到一個單一的、集中的資料儲存中。這個想法是為了確保所有的資料對可能需要它的每個服務都是可用的。管理單個資料儲存很容易，也很方便，而且資料建模對整個應用程式來說是一致的，與使用它的服務無關。

不要這樣做，集中你的資料是一個壞主意。這裡有三個原因：

集中的資料很難擴充套件

當整個應用程式的資料都在一個集中的資料儲存中時，隨著應用程式的增長，你必須擴充套件整個資料儲存以滿足應用程式中所有服務的需求。這顯示在圖1的左邊。如果你為每個服務使用單獨的資料儲存，只有需求增加的服務需要擴充套件，而被擴充套件的資料庫是一個較小的資料庫。這在圖1的右邊顯示。

將小型資料庫擴充套件到更大的規模要比將大型資料庫擴充套件到更大的規模容易得多。

圖1. 按服務劃分資料可以簡化擴充套件

集中的資料以後很難分割

新開發應用程式的開發者通常的想法是：“我現在不需要擔心擴充套件的問題，在以後需要的時候再擔心吧”。這種觀點雖然很普遍，但在某些時候卻會導致擴充套件問題。當應用程式變得流行時，你必須重新思考架構決策，以滿足客戶的增量需求。

一個常見的架構變化是需要將你的資料儲存分割成更小的資料儲存。問題是，在應用程式剛建立時比在應用程式生命週期的後期更容易進行分割。當應用程式已經存在了幾年，並且應用程式的所有部分都可以訪問對應的資料時，要確定資料集的哪些部分可以被分割成一個單獨的資料儲存而不需要對使用資料的程式碼進行重大重寫就變得非常困難。即使是簡單的問題也變得很困難。哪些服務在使用Profiles表?是否有服務同時需要系統表和專案表?

而且，更糟糕的是，是否有任何服務使用這兩個表來執行連線?它的用途是什麼?在程式碼中的什麼地方完成的?我們怎樣才能重構這種變化?

一個資料集在一個資料儲存中停留的時間越長，以後就越難把這個資料儲存分成更小的部分。

透過將資料按功能分成獨立的資料儲存，你可以避免以後將資料從連線的表中分離出來的相關問題，也可以減少程式碼中存在的資料之間意外關聯的可能性。

集中的資料使資料所有權無法實現

將資料劃分為多個服務的一大優勢是能夠將應用所有權劃分為不同的、可分離的部分。單個開發團隊的應用程式所有權是現代應用開發的一個核心原則，它可以促進更好的組織擴充套件，並在問題發生時提高響應能力。這種所有權模式在面向單一團隊的服務架構(STOSA)開發模式中進行了討論。

當你有大量的開發團隊都在為一個大型的應用程式做貢獻時，這種模式非常有效，但即使是有較小團隊的小型應用程式也能從這種模式中受益。

問題是，一個團隊要擁有一個服務的所有權，他們必須同時擁有該服務的程式碼和資料。這意味著一個服務(服務A)不應該直接訪問另一個服務(服務B)的資料。如果服務A需要儲存在服務B中的東西，它必須呼叫服務B的一個服務入口點，而不是直接訪問該資料。

圖2. 服務A永遠不應該直接訪問服務B的資料

這允許服務B對其資料、如何儲存以及如何維護擁有完全的自主權。

那麼，有什麼選擇呢?當你構建面向服務的架構(SOA)時，每個服務應該擁有自己的資料。這些資料是服務的一部分，並被納入服務中。

圖3. 每個服務都有自己的資料

這樣，服務的所有者可以管理該服務的資料。如果需要對資料進行模式改變或其他結構性改變，服務所有者可以在沒有任何其他服務所有者參與的情況下實現更改。隨著應用程式(及其服務)的增長，服務所有者可以做出擴充套件決策和資料重構決策，以處理增加的負載和變化的需求，而無需其他服務所有者的參與。

一個問題經常出現，那些真正需要在應用程式之間共享的資料怎麼辦?諸如使用者配置檔案資料，或其他在應用程式的許多常用的資料。一個誘人的快速解決方案可能是隻在多個服務之間共享所需的資料，如圖4所示。每個服務可能有它自己的資料，同時也可以訪問共享的資料。

圖4. 不建議在服務之間共享資料

更好的方法是將共享資料放入一個由所有其他服務使用的新服務中，如圖5所示。

圖5. 使用服務是訪問共享資料的正確方式

服務C這一新的服務也應該遵循STOSA的要求。特別是，它應該有一個單一的、明確的團隊來擁有該服務，從而擁有共享資料。如果任何其他服務，如圖中的服務A或服務B，需要訪問共享資料，它必須透過服務C提供的API來實現。這樣，服務C的所有者是唯一負責共享資料的團隊，可以就擴充套件、重構和更新方面做出適當的決策。只要維護一個一致的API供服務A和服務B使用，服務C就可以做出任何關於更新資料的決定。

這與圖4相反，圖4中服務A和服務B都直接訪問共享資料。在這個模型中，沒有一個團隊可以在不涉及直接訪問資料的所有其他團隊的情況下對資料的結構、佈局、擴充套件或建模做出任何決定，這限制了應用程式開發過程的可擴充套件性。

使用微服務或其他SOA是管理從事大型應用的大型開發團隊的一個好方法。但是，服務架構也必須包含應用程式的資料，否則真正的服務獨立性--也就是開發組織的擴充套件獨立性--將不可能實現。

作者：Lee Atchison是雲端計算和應用現代化領域公認的思想領袖。Lee在產品開發、架構、擴充套件和現代化方面有三十多年的經驗，曾在亞馬遜、亞馬遜網路服務(AWS)、New Relic和其他現代應用組織工作。