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

?

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

?

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

?

微服務(wù)一詞源于Martin Fowler（馬丁.福勒）的名為 Microservices 的博文， 可以在他的官方博客上找到這篇文章：http://martinfowler.com/articles/microservices.html?

中文翻譯版本：https://www.martinfowler.cn/articles/microservices.html?

?

簡單地說， 微服務(wù)是系統(tǒng)架構(gòu)上的一種設(shè)計(jì)風(fēng)格， 它的主旨是將一個(gè)原本獨(dú)立的系統(tǒng)拆分成多個(gè)小型服務(wù)，這些小型服務(wù)都在各自獨(dú)立的進(jìn)程中運(yùn)行，服務(wù)之間通過基于HTTP的RESTful API進(jìn)行通信協(xié)作；

?

被拆分后的每一個(gè)小型服務(wù)都圍繞著系統(tǒng)中的某一項(xiàng)業(yè)務(wù)功能進(jìn)行構(gòu)建， 并且每個(gè)服務(wù)都是一個(gè)獨(dú)立的項(xiàng)目，可以進(jìn)行獨(dú)立的測試、開發(fā)和部署等；
由于各個(gè)獨(dú)立的服務(wù)之間使用的是基于HTTP的JSON作為數(shù)據(jù)通信協(xié)作的基礎(chǔ)，所以這些微服務(wù)可以使用不同的語言來開發(fā)；

?

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

?

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

?

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

?

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

?

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

?

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

?

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

?

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

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

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

?

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

?

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

?

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

?

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

?

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

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

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

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

負(fù)載均衡?? ?Ribbon

服務(wù)熔斷?? ?Hystrix

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

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

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

?

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

?

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

?

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

?

加之Spring Cloud 有其Spring 的強(qiáng)大技術(shù)背景，極高的社區(qū)活躍度，也許未來Spring Cloud會(huì)成為微服務(wù)的標(biāo)準(zhǔn)技術(shù)解決方案；