01、什麼是微服務

鞍-發表於2021-01-01
微服務

01、微服務和傳統服務講解

--一個對於學java比較經常碰到的，也是必須要了解的內容。即微服務 docker springboot springcloud的關係

--一個基本的應用業務場景圖，幫助理解微服務

--部署前準備：
    --服務docker化
        --主要是調整服務配置便於做成映象
    --用docker-compose將所有的執行內容集中，並保證容器間的通訊
    --搭建私有倉庫用於存放映象，所用的是harbor

--服務編排：
    --主要是k8s

02、軟體架構是如何發展到微服務這一步的

--最開始的jsp -->  mvc --> dubbo -->

--單體架構：
    將功能和業務集中在一個釋出包中，部署執行在同一個程式就是單體架構
        --易於開發
        --易於測試
        --易於部署
        --易於水平伸縮：只要把打好的包複製到另一個配置好的環境中即可

    --單體架構的挑戰：
        --程式碼膨脹，難以維護
        --新人上手困難
        --創新困難：前後端框架切換代價太大
        --構建部署成本太大
        --擴充套件性差：擴充套件性不是指水平伸縮而是指對單臺機器的要求非常高，這就很難辦到
--由於單體架構很難做提高，因此就需要使用微服務

--微服務：
    --一套小服務開發單個應用，每個服務執行在獨立的程式中
    --採用輕量級的通訊機制互聯
    --自動化部署

--微服務的衡量標準：
    --微的標準：
        --程式碼量不能作為衡量標準：和程式語言 人都有關係
        --開發時間：不能
        --微應該是不可度量的

    --微的特徵：
        --單一職責，只把緊密相關的業務邏輯放在一起，把不夠緊密地業務邏輯獨立出去
        --輕量級通訊
        --隔離性：每個微服務獨立執行互相不干擾
        --有自己的資料：降低資料的複雜度
        --技術多樣性：不在乎語言是什麼，只要提供出來API即可

    --微的背景：
        --網際網路快速發展
        --敏捷開發，精益方法深入人心，也就是用最少的開發做最快速的迭代
        --容器技術的成熟

--微服務優勢：
    --獨立性：比如對於登入服務可能qbs為2，使用者服務qbs為10。因此登陸的微服務開啟2個，使用者的開啟10個，同一類的微服務相互之間獨立不受干擾提高容錯性，不同類的微服務之間定製化開發節約成本
    --敏捷性：如果想要對功能做修改非常容易
    --技術棧靈活：不論後臺怎麼實現只要保持統一介面API即可
    --高效團隊

--微服務劣勢：
    --額外的工作：主要是服務的拆分，是非常深的學問，拆分過大過小都不合適。例如 DDD -- Domain-Driven Design / 領域驅動設計
    --資料一致性：儘量讓涉及多表聯查的資料庫和服務在同一個微服務中
    --溝通成本上升

--微服務的結構如下： 
    --場景設定：
        --使用者登陸註冊
        --發簡訊 發郵件
        --檢視課程列表和對課程進行curd

--首先看一下單體架構什麼樣，如下圖所示：  
    --一整個應用提供多個API介面供web和手機呼叫

--微服務搭建上述場景的結構圖：

03、微服務通訊

--什麼時候需要通訊：
   
--如何高效便捷安全的通訊：

--微服務如何發現彼此：

--微服務如何部署 更新 擴容
    --一般一個系統可能涉及到的微服務能夠達到
--微服務之間通訊：
    --通訊模式：
        --一對一 還是 一對多
        --同步 還是 非同步

--釋出訂閱：
    --給訂閱者，關注者傳送訊息

--傳送非同步響應：
    --平臺在接單以後，將其分發給不同供應商讓其搶單，先到先得
    --可能現在是根據演算法配單，但也基本是一個模式

    --通訊協議考慮：
        --REST API：基於HTTP協議的通訊介面，用於前後端的資料互動
            --REST：Representational State Transfer表現層狀態轉移，也就是前後端按照http協議請求和響應資料
            --API：介面
            --這個不強制和業務場景有關

        --RPC：dubbo grpc motan dubbox thrift等

        --MQ：訊息佇列，對於訊息訂閱非常合適

    --微服務之間通訊框架選擇：
        --RPC使用的最多，那就涉及到如何選擇一個RPC框架：
            --IO：同步IO 非同步非阻塞IO || 長連線 短連線
            --執行緒排程模型：單執行緒還是多執行緒
            --序列化方式：json xml 二進位制的不可見序列化[不常用]
            --多語言支援：
            --服務治理：服務發現 服務監控 支援叢集部署 服務的高可用

        --流行的rpc框架：
            --dubbo grpc motan dubbox thrift
--dubbo[阿里]示意圖如下：

--motan[新浪微博]示意圖如下：
    --subscribe：訂閱
    --notify：通知
    --好像只支援java

