[導(dǎo)讀]前言：起初沒有意識到自己選了這么一個對自己來說有一些“宏大”的問題，因為里面涉及到好多知識..所以砍了一些內(nèi)容.. 一、信息技術(shù)發(fā)展趨勢信息技術(shù)發(fā)展的三個階段信息技術(shù)從出現(xiàn)到逐漸成為主流，主要經(jīng)歷了軟件、開源、云三個階段的發(fā)展。從軟件到開源，

前言：起初沒有意識到自己選了這么一個對自己來說有一些“宏大”的問題，因為里面涉及到好多知識..所以砍了一些內(nèi)容..

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

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

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

1. 軟件改變世界

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

2. 開源改變軟件

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

3. 云吞噬開源

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

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

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

1. 海量用戶

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

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

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

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

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

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

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

4. 流量突增

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

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

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

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

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

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

架構(gòu)的演變

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

1. 單體架構(gòu)

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

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

復(fù)雜性高： 以一個百萬行級別的單體應(yīng)用為例，整個項目包含的模塊非常多、模塊的邊界模糊、依賴關(guān)系不清晰、代碼質(zhì)量參差不齊、混亂地堆砌在一起。可想而知整個項目非常復(fù)雜。每次修改代碼都心驚膽戰(zhàn)，甚至添加一個簡單的功能，或者修改一個 Bug 都會帶來隱含的缺陷。
技術(shù)債務(wù)： 隨著時間推移、需求變更和人員更迭，會逐漸形成應(yīng)用程序的技術(shù)債務(wù)，并且越積越多?！?不壞不修”，這在軟件開發(fā)中非常常見，在單體應(yīng)用中這種思想更甚。已使用的系統(tǒng)設(shè)計或代碼難以被修改，因為應(yīng)用程序中的其他模塊可能會以意料之外的方式使用它。
部署頻率低： 隨著代碼的增多，構(gòu)建和部署的時間也會增加。而在單體應(yīng)用中，每次功能的變更或缺陷的修復(fù)都會導(dǎo)致需要重新部署整個應(yīng)用。全量部署的方式耗時長、影響范圍大、風(fēng)險高，這使得單體應(yīng)用項目上線部署的頻率較低。而部署頻率低又導(dǎo)致兩次發(fā)布之間會有大量的功能變更和缺陷修復(fù)，出錯率比較高。
可靠性差： 某個應(yīng)用Bug，例如死循環(huán)、內(nèi)存溢出等，可能會導(dǎo)致整個應(yīng)用的崩潰。
擴(kuò)展能力受限： 單體應(yīng)用只能作為一個整體進(jìn)行擴(kuò)展，無法根據(jù)業(yè)務(wù)模塊的需要進(jìn)行伸縮。例如，應(yīng)用中有的模塊是計算密集型的，它需要強(qiáng)勁的CPU；有的模塊則是IO密集型的，需要更大的內(nèi)存。由于這些模塊部署在一起，不得不在硬件的選擇上做出妥協(xié)。
阻礙技術(shù)創(chuàng)新： 單體應(yīng)用往往使用統(tǒng)一的技術(shù)平臺或方案解決所有的問題，團(tuán)隊中的每個成員都必須使用相同的開發(fā)語言和框架，要想引入新框架或新技術(shù)平臺會非常困難。

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

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

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

降低了耦合度： 把模塊拆分,使用接口通信,降低模塊之間的耦合度。
責(zé)任清晰： 把項目拆分成若干個子項目,不同的團(tuán)隊負(fù)責(zé)不同的子項目。
擴(kuò)展方便： 增加功能時只需要再增加一個子項目,調(diào)用其他系統(tǒng)的接口就可以。
部署方便： 可以靈活的進(jìn)行分布式部署。
提高代碼的復(fù)用性： 比如 service 層，如果不采用分布式 REST 服務(wù)方式架構(gòu)就會在手機(jī) wap 商城，微信商城，PC，Android，IOS 每個端都要寫一個 service 層邏輯，開發(fā)量大，難以維護(hù)一起升級，這時候就可以采用分布式 REST 服務(wù)方式，公用一個 service 層。

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

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

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

