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