[[430234]]

實(shí)施微服務(wù)架構(gòu)，我們一直在遵循一個(gè)實(shí)踐原則：每個(gè)微服務(wù)要有自己獨(dú)立的數(shù)據(jù)庫(kù)，避免數(shù)據(jù)庫(kù)層面的耦合。這種理所當(dāng)然感覺(jué)好像不需要多加思考，就是應(yīng)該這樣做；

圖片來(lái)源：James Lewis 和 Martin Fowler 的文章《Microservices》

　　那么到底為什么每個(gè)微服務(wù)都需要獨(dú)立的數(shù)據(jù)庫(kù)，數(shù)據(jù)放在一個(gè)數(shù)據(jù)庫(kù)有問(wèn)題嗎？要回答這個(gè)問(wèn)題，我們還是要回歸到微服務(wù)的定義 （參見(jiàn) James Lewis 和 Martin Fowler 的文章《Microservices》，地址：
https://martinfowler.com/articles/microservices.html）：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

　　這個(gè)定義中指明了微服務(wù)架構(gòu)風(fēng)格的典型特征，如：技術(shù)異構(gòu)（每個(gè)服務(wù)可以采用不同的編程語(yǔ)言或不同的數(shù)據(jù)存儲(chǔ)技術(shù)）、獨(dú)立部署和圍繞業(yè)務(wù)能力構(gòu)建，等等。我們可以從微服務(wù)架構(gòu)風(fēng)格的幾個(gè)典型特征入手，看看獨(dú)立數(shù)據(jù)庫(kù)可以帶來(lái)哪些好處，或者共享數(shù)據(jù)庫(kù)會(huì)帶來(lái)哪些問(wèn)題。

微服務(wù)支持技術(shù)異構(gòu)

　　為了更好的解決特殊場(chǎng)景的問(wèn)題，微服務(wù)架構(gòu)并不提倡使用適合所有場(chǎng)景的標(biāo)準(zhǔn)化技術(shù)，而是針對(duì)每個(gè)服務(wù)的特點(diǎn)，選擇更合適的技術(shù)。

　　這個(gè)技術(shù)不僅包括編程語(yǔ)言、技術(shù)框架，當(dāng)然也包括數(shù)據(jù)存儲(chǔ)技術(shù)；紐曼(Sam Newman)在《微服務(wù)設(shè)計(jì)》一書(shū)中舉了一個(gè)例子很好的解釋了數(shù)據(jù)存儲(chǔ)技術(shù)異構(gòu)帶來(lái)的好處：

　　對(duì)于社交網(wǎng)絡(luò)來(lái)說(shuō)，圖數(shù)據(jù)庫(kù)能夠更好的處理用戶之間的交互操作，但對(duì)于用戶發(fā)布的帖子而言，文檔數(shù)據(jù)庫(kù)可能是一個(gè)更好的選擇

圖片來(lái)源：《微服務(wù)設(shè)計(jì)》第 1 章圖1-1

　　技術(shù)異構(gòu)很自然讓我們?yōu)槊總€(gè)微服務(wù)選擇了獨(dú)立的數(shù)據(jù)庫(kù)，但杠精附體的同學(xué)可能緊接著會(huì)問(wèn)：那如果服務(wù)不需要采用異構(gòu)的技術(shù)，那是不是就可以使用同一個(gè)數(shù)據(jù)庫(kù)了呢，比如都使用 MySQL 數(shù)據(jù)庫(kù)？

微服務(wù)是自治的

　　微服務(wù)是小而自治的，自治性的一個(gè)非常重要的特性就是獨(dú)立部署，一個(gè)服務(wù)的修改和部署不應(yīng)該對(duì)其他服務(wù)產(chǎn)生影響，但如果多個(gè)服務(wù)共享數(shù)據(jù)庫(kù)，在數(shù)據(jù)庫(kù)層的耦合讓不確定性變大，一個(gè)服務(wù)對(duì)數(shù)據(jù)庫(kù)結(jié)構(gòu)的變更很有可能影響其他服務(wù)，即破壞了自治性。

　　自治性的好處體現(xiàn)在整個(gè)系統(tǒng)的彈性上，當(dāng)一個(gè)服務(wù)發(fā)生故障時(shí)，不會(huì)造成整個(gè)系統(tǒng)的不可用。然而，如果多個(gè)服務(wù)共享數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)的異常會(huì)導(dǎo)致多個(gè)服務(wù)同時(shí)故障，也就大大增加了整個(gè)系統(tǒng)不可用的概率。

　　自治性還體現(xiàn)在服務(wù)的可擴(kuò)展性上，不同的服務(wù)因業(yè)務(wù)不同其需要滿足的性能和并發(fā)量要求也不同。當(dāng)請(qǐng)求量增加時(shí)只需要對(duì)部分服務(wù)進(jìn)行擴(kuò)展，而不是所有服務(wù)；同樣當(dāng)數(shù)據(jù)庫(kù)性能無(wú)法滿足需求時(shí)，只需要對(duì)部分服務(wù)的數(shù)據(jù)庫(kù)進(jìn)行擴(kuò)容升級(jí)，而如果多個(gè)服務(wù)共享數(shù)據(jù)庫(kù)，擴(kuò)容升級(jí)的影響就會(huì)作用到多個(gè)服務(wù)，一方面破壞了服務(wù)的自治性，另一方面當(dāng)其他服務(wù)對(duì)數(shù)據(jù)庫(kù)沒(méi)有那么高要求時(shí)，資源是浪費(fèi)的。

