前言：起初沒有意識(shí)到自己選了這么一個(gè)對(duì)自己來說有一些“宏大”的問題，因?yàn)槔锩嫔婕暗胶枚嘀R(shí)..所以砍了一些內(nèi)容..

一、信息技術(shù)發(fā)展趨勢(shì)

信息技術(shù)發(fā)展的三個(gè)階段

信息技術(shù)從出現(xiàn)到逐漸成為主流，主要經(jīng)歷了軟件、開源、云三個(gè)階段的發(fā)展。從軟件到開源，再到云，這也是信息技術(shù)的發(fā)展趨勢(shì)。

1. 軟件改變世界

縱觀人類社會(huì)漫長的發(fā)展歷史，農(nóng)耕時(shí)代、工業(yè)時(shí)代與信息時(shí)代可謂是明顯的三個(gè)分水嶺，每個(gè)時(shí)代都會(huì)出現(xiàn)很多新興的領(lǐng)域，作為信息時(shí)代最重要的載體，互聯(lián)網(wǎng)越來越成為當(dāng)今社會(huì)關(guān)注的焦點(diǎn)，互聯(lián)網(wǎng)的基石之一——軟件，正在迅速地改變著這個(gè)世界。

2. 開源改變軟件

隨著軟件行業(yè)的成熟，相比于“重復(fù)造輪子”，“站在巨人的肩膀上”明顯可以更加容易和快速地創(chuàng)造出優(yōu)秀的新產(chǎn)品。隨著開源文化越來越被認(rèn)可，以及社區(qū)文化越來越成熟，使用優(yōu)秀的開源產(chǎn)品作為基礎(chǔ)架構(gòu)來快速搭建系統(tǒng)以實(shí)現(xiàn)市場戰(zhàn)略，成為當(dāng)今最優(yōu)的資源配比方案。

3. 云吞噬開源

僅通過開源產(chǎn)品搭建并運(yùn)維一個(gè)高可用、高度彈性化的平臺(tái)，進(jìn)而實(shí)現(xiàn)互聯(lián)網(wǎng)近乎100%的可用性，難度可想而知。因此，在提供技術(shù)思路的同時(shí)，進(jìn)一步提供整套云解決方案以保證不斷擴(kuò)展的非功能需求，便成了當(dāng)今新一代互聯(lián)網(wǎng)平臺(tái)的追求。

隨著用戶集群規(guī)模的進(jìn)一步加大，單純的分布式系統(tǒng)已經(jīng)難以駕馭，因此技術(shù)圈開啟了一個(gè)概念爆發(fā)的時(shí)代——SOA、DevOps、容器、CI/CD、微服務(wù)、Service Mesh等概念層出不窮，而 Docker、Kubernetes、Mesos、Spring Cloud、Istio 等一系列產(chǎn)品的出現(xiàn)，標(biāo)志著云時(shí)代已真正到來。

互聯(lián)網(wǎng)架構(gòu)的核心問題

1. 海量用戶

當(dāng)今的互聯(lián)網(wǎng)大潮，已經(jīng)越來越難以估算用戶量以及由此產(chǎn)生的自然數(shù)據(jù)增長有多少了，區(qū)別于我們?nèi)粘５纳睿ɡ缟虉?，僅有 10 個(gè)人和有 1000 人的購物體驗(yàn)是明顯不同的），企業(yè)如何做到無差別地為全世界所有的用戶提供服務(wù)，成了一道難題。

2. 產(chǎn)品迅速迭代

面對(duì)當(dāng)今快速增長的業(yè)務(wù)和需求，敏捷開發(fā)成為了熱門的選擇。在不斷迭代的過程中，時(shí)間成本就顯得尤為重要。如何敏捷地探知市場需求并將其實(shí)現(xiàn)，是互聯(lián)網(wǎng)行業(yè)的立命之本。產(chǎn)品快速升級(jí)必然會(huì)推動(dòng)、測(cè)試、交付甚至系統(tǒng)迅速迭代。

