某文讀後感 與 OUT

 

同事推送過來的一篇文字--FROM 騰訊雲，《不要在微服架構中使用單一數據庫》看完以後就有了這段糙文，那篇文章是從開發的角度，或者說架構師的角度來看待在今天的系統集成中，或者說應該如何看待數據庫。

我們先來看看幾個"XXXX"的架構設計，與架構設計中使用數據庫的模式。

如果用一句話來形容，這樣的架構設計，Do you lost your mind ?

難道就那麼喜歡，把所有的雞蛋都放到一個籃子裏面？  

身爲架構師不光要考慮軟件架構層的問題，同時也要考慮硬件架構以及系統的耦合性的問題。

在軟件的架構都進行微服務化後，單一的數據庫卻成爲一個承載所有微服務數據的地方，這是難以想象的。如同上圖，ORACLE RAC 基於的是底層的存儲層，爲上層提供服務，而單點的性質就在 ORACLE RAC  的存儲層。如果存儲層稍有差池，整體的微服務任你拆的在散，消息傳遞的在有效可靠，都會被你不注意的單點毀於一旦。

當然你可以做 RAC 層底層的存儲的冗餘，但由此也不能說明你的微服務化是成功的，及時故障轉移，他還是一個單點，不是嗎。

拋去考慮 FAILOVER 的問題，性能的問題，也會在上面的設計中產生問題，假設，如果你出去遊玩，你是願意住在一個大通鋪和10幾個人一起擠，你還是願意住單人間。 

如果你不是熱衷「佔便宜」，或者有特殊癖好的話，一般的人都傾向於去住單人間。單人間對自己和對別人都是可控的，隔離的，互相不影響的。

換到微服，也是這樣，你是願意你的微服後端都有條不紊的運行在分佈式數據庫中，還是都擠在 類似 ORACLE RAC 這樣的大通鋪中，隨着你項目的增多，性能的爭用會在數據庫中爆發，然後你可能面臨的就是遷庫，或者再次提高單體數據庫的某些性能和容量。

說到這裏，到底爲什麼現在的軟件開發不在願意使用原來的方式去開發軟件，而單單要提到 微服務，微服務框架來進行軟件的開發。

       龐大的單塊服務作爲一個整體擴展，系統中只有一小部分存在性能問題,也需要對整個服務進行擴展，若使用較小的多個服務,只對需要擴展的服務進行擴展,這樣就能避免很多不必要的麻煩並且可以部署在性能稍差的硬件上。

       在有幾百萬行代碼的單塊應用程序中，即使只修改了一行代碼,也需要重新部署整個應用程序才能夠發佈該變更。這種部署的影響很大、風險很高,因此相關千系人不敢輕易做部署。於是在實際操作中,部署的頻率就會變得很低。這意味着在兩次發佈之間我們對軟件做了很多功能增強,但直到最後一刻才把這些大量的變更一次性發布到生產環境中。另一個問題兩次發佈之間的差異越大,出錯的可能性就更大在微服務架構中,各個服務的部署是獨立的這樣就可以更快地對特定部分的代碼進行部署。之間通過消息傳遞，消費（MQ）等方式來進行工作，如果某個模塊出現問題，不會大面積影響其他模塊，業務可能受到的損傷更小，或者根本就可以忽略。

而在軟件設計上很明白的問題，反而到了數據庫上就開始迷糊了，將所有的微服的數據放置到一個數據庫這樣的情況不少見，尤其傳統行業裏面做的很差勁。這其中有一部分是 架構師的問題，另一部分是管理數據庫的人員的意識有問題，還活在 一庫走天下的舊思維下。

 掌握多種數據庫，來應付目前的軟件開發模式，是一種必然。一個公司可能使用的數據庫不在是1 種 2種，這就對數據庫管理者提出了更高的要求。如果不能滿足目前開發的模式，則這樣的人員也必然會被淘汰。

最近一則新聞也是夠奇葩，說某市的出租司機，將共享單車都扔到河裏面，因爲共享單車搶了生意，除了可笑以外，這些人也很可悲，妄圖螳臂當車，也只能是成爲笑談。

同樣數據庫使用和管理的概念也在這波潮流中被改變，數據庫可能不在變得更重要，很可能變得不重要，硬件的大幅度提升可能數據庫優化也將變得不再重要或者以前認爲不是數據庫的東西，現在也屬於數據庫，例如 ES ， NEO4J,  服務的方式不同，服務的業務不同，更傾向於更專業的，有傾向性的降低開發和管理的門檻的產品，不再是貴的要死還沒有特色的產品。

最後，說到開源數據庫，類似於微服務這樣的軟件架構，並且正確設計其底層的數據庫，一定不是類似上圖那樣的設計，反而和可能是下圖這樣的方式，而作爲一個企業成本是重要的，脫離成本談任何問題都沒有底氣，而如何節省成本，並且在節省成本的同時也能滿足企業的需求，滿足開發的需求才是一個數據庫架構師應該做的。