微服務入門【系列視訊課程】

Java貓說發表於2019-01-10
微服務

本文首發於本部落格 貓叔的部落格，轉載請申明出處

公眾號：Java貓說

現架構設計（碼農）兼創業技術顧問，不羈平庸，熱愛開源，雜談程式人生與不定期乾貨。

Image Text

視訊教程地址

GitHub原始碼：mic-demo

第一章 從傳統單體架構走向微服務

Hello，大家好，我是貓叔MySelf，本課程將帶領大家入門微服務。

各位年輕又帥氣的靚仔們！

  • 新入職公司，接手公司專案，你所看到的是不是就是一座大山
  • 你們接觸的專案是不是龐大的程式碼塊、並關係錯綜複雜（一大堆的目錄與包）
  • 是不是接手後交付週期也很長（入門也是幾個通宵）
  • 有沒有覺得該專案的擴充套件能力與彈性受限
  • 同時，對於大家這樣熱愛新技術的同學，有時一用上新技術與工具框架就各種BUG
  • 而且一個微不足道的小問題，可以導致整個應用掛掉（高層還總是嘮叨我們）

也是辛苦大家那段時間每夜每夜的加班工作了！

在聽微服務之前，因為學員層次不一，希望大家有了解到至少一個單體架構的web專案開發經驗或大致流程，這樣學起來更輕鬆哦！

聰明的老外總是能先於我們發現新的高效的開發模式，近幾年前一個老頭就提出了我們將要學習的“微服務”：微服務架構風格是一種將單個應用程式作為一套小型服務開發的方法，每種應用程式都在自己的程式中執行，並與輕量級機制（通常是HTTP資源API）進行通訊。 這些服務是圍繞業務功能構建的，可以通過全自動部署機制獨立部署。 這些服務的集中管理最少，可以用不同的程式語言編寫，並使用不同的資料儲存技術。

大叔的圖片

這個看起來有點複雜，我就不念了，像教科書一樣的文案，有興趣的同學可以上網深入瞭解。

我們整理一下，並優先入門一些重點。

  • 其目的是有效的拆分應用，實現敏捷開發和部署
  • 只做一件事，並把它做好

對於我們這種要求簡單的，工作的時候一般都只想做一件事就好了，不 要讓我顧及太多。

  • 單一（隔離）、獨立指責

我們可以盡情的在自己負責的專案上“玩耍”啦！對於其他服務層的對接僅需要按照各個應用通訊介面文件去走即可！

  • 通訊（同非同步）

我們總是要和人交流的，對於我們自己獨自負責的服務也是需要去交朋友的，因此它需要與其他各個服務進行通訊，這裡的通訊可能是同步的、非同步的。 對於每個引用都有他們自己的資料，微服務的採納有助於我們可以針對部分火爆業務採用不同的資料庫型別或者分庫讀取，而不再需要在同一專案整合多個資料庫操作。

  • 資料獨立

我們可以發揮不同語言的優勢，比如python、nodejs、php….這對技術專項不同的開發團隊來說，配合起來將更加容易與得心應手。

  • 技術棧靈活（資料流、儲存、業務）
  • 獨立部署、團隊組織架構有效調整

第二章 單體架構電商Demo講解

一個普通的電商專案：

  • 使用者服務：註冊
  • 商品服務：查詢商品
  • 訂單服務：下單、檢視訂單

資料庫表：

  • 使用者表：使用者id、使用者名稱、使用者密碼、建立時間
  • 商品表：商品id、商品名、商品詳情、商品價格、
  • 庫存表：商品id、庫存數
  • 訂單表：訂單id、使用者名稱、商品id、訂單價格、商品總數、建立時間

大致的模擬環境：

使用者下單與查詢訂單列表，同時還具備管理人員查詢庫存

介面列表：

  • 地址： http://localhost:8080/sells/order/order POST

  • 引數

    id 》 使用者id goodsId 》 商品id num 》 商品數量

  • 例子

{
    "code": 200,
    "msg": "成功",
    "data": "MS04780334"
}
複製程式碼

  • 地址：localhost:8762/order/order?id=1 GET

  • 引數

    id 》 使用者id

  • 例子