3. 7x24 小時(shí)不間斷服務(wù)

我們要保證應(yīng)用全天候不間斷的可用，必須要考慮到隨時(shí)可能發(fā)生的意外，例如光纜挖斷、機(jī)房失火等，每一次宕機(jī)都可能會(huì)造成巨大的損失。另外，如果系統(tǒng)設(shè)計(jì)得不夠健壯，對(duì)其升級(jí)和維護(hù)時(shí)就要停止服務(wù)。頻繁的系統(tǒng)升級(jí)同樣會(huì)對(duì)系統(tǒng)可用性產(chǎn)生很大的影響。

雖然隨時(shí)隨處可用的難度非常大，但互聯(lián)網(wǎng)應(yīng)用會(huì)盡量縮短宕機(jī)時(shí)間。通常使用 3~5 個(gè) 9（3 個(gè) 9 即 99.9%，4 個(gè) 9 即 99.99%，5 個(gè) 9 即 99.999%）作為衡量系統(tǒng)可用性的指標(biāo)，表示系統(tǒng)在 1 年的運(yùn)行過程中可以正常使用的時(shí)間與總運(yùn)行時(shí)間的比值，下面分別計(jì)算 3~5 個(gè) 9 指標(biāo)下的全年宕機(jī)時(shí)間，感受一下它們的可靠性差異：

3 個(gè) 9：（1 - 99.9%） x 365 x 24 = 8.76 小時(shí)
4 個(gè) 9：（1 - 99.99&） x 365 x 24 = 52.6 分鐘
4 個(gè) 9：（1 - 99.999&） x 365 x 24 = 5.26 分鐘

4. 流量突增

流量突增分為可預(yù)期型徒增和不可預(yù)期型徒增，像促銷活動(dòng)、有計(jì)劃的熱點(diǎn)事件等引起的流量突增屬于前者，可以通過提前擴(kuò)容、預(yù)案演練等方式精心為這些流量突增準(zhǔn)備應(yīng)對(duì)方案。而意料之外的熱點(diǎn)事件（如地震）往往事發(fā)突然，系統(tǒng)來不及準(zhǔn)備應(yīng)對(duì)措施，因此若系統(tǒng)本身的可用性、彈性等非功能需求十分成熟，便可以在某種程度上應(yīng)對(duì)這種突增。

5. 業(yè)務(wù)組合復(fù)雜

很多互聯(lián)網(wǎng)公司都是跨界巨頭，我們知道，即使不跨界，在單一領(lǐng)域編織一個(gè)大規(guī)模的成型業(yè)務(wù)系統(tǒng)也并不簡單。

上圖是我從 ProcessOn 模板里隨便找的一張關(guān)于電商平臺(tái)應(yīng)用服務(wù)的架構(gòu)圖，可以看到里面交織了各種各樣的業(yè)務(wù)，當(dāng)行業(yè)的擴(kuò)張速度超出預(yù)計(jì)的增長的時(shí)候，對(duì)底層支撐的考驗(yàn)要求也越來越高。

二、什么是微服務(wù)

需要注意，“微服務(wù)”與“微服務(wù)架構(gòu)”有著本質(zhì)的區(qū)別： “微服務(wù)”強(qiáng)調(diào)的是服務(wù)的大小，它關(guān)注的是某一個(gè)點(diǎn)。而“微服務(wù)架構(gòu)”則是一種架構(gòu)思想，需要從整體上對(duì)軟件系統(tǒng)進(jìn)行通盤的考慮。

架構(gòu)的演變

要了解微服務(wù)是如何誕生的，我們有必要對(duì)架構(gòu)的演變過程有一定的了解。上面已經(jīng)對(duì)架構(gòu)主要面臨的問題進(jìn)行了闡述，下面我們來了解一下架構(gòu)是如何一步一步升級(jí)并轉(zhuǎn)化到“云”上的。

1. 單體架構(gòu)

