什麼是微服務架構

這是我參與更文挑戰的第23天，活動詳情查看：更文挑戰。

微服務的發展史

  在微服務到來以前，單體應用程序所暴露的缺點主要有：

• 複雜性高
• 擴展性差
• 團隊協做開發成本高
• 部署效率低下
• 系統不好的高可用性

  複雜性，體如今：隨着業務的不斷迭代，項目的代碼量急劇的增多，項目模塊也會隨着而增長，整個項目就會變成的很是複雜。

  開發成本高，體如今：團隊開發幾十我的在修改代碼，而後一塊兒合併到同一地址分支，打包部署，測試階段只要有一小塊功能有問題，就得從新編譯打包部署，從新測試，全部相關的開發人員都得參與其中，效率低下，開發成本極高。

  擴展性差，體如今：在新增功能業務的時候，代碼層面會考慮在不影響現有的業務基礎上編寫代碼，提升了代碼的複雜性。

  部署效率低，體如今：當單體應用的代碼愈來愈多，依賴的資源愈來愈多時，應用編譯打包、部署測試一次，須要花費的時間愈來愈多，致使部署效率低下。

  高可用差，體如今：因爲全部的業務功能最後都部署到同一個文件，一旦某一功能涉及的代碼或者資源有問題，那就會影響到整個文件包部署的功能。舉個特別鮮明的示例：上世紀8、九十年代，不少的黃頁以及延伸到後來的網站中，不少的展現頁面與獲取數據的後端都是在一個服務模塊中。這就形成一個很很差的影響：若是隻是修改極小部分的頁面展現或圖片展現，則須要把整個服務模塊進行打包部署，這樣會致使時間的嚴重浪費以及成本的增長。更加糟糕的是，給用戶帶來很是很差的體驗，用戶沒法理解的是：只是換個網站的某塊微小的展現區，致使了整個網站在那一時刻沒法正常的訪問。固然，也許，對於那個時候互聯網的不發達，人們對於這樣的體驗，已經算是一種幸福的享受了。

  因爲單體應用具備以上的種種缺點，致使了一個新名詞、新概念的誕生：微服務。

微服務究竟是啥

  其實，從早年間的單體應用，到 2014 年起，得益於以 Docker 爲表明的容器化技術的成熟以及 DevOps 文化的興起，服務化的思想進一步演化，演變爲今天咱們所熟知的微服務。那麼，微服務究竟是啥？

  微服務，英文名：microservice，百度百科上將其定義爲：SOA 架構的一種變體。微服務（或微服務架構）是一種將應用程序構造爲一組低耦合的服務。

  微服務有着一些鮮明的特色：

• 功能單一
• 服務粒度小
• 服務間獨立性強
• 服務間依賴性弱
• 服務獨立維護
• 服務獨立部署

  對於每個微服務來講，其提供的功能應該是單一的；其粒度很小的；它只會提供某一業務功能涉及到的相關接口。如：電商系統中的訂單系統、支付系統、產品系統等，每個系統服務都只是作該系統獨立的功能，不會涉及到不屬於它的功能邏輯。

  微服務之間的依賴性應該是儘可能弱的，這樣帶來的好處是：不會由於單一系統服務的宕機，而致使其它系統沒法正常運行，從而影響用戶的體驗。一樣以電商系統爲例：用戶將商品加入購物車後，提交訂單，這時候去支付，發現沒法支付，此時，能夠將訂單進入待支付狀態，從而防止訂單的丟失和用戶體驗的不友好。若是訂單系統與支付系統的強依賴性，會致使訂單系統一直在等待支付系統的迴應，這樣會致使用戶的界面始終處於加載狀態，從而致使用戶沒法進行任何操做。

  當出現某個微服務的功能須要升級，或某個功能須要修復 bug 時，只須要把當前的服務進行編譯、部署便可，不須要一個個打包整個產品業務功能的巨多服務，獨立維護、獨立部署。

  上面描述的微服務，其實突出其鮮明特性：高內聚、低耦合，問題來了。什麼是高內聚，什麼是低耦合呢？所謂高內聚：就是說每一個服務處於同一個網絡或網域下，並且相對於外部，整個的是一個封閉的、安全的盒子。盒子對外的接口是不變的，盒子內部各模塊之間的接口也是不變的，可是各模塊內部的內容能夠更改。模塊只對外暴露最小限度的接口，避免強依賴關係。增刪一個模塊，應該只會影響有依賴關係的相關模塊，無關的不該該受影響。

  所謂低耦合：從小的角度來看，就是要每一個 Java 類之間的耦合性下降，多用接口，利用 Java 面向對象編程思想的封裝、繼承、多態，隱藏實現細節。從模塊之間來說，就是要每一個模塊之間的關係下降，減小冗餘、重複、交叉的複雜度，模塊功能劃分儘量單一。

微服務的革命性與重要性

  上一小節講述了什麼是微服務，微服務的鮮明特性。其實，從單體應用看微服務，就能看出微服務的重要性，它是完全改革了應用程序的慣性，它的設計理念的出現：讓開發人員減小大量的開發成本以及修復成本；讓產品的使用者擁有一種溫馨的體驗感。它解決了單體應用程序的不少難以解決的問題，更具備創新性。它讓咱們的系統儘量快地響應變化。

  微服務將原來耦合在一塊兒的複雜業務拆分爲單個服務，規避了本來複雜度無止境的積累，每個微服務專一於單一功能，並經過定義良好的接口清晰表述服務邊界。

  因爲微服務具有獨立的運行進程，因此每一個微服務能夠獨立部署。當業務迭代時只須要發佈相關服務的迭代便可，下降了測試的工做量同時也下降了服務發佈的風險。

  在微服務架構下，當某一組件發生故障時，故障會被隔離在單個服務中。如經過限流、熔斷等方式下降錯誤致使的危害，保障核心業務的正常運行。