一、微服務簡介

1. 微服務的誕生

微服務是基于分而治之的思想演化出來的。過去傳統(tǒng)的一個大型而又全面的系統(tǒng)，隨著互聯(lián)網(wǎng)的發(fā)展已經(jīng)很難滿足市場對技術的需求，于是我們從單獨架構發(fā)展到分布式架構，又從分布式架構發(fā)展到 SOA 架構，服務不斷的被拆分和分解，粒度也越來越小，直到微服務架構的誕生。

微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。

每個服務運行在其獨立的進程中，服務和服務間采用輕量級的通信機制互相溝通（通常是基于 HTTP 的 RESTful API）。每個服務都圍繞著具體業(yè)務進行構建，并且能夠被獨立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應盡量避免統(tǒng)一的、集中式的服務管理機制，對具體的一個服務而言，應根據(jù)業(yè)務上下文，選擇合適的語言、工具對其進行構建。

2. 微服務架構與SOA架構的區(qū)別

微服務是真正的分布式的、去中心化的。把所有的“思考”邏輯包括路由、消息解析等放在服務內(nèi)部，去掉一個大一統(tǒng)的 ESB，服務間輕通信，是比 SOA 更徹底的拆分。

微服務架構強調(diào)的重點是業(yè)務系統(tǒng)需要徹底的組件化和服務化，原有的單個業(yè)務系統(tǒng)會拆分為多個可以獨立開發(fā)，設計，運行和運維的小應用，這些小應用之間通過服務完成交互和集成。

3. 微服務架構引發(fā)的問題

隨著整個業(yè)務數(shù)據(jù)被分散在各個子服務之后，也帶來了兩個最明顯的問題。

• 業(yè)務管理系統(tǒng)對數(shù)據(jù)完整性查詢，比如分頁查詢、多條件查詢等，數(shù)據(jù)被割裂后如何來整合?
• 數(shù)據(jù)分析挖掘，這些需求可能需要分析全量的數(shù)據(jù)，并且在分析時不能影響到當前業(yè)務

從技術方案來講，我們一般有兩種選擇來處理這些問題，第一種是在線處理數(shù)據(jù)，第二種是離線處理數(shù)據(jù)。

• 在線處理數(shù)據(jù)的方案：通過微服務提供的接口來獲取數(shù)據(jù)，然后進行數(shù)據(jù)整合，不過這種方式有著明顯的弊端，就是調(diào)用者需要編寫大量的代碼進行數(shù)據(jù)處理。其次在對各個微服務進行調(diào)取數(shù)據(jù)時會影響微服務的正常業(yè)務處理性能
• 離線處理數(shù)據(jù)方案：將業(yè)務數(shù)據(jù)準實時的同步到另外一個數(shù)據(jù)庫中，在同步的過程中進行數(shù)據(jù)整合處理，以滿足業(yè)務方對數(shù)據(jù)的需求，數(shù)據(jù)同步過來后，再提供另外一個服務接口專業(yè)負責對外輸出數(shù)據(jù)信息，這種方案有兩個特點：①數(shù)據(jù)同步方案是關鍵，技術選型有很多，如何選擇切合公司業(yè)務的技術方案；②離線數(shù)據(jù)處理對微服務正常業(yè)務處理沒有影響。

推薦使用第二種，利用 Spring Boot 和 MongoDB 可以輕松的解決這個問題，通過技術手段將分裂到 N 個微服務的數(shù)據(jù)同步到 MongoDB 集群中，在同步的過程中進行數(shù)據(jù)清洗，來滿足公司的各項業(yè)務需求

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

二、CAP 理論

Consistency ：指數(shù)據(jù)的強一致性。如果寫入某個數(shù)據(jù)成功，之后讀取，讀到的都是新 寫入的數(shù)據(jù)：如果寫入失敗，之后讀取的都不是寫入失敗的數(shù)據(jù)。 Availability ：指服務的可用性 Partition-tolerance ：指分區(qū)容錯

在分布式系統(tǒng)中 P是基本要求，而單體服務是 CA 系統(tǒng)， 微服務系統(tǒng)通常是 AP 系統(tǒng)，即同時滿足了可用性和分區(qū)容錯。

這就有了 個難題：在分布式系統(tǒng)中如何保證數(shù)據(jù)的一致性？這就是大家經(jīng)常討論的 分布式事務

三、分布式事務

在微服務架構中，分布式事務 般的解決辦法就是 兩階段提交 或者 三階段 提交，不管使用哪都存在事務失敗，導致數(shù)據(jù)不 致的情況，關鍵時刻還得人工去恢復數(shù)據(jù)。