單體架構(gòu)比較初級(jí)，典型的三級(jí)架構(gòu)，前端(Web/手機(jī)端)+中間業(yè)務(wù)邏輯層+數(shù)據(jù)庫層。這是一種典型的 MVC 框架的應(yīng)用。

單體架構(gòu)的應(yīng)用比較容易部署、測(cè)試， 在項(xiàng)目的初期，單體應(yīng)用可以很好地運(yùn)行。然而，隨著需求的不斷增加， 越來越多的人加入開發(fā)團(tuán)隊(duì)，代碼庫也在飛速地膨脹。慢慢地，單體應(yīng)用變得越來越臃腫，可維護(hù)性、靈活性逐漸降低，維護(hù)成本越來越高。下面是單體架構(gòu)應(yīng)用的一些缺點(diǎn)：

• 復(fù)雜性高： 以一個(gè)百萬行級(jí)別的單體應(yīng)用為例，整個(gè)項(xiàng)目包含的模塊非常多、模塊的邊界模糊、 依賴關(guān)系不清晰、 代碼質(zhì)量參差不齊、 混亂地堆砌在一起?？上攵麄€(gè)項(xiàng)目非常復(fù)雜。每次修改代碼都心驚膽戰(zhàn)， 甚至添加一個(gè)簡單的功能， 或者修改一個(gè) Bug 都會(huì)帶來隱含的缺陷。

• 技術(shù)債務(wù)： 隨著時(shí)間推移、需求變更和人員更迭，會(huì)逐漸形成應(yīng)用程序的技術(shù)債務(wù)， 并且越積 越多?！?不壞不修”， 這在軟件開發(fā)中非常常見， 在單體應(yīng)用中這種思想更甚。已使用的系統(tǒng)設(shè)計(jì)或代碼難以被修改，因?yàn)閼?yīng)用程序中的其他模塊可能會(huì)以意料之外的方式使用它。

• 部署頻率低： 隨著代碼的增多，構(gòu)建和部署的時(shí)間也會(huì)增加。而在單體應(yīng)用中， 每次功能的變更或缺陷的修復(fù)都會(huì)導(dǎo)致需要重新部署整個(gè)應(yīng)用。全量部署的方式耗時(shí)長、 影響范圍大、 風(fēng)險(xiǎn)高， 這使得單體應(yīng)用項(xiàng)目上線部署的頻率較低。而部署頻率低又導(dǎo)致兩次發(fā)布之間會(huì)有大量的功能變更和缺陷修復(fù)，出錯(cuò)率比較高。

• 可靠性差： 某個(gè)應(yīng)用Bug，例如死循環(huán)、內(nèi)存溢出等， 可能會(huì)導(dǎo)致整個(gè)應(yīng)用的崩潰。

• 擴(kuò)展能力受限： 單體應(yīng)用只能作為一個(gè)整體進(jìn)行擴(kuò)展，無法根據(jù)業(yè)務(wù)模塊的需要進(jìn)行伸縮。例如，應(yīng)用中有的模塊是計(jì)算密集型的，它需要強(qiáng)勁的CPU；有的模塊則是IO密集型的，需要更大的內(nèi)存。由于這些模塊部署在一起，不得不在硬件的選擇上做出妥協(xié)。

• 阻礙技術(shù)創(chuàng)新： 單體應(yīng)用往往使用統(tǒng)一的技術(shù)平臺(tái)或方案解決所有的問題， 團(tuán)隊(duì)中的每個(gè)成員 都必須使用相同的開發(fā)語言和框架，要想引入新框架或新技術(shù)平臺(tái)會(huì)非常困難。

2. 分布式架構(gòu)

