三分鐘完全弄懂什麼是分佈式和微服務架構

1、微服務簡介

1. 微服務的誕生

微服務是基於分而治之的思想演化出來的。過去傳統的一個大型而又全面的系統，隨着互聯網的發展已經很難知足市場對技術的需求，因而咱們從單獨架構發展到分佈式架構，又從分佈式架構發展到 SOA 架構，服務不斷的被拆分和分解，粒度也愈來愈小，直到微服務架構的誕生。

微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。

每一個服務運行在其獨立的進程中，服務和服務間採用輕量級的通訊機制互相溝通（一般是基於 HTTP 的 RESTful API）。每一個服務都圍繞着具體業務進行構建，而且可以被獨立地部署到生產環境、類生產環境等。另外，應儘可能避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建。

2. 微服務架構與SOA架構的區別

微服務是真正的分佈式的、去中心化的。把全部的「思考」邏輯包括路由、消息解析等放在服務內部，去掉一個大一統的 ESB，服務間輕通訊，是比 SOA 更完全的拆分。

微服務架構強調的重點是業務系統須要完全的組件化和服務化，原有的單個業務系統會拆分爲多個能夠獨立開發，設計，運行和運維的小應用，這些小應用之間經過服務完成交互和集成。

3. 微服務架構引起的問題

隨着整個業務數據被分散在各個子服務以後，也帶來了兩個最明顯的問題。

• 業務管理系統對數據完整性查詢，好比分頁查詢、多條件查詢等，數據被割裂後如何來整合?
• 數據分析挖掘，這些需求可能須要分析全量的數據，而且在分析時不能影響到當前業務

從技術方案來說，咱們通常有兩種選擇來處理這些問題，第一種是在線處理數據，第二種是離線處理數據。

• 在線處理數據的方案：經過微服務提供的接口來獲取數據，而後進行數據整合，不過這種方式有着明顯的弊端，就是調用者須要編寫大量的代碼進行數據處理。其次在對各個微服務進行調取數據時會影響微服務的正常業務處理性能

• 離線處理數據方案：將業務數據準實時的同步到另一個數據庫中，在同步的過程當中進行數據整合處理，以知足業務方對數據的需求，數據同步過來後，再提供另一個服務接口專業負責對外輸出數據信息，這種方案有兩個特色：①數據同步方案是關鍵，技術選型有不少，如何選擇切合公司業務的技術方案；②離線數據處理對微服務正常業務處理沒有影響。

推薦使用第二種，利用 Spring Boot 和 MongoDB 能夠輕鬆的解決這個問題，經過技術手段將分裂到 N 個微服務的數據同步到 MongoDB 集羣中，在同步的過程當中進行數據清洗，來知足公司的各項業務需求

在微服務架構中，有 大難題，那就是 服務故障的傳播性 、 服務的劃分 和 分佈式事務 。

2、CAP 理論

Consistency ：指數據的強一致性。若是寫入某個數據成功，以後讀取，讀到的都是新 寫入的數據：若是寫入失敗，以後讀取的都不是寫入失敗的數據。
Availability ：指服務的可用性
Partition-tolerance ：指分區容錯

在分佈式系統中 P是基本要求，而單體服務是 CA 系統， 微服務系統一般是 AP 系統，即同時知足了可用性和分區容錯。

這就有了 個難題：在分佈式系統中如何保證數據的一致性？這就是你們常常討論的 分佈式事務

3、分佈式事務

在微服務架構中，分佈式事務 般的解決辦法就是 兩階段提交 或者 三階段 提交，無論使用哪都存在事務失敗，致使數據不 致的狀況，關鍵時刻還得人工去恢復數據。

• 第一階段：發起一個分佈式事務，交給事務協調器TC處理，TC向多有的參與事務的節點發送處理事務操做的準備操做。全部的參與節點執行準備操做，將Undo和Redo 信息寫進日誌，並向事務管理器返回準備操做是否成功
• 第二階段：事務管理器收集全部節點的準備操做是否成功，若是都成功，則通知全部的節點執行提交操做；若是有 個失敗，則執行回滾操做