• 第一階段：發(fā)起一個分布式事務，交給事務協(xié)調(diào)器TC處理，TC向多有的參與事務的節(jié)點發(fā)送處理事務操作的準備操作。所有的參與節(jié)點執(zhí)行準備操作，將Undo和Redo 信息寫進日志，并向事務管理器返回準備操作是否成功
• 第二階段：事務管理器收集所有節(jié)點的準備操作是否成功，如果都成功，則通知所有的節(jié)點執(zhí)行提交操作；如果有 個失敗，則執(zhí)行回滾操作

兩階段提交，將事務分成兩部分能夠大大提高分布式事務成功的概率。如果在第 階段都成功了，而執(zhí)行第 階段的某 個節(jié)點失敗，仍然導致數(shù)據(jù)的不準確，這時一般需要人工去處 理，這就是當初在第一步記錄日志的原因。另外，如果分布式事務涉及的節(jié)點很多，某 個節(jié) 點的網(wǎng)絡出現(xiàn)異常會導致整個事務處于阻塞狀態(tài)，大大降低數(shù)據(jù)庫的性能。 所以一般情況下， 盡量少用分布式事務。

四、服務劃分

橫向拆分：按照不同的業(yè)務域進行拆分，例如訂單、營銷、風控、積分資源等。形成獨立的業(yè)務領域微服務集群。

縱向拆分：把一個業(yè)務功能里的不同模塊或者組件進行拆分。例如把公共組件拆分成獨立的原子服務，下沉到底層，形成相對獨立的原子服務層。這樣一縱一橫，就可以實現(xiàn)業(yè)務的服務化拆分。

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

總之，微服務的設計一定要 漸進式 的，總的原則是 服務內(nèi)部高內(nèi)聚，服務之間低耦合。

微服務特點：

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

1. 給數(shù)據(jù)庫帶來的挑戰(zhàn)

隨著服務拆分后，我們遇到最大的問題就是后臺管理的聯(lián)合查詢，每個微服務都有自己獨立的數(shù)據(jù)庫，那么后臺該怎么處理？

這里一般有如下幾種方式：

1. 嚴格按照微服務的劃分來做，微服務相互獨立，各微服務數(shù)據(jù)庫也獨立，后臺需要展示數(shù)據(jù)時，調(diào)用各微服務的接口來獲取對應的數(shù)據(jù)，再進行數(shù)據(jù)處理后展示出來，這是標準的用法，也是最麻煩的用法。
2. 將業(yè)務高度相關的表放到一個庫中，將業(yè)務關系不是很緊密的表嚴格按照微服務模式來拆分，這樣既可以使用微服務，也避免了數(shù)據(jù)庫分散導致后臺系統(tǒng)統(tǒng)計功能難以實現(xiàn)，是一個折中的方案。
3. 數(shù)據(jù)庫嚴格按照微服務的要求來切分，以滿足業(yè)務高并發(fā)，實時或者準實時將各微服務數(shù)據(jù)庫數(shù)據(jù)同步到NoSQL數(shù)據(jù)庫中，在同步的過程中進行數(shù)據(jù)清洗，用來滿足后臺業(yè)務系統(tǒng)的使用，推薦使用MongoDB、HBase等。

三種方案在不同的公司我都使用過，第一種方案適合業(yè)務較為簡單的小公司；第二種方案，適合在原有系統(tǒng)之上，慢慢演化為微服務架構的公司；第三種適合大型高并發(fā)的互聯(lián)網(wǎng)公司。

五、熔斷器

為了解決分布式系統(tǒng)的雪崩效應，分布式系統(tǒng)引進了 熔斷器機制 。

當一個服務的處理用戶請求的失敗次數(shù)在一定時間內(nèi)小于設定的閥值時，熔斷器出于關閉狀態(tài)，服務正常。

當服務處理用戶請求失敗次數(shù)在一定時間內(nèi)大于設定的閥值時，說明服務出現(xiàn)故障，打開熔斷器，這是所有的請求會快速失敗，不執(zhí)行業(yè)務邏輯

當處于打開狀態(tài)的熔斷器時，一段時間后出于半打開狀態(tài)，并執(zhí)行一定數(shù)量的請求，剩余的請求會執(zhí)行快速失敗，若執(zhí)行請求失敗了，則繼續(xù)打開熔斷器，若成功了，則將熔斷器關閉

熔斷器不僅能防止系統(tǒng)的“雪崩”效應，還具有以下作用

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

六、服務網(wǎng)關