中級(jí)架構(gòu)，分布式應(yīng)用，中間層分布式 + 數(shù)據(jù)庫分布式，是單體架構(gòu)的并發(fā)擴(kuò)展，將一個(gè)大的系統(tǒng)劃分為多個(gè)業(yè)務(wù)模塊，業(yè)務(wù)模塊分別部署在不同的服務(wù)器上，各個(gè)業(yè)務(wù)模塊之間通過接口進(jìn)行數(shù)據(jù)交互。數(shù)據(jù)庫也大量采用分布式數(shù)據(jù)庫，如 Redis、Elasticsearch、Solor 等。通過 LVS/Nginx 代理應(yīng)用，將用戶請(qǐng)求均衡的負(fù)載到不同的服務(wù)器上。

該架構(gòu)相對(duì)于單體架構(gòu)來說，這種架構(gòu)提供了負(fù)載均衡的能力，大大提高了系統(tǒng)負(fù)載能力，解決了網(wǎng)站高并發(fā)的需求。另外還有以下特點(diǎn)：

• 降低了耦合度： 把模塊拆分,使用接口通信,降低模塊之間的耦合度。

• 責(zé)任清晰： 把項(xiàng)目拆分成若干個(gè)子項(xiàng)目,不同的團(tuán)隊(duì)負(fù)責(zé)不同的子項(xiàng)目。

• 擴(kuò)展方便： 增加功能時(shí)只需要再增加一個(gè)子項(xiàng)目,調(diào)用其他系統(tǒng)的接口就可以。

• 部署方便： 可以靈活的進(jìn)行分布式部署。

• 提高代碼的復(fù)用性： 比如 service 層，如果不采用分布式 REST 服務(wù)方式架構(gòu)就會(huì)在手機(jī) wap 商城，微信商城，PC，Android，IOS 每個(gè)端都要寫一個(gè) service 層邏輯，開發(fā)量大，難以維護(hù)一起升級(jí)，這時(shí)候就可以采用分布式 REST 服務(wù)方式，公用一個(gè) service 層。

缺點(diǎn)： 系統(tǒng)之間的交互要使用遠(yuǎn)程通信,接口開發(fā)增大工作量,但是利大于弊。

3. 微服務(wù)架構(gòu)

微服務(wù)架構(gòu)，主要是中間層分解，將系統(tǒng)拆分成很多小應(yīng)用（微服務(wù)），微服務(wù)可以部署在不同的服務(wù)器上，也可以部署在相同的服務(wù)器不同的容器上。當(dāng)應(yīng)用的故障不會(huì)影響到其他應(yīng)用，單應(yīng)用的負(fù)載也不會(huì)影響到其他應(yīng)用，其代表框架有 Spring cloud、Dubbo 等。

• 易于開發(fā)和維護(hù)： 一個(gè)微服務(wù)只會(huì)關(guān)注一個(gè)特定的業(yè)務(wù)功能，所以它業(yè)務(wù)清晰、代碼量較少。開發(fā)和維護(hù)單個(gè)微服務(wù)相對(duì)簡單。而整個(gè)應(yīng)用是由若干個(gè)微服務(wù)構(gòu)建而成的，所以整個(gè)應(yīng)用也會(huì)被維持在一個(gè)可控狀態(tài)。

• 單個(gè)微服務(wù)啟動(dòng)較快： 單個(gè)微服務(wù)代碼量較少， 所以啟動(dòng)會(huì)比較快。

• 局部修改容易部署： 單體應(yīng)用只要有修改，就得重新部署整個(gè)應(yīng)用，微服務(wù)解決了這樣的問題。一般來說，對(duì)某個(gè)微服務(wù)進(jìn)行修改，只需要重新部署這個(gè)服務(wù)即可。

• 技術(shù)棧不受限： 在微服務(wù)架構(gòu)中，可以結(jié)合項(xiàng)目業(yè)務(wù)及團(tuán)隊(duì)的特點(diǎn)，合理地選擇技術(shù)棧。例如某些服務(wù)可使用關(guān)系型數(shù)據(jù)庫MySQL；某些微服務(wù)有圖形計(jì)算的需求，可以使用Neo4j；甚至可根據(jù)需要，部分微服務(wù)使用Java開發(fā)，部分微服務(wù)使用Node.js開發(fā)。

