本文首發於本博客 貓叔的博客,轉載請申明出處php
現架構設計(碼農)兼創業技術顧問,不羈平庸,熱愛開源,雜談程序人生與不按期乾貨。html
Hello,你們好,我是貓叔MySelf,本課程將帶領你們入門微服務。node
各位年輕又帥氣的靚仔們!python
也是辛苦你們那段時間每夜每夜的加班工做了!git
在聽微服務以前,由於學員層次不一,但願你們有了解到至少一個單體架構的web項目開發經驗或大體流程,這樣學起來更輕鬆哦!github
聰明的老外老是能先於咱們發現新的高效的開發模式,近幾年前一個老頭就提出了咱們將要學習的「微服務」:微服務架構風格是一種將單個應用程序做爲一套小型服務開發的方法,每種應用程序都在本身的進程中運行,並與輕量級機制(一般是HTTP資源API)進行通訊。 這些服務是圍繞業務功能構建的,能夠經過全自動部署機制獨立部署。 這些服務的集中管理最少,能夠用不一樣的編程語言編寫,並使用不一樣的數據存儲技術。web
大叔的圖片數據庫
這個看起來有點複雜,我就不念了,像教科書同樣的文案,有興趣的同窗能夠上網深刻了解。編程
咱們整理一下,並優先入門一些重點。安全
對於咱們這種要求簡單的,工做的時候通常都只想作一件事就行了,不 要讓我顧及太多。
咱們能夠盡情的在本身負責的項目上「玩耍」啦!對於其餘服務層的對接僅須要按照各個應用通訊接口文檔去走便可!
咱們老是要和人交流的,對於咱們本身獨自負責的服務也是須要去交朋友的,所以它須要與其餘各個服務進行通訊,這裏的通訊多是同步的、異步的。 對於每一個引用都有他們本身的數據,微服務的採納有助於咱們能夠針對部分火爆業務採用不一樣的數據庫類型或者分庫讀取,而再也不須要在同一項目整合多個數據庫操做。
咱們能夠發揮不一樣語言的優點,好比python、nodejs、php….這對技術專項不一樣的開發團隊來講,配合起來將更加容易與駕輕就熟。
大體的模擬環境:
用戶下單與查詢訂單列表,同時還具有管理人員查詢庫存
地址: 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,咱們還須要說一下它基於的更厲害的框架,它就是Netflix。Netflix的多個開源組件一塊兒正好能夠提供完整的分佈式微服務基礎架構環境,而SpringCloud就是對Netflix的多個開源組件進一步封裝而成的。
同時,它利用SpringBoot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發,好比咱們今天將學到的服務發現註冊(Eureka)、調用框架(聲明式服務客戶端Fegin)等等。
Spring Cloud將目前各個比較成熟、經得起實際考驗的服務框架組合起來,經過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理,由於咱們僅僅配置一下、寫幾句代碼就能夠實現一個想要的簡單的微服務。
Spring Cloud Eureka
Spring Cloud 服務間的一種RestFul調用方式
一、Feign
我想極具好奇心的同窗們必定不知足這麼一點的概況,的確,微服務還有更多的知識點須要你們去掌握與瞭解。
說了那麼多,微服務的缺點是什麼呀!?我老是但願唱反調的同窗
毒液中的片斷,世界掌握在咱們手中
沒錯,任何思想都有其適用性與自身環境,微服務也不例外。
在介紹了微服務原理後,你們會提出什麼問提呢?
我作學生的時候就提出了幾個小問題。
微服務架構的取捨?
須要避免爲了「微服務」而「微服務」。
對傳統企業而言,開始時能夠考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用,逐步探索及積累微服務架構經驗,而非全盤實施微服務架構。
微服務的不足又是哪些?
微服務的複雜度 分佈式事務(CAP理論,AP系統) 服務的劃分 服務的部署
各個服務組件的版本與部署乃至升級?
一套完善的開發管理規範,包括開發設計規範、分支管理規範、持續集成規範,再利用Docker容器的自然的特性:「版本控制、可移植性、隔離性」就能夠實現組件的版本管理。實質上基於在支持DevOps完整流程的容器雲平臺,便可實現整個開發過程及交付中的持續集成、快速部署、灰度發佈及無縫升級。
最後但願你們都能在將來深刻了解並使用微服務。