什么是微服務架構

我們知道分布式強調系統的拆分，其實微服務也是強調系統的拆分，微服務架構屬于分布式架構的范疇；

并且到目前為止，微服務并沒有一個統一的標準的定義，那么微服務究竟是什么？

微服務并且到目前為止，微服務并沒有一個統一的標準的定義，那么微服務究竟是什么？

一詞源于Martin Fowler（馬丁.福勒）的名為 Microservices 的博文， 簡單地說， 微服務是系統架構上的一種設計風格， 它的主旨是將一個原本獨立的系統拆分成多個小型服務，這些小型服務都在各自獨立的進程中運行，服務之間通過基于HTTP的RESTful API進行通信協作；

被拆分后的每一個小型服務都圍繞著系統中的某一項業務功能進行構建， 并且每個服務都是一個獨立的項目，可以進行獨立的測試、開發和部署等；

由于各個獨立的服務之間使用的是基于HTTP的JSON作為數據通信協作的基礎，所以這些微服務可以使用不同的語言來開發；

微服務架構的優缺點

1、我們知道微服務架構是將系統中的不同功能模塊拆分成多個不同的服務，這些服務進行獨立地開發和部署，每個服務都運行在自己的進程內，這樣每個服務的更新都不會影響其他服務的運行；

2、由于每個服務是獨立部署的，所以我們可以更準確地監控每個服務的資源消耗情況，進行性能容量的評估，通過壓力測試，也很容易發現各個服務間的性能瓶頸所在；

3、由于每個服務都是獨立開發，項目的開發也比較方便，減少代碼的沖突、代碼的重復，邏輯處理流程也更加清晰，讓后續的維護與擴展更加容易；

4、微服務可以使用不同的編程語言進行開發；

但是在系統架構領域關于微服務架構也有一些爭論，有人傾向于在系統設計與開發中采用微服務架構實現軟件系統的低耦合，被認為是系統架構的未來方向，Martin Fowler（馬丁.福勒）也給微服務架構很高的評價；

同時，對微服務架構也有人持反對觀點，他們表示：

1、微服務架構增加了系統維護、部署的難度，導致一些功能模塊或代碼無法復用；

2、隨著系統規模的日漸增長，微服務在一定程度上也會導致系統變得越來越復雜，增加了集成測試的復雜度；

3、隨著微服務的增多，數據的一致性問題，服務之間的通信成本等都凸顯了出來；

所以在系統架構時也要提醒自己：不要為了微服務而微服務。

為什么選擇Spring Cloud構建微服務

微服務一詞是Martin Fowler（馬丁.福勒）于2014年提出來的，近幾年微服務架構的討論非常火熱，無數的架構師和開發者在實際項目中實踐著微服務架構的設計理念，他們在微服務架構中針對不同應用場景出現的各種問題，也推出了很多解決方案和開源框架，其中我們國內的互聯網企業也有一些著名的框架和方案；

整個微服務架構是由大量的技術框架和方案構成，比如：

服務基礎開發    Spring MVC、Spring、SpringBoot

服務注冊與發現    Netflix的Eureka、Apache的ZooKeeper等

服務調用    RPC調用有阿里巴巴的Dubbo，Rest方式調用有當當網Dubbo基礎上擴展的Dubbox

分布式配置管理    百度的Disconf、360的QConf、淘寶的Diamond、Netflix的Archaius等

負載均衡    Ribbon

服務熔斷    Hystrix

API網關    Zuul

批量任務    當當網的Elastic-Job、Linkedln的Azkaban

服務跟蹤    京東的Hydra、Twitter的Zipkin等

但是在微服務架構上，幾乎大部分的開源組件都只能解決某一個場景下的問題，所以這些實施微服務架構的公司也是整合來自不同公司或組織的諸多開源框架，并加入針對自身業務的一些改進，沒有一個統一的架構方案；

所以當我們準備實施微服務架構時，我們要整合各個公司或組織的開源軟件，而且某些開源軟件又有多種選擇，這導致在做技術選型的初期，需要花費大量的時間進行預備研、分析和實驗，這些方案的整合沒有得到充分的測試，可能在實踐中會遇到各種各樣的問題；

Spring Cloud的出現，可以說是為微服務架構迎來一縷曙光，有SpringCloud社區的巨大支持和技術保障，讓我們實施微服務架構變得異常簡單了起來，它不像我們之前所列舉的框架那樣，只是解決微服務中的某一個問題，而是一個解決微服務架構實施的綜合性解決框架，它整合了諸多被廣泛實踐和證明有效的框架作為實施的基礎組件，又在該體系基礎上創建了一些非常優秀的邊緣組件將它們很好地整合起來。

加之Spring Cloud 有其Spring 的強大技術背景，極高的社區活躍度，也許未來Spring Cloud會成為微服務的標準技術解決方案。