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

本文首發於本博客 貓叔的博客,轉載請申明出處php

公衆號:Java貓說

現架構設計(碼農)兼創業技術顧問,不羈平庸,熱愛開源,雜談程序人生與不按期乾貨。html

Image Text

視頻教程地址

GitHub源碼:mic-demo

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

Hello,你們好,我是貓叔MySelf,本課程將帶領你們入門微服務。node

各位年輕又帥氣的靚仔們!python

  • 新入職公司,接手公司項目,你所看到的是否是就是一座大山
  • 大家接觸的項目是否是龐大的代碼塊、並關係錯綜複雜(一大堆的目錄與包)
  • 是否是接手後交付週期也很長(入門也是幾個通宵)
  • 有沒有以爲該項目的擴展能力與彈性受限
  • 同時,對於你們這樣熱愛新技術的同窗,有時一用上新技術與工具框架就各類BUG
  • 並且一個微不足道的小問題,能夠致使整個應用掛掉(高層還老是嘮叨咱們)

也是辛苦你們那段時間每夜每夜的加班工做了!git

在聽微服務以前,由於學員層次不一,但願你們有了解到至少一個單體架構的web項目開發經驗或大體流程,這樣學起來更輕鬆哦!github

聰明的老外老是能先於咱們發現新的高效的開發模式,近幾年前一個老頭就提出了咱們將要學習的「微服務」:微服務架構風格是一種將單個應用程序做爲一套小型服務開發的方法,每種應用程序都在本身的進程中運行,並與輕量級機制(一般是HTTP資源API)進行通訊。 這些服務是圍繞業務功能構建的,能夠經過全自動部署機制獨立部署。 這些服務的集中管理最少,能夠用不一樣的編程語言編寫,並使用不一樣的數據存儲技術。web

大叔的圖片數據庫

這個看起來有點複雜,我就不念了,像教科書同樣的文案,有興趣的同窗能夠上網深刻了解。編程

咱們整理一下,並優先入門一些重點。安全

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

對於咱們這種要求簡單的,工做的時候通常都只想作一件事就行了,不 要讓我顧及太多。

  • 單一(隔離)、獨立指責

咱們能夠盡情的在本身負責的項目上「玩耍」啦!對於其餘服務層的對接僅須要按照各個應用通訊接口文檔去走便可!

  • 通訊(同異步)

咱們老是要和人交流的,對於咱們本身獨自負責的服務也是須要去交朋友的,所以它須要與其餘各個服務進行通訊,這裏的通訊多是同步的、異步的。 對於每一個引用都有他們本身的數據,微服務的採納有助於咱們能夠針對部分火爆業務採用不一樣的數據庫類型或者分庫讀取,而再也不須要在同一項目整合多個數據庫操做。

  • 數據獨立

咱們能夠發揮不一樣語言的優點,好比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

  • 一、Eureka是一個基於REST的服務
  • 二、基於Netflix Eureka作了二次封裝
  • 三、核心組件爲:
    • Eureka Server 註冊中心(服務端)
    • Eureka Client 服務註冊(客戶端)

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

Spring Cloud 服務間的一種RestFul調用方式

一、Feign

  • 聲明式REST客戶端
  • 接口 + 註解(開啓、指定服務名)
  • 本質依舊是一個HTTP客戶端

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

我想極具好奇心的同窗們必定不知足這麼一點的概況,的確,微服務還有更多的知識點須要你們去掌握與瞭解。

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

說了那麼多,微服務的缺點是什麼呀!?我老是但願唱反調的同窗

毒液中的片斷,世界掌握在咱們手中

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

在介紹了微服務原理後,你們會提出什麼問提呢?

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

  • 微服務架構的取捨?

    須要避免爲了「微服務」而「微服務」。

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

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

    微服務的複雜度 分佈式事務(CAP理論,AP系統) 服務的劃分 服務的部署

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

    一套完善的開發管理規範,包括開發設計規範、分支管理規範、持續集成規範,再利用Docker容器的自然的特性:「版本控制、可移植性、隔離性」就能夠實現組件的版本管理。實質上基於在支持DevOps完整流程的容器雲平臺,便可實現整個開發過程及交付中的持續集成、快速部署、灰度發佈及無縫升級。

最後但願你們都能在將來深刻了解並使用微服務。

相關文章
相關標籤/搜索