兩階段提交，將事務分紅兩部分可以大大提升分佈式事務成功的機率。若是在第 階段都成功了，而執行第 階段的某 個節點失敗，仍然致使數據的不許確，這時通常須要人工去處 理，這就是當初在第一步記錄日誌的緣由。另外，若是分佈式事務涉及的節點不少，某 個節 點的網絡出現異常會致使整個事務處於阻塞狀態，大大下降數據庫的性能。 因此通常狀況下， 儘可能少用分佈式事務。

4、服務劃分

橫向拆分：按照不一樣的業務域進行拆分，例如訂單、營銷、風控、積分資源等。造成獨立的業務領域微服務集羣。

縱向拆分：把一個業務功能裏的不一樣模塊或者組件進行拆分。例如把公共組件拆分紅獨立的原子服務，下沉到底層，造成相對獨立的原子服務層。這樣一縱一橫，就能夠實現業務的服務化拆分。

要作好微服務的分層：梳理和抽取核心應用、公共應用，做爲獨立的服務下沉到核心和公共能力層，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求

總之，微服務的設計必定要 漸進式 的，總的原則是 服務內部高內聚，服務之間低耦合。

微服務特色：

• 按照業務劃分服務，單個服務代碼量小，業務單一，易於維護
• 每一個微服務都有本身獨立的基礎組件，例如數據庫、緩存等且運行在獨立的進程中
• 微服務之間的通訊是經過HTTP協議或者消息組件，且具備容錯能力
• 微服務有一套服務治理的解決方案，服務之間不耦合，能夠隨時加入和剔除
• 單個微服務可以集羣化部署，而且有負責 均衡的能力
• 整個微服務系統應該有完整的安全機制，包括用戶驗證，權限驗證，資源保護
• 整個微服務系統有鏈路追蹤的能力
• 有一套完整的實時日誌系統

1. 給數據庫帶來的挑戰

隨着服務拆分後，咱們遇到最大的問題就是後臺管理的聯合查詢，每一個微服務都有本身獨立的數據庫，那麼後臺該怎麼處理？

這裏通常有以下幾種方式：

1. 嚴格按照微服務的劃分來作，微服務相互獨立，各微服務數據庫也獨立，後臺須要展現數據時，調用各微服務的接口來獲取對應的數據，再進行數據處理後展現出來，這是標準的用法，也是最麻煩的用法。
2. 將業務高度相關的表放到一個庫中，將業務關係不是很緊密的表嚴格按照微服務模式來拆分，這樣既可使用微服務，也避免了數據庫分散致使後臺系通通計功能難以實現，是一個折中的方案。
3. 數據庫嚴格按照微服務的要求來切分，以知足業務高併發，實時或者準實時將各微服務數據庫數據同步到NoSQL數據庫中，在同步的過程當中進行數據清洗，用來知足後臺業務系統的使用，推薦使用MongoDB、HBase等。

三種方案在不一樣的公司我都使用過，第一種方案適合業務較爲簡單的小公司；第二種方案，適合在原有系統之上，慢慢演化爲微服務架構的公司；第三種適合大型高併發的互聯網公司。

5、熔斷器

爲了解決分佈式系統的雪崩效應，分佈式系統引進了 熔斷器機制 。

當一個服務的處理用戶請求的失敗次數在必定時間內小於設定的閥值時，熔斷器出於關閉狀態，服務正常。

當服務處理用戶請求失敗次數在必定時間內大於設定的閥值時，說明服務出現故障，打開熔斷器，這是全部的請求會快速失敗，不執行業務邏輯

當處於打開狀態的熔斷器時，一段時間後出於半打開狀態，並執行必定數量的請求，剩餘的請求會執行快速失敗，若執行請求失敗了，則繼續打開熔斷器，若成功了，則將熔斷器關閉

熔斷器不只能防止系統的「雪崩」效應，還具備如下做用

• 將資源進行隔離
• 服務降級的功能
• 自我修復能力

6、服務網關

在微服務系統中，API 接口資源一般是有服務網關（也稱API網關）統一暴露，內部服務不直接對外提供API資源的暴露。好處在於隱藏內部服務，保護系統安全

網關層一般以集羣的形式存在。並在服務網關層前一般會加上Nginx 用來負載均衡

網關意義：