--thrift[facebook]示意圖如下：
    --序列化支援多種
    --支援多種語言：python c c++ java 
    --多種IO
    --多種執行緒模型支援
    --缺少服務治理

--grpc[google]示意圖如下：

--多種rpc框架對比：

04、服務發現、部署更新和擴容

--服務發現：
    --傳統的架構：不含服務發現

    --客戶端發現：

    --服務端發現：

05、服務的部署更新擴容

--由於微服務數量眾多，更新部署頻率高。部署更新極其複雜

--服務編排：
    --包含服務發現 服務部署 更新 擴縮容，除此之外可能還包括別的功能

--服務編排的工具：
    --docker swarm[docker]  ||  mesos[apache]  ||  kubernetes[google]

06、springboot與微服務

--springboot核心使命：   
    --化繁為簡

--springboot核心功能:
    --獨立執行  java -jar xxx.jar
    --內嵌web伺服器  能夠直接通過命令列啟動的原因
    --簡化配置
    --提供了準生產的應用監控

--springboot與微服務的關係：
    --springboot特點：輕量級 無需複雜的配置 直接就能啟動
    
    --微服務特點：數量多 輕量級

07、springcloud與微服務的關係

--springcloud的使命：
    --簡化java的分散式系統

    --提供的分散式能力如下：
        --統一的配置管理
        --服務的註冊 發現
        --服務的呼叫
        --負載均衡
        --全域性鎖
        --登陸器
      
    --特點：
        --是一系列框架的集合
        --簡化的java分散式系統
        --對springboot的封裝
    
    --核心元件：
        --Netflix Eureka 服務發現元件
        --Netflix Ribbon 客戶端負載均衡元件
        --Netflix Hystrix 斷路器
        --Netflix Zuul 服務閘道器
        --Spring Cloud Config 分散式配置

--springboot:
    --意在簡化，是一種開發配置風格，使用起來不想ssm那樣需要配置大量檔案

--springcloud:
    --意在提供一個簡化的分散式系統，將已有框架進行整合，使其風格 功能得到統一

--springcloud與微服務：
    --微服務就是一個獨立的分散式服務，springcloud就是微服務的Java解決方案
    --所提供的功能還不包括服務的監控、服務的啟動、報錯處理等功能，這些需要服務編排框架來完成

08、springcloud的五大核心元件基本講解--便於理解微服務與springcloud關係

--Netflix Eureka 服務發現元件
    --客戶端發現模式
    --每個機房獨立，保證了叢集的高可用
    --Eurake Server：服務註冊中心，類似於zookeeper
    --Application Service：在Eurake中註冊服務，並實時更新和Eurake保持服務的一致性。同時Eurake會檢測Application Service，如果一段時間內沒有相應就判斷其失效將其移除
    --Application Client：通過在Eurake中查詢註冊服務、介面ip，再對服務進行呼叫
    --這裡Eurake只是告訴客戶端服務的ip 埠，並不會涉及到客戶端和服務端的資料互動
    --不論是client 還是 service，都會執行一個Eurake client用以和Eurake保持互動和通訊

--Netflix Ribbon 客戶端負載均衡元件
    --首先這張圖是一個雲上的應用場景，亞馬遜ELB接受請求併發給Edge Service
    --Edge Service接收到請求後，Ribbon會通過Eurake的服務發現呼叫介面。每一類Ribbon管理一系列的同類分散式微服務，通過負載均衡演算法找到一個後臺併傳送給該後臺進行處理


--Edge Service:
    --微服務存在各種各種返回的原始資料，需要通過Edge Service進行整合
    
    --特點：
        --整合後端多個服務的資料
        --離使用者最近

--Netflix Hystrix 斷路器：
    --一個web使用者請求一個資料庫資源，當一個請求沒有響應時，web使用者可能拼命點選導致即使資料庫及時回覆以後，堆積的請求再次壓垮服務
    --解決的兩個問題：
        --當發現請求不被響應時，後續的請求就不會傳送給服務方
        --當服務不可用時，可以找一個更優的結果返回給前端，比如去除最近的快取資料傳送回去

    --Hystrix的狀態切換：
        --首先處於closed狀態，斷路器閉合，請求和響應都沒有問題
        --當請求沒有得到響應時，斷路器快速斷開，處於open狀態
        --過一段時間再次傳送請求，如果通了則切換為 half open狀態，如果繼續請求沒有問題就切換回close狀態，如果仍然出現錯誤則退回open狀態

Netflix Zuul 服務閘道器
    --提供閘道器APIGateWay，用於負載均衡，許可權控制等
    --主要是服務路由尋找和分配

--Spring Cloud Config 分散式配置
    --zookeeper可以提供動態配置更新載入，spring cloud config是預設使用靜態載入當然也可以配置成動態

相關文章