{
    "code": 200,
    "msg": "成功",
    "data": [
        {
            "orderId": "MS04475904",
            "goodsId": "MS000001",
            "name": "貓叔",
            "orderPrice": 1598,
            "orderNum": 2,
            "createTime": "2018-12-13T05:59:24.000+0000"
        },
        {
            "orderId": "MS04663799",
            "goodsId": "MS000002",
            "name": "貓叔",
            "orderPrice": 2999,
            "orderNum": 1,
            "createTime": "2018-12-12T16:04:18.000+0000"
        },
        {
            "orderId": "MS04780334",
            "goodsId": "MS000001",
            "name": "貓叔",
            "orderPrice": 1598,
            "orderNum": 2,
            "createTime": "2018-12-13T08:10:29.000+0000"
        }
    ]
}
複製程式碼

  • 地址： localhost:8763/goods/goods?id=1&goodsId=MS000002 GET

  • 引數

    id 》 管理員id goodsId 》 商品id

  • 例子

{
    "code": 200,
    "msg": "成功",
    "data": {
        "inventoryId": "IN4567825",
        "goodsId": "MS000002",
        "inventoryNum": 13
    }
}
複製程式碼

微服務架構拆分

當前只有三個服務，一個使用者服務、一個訂單服務、一個庫存服務

假設我們的生意狂飆上漲，投放了分銷環節、線上廣告啥的，這個時候的訂單量非常高。那麼我們就可以使用微服務的思想，講訂單服務抽離出來。

那麼我們將使用SpringCloud來完成這一操作與編碼。

在基於單體架構的情況下，我們將進行手把手的演進，希望同學們可以一起來擼一把。

首先是Eureka註冊中心，我們需要向某人說明這裡是什麼，

並將單體服務拆分為兩個，order-client服務 還有 其餘的服務。

那麼我們就再新建兩個對應的Eureka Client的服務並註冊到註冊中心

同時兩個服務之間的通訊也需要採用SpringCloud的操作。

第三章 SpringCloud入門

說到SpringCloud，我們還需要說一下它基於的更厲害的框架，它就是Netflix。Netflix的多個開源元件一起正好可以提供完整的分散式微服務基礎架構環境，而SpringCloud就是對Netflix的多個開源元件進一步封裝而成的。

同時，它利用SpringBoot的開發便利性巧妙地簡化了分散式系統基礎設施的開發，比如我們今天將學到的服務發現註冊（Eureka）、呼叫框架（宣告式服務客戶端Fegin）等等。

Spring Cloud將目前各個比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝遮蔽掉了複雜的配置和實現原理，因為我們僅僅配置一下、寫幾句程式碼就可以實現一個想要的簡單的微服務。

第四章 Eureka實操與微服務架構搭建

Spring Cloud Eureka

  • 1、Eureka是一個基於REST的服務
  • 2、基於Netflix Eureka做了二次封裝
  • 3、核心元件為：
    • Eureka Server 註冊中心（服務端）
    • Eureka Client 服務註冊（客戶端）

第五章 服務拆分與應用間通訊

Spring Cloud 服務間的一種RestFul呼叫方式

1、Feign

  • 宣告式REST客戶端
  • 介面 + 註解（開啟、指定服務名）
  • 本質依舊是一個HTTP客戶端

第六章 關於微服務的不解與深入探討

我想極具好奇心的同學們一定不滿足這麼一點的概況，的確，微服務還有更多的知識點需要大家去掌握與瞭解。

  • 負載均衡
  • 安全機制
  • 配置中心
  • 鏈路追蹤
  • 容器搭配

說了那麼多，微服務的缺點是什麼呀！？我總是希望唱反調的同學

毒液中的片段，世界掌握在我們手中

沒錯，任何思想都有其適用性與自身環境，微服務也不例外。

在介紹了微服務原理後，大家會提出什麼問提呢？

我做學生的時候就提出了幾個小問題。

  • 微服務架構的取捨？

    需要避免為了“微服務”而“微服務”。

    對傳統企業而言，開始時可以考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用，逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。

  • 微服務的不足又是哪些？

    微服務的複雜度 分散式事務（CAP理論，AP系統） 服務的劃分 服務的部署

  • 各個服務元件的版本與部署乃至升級？

    一套完善的開發管理規範，包括開發設計規範、分支管理規範、持續整合規範，再利用Docker容器的天然的特性：“版本控制、可移植性、隔離性”就可以實現元件的版本管理。實質上基於在支援DevOps完整流程的容器雲平臺，即可實現整個開發過程及交付中的持續整合、快速部署、灰度釋出及無縫升級。

最後希望大家都能在未來深入瞭解並使用微服務。

相關文章