關於微服務架構的個人理解（一）
文章目錄
-
什麽是微服務架構
-
微服務的出現與發展
-
傳統開發模式與微服務的區別
-
微服務的實踐理論
什麽是微服務架構
概念：微服務架構是一種架構理念，是指將功能分解到離散的各個服務當中，從而降低系統的耦合性，並提供更加靈活的服務支持。把一個大型的單體應用程序和服務拆分為數個或數十個的微小型服務，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協議。
定義：圍繞業務領域組件來創建應 用，這些應用可獨立地進行開發、管理和叠代。在分散的組件中使用雲架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單。
本質： 微服務的本質，是指用一些功能比較明確、業務比較精煉的服務去解決更大、更實際的問題。
微服務的出現與發展
微服務（Microservice）這個概念是2012年出現的，作為加快Web和移動應用程序開發進程的一種方法，2014年開始受到各方的關註，而2015年，可以說是微服務的元年；
越來越多的論壇、社區、blog以及互聯網行業巨頭開始對微服務進行討論、實踐，可以說這樣更近一步推動了微服務的發展和創新。而微服務的流行，Martin Fowler功不可沒。
這老頭是個奇人，特別擅長抽象歸納和制造概念。特別是微服務這種新生的名詞，都有一個特點：一解釋就懂，一問就不知，一討論就打架。
Martin Fowler是國際著名的OO專家，敏捷開發方法的創始人之一，現為ThoughtWorks公司的首
席科學家。在面向對象分析設計、UML、模式、軟件開發方法學、XP、重構等方面，都是世界頂級的
專家，現為Thought Works公司的首席科學家。Thought Works是一家從事企業應用開發和——集
成的公司。早在20世紀80年代，Fowler就是使用對象技術構建多層企業應用的倡導者，他著有幾
本經典書籍： 《企業應用架構模式》、《UM L精粹》和《重構》等（摘自百度百科
傳統開發模式和微服務的區別
1.傳統開發模式
先來看看傳統的 WEB 開發方式，通過對比比較容易理解什麽是 微服務架構。和 微服務 相對應的，這種方式一般被稱為 單體式開發（Monolithic）。
既所有的功能打包在一個 WAR 包裏，基本沒有外部依賴（除了容器），部署在一個 JavaEE 容器（Tomcat，JBoss，WebLogic）裏，包含了 DO/DAO，Service，UI 等所有邏輯。
優點：
-
開發簡單，集中式管理
-
基本不會重復開發
-
功能都在本地，沒有分布式的管理和調用消耗
缺點：
-
效率低：開發都在同一個項目改代碼，相互等待，沖突不斷
-
維護難：代碼功功能耦合在一起，新人不知道何從下手
-
不靈活：構建時間長，任何小修改都要重構整個項目，耗時
-
穩定性差：一個微小的問題，都可能導致整個應用掛掉
-
擴展性不夠：無法滿足高並發下的業務需求
2.微服務架構
目的：有效的拆分應用，實現敏捷開發和部署
關於微服務的一個形象表達如下：
X軸：運行多個負載均衡器之後的運行實例
Y軸：將應用進一步分解為微服務（分庫）
Z軸：大數據量時，將服務分區（分表）
微服務架構的特性
-
一系列的獨立的服務共同組成系統
-
單獨部署，跑在自己的進程中
-
每個服務為獨立的業務開發
-
分布式管理
-
非常強調隔離性
大概的標準
-
分布式服務組成的系統
-
按照業務，而不是技術來劃分組織
-
做有生命的產品而不是項目
-
強服務個體和弱通信（ Smart endpoints and dumb pipes ）
-
自動化運維（ DevOps ）
-
高度容錯性
-
快速演化和叠代
微服務的實踐理論
? 要實際的應用微服務，需要解決以下問題：
-
客戶端如何訪問這些服務
-
每個服務之間如何通信
-
如此多的服務，如何實現？
-
服務掛了，如何解決？（備份方案，應急處理機制）
一、客戶端如何訪問這些服務
原來的 Monolithic 方式開發，所有的服務都是本地的，UI 可以直接調用，現在按功能拆分成獨立的服務，跑在獨立的一般都在獨立的虛擬機上的 Java 進程了。客戶端 UI 如何訪問他？
後臺有 N 個服務，前臺就需要記住管理 N 個服務，一個服務 下線、更新、升級，前臺就要重新部署，這明顯不服務我們拆分的理念，特別當前臺是移動應用的時候，通常業務變化的節奏更快。
另外，N 個小服務的調用也是一個不小的網絡開銷。還有一般微服務在系統內部，通常是無狀態的，用戶登錄信息和權限管理最好有一個統一的地方維護管理（OAuth）。
所以，一般在後臺 N 個服務和 UI 之間一般會一個代理或者叫 API Gateway，他的作用包括：
-
提供統一服務入口，讓微服務對前臺透明
-
聚合後臺的服務，節省流量，提升性能
-
提供安全，過濾，流控等API管理功能
其實這個 API Gateway 可以有很多廣義的實現辦法，可以是一個軟硬一體的盒子，也可以是一個簡單的 MVC 框架，甚至是一個 Node.js 的服務端。他們最重要的作用是為前臺（通常是移動應用）提供後臺服務的聚合，提供一個統一的服務出口，解除他們之間的耦合，不過 API Gateway 也有可能成為 單點故障點或者性能的瓶頸。
二、每個服務之間如何通信
所有的微服務都是獨立的 Java 進程跑在獨立的虛擬機上，所以服務間的通信就是 IPC（Inter Process Communication），已經有很多成熟的方案。現在基本最通用的有兩種方式：
同步調用
-
REST（JAX-RS，Spring Boot）
-
RPC（Thrift, Dubbo）
同步調用比較簡單，一致性強，但是容易出調用問題，性能體驗上也會差些，特別是調用層次多的時候。一般 REST 基於 HTTP，更容易實現，更容易被接受，服務端實現技術也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要求，只要封裝了 HTTP 的 SDK 就能調用，所以相對使用的廣一些。RPC 也有自己的優點，傳輸協議更高效，安全更可控，特別在一個公司內部，如果有統一個的開發規範和統一的服務框架時，他的開發效率優勢更明顯些。就看各自的技術積累實際條件，自己的選擇了。
異步消息調用
-
Kafka
-
Notify
-
MessageQueue
PS:異步消息的方式在分布式系統中有特別廣泛的應用，他既能減低調用服務之間的耦合，又能成為調用之間的緩沖，確保消息積壓不會沖垮被調用方，同時能保證調用方的服務體驗，繼續幹自己該幹的活，不至於被後臺性能拖慢。不過需要付出的代價是一致性的減弱，需要接受數據 最終一致性；還有就是後臺服務一般要實現 冪等性，因為消息送出於性能的考慮一般會有重復（保證消息的被收到且僅收到一次對性能是很大的考驗）；
三、如此多的服務，如何實現
在微服務架構中，一般每一個服務都是有多個拷貝，來做負載均衡。一個服務隨時可能下線，也可能應對臨時訪問壓力增加新的服務節點。服務之間如何相互感知？服務如何管理？
這就是服務發現的問題了。一般有兩類做法，也各有優缺點。基本都是通過 Zookeeper 等類似技術做服務註冊信息的分布式管理。當服務上線時，服務提供者將自己的服務信息註冊到 ZK（或類似框架），並通過心跳維持長鏈接，實時更新鏈接信息。服務調用者通過 ZK 尋址，根據可定制算法，找到一個服務，還可以將服務信息緩存在本地以提高性能。當服務下線時，ZK 會發通知給服務客戶端。
基於客戶端的服務註冊與發現
優點是架構簡單，擴展靈活，只對服務註冊器依賴。缺點是客戶端要維護所有調用服務的地址，有技術難度，一般大公司都有成熟的內部框架支持，比如 Dubbo。
基於服務端的服務註冊與發現
優點是簡單，所有服務對於前臺調用方透明，一般在小公司在雲服務上部署的應用采用的比較多。
四、服務掛了，如何解決
前面提到，Monolithic 方式開發一個很大的風險是，把所有雞蛋放在一個籃子裏，一榮俱榮，一損俱損。而分布式最大的特性就是網絡是不可靠的。通過微服務拆分能降低這個風險，不過如果沒有特別的保障，結局肯定是噩夢。所以當我們的系統是由一系列的服務調用鏈組成的時候，我們必須確保任一環節出問題都不至於影響整體鏈路。相應的手段有很多：
-
重試機制
-
限流
-
熔斷機制
-
負載均衡
-
降級（本地緩存）
關於微服務架構的個人理解（一）