Spring Cloud微服務(wù)架構(gòu)概述
系統(tǒng)進(jìn)化理論概述
在系統(tǒng)架構(gòu)與設(shè)計(jì)的實(shí)踐中，經(jīng)歷了兩個(gè)階段，一個(gè)階段是早些年常見(jiàn)的集中式系統(tǒng)，一個(gè)階段是近年來(lái)流行的分布式系統(tǒng);
集中式系統(tǒng)
集中式系統(tǒng)也叫單體應(yīng)用，就是把所有的程序、功能、模塊都集中到一個(gè)項(xiàng)目中，部署在一臺(tái)服務(wù)器上，從而對(duì)外提供服務(wù);
分布式系統(tǒng)
分布式系統(tǒng)就是把所有的程序、功能拆分成不同的子系統(tǒng)，部署在多臺(tái)不同的服務(wù)器上，這些子系統(tǒng)相互協(xié)作共同對(duì)外提供服務(wù)，而對(duì)用戶而言他并不知道后臺(tái)是多個(gè)子系統(tǒng)和多臺(tái)服務(wù)器在提供服務(wù)，在使用上和集中式系統(tǒng)一樣;
集中式系統(tǒng)跟分布式系統(tǒng)是相反的兩個(gè)概念，他們的區(qū)別體現(xiàn)在“合”與“分”。
系統(tǒng)進(jìn)化理論背景
系統(tǒng)進(jìn)化的背景與中國(guó)互聯(lián)網(wǎng)用戶規(guī)模龐大有巨大關(guān)系，中國(guó)互聯(lián)網(wǎng)用戶規(guī)模有7.7億，龐大的用戶訪問(wèn)量對(duì)系統(tǒng)的架構(gòu)設(shè)計(jì)是巨大的挑戰(zhàn);
產(chǎn)品或者網(wǎng)站初期，通常功能較少，用戶量也不多，所以一般按照單體應(yīng)用進(jìn)行設(shè)計(jì)和開(kāi)發(fā)，按照經(jīng)典的MVC三層架構(gòu)設(shè)計(jì);
隨著業(yè)務(wù)的發(fā)展，應(yīng)用功能的增加，訪問(wèn)用戶的增多，傳統(tǒng)的采用集中式系統(tǒng)進(jìn)行開(kāi)發(fā)的方式就不再適用了，因?yàn)樵谶@種情況下，集中式系統(tǒng)就會(huì)逐步變得非常龐大，很多人維護(hù)這么一個(gè)系統(tǒng)，開(kāi)發(fā)、測(cè)試、上線都會(huì)造成很大問(wèn)題，比如代碼沖突，代碼重復(fù)，邏輯錯(cuò)綜混亂，代碼邏輯復(fù)雜度增加，響應(yīng)新需求的速度降低，隱藏的風(fēng)險(xiǎn)增大;
所以需要按照業(yè)務(wù)維度進(jìn)行應(yīng)用拆分，采用分布式開(kāi)發(fā)，每個(gè)應(yīng)用專職于做某一些方面的事情，比如將一個(gè)集中式系統(tǒng)拆分為用戶服務(wù)、訂單服務(wù)、產(chǎn)品服務(wù)、交易服務(wù)等，各個(gè)應(yīng)用服務(wù)之間通過(guò)相互調(diào)用完成某一項(xiàng)業(yè)務(wù)功能。
什么是微服務(wù)架構(gòu)
分布式強(qiáng)調(diào)系統(tǒng)的拆分，微服務(wù)也是強(qiáng)調(diào)系統(tǒng)的拆分，微服務(wù)架構(gòu)屬于分布式架構(gòu)的范疇;
并且到目前為止，微服務(wù)并沒(méi)有一個(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
簡(jiǎn)單地說(shuō)， 微服務(wù)是系統(tǒng)架構(gòu)上的一種設(shè)計(jì)風(fēng)格， 它的主旨是將一個(gè)原本獨(dú)立的系統(tǒng)拆分成多個(gè)小型服務(wù)，這些小型服務(wù)都在各自獨(dú)立的進(jìn)程中運(yùn)行，服務(wù)之間通過(guò)基于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ú)立的測(cè)試、開(kāi)發(fā)和部署等；
由于各個(gè)獨(dú)立的服務(wù)之間使用的是基于HTTP的JSON作為數(shù)據(jù)通信協(xié)作的基礎(chǔ)，所以這些微服務(wù)可以使用不同的語(yǔ)言來(lái)開(kāi)發(fā)；
微服務(wù)架構(gòu)的優(yōu)缺點(diǎn)
1、我們知道微服務(wù)架構(gòu)是將系統(tǒng)中的不同功能模塊拆分成多個(gè)不同的服務(wù)，這些服務(wù)進(jìn)行獨(dú)立地開(kāi)發(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)估，通過(guò)壓力測(cè)試，也很容易發(fā)現(xiàn)各個(gè)服務(wù)間的性能瓶頸所在;
3、由于每個(gè)服務(wù)都是獨(dú)立開(kāi)發(fā)，項(xiàng)目的開(kāi)發(fā)也比較方便，減少代碼的沖突、代碼的重復(fù)，邏輯處理流程也更加清晰，讓后續(xù)的維護(hù)與擴(kuò)展更加容易;
4、微服務(wù)可以使用不同的編程語(yǔ)言進(jìn)行開(kāi)發(fā);
但是在系統(tǒng)架構(gòu)領(lǐng)域關(guān)于微服務(wù)架構(gòu)也有一些爭(zhēng)論，有人傾向于在系統(tǒng)設(shè)計(jì)與開(kāi)發(fā)中采用微服務(wù)架構(gòu)實(shí)現(xiàn)軟件系統(tǒng)的低耦合，被認(rèn)為是系統(tǒng)架構(gòu)的未來(lái)方向，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)致一些功能模塊或代碼無(wú)法復(fù)用;
2、隨著系統(tǒng)規(guī)模的日漸增長(zhǎng)，微服務(wù)在一定程度上也會(huì)導(dǎo)致系統(tǒng)變得越來(lái)越復(fù)雜，增加了集成測(cè)試的復(fù)雜度;
3、隨著微服務(wù)的增多，數(shù)據(jù)的一致性問(wèn)題，服務(wù)之間的通信成本等都凸顯了出來(lái);
所以在系統(tǒng)架構(gòu)時(shí)也要提醒自己：不要為了微服務(wù)而微服務(wù)。
為什么選擇Spring Cloud構(gòu)建微服務(wù)
微服務(wù)一詞是Martin Fowler(馬丁.福勒)于2014年提出來(lái)的，近幾年微服務(wù)架構(gòu)的討論非常火熱，無(wú)數(shù)的架構(gòu)師和開(kāi)發(fā)者在實(shí)際項(xiàng)目中實(shí)踐著微服務(wù)架構(gòu)的設(shè)計(jì)理念，他們?cè)谖⒎?wù)架構(gòu)中針對(duì)不同應(yīng)用場(chǎng)景出現(xiàn)的各種問(wèn)題，也推出了很多解決方案和開(kāi)源框架，其中我們國(guó)內(nèi)的互聯(lián)網(wǎng)企業(yè)也有一些著名的框架和方案;
整個(gè)微服務(wù)架構(gòu)是由大量的技術(shù)框架和方案構(gòu)成，比如：
| 服務(wù)基礎(chǔ)開(kāi)發(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)上，幾乎大部分的開(kāi)源組件都只能解決某一個(gè)場(chǎng)景下的問(wèn)題，所以這些實(shí)施微服務(wù)架構(gòu)的公司也是整合來(lái)自不同公司或組織的諸多開(kāi)源框架，并加入針對(duì)自身業(yè)務(wù)的一些改進(jìn)，沒(méi)有一個(gè)統(tǒng)一的架構(gòu)方案;
所以當(dāng)我們準(zhǔn)備實(shí)施微服務(wù)架構(gòu)時(shí)，我們要整合各個(gè)公司或組織的開(kāi)源軟件，而且某些開(kāi)源軟件又有多種選擇，這導(dǎo)致在做技術(shù)選型的初期，需要花費(fèi)大量的時(shí)間進(jìn)行預(yù)備研、分析和實(shí)驗(yàn)，這些方案的整合沒(méi)有得到充分的測(cè)試，可能在實(shí)踐中會(huì)遇到各種各樣的問(wèn)題;
Spring Cloud的出現(xiàn)，可以說(shuō)是為微服務(wù)架構(gòu)迎來(lái)一縷曙光，有SpringCloud社區(qū)的巨大支持和技術(shù)保障，讓我們實(shí)施微服務(wù)架構(gòu)變得異常簡(jiǎn)單了起來(lái)，它不像我們之前所列舉的框架那樣，只是解決微服務(wù)中的某一個(gè)問(wèn)題，而是一個(gè)解決微服務(wù)架構(gòu)實(shí)施的綜合性解決框架，它整合了諸多被廣泛實(shí)踐和證明有效的框架作為實(shí)施的基礎(chǔ)組件，又在該體系基礎(chǔ)上創(chuàng)建了一些非常優(yōu)秀的邊緣組件將它們很好地整合起來(lái)。
加之Spring Cloud 有其Spring 的強(qiáng)大技術(shù)背景，極高的社區(qū)活躍度，也許未來(lái)Spring Cloud會(huì)成為微服務(wù)的標(biāo)準(zhǔn)技術(shù)解決方案;