• 網關將全部服務的API接口資源統一聚合，對外統一暴露
• 網關能夠作一些用戶身份認證，權限認證，防止非法請求操做API 接口，對內部服務起到保護做用
• 網關能夠實現監控功能，實時日誌輸出、對請求進行記錄
• 網關能夠用來作流量監控，在高流量的狀況下，對服務進行降級
• API 接口從內部服務分離出來，方便作測試

固然，網關實現這些功能，須要作高可用，不然網關極可能成功架構的瓶頸，最經常使用的網關組件Zuul、Nginx

7、服務配置統一管理

在微服務架構中，須要有統一管理配置文件的組件，例如：SpringCloud Config組件、阿里的Diamond、百度的Disconf、攜程的Apollo等

8、服務鏈路追蹤

在微服務架構中，必須實現分佈式鏈路追蹤，去跟進一個請求到底有哪些服務參與、參與順序，是每一個請求鏈路清晰可見，便於問題快速定位

經常使用鏈路追蹤組件有Google的Dapper、Twitter 的Zipkin，以及阿里Eagleeye(鷹眼)

9、微服務框架

市面經常使用微服務框架有：Spring Cloud 、Dubbo 、kubernetes

• 從功能模塊上考慮，Dubbo缺乏不少功能模塊，例如網關、鏈路追蹤等
• 從學習成本上考慮，Dubbo 版本趨於穩定，穩定完善、能夠即學即用，難度簡單，Spring cloud 基於Spring Boot，須要先掌握Spring Boot ，例外Spring cloud 大多爲英文文檔，要求學習者有必定的英文閱讀能力
• 從開發風格考慮，Dubbo傾向於xml的配置方式，Spring cloud 基於Spring Boot ，採用基於註解和JavaBean配置方式的敏捷開發
• 從開發速度上考慮，Spring cloud 具備更高的開發和部署速度
• 從通訊方式上考慮，Spring cloud 基於HTTP Restful 風格，服務於服務之間徹底無關、無耦合。Dubbo 基於遠程調用，對接口、平臺和語言有強依賴性，若是須要實現跨平臺，須要有額外的中間件。

因此Dubbo專一於服務治理；Spring Cloud關注於微服務架構生態。

10、SpringCloud經常使用組件

• Eureka：服務註冊和發現組件
• Hystrix：熔斷組件
• Ribbon：負載均衡組件
• Zuul：路由網關

以上4個組件來自於Netflix 公司，統稱爲Spring Cloud Netflix

• Spring Cloud Config：配置文件統一管理
• Spring Cloud Security：Spring Security組件封裝，提供用戶驗證和權限驗證，通常與Spring Security OAuth2 組一塊兒使用，經過搭建受權服務，驗證Token或者JWT這種形式對整個微服務系統進行安全驗證
• Spring Cloud Sleuth：分佈式鏈路追蹤組件，他分封裝了Dapper、Zipkin、Kibana 的組件
• Spring Cloud Stream：Spring Cloud框架的數據流操做包，能夠封裝RabbitMq，ActiveMq，Kafka，Redis等消息組件，利用Spring Cloud Stream能夠實現消息的接收和發送

一個簡單的Spring Cloud 構建的微服務系統，一般由服務註冊中心Eureka、網關Zuul、配置中心Config和受權服務Auth構成

Spring Cloud Netflix功能：

• 服務發現：能夠註冊Eureka實例，而且客戶端可使用Spring託管的Bean發現實例
• 服務發現：可使用聲明性Java配置建立嵌入式Eureka服務器
• 斷路器：Hystrix客戶端可使用簡單的註釋驅動的方法裝飾器構建
• 斷路器：具備聲明性Java配置的嵌入式Hystrix儀表板
• 聲明式REST客戶端：Feign建立一個用JAX-RS或Spring MVC註釋修飾的接口的動態實現。
• 客戶端負載均衡器：功能區
• 外部配置：從Spring Environment到Archaius的橋樑（使用Spring Boot約定啓用Netflix組件的本機配置）
• 路由器和過濾器：Zuul過濾器的自動從新註冊，以及用於反向代理建立的簡單配置約定

感謝你們的閱讀，若有錯誤之處歡迎指正！

想要閱讀更多精彩內容，能夠關注個人微信公衆號：Java技術zhai，這是個人私人公衆號，專一於Java技術分享，期待你的參與。