在微服務系統(tǒng)中，API 接口資源通常是有服務網(wǎng)關（也稱API網(wǎng)關）統(tǒng)一暴露，內(nèi)部服務不直接對外提供API資源的暴露。好處在于隱藏內(nèi)部服務，保護系統(tǒng)安全

網(wǎng)關層通常以集群的形式存在。并在服務網(wǎng)關層前通常會加上Nginx 用來負載均衡

網(wǎng)關意義：

• 網(wǎng)關將所有服務的API接口資源統(tǒng)一聚合，對外統(tǒng)一暴露
• 網(wǎng)關可以做一些用戶身份認證，權限認證，防止非法請求操作API 接口，對內(nèi)部服務起到保護作用
• 網(wǎng)關可以實現(xiàn)監(jiān)控功能，實時日志輸出、對請求進行記錄
• 網(wǎng)關可以用來做流量監(jiān)控，在高流量的情況下，對服務進行降級
• API 接口從內(nèi)部服務分離出來，方便做測試

當然，網(wǎng)關實現(xiàn)這些功能，需要做高可用，否則網(wǎng)關很可能成功架構的瓶頸，最常用的網(wǎng)關組件Zuul、Nginx

七、服務配置統(tǒng)一管理

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

八、服務鏈路追蹤

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

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

九、微服務框架

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

• 從功能模塊上考慮，Dubbo缺少很多功能模塊，例如網(wǎng)關、鏈路追蹤等
• 從學習成本上考慮，Dubbo 版本趨于穩(wěn)定，穩(wěn)定完善、可以即學即用，難度簡單，Spring cloud 基于Spring Boot，需要先掌握Spring Boot ，例外Spring cloud 大多為英文文檔，要求學習者有一定的英文閱讀能力
• 從開發(fā)風格考慮，Dubbo傾向于xml的配置方式，Spring cloud 基于Spring Boot ，采用基于注解和JavaBean配置方式的敏捷開發(fā)
• 從開發(fā)速度上考慮，Spring cloud 具有更高的開發(fā)和部署速度
• 從通信方式上考慮，Spring cloud 基于HTTP Restful 風格，服務于服務之間完全無關、無耦合。Dubbo 基于遠程調(diào)用，對接口、平臺和語言有強依賴性，如果需要實現(xiàn)跨平臺，需要有額外的中間件。

所以Dubbo專注于服務治理；Spring Cloud關注于微服務架構生態(tài)。

十、SpringCloud常用組件

• Eureka：服務注冊和發(fā)現(xiàn)組件
• Hystrix：熔斷組件
• Ribbon：負載均衡組件
• Zuul：路由網(wǎng)關

以上4個組件來自于Netflix 公司，統(tǒng)稱為Spring Cloud Netflix

• Spring Cloud Config：配置文件統(tǒng)一管理
• Spring Cloud Security：Spring Security組件封裝，提供用戶驗證和權限驗證，一般與Spring Security OAuth2 組一起使用，通過搭建授權服務，驗證Token或者JWT這種形式對整個微服務系統(tǒng)進行安全驗證
• Spring Cloud Sleuth：分布式鏈路追蹤組件，他分封裝了Dapper、Zipkin、Kibana 的組件
• Spring Cloud Stream：Spring Cloud框架的數(shù)據(jù)流操作包，可以封裝RabbitMq，ActiveMq，Kafka，Redis等消息組件，利用Spring Cloud Stream可以實現(xiàn)消息的接收和發(fā)送

一個簡單的Spring Cloud 構建的微服務系統(tǒng)，通常由服務注冊中心Eureka、網(wǎng)關Zuul、配置中心Config和授權服務Auth構成

Spring Cloud Netflix功能：

• 服務發(fā)現(xiàn)：可以注冊Eureka實例，并且客戶端可以使用Spring托管的Bean發(fā)現(xiàn)實例
• 服務發(fā)現(xiàn)：可以使用聲明性Java配置創(chuàng)建嵌入式Eureka服務器
• 斷路器：Hystrix客戶端可以使用簡單的注釋驅(qū)動的方法裝飾器構建
• 斷路器：具有聲明性Java配置的嵌入式Hystrix儀表板
• 聲明式REST客戶端：Feign創(chuàng)建一個用JAX-RS或Spring MVC注釋修飾的接口的動態(tài)實現(xiàn)。
• 客戶端負載均衡器：功能區(qū)
• 外部配置：從Spring Environment到Archaius的橋梁（使用Spring Boot約定啟用Netflix組件的本機配置）
• 路由器和過濾器：Zuul過濾器的自動重新注冊，以及用于反向代理創(chuàng)建的簡單配置約定