寫在開頭:任何架構(gòu)都不能解決所有問題,沒有完美的架構(gòu),只有最合適的架構(gòu)
先放大招
微服務(wù)簡介
微服務(wù)一定要區(qū)別于系統(tǒng)，服務(wù)是指一個或者一組相對較小且獨立的功能單元，是在某一設(shè)計維度拆分的最小功能集。
微服務(wù)最早由Martin Fowler與James Lewis于2014年共同提出，微服務(wù)架構(gòu)風格是一種使用一套小服務(wù)來開發(fā)單個應(yīng)用的方式途徑，每個服務(wù)運行在自己的進程中，并使用輕量級機制通信，通常是HTTP API，這些服務(wù)基于業(yè)務(wù)能力構(gòu)建，并能夠通過自動化部署機制來獨立部署，這些服務(wù)使用不同的編程語言實現(xiàn)，以及不同數(shù)據(jù)存儲技術(shù)，并保持最低限度的集中式管理。
傳統(tǒng)單系統(tǒng)弊端
在傳統(tǒng)的IT行業(yè)軟件大多都是各種獨立系統(tǒng)的堆砌，這些系統(tǒng)的問題總結(jié)來說就是擴展性差，可靠性不高，維護成本高。
主要有以下幾個問題:
1. 復(fù)雜性逐漸變高
單一系統(tǒng)隨著功能的不斷增加,在模塊之間沒有明確區(qū)分的情況下,邏輯會越來越亂,查找問題以及交接也會越來越復(fù)雜
2. 阻礙技術(shù)更新
單一系統(tǒng)使用的某個技術(shù)框架如果需要更新,需要查找所有依賴的邏輯,付出的成本代價想當大,所以單系統(tǒng)項目基本會一直使用最初搭建的項目架構(gòu)一點一點增加補丁,直到無法維護.
3.無法按需伸縮
所有系統(tǒng)所有模塊都是同等地位,沒辦法按照某些接口 IO/CPU 密集型需求單獨增加對應(yīng)的機器,提升系統(tǒng)的整體性能
4.數(shù)據(jù)和業(yè)務(wù)無法有效拆分
在傳統(tǒng)系統(tǒng)中,所有數(shù)據(jù)庫都在一起,經(jīng)常會出現(xiàn)單個業(yè)務(wù)操作多個數(shù)據(jù)庫等操作,導(dǎo)致系統(tǒng)之間業(yè)務(wù)和數(shù)據(jù)難以有效拆分.
5. 無法快速迭代
由于所有業(yè)務(wù)代碼都在一起,不管大小迭代都需要經(jīng)過完整的系統(tǒng)測試,不能測試系統(tǒng)某一部分來保證系統(tǒng)功能正常.
微服務(wù)優(yōu)缺點
隨著互聯(lián)網(wǎng)應(yīng)用數(shù)據(jù)量、并發(fā)量、業(yè)務(wù)復(fù)雜度的增長,單一系統(tǒng)已經(jīng)無法滿足業(yè)務(wù),逐漸產(chǎn)生了微服務(wù)思想.
微服務(wù)架構(gòu)主要解決了以下問題:
1.便于開發(fā),測試以及查找問題
每個模塊就是一個服務(wù),代碼量明顯減少,遇到問題比較容易找到定位和修改.修改單個模塊只要保證本模塊測試通過就可以保證整個系統(tǒng)正常.
2.便于服務(wù)按需彈性伸縮
隨著業(yè)務(wù)發(fā)展和并發(fā)增加,每個模塊都要部署很多服務(wù),每個模塊可以按照模塊性能按需進行彈性伸縮
3.便于數(shù)據(jù)和業(yè)務(wù)的封裝
單體架構(gòu)所有的模塊都共用一個數(shù)據(jù)庫，存儲方式比較單一，微服務(wù)每個模塊都可以使用不同的存儲方式（比如有的用redis，有的用mysql等），數(shù)據(jù)庫也是單個模塊對應(yīng)自己的數(shù)據(jù)庫。
4.便于使用新技術(shù)以及業(yè)務(wù)技術(shù)升級
單體架構(gòu)所有的模塊開發(fā)所使用的技術(shù)一樣，微服務(wù)每個模塊都可以使用不同的開發(fā)技術(shù)，開發(fā)模式更靈活。
微服務(wù)會引入以下問題:
1.分布式事務(wù)處理
比如轉(zhuǎn)賬業(yè)務(wù),傳統(tǒng)業(yè)務(wù)會修改用戶余額,新增用戶賬單以及其他操作,如果有其中一個失敗就會全部按失敗處理,但是如果采用微服務(wù),用戶余額和賬單如果不在一個服務(wù)中處理,就會產(chǎn)生錯誤數(shù)據(jù).
2.RPC服務(wù)超時或失敗
服務(wù)調(diào)用者應(yīng)有一些應(yīng)對策略，比如重發(fā)
關(guān)鍵服務(wù)例如支付，要注意冪等性，因為重發(fā)會導(dǎo)致重復(fù)操作
3.并發(fā)鎖
相當于單服務(wù)中的鎖機制
微服務(wù)粒度
從拆分粒度可以分為:
粗粒度：一個服務(wù)層
所有的信息存儲都在一個service里，那么一個地方出bug，就將影響整個業(yè)務(wù)
一個子業(yè)務(wù)(數(shù)據(jù)庫)一個service
這個是目前適合大多數(shù)公司業(yè)務(wù)系統(tǒng)拆分的架構(gòu)
一個service出問題也不會影響其他service，同時數(shù)據(jù)層也按照業(yè)務(wù)垂直拆分開了
服務(wù)架構(gòu)見下圖
一個數(shù)據(jù)表對應(yīng)一個service
等各個數(shù)據(jù)表之間也解耦開了，不會相互影響了
一個接口對應(yīng)一個service
多個服務(wù)操縱同一個數(shù)據(jù)表，使用同一片緩存，每個接口出問題，都不會影響其他接口。
微服務(wù)設(shè)計原則
單一職責原則
意思是每個微服務(wù)只需要實現(xiàn)自己的業(yè)務(wù)邏輯就可以了，比如訂單管理模塊，它只需要處理訂單的業(yè)務(wù)邏輯就可以了，其它的不必考慮。
服務(wù)自治原則
意思是每個微服務(wù)從開發(fā)、測試、運維等都是獨立的，包括存儲的數(shù)據(jù)庫也都是獨立的，自己就有一套完整的流程，我們完全可以把它當成一個項目來對待。不必依賴于其它模塊。
輕量級通信原則
首先是通信的語言非常的輕量，第二，該通信方式需要是跨語言、跨平臺的，之所以要跨平臺、跨語言就是為了讓每個微服務(wù)都有足夠的獨立性，可以不受技術(shù)的鉗制。
接口明確原則
由于微服務(wù)之間可能存在著調(diào)用關(guān)系，為了盡量避免以后由于某個微服務(wù)的接口變化而導(dǎo)致其它微服務(wù)都做調(diào)整，在設(shè)計之初就要考慮到所有情況，讓接口盡量做的更通用，更靈活，從而盡量避免其它模塊也做調(diào)整。
