1. 微服務是什麼？

開篇之前先宣告我對微服務的幾點態度：

1.架構模式有很多，微服務不是唯一的選擇也不是什麼銀彈。國內絕大多數中小公司引入微服務都是在盲目追新，也能看出做此種技術選型的工程師基礎架構素質的不足。

2.“.你必須長的足夠高才能使用微服務”。微服務基礎設施，尤其是容器技術、自動化部署、自動化測試這些不完備，微服務形同虛設，不會帶來什麼質的提升。

3.微服務架構的關鍵不在於具體的實現，而在於如何合理地劃分服務邊界以及組織架構是否相匹配。不考慮研發團隊的規模和組成就盲目上微服務是不良的技術選型。

2. 為什麼採用微服務?

是否選擇微服務取決於你要設計的系統的複雜度。

微服務是用來把控複雜系統的，但是隨之而來的就是引入了微服務本身的複雜度。

需要解決包括自動化部署、監控、容錯處理、最終一致性等其他分散式系統面臨的問題。即使已經有一些普遍使用的解決方案，但是仍然是有不小的成本的。

生產力和複雜度的關係如圖所示，可見系統越複雜，微服務帶來的收益越大。此外，無論是單體應用還是微服務，團隊的技能都需要能夠把控住。

除非管理單體應用的成本已經太複雜了(太大導致很難修改和部署)，否則都不要考慮微服務。

大部分應用都應該選擇單體架構，做好單體應用的模組化而不是拆分成服務。

因此，系統一開始採用單體架構，做好模組化，之後隨著系統變得越來越複雜、模組/服務間的邊界越來越清晰，再重構為微服務架構是一個合理的架構演化路徑。

四個可以考慮上微服務的情況：

1.多人開發一個模組/專案，提交程式碼頻繁出現大量衝突。

2.模組間嚴重耦合，互相依賴，每次變動需要牽扯多個團隊，單次上線需求太多，風險大。

3.主要業務和次要業務耦合，橫向擴充套件流程複雜。

4.熔斷降級全靠 if-else。

3. 微服務架構(生鮮電商)

參考我的其他的文章

4. 微服務的優點

通過上面的架構圖，我們可以知道，生鮮電商可以根據模組的劃分如下：

分為使用者服務，商品服務，購物車服務，訂單服務，支付服務，售後服務，促銷服務等，服務與服務之間是互相的獨立的，互相不影響，而且各自都有自己的擴充套件性與隔離性. 不會因為某一個服務而導致整個系統架構的不可用，有點非常明顯.

總結一句話：優點：模組的強邊界;獨立部署;技術選型的多樣性

5. 微服務的缺點

通過上面的架構圖，我們可以知道，根據服務的拆分，我們發現生鮮電商分了很多的服務，把原來的功能都獨立起來，形成了強有力的微服務架構.

但是每個服務的維護與開發都需要2-3個人進行開發與維護，如果生鮮電商有10個模組，團隊規模過大，溝通成本很高，而且一旦生產環境出了問題，需要聯合起來進行排查，整個交易路線過於長，不利於維護.

整體而言，增加了研發成本，運營成本，伺服器成本，溝通成本，排查問題的成本

缺點：分散式帶來程式設計複雜度，遠端呼叫的消耗;捨棄強一致性，實現最終一致性;操作複雜性要求有一個成熟的運維團隊或者運維基礎設施。

實戰說明：1.比如使用者突然下不了訂單了。系統預警後，需要找到訂單服務的相關人員，進行問題的排查，這個需要時間，

2.假如問題定位後，發現是由於商品的價格設定有誤，導致訂單無法儲存，這個就需要去找商品服務的人員協助，

3.商品人員發現技術沒問題，是運營人員引數配置出錯了，導致商品這塊的價格有問題，最終無法下單。

4.最終找下運營人員，把問題解決，整個流程就又通了。

6. 決策權衡微服務

寫到最後，我不建議專案第一期做微服務架構，這兩年微服務架構在大公司變成了大小中臺戰略，因為其有複雜性非常的高，而且需要人專注某一個具體的模組與領域，提高工作效率.（淘寶，天貓，京東都採用這種，巨無霸公司）

xx生鮮，根據我6年生鮮生涯的經驗來看目前我認為其複雜性與功能性要求，不需要殺雞用牛刀. 如果以後有需要可以進行鍼對化的優化與業務處理.

最終例項如下：

實際運營截圖：