老王學習go語言——2.1 Go Kit和Go Micro

《Go語言高並發與微服務實戰》

讓開發者專注於自身業務邏輯的開發 這句話放在開篇，幾乎每個技術框架都聲稱自己可以做到這一點，以下的兩個框架也不例外。

書中雖然介紹了這兩個框架，但比較簡單。打算綜合其他社區和官網的內容，把這部分內容豐富一下，相信以後用的到。

Go Kit

Go-kit（gokit.io）是Go語言工具包的集合，可幫助工程師構建強大，可靠和可維護的微服務。Go-kit提供了用於實現系統監控和彈性模式組件的庫，例如日誌記錄、跟蹤、限流和熔斷等，這些庫協助工程師提高微服務架構的性能和穩定性

為了求甚解，建議大家可以直接去官網進行了解

https://gokit.io/

就喜歡這種風格的網站，一目了然，重點突出。

Go Kit並沒有強調自己是個FrameWork，而是「A tookit」，輕量級，讓你能夠把經歷聚焦在業務邏輯上。簡單明了。

而為什麼是Go Kit，官方給出的解釋：Go 是一種很棒的通用語言，但微服務需要一定量的專門支持。RPC 安全性、系統可觀察性、基礎結構集成、甚至程序設計 – Go kit填補了標準庫留下的空白，使 Go 成為在任何組織中編寫微服務的一流語言。用現在流行的詞來講，這個tookit是以賦能Go為使命的。這樣說起來好像「高大上」了許多。

網站簡潔到幾乎沒有一句多餘的廢話，我是誰，為什麼是我，例子，原始碼就這些，我還真喜歡這種風格。所以要分享點兒東西，我又沒有心思在這個時候直接進入編程示例，於是只能先去Github,看看readme和程序結構了。

Motivation

Go已經逐漸成為伺服器語言，但它在Facebook、Twitter、Netflix和 SoundCloud等所謂的&34;公司中仍然不足。許多這些組織都轉向基於 JVM 的技術棧來處理其業務邏輯，這主要由於直接支持其微服務體系結構的庫和生態系統。

為了取得更大的成功，Go 不僅僅要是一種程序設計語言，。它需要一個全面的工具包，用於大的分布式編程。Go kit是一組包和最佳實踐，為任何規模的組織提供全面、可靠且可信賴的構建微服務的方法。

目標

在異構 SOA 中運行 – 期望與大多數非 Go-kit 服務進行交互

RPC 作為主要消息傳遞模式

可插拔的序列化和傳輸 – 不只是 JSON 通過 HTTP

在現有基礎設施中運行 – 沒有特定工具或技術的授權

非目標

支持 RPC 以外的消息傳遞模式（目前）– 例如 MPI、酒吧/子、CQRS 等。

通過調整現有軟體來重新實現功能

對運營問題有意見：部署、配置、流程監督、編排等。

關於程序結構和其他一些介紹，可以請移步到。

https://gokit.io/faq/#introduction-mdash-understanding-go-kit-key-concepts

這裡只挑重點列一下：

1.go-Kit不是MVC框架，基礎結構是transport, EndPoint,Service，請求首先進入transport,然後是Endpoint，最後由Service來處理。響應則走相反的路徑。transport,是進行服務轉換的，可以在單一服務中同時支持多種訪問方式比如http,aRPC,transport也是為了在業務邏輯和響應方式上進行解耦和統一處理。而EndPoint很像MVC中的Controller，在這裡調用實際的Service，Service就很好理解了。

Requests enter the service at layer 1, flow down to layer 3, and responses take the reverse course.

Go-Kit分層 最上面transport,中間EndPoint，最下面Service

將所有這些概念放在一起，我們可以看到 Go kit 微服務的模型像洋蔥一樣，具有許多層。這些圖層可以分組到我們的三個域中。最內層的服務域是一切基於您的特定服務定義，以及實現所有業務邏輯的地方。中間Endpoint是將服務的每個方法抽象到通用Endpoint域。。最後，最外層的傳輸域是端點綁定到具體傳輸（如 HTTP 或 gRPC）的地方。

通過定義服務接口並提供具體實現，實現核心業務邏輯。然後，編寫服務中間件以提供其他功能，如日誌記錄、分析、檢測等，即任何需要了解業務領域的信息。

Go 套件提供端點和傳輸域中間件，用於速率限制、電路中斷、負載平衡和分布式跟蹤等功能，所有這些功能通常與您的業務領域無關。

好吧，Go-Kit先介紹到這裡吧，後續具體實現微服務的時候，再分析學習搭建開發環境，say helloworld的方法。

Go Micro

Go Micro是一個插件化的基礎框架，基於此可以構建微服務。Micro的設計哲學是『可插拔』的插件化架構。在架構之外，它默認實現了consul作為服務發現，通過http進行通信，通過protobuf和json進行編解碼。

這裡是每個技術框架共同的追求：讓開發者專注於自身業務邏輯的開發

go-micro的主要功能