易于開發(fā)和維護(hù)： 一個微服務(wù)只會關(guān)注一個特定的業(yè)務(wù)功能，所以它業(yè)務(wù)清晰、代碼量較少。開發(fā)和維護(hù)單個微服務(wù)相對簡單。而整個應(yīng)用是由若干個微服務(wù)構(gòu)建而成的，所以整個應(yīng)用也會被維持在一個可控狀態(tài)。
單個微服務(wù)啟動較快： 單個微服務(wù)代碼量較少，所以啟動會比較快。
局部修改容易部署： 單體應(yīng)用只要有修改，就得重新部署整個應(yīng)用，微服務(wù)解決了這樣的問題。一般來說，對某個微服務(wù)進(jìn)行修改，只需要重新部署這個服務(wù)即可。
技術(shù)棧不受限： 在微服務(wù)架構(gòu)中，可以結(jié)合項目業(yè)務(wù)及團(tuán)隊的特點，合理地選擇技術(shù)棧。例如某些服務(wù)可使用關(guān)系型數(shù)據(jù)庫MySQL；某些微服務(wù)有圖形計算的需求，可以使用Neo4j；甚至可根據(jù)需要，部分微服務(wù)使用Java開發(fā)，部分微服務(wù)使用Node.js開發(fā)。

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

運維要求較高： 更多的服務(wù)意味著更多的運維投入。在單體架構(gòu)中，只需要保證一個應(yīng)用的正常運行。而在微服務(wù)中，需要保證幾十甚至幾百個服務(wù)服務(wù)的正常運行與協(xié)作，這給運維帶來了很大的挑戰(zhàn)。
分布式固有的復(fù)雜性： 使用微服務(wù)構(gòu)建的是分布式系統(tǒng)。對于一個分布式系統(tǒng)，系統(tǒng)容錯、網(wǎng)絡(luò)延遲、分布式事務(wù)等都會帶來巨大的挑戰(zhàn)。
接口調(diào)整成本高： 微服務(wù)之間通過接口進(jìn)行通信。如果修改某一個微服務(wù)的API，可能所有使用了該接口的微服務(wù)都需要做調(diào)整。
重復(fù)勞動： 很多服務(wù)可能都會使用到相同的功能，而這個功能并沒有達(dá)到分解為一個微服務(wù)的程度，這個時候，可能各個服務(wù)都會開發(fā)這一功能，從而導(dǎo)致代碼重復(fù)。盡管可以使用共享庫來解決這個問題（例如可以將這個功能封裝成公共組件，需要該功能的微服務(wù)引用該組件），但共享庫在多語言環(huán)境下就不一定行得通了。

4. Serverless 架構(gòu)

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

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

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

微服務(wù)定義

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

服務(wù)拆分粒度更細(xì)。微服務(wù)可以說是更細(xì)維度的服務(wù)化，小到一個子子模塊，只要該模塊依賴的資源與其他模塊都沒有關(guān)系，那么就可以拆分成一個微服務(wù)。
服務(wù)獨立部署。每個服務(wù)都嚴(yán)格遵循獨立打包部署的準(zhǔn)則，互不影響。比如一臺物理機(jī)上可以部署多個 Docker 實例，每個 Docker 實例可以部署一個微服務(wù)的代碼。
服務(wù)獨立維護(hù)。每個微服務(wù)都可以交由一個小團(tuán)隊甚至個人來開發(fā)、測試、發(fā)布和運維，并對整個生命周期負(fù)責(zé)。
服務(wù)治理能力要求高。因為拆分為微服務(wù)之后，服務(wù)的數(shù)量變多，因此需要有統(tǒng)一的服務(wù)治理平臺，來對各個服務(wù)進(jìn)行管理。

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

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

微服務(wù)為大型系統(tǒng)而生。隨著業(yè)務(wù)的快速增長，會帶來系統(tǒng)流量壓力和復(fù)雜度的上升，系統(tǒng)的可維護(hù)性和可擴(kuò)展性成為架構(gòu)設(shè)計的主要考慮因素，微服務(wù)架構(gòu)設(shè)計理念通過小而美的業(yè)務(wù)拆分，通過分而自治來實現(xiàn)復(fù)雜系統(tǒng)的優(yōu)雅設(shè)計實現(xiàn)。
微服務(wù)架構(gòu)是面向結(jié)果的。微服務(wù)架構(gòu)設(shè)計風(fēng)格的產(chǎn)生并非是出于學(xué)術(shù)或為標(biāo)準(zhǔn)而標(biāo)準(zhǔn)的設(shè)計，而是在軟件架構(gòu)設(shè)計領(lǐng)域不斷演進(jìn)過程中，面對實際工業(yè)界所遇到問題，而出現(xiàn)的面向解決實際問題的架構(gòu)設(shè)計風(fēng)格。
專注于服務(wù)的可替代性來設(shè)計。微服務(wù)架構(gòu)設(shè)計風(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