微服務這幾年不可謂不火，很多技術團隊都開始在自己的專案上引入了微服務。一方面這些團隊確實很好的推動了微服務的應用和發展，另一方面也可以看到一些盲目追技術熱點的行為所帶來的危害，比如很多中小團隊對微服務的基礎知識只是做了很淺顯的了解就開始盲目的推動微服務的實施，最後導致了專案的失敗。
微服務要想做好是乙個非常複雜的架構，今天就先只聊一聊微服務的一些基礎架構，算是入門篇。
一、什麼是「 微服務 」？
「 微服務 」由 martin fowler 提出，它是指一種軟體架構風格。乙個大型的系統可以由多個微服務組成，每個微服務是被獨立部署，獨立完成自己的任務單元，微服務之間是通過api方式進行通訊呼叫，是松耦合的。
這個模式聽著是不是很熟悉的感覺？
因為在提出「 微服務 」概念之前，很多網際網路公司的中大型專案早就是按照將業務拆分成獨立單元的形式在部署和架構的，這與微服務的思路是一脈相通的，只不過實現方式沒有現在這麼規範與體系。
那「 微服務 」到底是怎麼演變過來的呢？
在做乙個新專案的時候，一開始專案大多數都很小，都是「 單體應用 」，這是很常見的做法。在專案規模小的時候，這種方式開發效率和運維效率都最高，符合網際網路公司快速響應的要求。
但是隨著業務量越來越大，專案也越來越複雜，開發團隊人員也越來越多。這個時候還採用單體應用，問題就會很明顯了。下面挑選兩個最為常見的問題來舉例：
為了解決這些問題，大家就開始考慮將「 單體應用 」進行拆分，進行服務化部署。然後又隨著 martin fowler對「 微服務 」概念的提出，加上 devops 的流行，進一步促進了微服務的火熱發展。
「 微服務 」的理念提倡每個服務都是單一職責，且每乙個服務都能實現自治，因此可以帶來一些明顯好處：
二、「 微服務 」的架構是什麼樣？
我們先來看一下「 微服務 」的架構圖：
看起來挺複雜對不對，事實上也確實很複雜。
所以微服務並不是適用於所有專案、所有團隊的。在應用之前一定要搞清楚是否適合自己。
要保證這麼一套微服務架構能成功執行起來，我們起碼需要以下這些微服務的基礎元件：
當然，上述只是乙個微服務架構最為核心的基礎元件，一旦微服務體系過大，例如有幾十上百個微服務節點，那麼開發、維護、測試的成本就會非常大。因此一般還會引入 自動化部署 和 自動化測試 來提高協同效率。
三、「 微服務 」入門如何避免踩坑？
你以為微服務架構都是下面這樣的嗎？
事實上，更能是下面這樣的，哈哈。
（**網路）
大家都在宣揚「 微服務 」多麼多麼的好，例如：易擴充套件、松耦合、服務簡單、獨立開發、易維護、輕量級等等。雖然這些優勢也是事實，但是「 微服務 」帶來的問題也很多，尤其是對於剛入門的團隊而言，應用微服務後，趟坑真的可以趟到你崩潰。下面就普及一些常見的問題來給大家打個預防針：
以上，就是對架構設計中「 微服務基礎 」的一些思考。
微服務軟體架構設計
在軟體內部經過綜合各種因素考量 權衡，選擇特定的技術，將系統劃分為不同的部分並使用這些部分相互分工，彼此協作，為使用者提供需要的價值 軟體架構進化考慮的因素 傳統架構 單體架構 概念優勢 挑戰微服務架構 定義使用一套小服務來開發單個應用的方式，每個服務執行在單獨的程序，一般採用輕量級的通訊機制互聯，...
微服務架構設計模式綜述
隨著微服務的大量應用，在實踐中也會遇到很多之前單體架構所沒有的問題，微服務架構設計模式也應運而生。架構方面的權威chris richardson先生從多個角度歸納了42個設計模式，我將其歸納整理如下表，以饗讀者。後面會陸續出關於微服務架構設計模式的文章，更加深入的闡述richardson先生關於微服...
大型工程微服務架構設計拙見
現在大型專案的設計架構都是進行服務精細化 微服務的設計。最近也是接觸到真實億級流量專案，大致記錄一下較為優秀的專案結構設計。不過師傅也說，總有更精妙的架構設計，只是目前我還沒有見過，所以本文只是記錄一些粗鄙之見。為了方便說明，這裡舉個例子，比如我們有個簡單的網售咖啡 網售咖啡平台專案名為 祺平 qp...