大概從16年開始，微服務的概念快速升溫，基本上人人在談。微服務來源于對SOA（Services Oriented Architecture）的優化重塑。經過這幾年的發展微服務在敏捷開發和複雜的企業級應用開發中的基本上是事實标準。

現在的軟件項目不再新開發巨大的單體應用，轉而開發衆多敏捷輕巧的小應用，共同完成一個大的目标。微服務就是這樣一種應用拆分方案的技術落地。

從上圖看到，每個微服務都有自己的業務層和數據庫層。相互之間完全獨立。彼此之間需要采用某種協議進行交互，常見的是HTTP、REST、Dubbo，甚至于使用消息系統交互

1，單一職能原則

這個原則很熟了，在面向對象設計中就經常提到。一個方法，一個類，一個微服務都應該僅負責一件事。

2，圍繞業務能力構建

微服務算是一種面向業務的服務架構設計。首先要做的是業務模塊的拆解。

微服務的理念是一切為了業務服務。每個微服務要根據自己解決的業務特性而選擇合适的技術棧。

這一點上和以前的單體應用有很大不同。在單體應用上，我們通常要考慮各個業務場景的限制，而選擇一些能見過不能場景的這種方案。

3，持續運維

一個微服務開發完成後，會由開發團隊長期進行後續的運維優化工作。

4，基礎設施的自動化

5，應對故障

微服務強調故障應對

微服務強調監控

1，根據業務選擇合适的技術棧

2，因為現在的服務都比較小，進行颠覆性改造的成本和難度會小很多

3，服務集群的水平擴展和收縮非常方便

4，服務是自給自足的，所以服務底層平台的切換更容易。究竟是使用公有雲，還是自己搭建私有雲平台。

5，微服務可以方便的添加新功能，稱為一個有機的系統（可以随着時間自己成長）

6，随着技術的發展演進，我們可以将一個微服務升級應用新的技術，而不需要升級整個系統，和前面的有點重複

7，在一個微服務中，可以有多個版本的某一服務

8，可以根據服務的邊界，确定團隊。在組織劃分上便于打造小而專的團隊

架構選擇的優劣隻有在系統使用幾年後才能真正顯現出來

并不是說以前的單體架構就一無是處，通過真确的業務理解，優秀的設計，專業的開發人員。單體應用一樣可以支撐業務

同樣，對于微服務架構，一個蹩腳的架構設計，一樣會導緻低劣的産品出來。要知道，微服務各個組件之間的交互是很複雜的，難以管理和控制。

所以，是一個好的設計 優秀的團隊帶來優秀的産品。

我建議先從單體架構開始設計一個應用，但單體應用過于複雜，可以嘗試拆分微服務。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!