簡單的微服務框架(二)- 基礎組件技術選型

服務框架

grpc

通信編碼

protobuf

服務描述

服務描述指的是服務接口的描述,這里我們統一通過 Swagger 對所有微服務接口進行管理和維護。

服務網關

(這部分自己實現)要是文章沒寫的我之后會補上

消息系統

kafka

數據庫存儲

我們將選用 MySQL 作為數據庫存儲系統,同時通過 gorm 實現 Go 語言與數據庫之間的交互,為了簡化系統,這里我們不會做分布式數據庫部署,而是將不同微服務對應的數據庫存放到一個數據庫服務器上,關于分布式數據庫的話題將留到后續分布式系列教程中去介紹。

服務發現

拆分出多個微服務后,客戶端調用遠程服務時會涉及到服務路由與發現的問題,我們在本次重構中選擇 Etcd 作為服務發現的注冊中心。

負載均衡

負載均衡是為了提高系統的可用性,可以進一步細分為服務端負載均衡和客戶端負載均衡,這里服務端負載均衡我們使用 Go-Micro 內置 Selector 組件的負載均衡機制(Random + Cache),客戶端負載均衡指的是將這個負載均衡策略下放到客戶端去實現,顯然服務端負載均衡更簡單一些,不需要我們做額外開發。

服務監控

服務監控我們選擇引入第三方組件進行可視化管理,這里選擇的方案是結合 PrometheusGrafana 實現,前者用于存儲監控樣本數據源,后者提供對監控數據的可視化展示。

服務治理

服務治理指的是通過一系列手段來保證在各種意外情況下,微服務調用仍然能夠正常進行,這些手段包括熔斷、隔離、限流、降級、負載均衡等,這里我們選擇引入開源的 hystrix-gogo-resiliency 來實現,前者是 Netflix 開源庫 hystrix 的 Go 語言版本,集流量控制、熔斷、容錯等功能于一身,被譽為“雪崩利器”,后者可提供重試功能,是彈性模式的 Go 語言實現。

服務追蹤

服務追蹤用于對每個請求調用的分布式完整服務鏈路進行記錄,從而方便問題定位和故障分析,這里我們選擇引入開源的分布式追蹤系統 ZipKin實現服務追蹤。

自動化測試

在本次重構中,我們使用 GoConvey 編寫行為測試代碼,并集成 CircleCI 進行自動化測試。

自動化部署

最后,我們將通過 Docker + Kubernetes 對微服務進行容器化編排和自動化部署。

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容