微服務(wù)雖然有很多吸引人的地方，但它并不是免費(fèi)的午餐，使用它是有代價(jià)的。使用微服務(wù)架構(gòu)面臨的挑戰(zhàn)。

• 運(yùn)維要求較高： 更多的服務(wù)意味著更多的運(yùn)維投入。在單體架構(gòu)中，只需要保證一個(gè)應(yīng)用的正常運(yùn)行。而在微服務(wù)中，需要保證幾十甚至幾百個(gè)服務(wù)服務(wù)的正常運(yùn)行與協(xié)作，這給運(yùn)維帶來了很大的挑戰(zhàn)。

• 分布式固有的復(fù)雜性： 使用微服務(wù)構(gòu)建的是分布式系統(tǒng)。對(duì)于一個(gè)分布式系統(tǒng)，系統(tǒng)容錯(cuò)、網(wǎng)絡(luò)延遲、分布式事務(wù)等都會(huì)帶來巨大的挑戰(zhàn)。

• 接口調(diào)整成本高： 微服務(wù)之間通過接口進(jìn)行通信。如果修改某一個(gè)微服務(wù)的API，可能所有使用了該接口的微服務(wù)都需要做調(diào)整。

• 重復(fù)勞動(dòng)： 很多服務(wù)可能都會(huì)使用到相同的功能，而這個(gè)功能并沒有達(dá)到分解為一個(gè)微服務(wù)的程度，這個(gè)時(shí)候，可能各個(gè)服務(wù)都會(huì)開發(fā)這一功能，從而導(dǎo)致代碼重復(fù)。盡管可以使用共享庫來解決這個(gè)問題（例如可以將這個(gè)功能封裝成公共組件，需要該功能的微服務(wù)引用該組件），但共享庫在多語言環(huán)境下就不一定行得通了。

4. Serverless 架構(gòu)

當(dāng)我們還在容器的浪潮中前行時(shí)，已經(jīng)有一些革命先驅(qū)悄然布局另外一個(gè)云計(jì)算戰(zhàn)場：Serverless 架構(gòu)。

Serverless 架構(gòu)能夠讓開發(fā)者在構(gòu)建應(yīng)用的過程中無需關(guān)注計(jì)算資源的獲取和運(yùn)維，由平臺(tái)來按需分配計(jì)算資源并保證應(yīng)用執(zhí)行的SLA（服務(wù)等級(jí)協(xié)議），按照調(diào)用次數(shù)進(jìn)行計(jì)費(fèi)，有效的節(jié)省應(yīng)用成本。

由于該架構(gòu)有一定的超前性，這里不做過多介紹，感興趣的童鞋可以戳這里：https://jimmysong.io/posts/what-is-serverless/

微服務(wù)定義

通過上面簡單的介紹，我們了解了我們的架構(gòu)是如何一步一步過渡到微服務(wù)的，為了解決單體應(yīng)用的諸多問題，我們提出了分布式的概念，通過將單體應(yīng)用拆分成諸多單獨(dú)的模塊來降低耦合以及提升系統(tǒng)性能，其實(shí)這里就涉及到一個(gè)服務(wù)化的概念，而微服務(wù)與之不同的是：

• 服務(wù)拆分粒度更細(xì)。微服務(wù)可以說是更細(xì)維度的服務(wù)化，小到一個(gè)子子模塊，只要該模塊依賴的資源與其他模塊都沒有關(guān)系，那么就可以拆分成一個(gè)微服務(wù)。

• 服務(wù)獨(dú)立部署。每個(gè)服務(wù)都嚴(yán)格遵循獨(dú)立打包部署的準(zhǔn)則，互不影響。比如一臺(tái)物理機(jī)上可以部署多個(gè) Docker 實(shí)例，每個(gè) Docker 實(shí)例可以部署一個(gè)微服務(wù)的代碼。

