前言：起初沒有意識到自己選了這麼一個對自己來說有一些“巨集大”的問題，因為裡面涉及到好多知識..所以砍了一些內容..
一、資訊科技發展趨勢
資訊科技發展的三個階段
資訊科技從出現到逐漸成為主流，主要經歷了軟體、開源、雲三個階段的發展。從軟體到開源，再到雲，這也是資訊科技的發展趨勢。
1. 軟體改變世界
縱觀人類社會漫長的發展歷史，農耕時代、工業時代與資訊時代可謂是明顯的三個分水嶺，每個時代都會出現很多新興的領域，作為資訊時代最重要的載體，網際網路越來越成為當今社會關注的焦點，網際網路的基石之一——軟體，正在迅速地改變著這個世界。
2. 開源改變軟體
隨著軟體行業的成熟，相比於“重複造輪子”，“站在巨人的肩膀上”明顯可以更加容易和快速地創造出優秀的新產品。隨著開源文化越來越被認可，以及社群文化越來越成熟，使用優秀的開源產品作為基礎架構來快速搭建系統以實現市場戰略，成為當今最優的資源配比方案。
3. 雲吞噬開源
僅通過開源產品搭建並運維一個高可用、高度彈性化的平臺，進而實現網際網路近乎100%的可用性，難度可想而知。因此，在提供技術思路的同時，進一步提供整套雲解決方案以保證不斷擴充套件的非功能需求，便成了當今新一代網際網路平臺的追求。
隨著使用者叢集規模的進一步加大，單純的分散式系統已經難以駕馭，因此技術圈開啟了一個概念爆發的時代——SOA、DevOps、容器、CI/CD、微服務、Service Mesh等概念層出不窮，而 Docker、Kubernetes、Mesos、Spring Cloud、Istio 等一系列產品的出現，標誌著雲時代已真正到來。
網際網路架構的核心問題
1. 海量使用者
當今的網際網路大潮，已經越來越難以估算使用者量以及由此產生的自然資料增長有多少了，區別於我們日常的生活（例如商場，僅有 10 個人和有 1000 人的購物體驗是明顯不同的），企業如何做到無差別地為全世界所有的使用者提供服務，成了一道難題。
2. 產品迅速迭代
面對當今快速增長的業務和需求，敏捷開發成為了熱門的選擇。在不斷迭代的過程中，時間成本就顯得尤為重要。如何敏捷地探知市場需求並將其實現，是網際網路行業的立命之本。產品快速升級必然會推動、測試、交付甚至系統迅速迭代。
3. 7x24 小時不間斷服務
我們要保證應用全天候不間斷的可用，必須要考慮到隨時可能發生的意外，例如光纜挖斷、機房失火等，每一次當機都可能會造成巨大的損失。另外，如果系統設計得不夠健壯，對其升級和維護時就要停止服務。頻繁的系統升級同樣會對系統可用性產生很大的影響。
雖然隨時隨處可用的難度非常大，但網際網路應用會盡量縮短當機時間。通常使用 3~5 個 9（3 個 9 即 99.9%，4 個 9 即 99.99%，5 個 9 即 99.999%）作為衡量系統可用性的指標，表示系統在 1 年的執行過程中可以正常使用的時間與總執行時間的比值，下面分別計算 3~5 個 9 指標下的全年當機時間，感受一下它們的可靠性差異：
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. 流量突增
流量突增分為可預期型徒增和不可預期型徒增，像促銷活動、有計劃的熱點事件等引起的流量突增屬於前者，可以通過提前擴容、預案演練等方式精心為這些流量突增準備應對方案。而意料之外的熱點事件（如地震）往往事發突然，系統來不及準備應對措施，因此若系統本身的可用性、彈性等非功能需求十分成熟，便可以在某種程度上應對這種突增。
5. 業務組合複雜
很多網際網路公司都是跨界巨頭，我們知道，即使不跨界，在單一領域編織一個大規模的成型業務系統也並不簡單。
上圖是我從 ProcessOn 模板裡隨便找的一張關於電商平臺應用服務的架構圖，可以看到裡面交織了各種各樣的業務，當行業的擴張速度超出預計的增長的時候，對底層支撐的考驗要求也越來越高。
二、什麼是微服務
需要注意，“微服務”與“微服務架構”有著本質的區別： “微服務”強調的是服務的大小，它關注的是某一個點。而“微服務架構”則是一種架構思想，需要從整體上對軟體系統進行通盤的考慮。
架構的演變
要了解微服務是如何誕生的，我們有必要對架構的演變過程有一定的瞭解。上面已經對架構主要面臨的問題進行了闡述，下面我們來了解一下架構是如何一步一步升級並轉化到“雲”上的。
1. 單體架構
單體架構比較初級，典型的三級架構，前端(Web/手機端)+中間業務邏輯層+資料庫層。這是一種典型的 MVC 框架的應用。
單體架構的應用比較容易部署、測試， 在專案的初期，單體應用可以很好地執行。然而，隨著需求的不斷增加， 越來越多的人加入開發團隊，程式碼庫也在飛速地膨脹。慢慢地，單體應用變得越來越臃腫，可維護性、靈活性逐漸降低，維護成本越來越高。下面是單體架構應用的一些缺點：
複雜性高： 以一個百萬行級別的單體應用為例，整個專案包含的模組非常多、模組的邊界模糊、 依賴關係不清晰、 程式碼質量參差不齊、 混亂地堆砌在一起。可想而知整個專案非常複雜。 每次修改程式碼都心驚膽戰， 甚至新增一個簡單的功能， 或者修改一個 Bug 都會帶來隱含的缺陷。
技術債務： 隨著時間推移、需求變更和人員更迭，會逐漸形成應用程式的技術債務， 並且越積 越多。“ 不壞不修”， 這在軟體開發中非常常見， 在單體應用中這種思想更甚。 已使用的系統設計或程式碼難以被修改，因為應用程式中的其他模組可能會以意料之外的方式使用它。
部署頻率低： 隨著程式碼的增多，構建和部署的時間也會增加。而在單體應用中， 每次功能的變更或缺陷的修復都會導致需要重新部署整個應用。全量部署的方式耗時長、 影響範圍大、 風險高， 這使得單體應用專案上線部署的頻率較低。 而部署頻率低又導致兩次釋出之間會有大量的功能變更和缺陷修復，出錯率比較高。
可靠性差： 某個應用Bug，例如死迴圈、記憶體溢位等， 可能會導致整個應用的崩潰。
擴充套件能力受限： 單體應用只能作為一個整體進行擴充套件，無法根據業務模組的需要進行伸縮。例如，應用中有的模組是計算密集型的，它需要強勁的CPU； 有的模組則是IO密集型的，需要更大的記憶體。 由於這些模組部署在一起，不得不在硬體的選擇上做出妥協。
阻礙技術創新： 單體應用往往使用統一的技術平臺或方案解決所有的問題， 團隊中的每個成員 都必須使用相同的開發語言和框架，要想引入新框架或新技術平臺會非常困難。
2. 分散式架構
中級架構，分散式應用，中間層分散式 + 資料庫分散式，是單體架構的併發擴充套件，將一個大的系統劃分為多個業務模組，業務模組分別部署在不同的伺服器上，各個業務模組之間通過介面進行資料互動。資料庫也大量採用分散式資料庫，如 Redis、Elasticsearch、Solor 等。通過 LVS/Nginx 代理應用，將使用者請求均衡的負載到不同的伺服器上。
該架構相對於單體架構來說，這種架構提供了負載均衡的能力，大大提高了系統負載能力，解決了網站高併發的需求。另外還有以下特點：
降低了耦合度： 把模組拆分,使用介面通訊,降低模組之間的耦合度。
責任清晰： 把專案拆分成若干個子專案,不同的團隊負責不同的子專案。
擴充套件方便： 增加功能時只需要再增加一個子專案,呼叫其他系統的介面就可以。
部署方便： 可以靈活的進行分散式部署。
提高程式碼的複用性： 比如 service 層，如果不採用分散式 REST 服務方式架構就會在手機 wap 商城，微信商城，PC，Android，IOS 每個端都要寫一個 service 層邏輯，開發量大，難以維護一起升級，這時候就可以採用分散式 REST 服務方式，公用一個 service 層。
缺點： 系統之間的互動要使用遠端通訊,介面開發增大工作量,但是利大於弊。
3. 微服務架構
微服務架構，主要是中間層分解，將系統拆分成很多小應用（微服務），微服務可以部署在不同的伺服器上，也可以部署在相同的伺服器不同的容器上。當應用的故障不會影響到其他應用，單應用的負載也不會影響到其他應用，其代表框架有 Spring cloud、Dubbo 等。
易於開發和維護： 一個微服務只會關注一個特定的業務功能，所以它業務清晰、程式碼量較少。 開發和維護單個微服務相對簡單。而整個應用是由若干個微服務構建而成的，所以整個應用也會被維持在一個可控狀態。
單個微服務啟動較快： 單個微服務程式碼量較少， 所以啟動會比較快。
區域性修改容易部署： 單體應用只要有修改，就得重新部署整個應用，微服務解決了這樣的問題。 一般來說，對某個微服務進行修改，只需要重新部署這個服務即可。
技術棧不受限： 在微服務架構中，可以結合專案業務及團隊的特點，合理地選擇技術棧。例如某些服務可使用關係型資料庫MySQL；某些微服務有圖形計算的需求，可以使用Neo4j；甚至可根據需要，部分微服務使用Java開發，部分微服務使用Node.js開發。
微服務雖然有很多吸引人的地方，但它並不是免費的午餐，使用它是有代價的。使用微服務架構面臨的挑戰。
運維要求較高： 更多的服務意味著更多的運維投入。在單體架構中，只需要保證一個應用的正常執行。而在微服務中，需要保證幾十甚至幾百個服務服務的正常執行與協作，這給運維帶來了很大的挑戰。
分散式固有的複雜性： 使用微服務構建的是分散式系統。對於一個分散式系統，系統容錯、網路延遲、分散式事務等都會帶來巨大的挑戰。
介面調整成本高： 微服務之間通過介面進行通訊。如果修改某一個微服務的API，可能所有使用了該介面的微服務都需要做調整。
重複勞動： 很多服務可能都會使用到相同的功能，而這個功能並沒有達到分解為一個微服務的程度，這個時候，可能各個服務都會開發這一功能，從而導致程式碼重複。儘管可以使用共享庫來解決這個問題（例如可以將這個功能封裝成公共元件，需要該功能的微服務引用該元件），但共享庫在多語言環境下就不一定行得通了。
4. Serverless 架構
當我們還在容器的浪潮中前行時，已經有一些革命先驅悄然佈局另外一個雲端計算戰場：Serverless 架構。
Serverless 架構能夠讓開發者在構建應用的過程中無需關注計算資源的獲取和運維，由平臺來按需分配計算資源並保證應用執行的SLA（服務等級協議），按照呼叫次數進行計費，有效的節省應用成本。
由於該架構有一定的超前性，這裡不做過多介紹，感興趣的童鞋可以戳這裡：https://jimmysong.io/posts/what-is-serverless/
微服務定義
通過上面簡單的介紹，我們瞭解了我們的架構是如何一步一步過渡到微服務的，為了解決單體應用的諸多問題，我們提出了分散式的概念，通過將單體應用拆分成諸多單獨的模組來降低耦合以及提升系統效能，其實這裡就涉及到一個服務化的概念，而微服務與之不同的是：
- 服務拆分粒度更細。微服務可以說是更細維度的服務化，小到一個子子模組，只要該模組依賴的資源與其他模組都沒有關係，那麼就可以拆分成一個微服務。
- 服務獨立部署。每個服務都嚴格遵循獨立打包部署的準則，互不影響。比如一臺物理機上可以部署多個 Docker 例項，每個 Docker 例項可以部署一個微服務的程式碼。
- 服務獨立維護。每個微服務都可以交由一個小團隊甚至個人來開發、測試、釋出和運維，並對整個生命週期負責。
- 服務治理能力要求高。因為拆分為微服務之後，服務的數量變多，因此需要有統一的服務治理平臺，來對各個服務進行管理。
儘管微服務和微服務架構有所不同，但我們通常也可以簡單理解為：
微服務是一種軟體架構風格，它是以專注於單一責任與功能的小型功能區塊為基礎，利用模組化的方式組合出複雜的大型應用程式，各功能區塊使用與語言無關的 API（例如 REST）集相互通訊，且每個服務可以被單獨部署，它具備以下三個核心特點：
- 微服務為大型系統而生。隨著業務的快速增長，會帶來系統流量壓力和複雜度的上升，系統的可維護性和可擴充套件性成為架構設計的主要考慮因素，微服務架構設計理念通過小而美的業務拆分，通過分而自治來實現複雜系統的優雅設計實現。
- 微服務架構是面向結果的。微服務架構設計風格的產生並非是出於學術或為標準而標準的設計，而是在軟體架構設計領域不斷演進過程中，面對實際工業界所遇到問題，而出現的面向解決實際問題的架構設計風格。
- 專注於服務的可替代性來設計。微服務架構設計風格核心要解決的問題之一便是如何便利地在大型系統中進行系統元件的維護和替換，且不影響整體系統穩定性。
參考資料
1. 淺談web網站架構演變過程 - https://www.cnblogs.com/xiaoMzjm/p/5223799.html
2. 網際網路架構演進之路 - https://zhuanlan.zhihu.com/p/42115757
3. 四種軟體架構演進史 - https://blog.csdn.net/xinyuan_java/article/details/88394332
- 《未來架構 從服務化到雲原生》 - 張亮 等著
擴充套件閱讀：
1.微服務的4個設計原則和19個解決方案 - http://p.primeton.com/articles/59b0f9244be8e61fea00be67
按照慣例黏一個尾巴：
歡迎轉載，轉載請註明出處！
簡書ID：@我沒有三顆心臟
github：wmyskxz
歡迎關注公眾微訊號：wmyskxz
分享自己的學習 & 學習資料 & 生活
想要交流的朋友也可以加qq群：3382693