1. 微服務的誕生
微服務是基于分而治之的思想演化出來的。過去傳統的一個大型而又全面的系統，随着網際網路的發展已經很難滿足市場對技術的需求，于是我們從單獨架構發展到分布式架構，又從分布式架構發展到 SOA 架構，服務不斷的被拆分和分解，粒度也越來越小，直到微服務架構的誕生。
微服務架構是一種架構模式，它提倡将單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。
每個服務運作在其獨立的程序中，服務和服務間采用輕量級的通信機制互相溝通（通常是基于 HTTP 的 RESTful API）。每個服務都圍繞着具體業務進行建構，并且能夠被獨立地部署到生産環境、類生産環境等。另外，應盡量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合适的語言、工具對其進行建構。
2. 微服務架構與SOA架構的差別
微服務是真正的分布式的、去中心化的。把所有的“思考”邏輯包括路由、消息解析等放在服務内部，去掉一個大一統的 ESB，服務間輕通信，是比 SOA 更徹底的拆分。
微服務架構強調的重點是業務系統需要徹底的元件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，運作和運維的小應用，這些小應用之間通過服務完成互動和內建。
3. 微服務架構引發的問題
随着整個業務資料被分散在各個子服務之後，也帶來了兩個最明顯的問題。
業務管理系統對資料完整性查詢，比如分頁查詢、多條件查詢等，資料被割裂後如何來整合?
資料分析挖掘，這些需求可能需要分析全量的資料，并且在分析時不能影響到目前業務
從技術方案來講，我們一般有兩種選擇來處理這些問題，第一種是線上處理資料，第二種是離線處理資料。
線上處理資料的方案：通過微服務提供的接口來擷取資料，然後進行資料整合，不過這種方式有着明顯的弊端，就是調用者需要編寫大量的代碼進行資料處理。其次在對各個微服務進行調取資料時會影響微服務的正常業務處理性能
離線處理資料方案：将業務資料準實時的同步到另外一個資料庫中，在同步的過程中進行資料整合處理，以滿足業務方對資料的需求，資料同步過來後，再提供另外一個服務接口專業負責對外輸出資料資訊，這種方案有兩個特點：①資料同步方案是關鍵，技術選型有很多，如何選擇切合公司業務的技術方案；②離線資料處理對微服務正常業務處理沒有影響。
推薦使用第二種，利用 Spring Boot 和 MongoDB 可以輕松的解決這個問題，通過技術手段将分裂到 N 個微服務的資料同步到 MongoDB 叢集中，在同步的過程中進行資料清洗，來滿足公司的各項業務需求
在微服務架構中，有 大難題，那就是 服務故障的傳播性 、 服務的劃分 和 分布式事務 。
CAP 理論
Consistency ：指資料的強一緻性。如果寫入某個資料成功，之後讀取，讀到的都是新 寫入的資料：如果寫入失敗，之後讀取的都不是寫入失敗的資料。 Availability ：指服務的可用性 Partition-tolerance ：指分區容錯
在分布式系統中 P是基本要求，而單體服務是 CA 系統， 微服務系統通常是 AP 系統，即同時滿足了可用性和分區容錯。
這就有了 個難題：在分布式系統中如何保證資料的一緻性？這就是大家經常讨論的 分布式事務
分布式事務
在微服務架構中，分布式事務 般的解決辦法就是 兩階段送出 或者 三階段 送出，不管使用哪都存在事務失敗，導緻資料不 緻的情況，關鍵時刻還得人工去恢複資料。
第一階段：發起一個分布式事務，交給事務協調器TC處理，TC向多有的參與事務的節點發送處理事務操作的準備操作。所有的參與節點執行準備操作，将Undo和Redo 資訊寫進日志，并向事務管理器傳回準備操作是否成功
第二階段：事務管理器收集所有節點的準備操作是否成功，如果都成功，則通知所有的節點執行送出操作；如果有 個失敗，則執行復原操作
兩階段送出，将事務分成兩部分能夠大大提高分布式事務成功的機率。如果在第 階段都成功了，而執行第 階段的某 個節點失敗，仍然導緻資料的不準确，這時一般需要人工去處 理，這就是當初在第一步記錄日志的原因。另外，如果分布式事務涉及的節點很多，某 個節 點的網絡出現異常會導緻整個事務處于阻塞狀态，大大降低資料庫的性能。 是以一般情況下， 盡量少用分布式事務。
服務劃分
橫向拆分：按照不同的業務域進行拆分，例如訂單、營銷、風控、積分資源等。形成獨立的業務領域微服務叢集。
縱向拆分：把一個業務功能裡的不同子產品或者元件進行拆分。例如把公共元件拆分成獨立的原子服務，下沉到底層，形成相對獨立的原子服務層。這樣一縱一橫，就可以實作業務的服務化拆分。
要做好微服務的分層：梳理和抽取核心應用、公共應用，作為獨立的服務下沉到核心和公共能力層，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求
總之，微服務的設計一定要 漸進式 的，總的原則是 服務内部高内聚，服務之間低耦合。
微服務特點：
- 按照業務劃分服務，單個服務代碼量小，業務單一，易于維護
- 每個微服務都有自己獨立的基礎元件，例如資料庫、緩存等且運作在獨立的程序中
- 微服務之間的通信是通過HTTP協定或者消息元件，且具有容錯能力
- 微服務有一套服務治理的解決方案，服務之間不耦合，可以随時加入和剔除
- 單個微服務能夠叢集化部署，并且有負責 均衡的能力
- 整個微服務系統應該有完整的安全機制，包括使用者驗證，權限驗證，資源保護
- 整個微服務系統有鍊路追蹤的能力
- 有一套完整的實時日志系統
1. 給資料庫帶來的挑戰
随着服務拆分後，我們遇到最大的問題就是背景管理的聯合查詢，每個微服務都有自己獨立的資料庫，那麼背景該怎麼處理？
這裡一般有如下幾種方式：
- 嚴格按照微服務的劃分來做，微服務互相獨立，各微服務資料庫也獨立，背景需要展示資料時，調用各微服務的接口來擷取對應的資料，再進行資料處理後展示出來，這是标準的用法，也是最麻煩的用法。
- 将業務高度相關的表放到一個庫中，将業務關系不是很緊密的表嚴格按照微服務模式來拆分，這樣既可以使用微服務，也避免了資料庫分散導緻背景系統統計功能難以實作，是一個折中的方案。
- 資料庫嚴格按照微服務的要求來切分，以滿足業務高并發，實時或者準實時将各微服務資料庫資料同步到NoSQL資料庫中，在同步的過程中進行資料清洗，用來滿足背景業務系統的使用，推薦使用MongoDB、HBase等。
三種方案在不同的公司我都使用過，第一種方案适合業務較為簡單的小公司；第二種方案，适合在原有系統之上，慢慢演化為微服務架構的公司；第三種适合大型高并發的網際網路公司。
熔斷器
為了解決分布式系統的雪崩效應，分布式系統引進了 熔斷器機制 。
當一個服務的處理使用者請求的失敗次數在一定時間内小于設定的閥值時，熔斷器出于關閉狀态，服務正常。
當服務處理使用者請求失敗次數在一定時間内大于設定的閥值時，說明服務出現故障，打開熔斷器，這是所有的請求會快速失敗，不執行業務邏輯
當處于打開狀态的熔斷器時，一段時間後出于半打開狀态，并執行一定數量的請求，剩餘的請求會執行快速失敗，若執行請求失敗了，則繼續打開熔斷器，若成功了，則将熔斷器關閉
熔斷器不僅能防止系統的“雪崩”效應，還具有以下作用
- 将資源進行隔離
- 服務降級的功能
- 自我修複能力
服務網關
在微服務系統中，API 接口資源通常是有服務網關（也稱API網關）統一暴露，内部服務不直接對外提供API資源的暴露。好處在于隐藏内部服務，保護系統安全
網關層通常以叢集的形式存在。并在服務網關層前通常會加上Nginx 用來負載均衡
網關意義：
- 網關将所有服務的API接口資源統一聚合，對外統一暴露
- 網關可以做一些使用者身份認證，權限認證，防止非法請求操作API 接口，對内部服務起到保護作用
- 網關可以實作監控功能，實時日志輸出、對請求進行記錄
- 網關可以用來做流量監控，在高流量的情況下，對服務進行降級
- API 接口從内部服務分離出來，友善做測試
當然，網關實作這些功能，需要做高可用，否則網關很可能成功架構的瓶頸，最常用的網關元件Zuul、Nginx
服務配置統一管理
在微服務架構中，需要有統一管理配置檔案的元件，例如：SpringCloud Config元件、阿裡的Diamond、百度的Disconf、攜程的Apollo等
服務鍊路追蹤
在微服務架構中，必須實作分布式鍊路追蹤，去跟進一個請求到底有哪些服務參與、參與順序，是每個請求鍊路清晰可見，便于問題快速定位
常用鍊路追蹤元件有Google的Dapper、Twitter 的Zipkin，以及阿裡Eagleeye(鷹眼)
微服務架構
市面常用微服務架構有：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關注于微服務架構生态。
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過濾器的自動重新注冊，以及用于反向代理建立的簡單配置約定
整理了一些個人覺得比較好Linux伺服器/架構師學習書籍、大廠面試題、和熱門技術教學視
頻資料（資料包括C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK，ffmpeg等）和架構學習路線腦圖（對标騰訊T8職級)，免費分享有需要的可以自行添加群擷取哦！~學習交流群【960994558】