一 認識微服務
1.1 什麼是微服務
-
使用一套小服務來開發單個應用的方式，每個服務執行在獨立的程式裡，一般採用輕量級的通訊機制互聯，並且它們可以透過自動化的方式部署
-
什麼叫微？
- 單一功能
- 程式碼少，不是，而且程式碼多
- 架構變的複雜了
- 微服務是設計思想，不是量的體現
1.2 微服務的特點
- 單一職責，此時專案專注於登入和註冊
- 輕量級的通訊，通訊與平臺和語言無關，http是輕量的，例如java的RMI屬於重量的
- 隔離性，資料隔離
- 有自己的資料
- 技術多樣性
1.3 微服務誕生背景
- 網際網路行業的快速發展，需求變化快，使用者數量變化快
- 敏捷開發深入人心，用最小的代價，做最快的迭代，頻繁修改、測試、上線
- 容器技術的成熟，是微服務的技術基礎
1.4 微服務架構的優勢
- 獨立性
- 使用者容易理解
- 技術棧靈活
- 高效團隊
二 微服務生態
1.1 硬體層
- 用Docker+k8s去解決
1.2 通訊層
-
網路傳輸，用RPC（遠端過程呼叫）
- HTTP傳輸，GET POST PUT DELETE
- 基於TCP，更靠底層，RPC基於TCP，Dubbo，Grpc，Thrift
-
需要知道呼叫誰，用服務註冊和發現
- 需要分散式資料同步：etcd，consul，zookeeper
- 資料傳遞這裡面可能是各種語言，各種技術，各種傳遞
1.3 應用平臺層
- 雲管理平臺、監控平臺、日誌管理平臺，需要他們支援
- 服務管理平臺，測試釋出平臺
- 服務治理平臺
1.4 微服務層
- 用微服務框架實現業務邏輯
三 微服務詳解
1.1 微服務架構
- 從程式架構來看如下
1.2 服務註冊和發現
-
客戶端做，需要實現一套註冊中心，記錄服務地址，知道具體訪問哪個，輪詢演算法去做，加權輪詢
-
服務端做，比較簡單，服務端啟動，自動註冊即可，AWS的ELB去訪問
-
微服務一般不用LVS負載，擴充套件例項需要改配置，不符合微服務彈性擴充套件思想
-
更多公司傾向於客戶端做註冊發現
-
etcd解決分散式一致性，raft
-
etcd使用場景：
- 註冊發現
- 共享配置
- 分散式鎖
- leader選舉
1.3 rpc呼叫和服務監控
-
RPC相關內容
- 資料傳輸：JSON Protobuf thrift
- 負載：隨機演算法 輪詢 一致性hash 加權
- 異常容錯：健康檢測 熔斷 限流
-
服務監控
- 日誌收集
- 打點取樣
四 微服務與DDD
1.1 什麼是DDD
- DDD（Domain-driven design）領域驅動設計是一種透過將實現連線到持續進化的模型來滿足複雜需求的軟體開發方法。領域模型是對業務模型的抽象，DDD是把業務模型翻譯成系統架構設計的一種方式。
1.2 DDD作用
——真正決定軟體複雜性的是設計方法。
-
有助於我們確定系統邊界
-
能夠聚焦在系統核心元素上
-
幫助我們拆分系統
1.3 DDD常用概念-領域
-
領域:領域是有範圍界限的,也可以說是有邊界的
-
核心域:核心域是業務系統的核心價值
-
通用子域:所有子域的消費者,提供著通用服務
-
支撐子域:專注於業務系統的某一重要的業務
1.4 DDD常用概念-領域模型
-
理解:領域模型是對我們軟體系統中要解決問題的抽象表達。
-
領域:反應的是我們業務上需要解決的問題
-
模型:我們針對該問題提出的解決方案
1.5 DDD常用概念-界限上下文
-
理解 :語文中的語境的意思
-
方式:領域+界限上下文
-
目的:不在如如何劃分邊界,而在如如何控制邊界
1.6 DDD域微服務四層架構
- DDD域微服務四層架構由介面、應用層、領域層、基礎設施層組成。
1.7 DDD優缺點：
-
優點：系統演進更方便，分為業務複雜性變化的演進和業務資料量變化的演進；更方便測試
-
缺點：系統改造成DDD複雜，開發熟悉DDD思想困難。
1.8 回到微服務的設計原則上
-
要領域驅動設計,而不是資料驅動設計,也不是介面驅動設計
-
要邊界清晰的微服務,而不是泥球小單體
-
要職能清晰的分層,而不是什麼都放的大籮筐
-
要做自己能hold住的微服務,而不是過度拆分的微服務
1.9 在本次微服務學習中，我們將採用DDD開發微服務專案。
-
介面由go-micro的Api閘道器提供。
-
應用層由go-micro提供的可插拔外掛提供。
-
領域層使用Mysql進行開發。
-
基礎設施處使用Docker+k8s完成。
五 RPC介紹
1.1 RPC簡介
- 遠端過程呼叫（Remote Procedure Call，RPC）是一個計算機通訊協議
- 該協議允許執行於一臺計算機的程式呼叫另一臺計算機的子程式，而程式設計師無需額外地為這個互動作用程式設計
- 如果涉及的軟體採用物件導向程式設計，那麼遠端過程呼叫亦可稱作遠端呼叫或遠端方法呼叫
1.2 流行RPC框架的對比
1.3 golang中如何實現RPC
- golang中實現RPC非常簡單，官方提供了封裝好的庫，還有一些第三方的庫
- golang官方的net/rpc庫使用encoding/gob進行編解碼，支援tcp和http資料傳輸方式，由於其他語言不支援gob編解碼方式，所以golang的RPC只支援golang開發的伺服器與客戶端之間的互動
- 官方還提供了net/rpc/jsonrpc庫實現RPC方法，jsonrpc採用JSON進行資料編解碼，因而支援跨語言呼叫，目前jsonrpc庫是基於tcp協議實現的，暫不支援http傳輸方式
1.4 RPC呼叫流程
- 微服務架構下資料互動一般是對內 RPC，對外 REST
- 將業務按功能模組拆分到各個微服務，具有提高專案協作效率、降低模組耦合度、提高系統可用性等優點，但是開發門檻比較高，比如 RPC 框架的使用、後期的服務監控等工作
- 一般情況下，我們會將功能程式碼在本地直接呼叫，微服務架構下，我們需要將這個函式作為單獨的服務執行，客戶端透過網路呼叫
六 gRPC介紹
1.1 gRPC簡介
-
gRPC由google開發，是一款語言中立、平臺中立、開源的遠端過程呼叫系統
-
gRPC 是一個高效能、開源、通用的RPC框架，基於HTTP2協議標準設計開發，預設採用Protocol Buffers資料序列化協議，支援多種開發語言。gRPC提供了一種簡單的方法來精確的定義服務，並且為客戶端和服務端自動生成可靠的功能庫。
-
在gRPC客戶端可以直接呼叫不同伺服器上的遠端程式，使用起來就像呼叫本地程式一樣，很容易去構建分散式應用和服務。和很多RPC系統一樣，服務端負責實現定義好的介面並處理客戶端的請求，客戶端根據介面描述直接呼叫需要的服務。客戶端和服務端可以分別使用gRPC支援的不同語言實現。
1.2 gRPC與Protobuf介紹
- 微服務架構中，由於每個服務對應的程式碼庫是獨立執行的，無法直接呼叫，彼此間的通訊就是個大問題
- gRPC可以實現微服務，將大的專案拆分為多個小且獨立的業務模組，也就是服務，各服務間使用高效的protobuf協議進行RPC呼叫，gRPC預設使用protocol buffers，這是google開源的一套成熟的結構資料序列化機制
- 可以用proto files建立gRPC服務，用message型別來定義方法引數和返回型別
1.3 gRPC主要特性
-
強大的IDL
gRPC使用ProtoBuf來定義服務，ProtoBuf是由Google開發的一種資料序列化協議（類似於XML、JSON、hessian）。ProtoBuf能夠將資料進行序列化，並廣泛應用在資料儲存、通訊協議等方面。
-
多語言支援
gRPC支援多種語言，並能夠基於語言自動生成客戶端和服務端功能庫。目前已提供了C版本grpc、Java版本grpc-java 和 Go版本grpc-go，其它語言的版本正在積極開發中，其中，grpc支援C、C++、Node.js、Python、Ruby、Objective-C、PHP和C#等語言，grpc-java已經支援Android開發。
-
HTTP2
gRPC基於HTTP2標準設計，所以相對於其他RPC框架，gRPC帶來了更多強大功能，如雙向流、頭部壓縮、多複用請求等。這些功能給移動裝置帶來重大益處，如節省頻寬、降低TCP連結次數、節省CPU使用和延長電池壽命等。同時，gRPC還能夠提高了雲端服務和Web應用的效能。gRPC既能夠在客戶端應用，也能夠在伺服器端應用，從而以透明的方式實現客戶端和伺服器端的通訊和簡化通訊系統的構建。
1.4 安裝gRPC和Protobuf
- gRPC與ProtoBuf的安裝大家自行百度，挺容易安裝的。
七 Go Micro介紹
主要內容可以檢視我寫的另外一篇文章：
Go Micro介紹與入門 - 掘金 (juejin.cn)
接下來簡單瞭解一下go-micro
1.1 go-micro簡介
- Go Micro是一個外掛化的基礎框架，基於此可以構建微服務，Micro的設計哲學是可插拔的外掛化架構
- 在架構之外，它預設實現了consul作為服務發現，透過http進行通訊，透過protobuf和json進行編解碼
- 是用來構建和管理分散式程式的系統
- Runtime (執行時) : 用來管理配置,認證,網路等
- Framework (程式開發框架) : 用來方便編寫微服務
- Clients (多語言客戶端) : 支援多語言訪問服務端
1.2 go-micro的主要功能
-
服務發現：自動服務註冊和名稱解析。
-
負載均衡：基於服務發現構建的客戶端負載均衡。
-
訊息編碼：基於內容型別的動態訊息編碼。
-
請求/響應：基於RPC的請求/響應，支援雙向流。
-
Async Messaging：PubSub是非同步通訊和事件驅動架構的一流公民。
-
可插拔介面：Go Micro為每個分散式系統抽象使用Go介面，因此，這些介面是可插拔的，並允許Go Micro與執行時無關，可以插入任何基礎技術
1.3 go-micro特性
- api: api 閘道器。使用服務發現具有動態請求路由的單個入口點. API 閘道器允許您在後端構建可擴充套件的微服務體系結構，並在前端合併公共 api. micro api 透過發現和可插拔處理程式提供強大的路由，為 http, grpc, Websocket, 釋出事件等提供服務.
- broker: 允許非同步訊息的訊息代理。微服務是事件驅動的體系結構，應該作為一等公民提供訊息傳遞。通知其他服務的事件，而無需擔心響應.
- network: 透過微網路服務構建多雲網路。只需跨任何環境連線網路服務，建立單個平面網路即可全域性路由. Micro 的網路根據每個資料中心中的本地登錄檔動態構建路由，確保根據本地設定路由查詢.
- new: 服務模板生成器。建立新的服務模板以快速入門. Micro 提供用於編寫微服務的預定義模板。始終以相同的方式啟動，構建相同的服務以提高工作效率.
- proxy: 建立在 Go Micro 上的透明服務代理。將服務發現，負載平衡，容錯，訊息編碼，中介軟體，監視等解除安裝到單個位置。獨立執行它或與服務一起執行.
- registry: 登錄檔提供服務發現以查詢其他服務，儲存功能豐富的後設資料和終結點資訊。它是一個服務資源管理器，允許您在執行時集中和動態地儲存此資訊.
- store: 有狀態是任何系統的必然需求。我們提供金鑰值儲存，提供簡單的狀態儲存，可在服務之間共享或長期解除安裝 m 以保持微服務無狀態和水平可擴充套件.
- web: Web 儀表板允許您瀏覽服務，描述其終結點，請求和響應格式，甚至直接查詢它們。儀表板還包括內建 CLI 的體驗，適用於希望動態進入終端的開發人員.
1.4 go-micro通訊流程
- Server監聽客戶端的呼叫，和Brocker推送過來的資訊進行處理。並且Server端需要向Register註冊自己的存在或消亡，這樣Client才能知道自己的狀態
- Register服務的註冊的發現，Client端從Register中得到Server的資訊，然後每次呼叫都根據演算法選擇一個的Server進行通訊，當然通訊是要經過編碼/解碼，選擇傳輸協議等一系列過程的
- 如果有需要通知所有的Server端可以使用Brocker進行資訊的推送，Brocker 資訊佇列進行資訊的接收和釋出
1.5 go-micro架構圖
八 小結
-
學習微服務要首先對微服務有個系統認知,這篇文章能夠幫助回顧
-
微服務瞭解清楚,如果對概念還不清楚要在理清楚吸收
-
DDD模型架構很重要，能夠幫助在開發的時候事半功倍
-
要理解RPC與gRPC之間的關係
-
Go有很多gRPC框架，go-micro只是其中之一，但是也很重要
-
ProtoBuf是一個成熟的資料傳輸機制，弄清弄懂也很重要
最後
希望大家關注博主和關注專欄，第一時間獲取最新內容
歡迎大家加入 夏沫の夢的學習交流群 進行學習交流經驗
