軟體架構：困難部分_6_拆開操作資料（資料庫）Solution Architecture The hard parts
在還沒有微服務的概念出現前，如果以八二法則來區分的話，普遍的系統有八成都會是屬於單體式系統（純屬個人不具名統計…）。
這種單體式系統，講白了就是從原本的一個小系統，一直不斷的向上累加功能，然後同一個來源資料庫，不斷的開表加欄位。一直到最後，就成了一個超巨大並且什麼功能都有的系統。
如果以資料庫的角度來深入的話，最明顯的問題就是：
一、如果資料庫掛了，整個系統直接 downtime。
二、哪些資料是哪些功能在用，沒有很明確的邊界劃分。因為不同的功能，有時後會需要一些相同的資料。這時後因為都是同一顆資料庫，所以寫法上很簡單，可以直接在不同的 procedure 或程式內直接抓取所需的資料表資料即可。
三、擴充不易。在這樣的框架底下，如果想要吃下更大的吞吐量，唯有將資料庫硬體再升級，或著是從源頭的程式來下手，在存取資料時動點手腳，比如說 sharding。
這一章明確的寫出五個步驟，說明如何將單一顆肥大資料庫進行拆分。
拆分資料五步驟
一、程式、資料庫都先不用作任何修改，先將資料庫裡面的資料表進行資料領域的分類。
比如說，customer, c_address 可分類為「客戶」。billing, payment 可分類為「支付」。
二、將各個分類分配給不同的資料庫模式。
以 Oracle 為例，就是將這些分類分給不同的 schema。如果是 Mssql 的話，「應該」是分配給不同的使用者。
三、分開資料庫到資料領域的連接。
這邊就開始會有一些修改，程式端需要把連到資料庫的連線切換成第二步所分類的不同資料庫模式（schema）。
四、將模式移到分開的資料庫伺服器
如果第三步的運行開始穩定後，可以開始把這些不同的資料庫模式（schema）建立一份另外獨立的資料庫。
個人認為這個動作很不容易。
第一是會需要 DBA 的配合，因為資料庫的複製動作會需要他們協助。
第二是因為在做複製的動作時，要考慮到資料的業務特性，不一定能在之後切換連接時佰分佰 no downtime。
五、切換到獨立的資料庫伺服器
最後一步，就是將程式的連線指過去新的資料庫。
心得
這一章和我之前讀過的單體式系統到微服務（Monolith to Microservice ISBN：9865028042）裡面提到的作法幾乎一樣，也許這是他們一致認為的 Best Practice 吧~~
個人認為這種作法可行性的確是蠻高的，並且風險也相對有下降，個人認為將它稱作最佳實作應該是不為過。只是在做這種資料拆分動作前，程式端會需要先做過一次領域的拆分，將邊界明確的切割出來。