• 服務(wù)獨(dú)立維護(hù)。每個(gè)微服務(wù)都可以交由一個(gè)小團(tuán)隊(duì)甚至個(gè)人來開發(fā)、測(cè)試、發(fā)布和運(yùn)維，并對(duì)整個(gè)生命周期負(fù)責(zé)。

• 服務(wù)治理能力要求高。因?yàn)椴鸱譃槲⒎?wù)之后，服務(wù)的數(shù)量變多，因此需要有統(tǒng)一的服務(wù)治理平臺(tái)，來對(duì)各個(gè)服務(wù)進(jìn)行管理。

盡管微服務(wù)和微服務(wù)架構(gòu)有所不同，但我們通常也可以簡單理解為：

微服務(wù)是一種軟件架構(gòu)風(fēng)格，它是以專注于單一責(zé)任與功能的小型功能區(qū)塊為基礎(chǔ)，利用模組化的方式組合出復(fù)雜的大型應(yīng)用程序，各功能區(qū)塊使用與語言無關(guān)的 API（例如 REST）集相互通訊，且每個(gè)服務(wù)可以被單獨(dú)部署，它具備以下三個(gè)核心特點(diǎn)：

• 微服務(wù)為大型系統(tǒng)而生。隨著業(yè)務(wù)的快速增長，會(huì)帶來系統(tǒng)流量壓力和復(fù)雜度的上升，系統(tǒng)的可維護(hù)性和可擴(kuò)展性成為架構(gòu)設(shè)計(jì)的主要考慮因素，微服務(wù)架構(gòu)設(shè)計(jì)理念通過小而美的業(yè)務(wù)拆分，通過分而自治來實(shí)現(xiàn)復(fù)雜系統(tǒng)的優(yōu)雅設(shè)計(jì)實(shí)現(xiàn)。

• 微服務(wù)架構(gòu)是面向結(jié)果的。微服務(wù)架構(gòu)設(shè)計(jì)風(fēng)格的產(chǎn)生并非是出于學(xué)術(shù)或?yàn)闃?biāo)準(zhǔn)而標(biāo)準(zhǔn)的設(shè)計(jì)，而是在軟件架構(gòu)設(shè)計(jì)領(lǐng)域不斷演進(jìn)過程中，面對(duì)實(shí)際工業(yè)界所遇到問題，而出現(xiàn)的面向解決實(shí)際問題的架構(gòu)設(shè)計(jì)風(fēng)格。

• 專注于服務(wù)的可替代性來設(shè)計(jì)。微服務(wù)架構(gòu)設(shè)計(jì)風(fēng)格核心要解決的問題之一便是如何便利地在大型系統(tǒng)中進(jìn)行系統(tǒng)組件的維護(hù)和替換，且不影響整體系統(tǒng)穩(wěn)定性。

參考資料

1. 淺談web網(wǎng)站架構(gòu)演變過程 - https://www.cnblogs.com/xiaoMzjm/p/5223799.html
2. 互聯(lián)網(wǎng)架構(gòu)演進(jìn)之路 - https://zhuanlan.zhihu.com/p/42115757
3. 四種軟件架構(gòu)演進(jìn)史 - https://blog.csdn.net/xinyuan_java/article/details/88394332

4. 《未來架構(gòu) 從服務(wù)化到云原生》 - 張亮 等著

擴(kuò)展閱讀：
1.微服務(wù)的4個(gè)設(shè)計(jì)原則和19個(gè)解決方案 - http://p.primeton.com/articles/59b0f9244be8e61fea00be67

按照慣例黏一個(gè)尾巴：

歡迎轉(zhuǎn)載，轉(zhuǎn)載請(qǐng)注明出處！ 
簡書ID：@我沒有三顆心臟  
github：wmyskxz  
歡迎關(guān)注公眾微信號(hào)：wmyskxz
分享自己的學(xué)習(xí) & 學(xué)習(xí)資料 & 生活
想要交流的朋友也可以加qq群：3382693