• 服務發現：自動服務註冊和名稱解析。服務發現是微服務開發的核心。當服務A需要與服務B通話時，它需要該服務的位置。默認發現機制是多播DNS（mdns），一種零配置系統。您可以選擇使用SWIM協議為p2p網絡設置八卦，或者為彈性雲原生設置設置consul
• 負載均衡：基於服務發現構建的客戶端負載均衡。一旦我們獲得了服務的任意數量實例的地址，我們現在需要一種方法來決定要路由到哪個節點。我們使用隨機散列負載均衡來提供跨服務的均勻分布，並在出現問題時重試不同的節點
• 消息編碼：基於內容類型的動態消息編碼。客戶端和伺服器將使用編解碼器和內容類型為您無縫編碼和解碼Go類型。可以編碼任何種類的消息並從不同的客戶端發送。客戶端和伺服器默認處理此問題。這包括默認的protobuf和json
• 請求/響應：基於RPC的請求/響應，支持雙向流。我們提供了同步通信的抽象。對服務的請求將自動解決，負載平衡，撥號和流式傳輸。啟用tls時，默認傳輸為http / 1.1或http2
• Async Messaging：PubSub是異步通信和事件驅動架構的一流公民。事件通知是微服務開發的核心模式。啟用tls時，默認消息傳遞是點對點http / 1.1或http2
• 可插拔接口：Go Micro為每個分布式系統抽象使用Go接口，因此，這些接口是可插拔的，並允許Go Micro與運行時無關，可以插入任何基礎技術

• go-micro之所以可以高度訂製和他的框架結構是分不開的，go-micro由8個關鍵的interface組成，每一個interface都可以根據自己的需求重新實現，這8個主要的inteface也構成了go-micro的框架結構
• 
  

圖片來源於網絡

• Server監聽客戶端的調用，和Brocker推送過來的信息進行處理。並且Server端需要向Register註冊自己的存在或消亡，這樣Client才能知道自己的狀態
• Register服務的註冊的發現，Client端從Register中得到Server的信息，然後每次調用都根據算法選擇一個的Server進行通信，當然通信是要經過編碼/解碼，選擇傳輸協議等一系列過程的
• 如果有需要通知所有的Server端可以使用Brocker進行信息的推送，Brocker 信息隊列進行信息的接收和發布。

Go -kit 於Go Mirco區別： Go-Kit為多數業務場景下實施微服務軟體架構提供指導和解決方案。

而Go Micro則是一個面向微服務的可插拔RPC框架，他是只在特殊細分領域上努力的框架。他嘗試簡化分布式系統之間的通信。

微服務設計的六大原則：

1.高內聚，低耦合

緊密關聯的事務應該放在一起，每個服務針對一個單一職責的業務能力封裝。服務間通過輕量級的通訊方式進行通信，服務間相對獨立。低耦合。

2.高度自治

1）服務獨立部署運行和擴展。而提使得代碼組織，發布節奏，快速交付和快速應對變化等有各大的靈活性。

2）獨立開發和演進。服務和服務之間採取語言無關的網絡通信進行交互。不受遺留系統技術棧的約束。

3）獨立的團隊。工作在獨立的上下文中

3.以業務為中心

每個服務代表了特定的業務邏輯，有明顯的邊界上下文。

4.彈性設計

容錯設計，防止級聯的服務雪崩。

5.日誌與監控

微服務架構天生在定位錯誤和進行追蹤的過程中相對繁瑣，所以對於日誌和監控的能力要求也就交到。結構化的日誌和服務依賴關心，方便快速發現問題及時修復。

6.自動化

微服務架構的複雜性，要求運維及管理能夠實現自動化，要不然服務和節點大到一定程度，維護和管理工作將具有非常大的難度。

領域驅動設計(DDD Domain Drive Design)

DDD不是語言，不是框架，也不是架構，而是一種思想，一種方法論，主要用於合理地劃分業務系統以及保持業務架構和系統架構的一致性這兩個領域。

DDD其實2003年就出現了，但是由於自身的問題，導致一直不溫不火，而這次被提起，就是借著微服務的東風。因為DDD的界限上下文可以很好的判定微服務劃分的粒度。

而無論是微服務還是SOA一直在服務劃分粒度上沒有統一標準，更多的憑團隊經驗，劃分打了不符合服務化的初衷，充分發揮架構的優勢，而劃分的過於小，無端增加複雜度，還使得系統過於凌亂，增大管理成本。

但DDD理解起來容易，實際落地到真正實踐中卻仍然十分困難。

DDD中根據問題域，將問題劃分為領域/子域，通用語言，限界上下文和架構風格等概念

大家只要記住DDD可以被用來指導進行微服務粒度的劃分，但DDD其實也有很大的工程量，個人並不知道是先跟著感覺走，遇到問題再調整力度是最合適的實踐方法論，還是先學習DDD，然後投入很多的經歷試圖找出最合適的劃分方法。見仁見智吧，但是DDD並不影響我們學習Go，先放一放吧。關於DDD就不發散了。

把上下文相關的和不相關的總算結束了。明天正式進入Go語言本身。