　　繼續(xù)杠精附體，那是不是可以把并發(fā)量和性能要求相近的業(yè)務(wù)合并為一個(gè)服務(wù)，而共享同一個(gè)數(shù)據(jù)庫(kù)呢？

微服務(wù)是圍繞業(yè)務(wù)能力構(gòu)建的

　　這個(gè)問(wèn)題其實(shí)是微服務(wù)架構(gòu)實(shí)施落地的一個(gè)非常熱點(diǎn)問(wèn)題：如何劃分微服務(wù)？

　　劃分微服務(wù)要遵循高內(nèi)聚、低耦合這個(gè)原則的，這也是微服務(wù)架構(gòu)優(yōu)勢(shì)所在；《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》引入了限界上下文（bounded context）的概念，通過(guò)對(duì)業(yè)務(wù)的梳理找到不同業(yè)務(wù)上下文之間的邊界，幫助我們找到了劃分微服務(wù)的方法，這里的重點(diǎn)在業(yè)務(wù)邊界。James Lewis 和 Martin Fowler 在微服務(wù)的定義中也強(qiáng)調(diào)微服務(wù)是構(gòu)建在業(yè)務(wù)能力之上的，可見(jiàn)微服務(wù)的小而自治是建立在獨(dú)立的業(yè)務(wù)能力基礎(chǔ)之上的。

　　因此，簡(jiǎn)單的將并發(fā)量和性能要求相近的業(yè)務(wù)合并到一個(gè)服務(wù)中，無(wú)法達(dá)到微服務(wù)期望的效果，也就沒(méi)法獲得微服務(wù)所具有的好處。一方面不同的業(yè)務(wù)對(duì)數(shù)據(jù)庫(kù)的要求除了要考慮并發(fā)量和性能，還應(yīng)該包括數(shù)據(jù)量的大小、讀寫(xiě)的比例、實(shí)時(shí)性要求等等，共享數(shù)據(jù)庫(kù)的方式一般情況下也很難滿足不同業(yè)務(wù)服務(wù)對(duì)這些指標(biāo)的要求，將所有服務(wù)的數(shù)據(jù)都存放在一個(gè)數(shù)據(jù)庫(kù)中本身也是一種非常大的挑戰(zhàn)。另一方面用動(dòng)態(tài)的視角看這個(gè)問(wèn)題，業(yè)務(wù)是發(fā)展的，隨著市場(chǎng)的不斷變化，不同的業(yè)務(wù)隨時(shí)間而演進(jìn)出來(lái)的需求可能是完全不同的，對(duì)數(shù)據(jù)庫(kù)的需求也會(huì)有所不同，共享數(shù)據(jù)庫(kù)的方式很可能變成瓶頸限制業(yè)務(wù)的發(fā)展。

微服務(wù)架構(gòu)要不斷演進(jìn)

[[430237]]

微服務(wù)架構(gòu)風(fēng)格還有一個(gè)非常重要的特征，就是支持架構(gòu)的演進(jìn)；不論是互聯(lián)網(wǎng)企業(yè)，還是在數(shù)字化轉(zhuǎn)型過(guò)程中的傳統(tǒng)企業(yè)，市場(chǎng)的變化和不確定性是不可避免的，當(dāng)接到一個(gè)新的需求，如果需要用新的技術(shù)手段來(lái)解決，微服務(wù)架構(gòu)就體現(xiàn)出了獨(dú)特的優(yōu)勢(shì)，在不對(duì)其他服務(wù)產(chǎn)生影響的情況下，可以隨意變更一個(gè)服務(wù)內(nèi)部的技術(shù)框架或數(shù)據(jù)存儲(chǔ)技術(shù)，共享數(shù)據(jù)庫(kù)明顯做不到這一點(diǎn)。

最后

　　每個(gè)微服務(wù)擁有獨(dú)立的數(shù)據(jù)庫(kù)作為微服務(wù)架構(gòu)風(fēng)格提倡的實(shí)踐之一，和其他實(shí)踐一起，像魯班鎖中的積木一樣巧妙組合在一起，共同支撐了微服務(wù)架構(gòu)風(fēng)格所具備的優(yōu)點(diǎn)，在軟件開(kāi)發(fā)實(shí)踐過(guò)程中，只有遵守微服務(wù)架構(gòu)風(fēng)格所推薦的這些實(shí)踐，才能最大化的發(fā)揮微服務(wù)架構(gòu)的優(yōu)勢(shì)。

　　每個(gè)服務(wù)擁有獨(dú)立數(shù)據(jù)庫(kù)并不是只有優(yōu)點(diǎn)，數(shù)據(jù)的分散管理給數(shù)據(jù)一致性帶來(lái)了很大的挑戰(zhàn)，考慮到分布式事務(wù)的高昂代價(jià)和實(shí)現(xiàn)成本，微服務(wù)提倡服務(wù)之間的無(wú)事務(wù)協(xié)調(diào)，通過(guò)最終一致性來(lái)保證業(yè)務(wù)流程的正常推進(jìn)。