大概從16年開始，微服務(wù)的概念快速升溫，基本上人人在談。微服務(wù)來源于對SOA（Services Oriented Architecture）的優(yōu)化重塑。經(jīng)過這幾年的發(fā)展微服務(wù)在敏捷開發(fā)和復雜的企業(yè)級應(yīng)用開發(fā)中的基本上是事實標準。
現(xiàn)在的軟件項目不再新開發(fā)巨大的單體應(yīng)用，轉(zhuǎn)而開發(fā)眾多敏捷輕巧的小應(yīng)用，共同完成一個大的目標。微服務(wù)就是這樣一種應(yīng)用拆分方案的技術(shù)落地。
從上圖看到，每個微服務(wù)都有自己的業(yè)務(wù)層和數(shù)據(jù)庫層。相互之間完全獨立。彼此之間需要采用某種協(xié)議進行交互，常見的是HTTP、REST、Dubbo，甚至于使用消息系統(tǒng)交互
原則
1，單一職能原則
這個原則很熟了，在面向?qū)ο笤O(shè)計中就經(jīng)常提到。一個方法，一個類，一個微服務(wù)都應(yīng)該僅負責一件事。
2，圍繞業(yè)務(wù)能力構(gòu)建
微服務(wù)算是一種面向業(yè)務(wù)的服務(wù)架構(gòu)設(shè)計。首先要做的是業(yè)務(wù)模塊的拆解。
微服務(wù)的理念是一切為了業(yè)務(wù)服務(wù)。每個微服務(wù)要根據(jù)自己解決的業(yè)務(wù)特性而選擇合適的技術(shù)棧。
這一點上和以前的單體應(yīng)用有很大不同。在單體應(yīng)用上，我們通常要考慮各個業(yè)務(wù)場景的限制，而選擇一些能見過不能場景的這種方案。
3，持續(xù)運維
一個微服務(wù)開發(fā)完成后，會由開發(fā)團隊長期進行后續(xù)的運維優(yōu)化工作。
4，基礎(chǔ)設(shè)施的自動化
5，應(yīng)對故障
微服務(wù)強調(diào)故障應(yīng)對
微服務(wù)強調(diào)監(jiān)控
益處
1，根據(jù)業(yè)務(wù)選擇合適的技術(shù)棧
2，因為現(xiàn)在的服務(wù)都比較小，進行顛覆性改造的成本和難度會小很多
3，服務(wù)集群的水平擴展和收縮非常方便
4，服務(wù)是自給自足的，所以服務(wù)底層平臺的切換更容易。究竟是使用公有云，還是自己搭建私有云平臺。
5，微服務(wù)可以方便的添加新功能，稱為一個有機的系統(tǒng)（可以隨著時間自己成長）
6，隨著技術(shù)的發(fā)展演進，我們可以將一個微服務(wù)升級應(yīng)用新的技術(shù)，而不需要升級整個系統(tǒng)，和前面的有點重復
7，在一個微服務(wù)中，可以有多個版本的某一服務(wù)
8，可以根據(jù)服務(wù)的邊界，確定團隊。在組織劃分上便于打造小而專的團隊
總結(jié)
架構(gòu)選擇的優(yōu)劣只有在系統(tǒng)使用幾年后才能真正顯現(xiàn)出來
并不是說以前的單體架構(gòu)就一無是處，通過真確的業(yè)務(wù)理解，優(yōu)秀的設(shè)計，專業(yè)的開發(fā)人員。單體應(yīng)用一樣可以支撐業(yè)務(wù)
同樣，對于微服務(wù)架構(gòu)，一個蹩腳的架構(gòu)設(shè)計，一樣會導致低劣的產(chǎn)品出來。要知道，微服務(wù)各個組件之間的交互是很復雜的，難以管理和控制。
所以，是一個好的設(shè)計+優(yōu)秀的團隊帶來優(yōu)秀的產(chǎn)品。
我建議先從單體架構(gòu)開始設(shè)計一個應(yīng)用，但單體應(yīng)用過于復雜，可以嘗試拆分微服務(wù)。