最後還是抽出一個題來擴展一下，那就是RPC，dubbo是RPC框架，Go Micro也是RPC，那麼RPC是什麼呢

RPC（Remote Procedure Call）遠程過程調用

進程間通信（IPC）是在多任務作業系統或聯網的計算機之間運行的程序和進程所用的通信技術。有兩種類型的進程間通信（IPC）。

本地過程調用(LPC)LPC用在多任務作業系統中，使得同時運行的任務能互相會話。這些任務共享內存空間使任務同步和互相發送信息。RPC調用的模型遠程過程調用（RPC)RPC類似於LPC，只是在網上工作。RPC開始是出現在Sun微系統公司和HP公司的運行UNⅨ作業系統的計算機中。

RPC的概念與技術早在1981年由Nelson提出。1984年，Birrell和Nelson把其用於支持異構型分布式系統間的通訊。Birrell的RPC 模型引入存根進程( stub) 作為遠程的本地代理，調用RPC運行時庫來傳輸網絡中的調用。Stub和RPC runtime屏蔽了網絡調用所涉及的許多細節，特別是，參數的編碼/解碼及網絡通訊是由stub和RPC runtime完成的，因此這一模式被各類RPC所採用。由於分布式系統的異構性及分布式計算模式與計算任務的多樣性，RPC作為網絡通訊與委託計算的實現機制，在方法、協議、語義、實現上不斷發展，種類繁多，其中SUN公司和開放軟體基金會在其分布式產品中所建立和實用的RPC較為典型。 [1]

在SUN公司的網絡文件系統NFS及開放網絡計算環境ONC中，RPC是基本實現技術。OSF醞釀和發展的另一個重要的分布式計算軟體環境DCE也是基於RPC的。在這兩個系統中，RPC既是其自身的實現機制，又是提供給用戶設計分布式應用程式的高級工具。由於對分布式計算的廣泛需求，ONC和DCE成為Client/Server模式分布式計算環境的主流產品，而RPC也成為實現分布式計算的事實標準之一。

以上內容是不是特別清楚，他來源於百科百科，囧。

RPC 是一種技術思想而非一種規範或協議，常見 RPC 技術和框架有：

應用級的服務框架：阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。

遠程通信協議：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。

通信框架：MINA 和 Netty。

目前流行的開源 RPC 框架還是比較多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。

下面重點介紹三種：

gRPC：是 Google 公布的開源軟體，基於***的 HTTP 2.0 協議，並支持常見的眾多程式語言。RPC 框架是基於 HTTP 協議實現的，底層使用到了 Netty 框架的支持。

Thrift：是 Facebook 的開源 RPC 框架，主要是一個跨語言的服務開發框架。

用戶只要在其之上進行二次開發就行，應用對於底層的 RPC 通訊等都是透明的。不過這個對於用戶來說需要學習特定領域語言這個特性，還是有一定成本的。

Dubbo：是阿里集團開源的一個極為出名的 RPC 框架，在很多網際網路公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是極其鮮明的特色。

在一個典型 RPC 的使用場景中，包含了服務發現、負載、容錯、網絡傳輸、序列化等組件，其中「RPC 協議」就指明了程序如何進行網絡傳輸和序列化。

RPC 的核心功能是指實現一個 RPC 最重要的功能模塊，就是上圖中的」RPC 協議」部分

一個 RPC 的核心功能主要有 5 個部分組成，分別是：客戶端、客戶端 Stub、網絡傳輸模塊、服務端 Stub、服務端等。

圖 4：RPC 核心功能圖

下面分別介紹核心 RPC 框架的重要組成：

• 客戶端(Client)：服務調用方。
• 客戶端存根(Client Stub)：存放服務端地址信息，將客戶端的請求參數數據信息打包成網絡消息，再通過網絡傳輸發送給服務端。
• 服務端存根(Server Stub)：接收客戶端發送過來的請求消息並進行解包，然後再調用本地服務進行處理。
• 服務端(Server)：服務的真正提供者。
• Network Service：底層傳輸，可以是 TCP 或 HTTP。

一次 RPC 調用流程如下：

• 服務消費者(Client 客戶端)通過本地調用的方式調用服務。
• 客戶端存根(Client Stub)接收到調用請求後負責將方法、入參等信息序列化(組裝)成能夠進行網絡傳輸的消息體。
• 客戶端存根(Client Stub)找到遠程的服務地址，並且將消息通過網絡發送給服務端。
• 服務端存根(Server Stub)收到消息後進行解碼(反序列化操作)。
• 服務端存根(Server Stub)根據解碼結果調用本地的服務進行相關處理
• 服務端(Server)本地服務業務處理。
• 處理結果返回給服務端存根(Server Stub)。
• 服務端存根(Server Stub)序列化結果。
• 服務端存根(Server Stub)將結果通過網絡發送至消費方。
• 客戶端存根(Client Stub)接收到消息，並進行解碼(反序列化)。
• 服務消費方得到最終結果。

懶得一個字一個字的打了，內容來源於網絡，說的比我清楚，我就不用重複勞動了，介紹了RPC的主流框架和技術。我們說的比較多的是dubbo,gRPC.