什么是微服務(wù)架構(gòu)

我們知道分布式強調(diào)系統(tǒng)的拆分，其實微服務(wù)也是強調(diào)系統(tǒng)的拆分，微服務(wù)架構(gòu)屬于分布式架構(gòu)的范疇；

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

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

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

被拆分后的每一個小型服務(wù)都圍繞著系統(tǒng)中的某一項業(yè)務(wù)功能進行構(gòu)建， 并且每個服務(wù)都是一個獨立的項目，可以進行獨立的測試、開發(fā)和部署等；

由于各個獨立的服務(wù)之間使用的是基于HTTP的JSON作為數(shù)據(jù)通信協(xié)作的基礎(chǔ)，所以這些微服務(wù)可以使用不同的語言來開發(fā)；

微服務(wù)架構(gòu)的優(yōu)缺點

1、我們知道微服務(wù)架構(gòu)是將系統(tǒng)中的不同功能模塊拆分成多個不同的服務(wù)，這些服務(wù)進行獨立地開發(fā)和部署，每個服務(wù)都運行在自己的進程內(nèi)，這樣每個服務(wù)的更新都不會影響其他服務(wù)的運行；

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

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

4、微服務(wù)可以使用不同的編程語言進行開發(fā)；

但是在系統(tǒng)架構(gòu)領(lǐng)域關(guān)于微服務(wù)架構(gòu)也有一些爭論，有人傾向于在系統(tǒng)設(shè)計與開發(fā)中采用微服務(wù)架構(gòu)實現(xiàn)軟件系統(tǒng)的低耦合，被認為是系統(tǒng)架構(gòu)的未來方向，Martin Fowler（馬丁.福勒）也給微服務(wù)架構(gòu)很高的評價；

同時，對微服務(wù)架構(gòu)也有人持反對觀點，他們表示：

1、微服務(wù)架構(gòu)增加了系統(tǒng)維護、部署的難度，導(dǎo)致一些功能模塊或代碼無法復(fù)用；

2、隨著系統(tǒng)規(guī)模的日漸增長，微服務(wù)在一定程度上也會導(dǎo)致系統(tǒng)變得越來越復(fù)雜，增加了集成測試的復(fù)雜度；

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

所以在系統(tǒng)架構(gòu)時也要提醒自己：不要為了微服務(wù)而微服務(wù)。

為什么選擇Spring Cloud構(gòu)建微服務(wù)

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

整個微服務(wù)架構(gòu)是由大量的技術(shù)框架和方案構(gòu)成，比如：

服務(wù)基礎(chǔ)開發(fā)    Spring MVC、Spring、SpringBoot

服務(wù)注冊與發(fā)現(xiàn)    Netflix的Eureka、Apache的ZooKeeper等

服務(wù)調(diào)用    RPC調(diào)用有阿里巴巴的Dubbo，Rest方式調(diào)用有當當網(wǎng)Dubbo基礎(chǔ)上擴展的Dubbox

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

負載均衡    Ribbon

服務(wù)熔斷    Hystrix

API網(wǎng)關(guān)    Zuul

批量任務(wù)    當當網(wǎng)的Elastic-Job、Linkedln的Azkaban

服務(wù)跟蹤    京東的Hydra、Twitter的Zipkin等

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

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

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

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