基於Golang設計一套微服務架構[轉]

本文轉載自查看原文 2018-05-29 18:55 8721

article - @嘟嘟嚕 - May/26/2018 18:35:30

如何基於Golang設計一套微服務架構

微服務（Microservices），這個近幾年我們經常聽到。那么現在市面上的的微服務架構技術有很多，比如比較成熟的 Spring Boot、Spring Cloud 全家桶。如果在非 Java 體系里如何實現微服務架構呢？

經過幾個月的折騰，我們就來聊聊Golang在微服務架構是如何實現？

What are microservices?

微服務 —— 也稱為微服務架構 —— 是一種架構風格，它將應用程序構建為松散耦合服務的集合，這些服務實現了各種業務功能。微服務體系結構支持大型復雜應用程序的持續交付/部署。它還使組織能夠發展其技術堆棧。

微狹義來講就是體積小
服務相對較小且獨立的功能單元

簡單來說，微服務架構就是將一個完整的應用從數據存儲開始垂直拆分多個不同的服務，每個服務能獨立部署、獨立維護、獨立擴展。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。通常，每個任務代表着一個小的業務能力。

傳統單體式應用

我們先來看看傳統的單體式應用架構:

Java 應用程序被打包成 WAR 文件部署在如 Tomcat上，他們很容易開發、部署，因為我們的 IDE 和其他工具就是專注於構建單體應用。這種簡單的方法有很大的局限性，我們來看看這種單體式架構它有哪些問題。

復雜性逐漸變高

項目有幾十萬行代碼，各個模塊之間區別比較模糊，邏輯比較混亂，代碼越多復雜性越高，越難解決遇到的問題。
技術債務逐漸上升

人員流動問題
部署速度逐漸變慢

代碼越多編譯越慢，部署越慢
阻礙技術創新

想要改變些什么，但歷史包袱太重
無法按需伸縮

比如cpu密集型的模塊，比如大內存模塊等

一旦應用程序成了一個龐大、復雜的單體，開發會陷入一個痛苦的境地，敏捷開發和交付的任何一次嘗試都將原地徘徊。主要問題是應用程序實在非常復雜，其對於任何一個開發人員來說顯得過於龐大。最終，正確修復 bug 和實現新功能變得非常困難而耗時。

為了解決這個問題，就誕生了一個新的概念”微服務”

微服務 — 解決復雜問題

每個服務通常實現一組不同的特性或功能
- 例如訂單管理、客戶管理等。每一個微服務都是一個迷你應用，它自己的六邊形架構包括了業務邏輯以及多個適配器。
每個微服務會暴露一個供其他微服務或應用客戶端消費的 API
- 其他微服務可能實現了一個 web UI。在運行時，每個實例通常是一個雲虛擬機（virtual machine，VM）或者一個 Docker 容器。

一個單體應用拆分成微服務

應用程序的每個功能區域現在都由自己的微服務實現，每個后端服務暴露 API，大部分服務消費的 API 由其他服務提供。一系列獨立運行的微服務共同構建起了整個系統。

每個服務為獨立的業務開發，一個微服務一般完成某個特定的功能

比如：訂單管理，用戶管理等；每個服務都擁有各自的數據庫

開發和交付中的伸縮立方

微服務架構模式相當於此伸縮立方的 Y 軸坐標，另外兩個坐標軸是由運行多個相同應用程序副本的負載均衡器組成的 X 軸坐標和 Z 軸坐標，其中請求的屬性（例如，一行記錄的主鍵或者客戶標識）用於將請求路由到特定的服務器。應用程序通常將這三種類型的坐標方式結合一起使用。Y 軸坐標將應用分解成微服務 X 坐標軸上運行着服務的多個實例，每個服務配合負載均衡器以滿足吞吐量和可用性。某些應用程序也有可能使用 Z 坐標軸來進行分區服務。

微服務架構特點

易於開發和維護
啟動較快
局部修改容易部署
技術棧不受限
按需伸縮

微服務架構模式可以實現每個微服務獨立部署，獨立擴展。

微服務的架構優勢

快速度發布
獨立擴展
快速試錯
快速應用新技術

快速發布

功能簡單，測試簡單，無過多依賴，配置簡單，發布簡單。

快速試錯-小步快跑

快速開發，快速上線，快速調整。

微服務的劣勢

性能損失，微服務之間都是通過restfull或grpc的方式進行通信。
系統復雜，一個應用或多個應用有非常多的服務
服務太多監控復雜。
微服務架構不適用於
- 對單機性格要求高
- 例如：操作系統，數據庫
對運維要求比較高
接口調整成本高

Golang 微服務架構技術

好了，不扯那么多，咱們來說今天的主題吧。Go在微服務架構中使用的一些技術方案。

既然是以Golang為主，那必然我們盡量全使用golang的技術架構。

首先我們需要解決一個問題！

假設我們的應用微服務化了，我們會遇到哪些問題？

要微服務架構需要面臨的一些問題

如何發現服務
如何對服務鏈路進行追蹤
如何管理配置
如何對服務API進行控制
如何部署(持續交付)

帶着這些問題我們找一些這些開源的解決方案。

那么如何將這些工具利用並組合起來呢？

我們先來看看這些工具都是什么？在微服務架構中擔任着什么樣的角色？

Consul

Consul是一個服務管理軟件。它主要特點:

Service Discovery

服務發現和配置的工具。分布式, 高度可用，並且具有非常好的可伸縮性。
Failure Detection

將服務發現與健康檢查配對，可以防止路由請求對不健康的主機，並使服務能夠輕松地提供斷路器。
Multi Datacenter

在沒有復雜的配置的情況下，Consul調度到多個數據中心。在其他數據中心查找服務，或保持請求本地。
KV Storage

靈活的Key/Value存儲動態配置，功能標記，協調，Leader選舉等。配置更改和即時通知。

可以用Consul來實現以下功能

分布式key/value，用於做配置中心。
分布式session，用於解決session的問題。
分布式鎖，其key/value也可以用於分布式鎖的問題
資源中心，動態管理redis、datasource、rabbitmq等資源

那么，我們暫時先把它當作服務注冊、發現和配置中心進行使用。

什么是服務注冊？

一個服務將其位置信息在“中心注冊節點”注冊的過程。該服務一般會將它的主機IP地址以及端口號進行注冊，有時也會有服務訪問的認證信息，使用協議，版本號，以及關於環境的一些細節信息。

什么是服務發現？

服務發現可以讓一個應用或者組件發現其運行環境以及其它應用或組件的信息。用戶配置一個服務發現工具就可以將實際容器跟運行配置分離開。常見配置信息包括：ip、端口號、名稱等。

當一項服務存在於多個主機節點上時，client端如何決策獲取相應正確的IP和port。

在傳統情況下，當出現服務存在於多個主機節點上時，都會使用靜態配置的方法來實現服務信息的注冊。

而當在一個復雜的系統里，需要較強的可擴展性時，服務被頻繁替換時，為避免服務中斷，動態的服務注冊和發現就很重要。

比如 Zookeeper，Doozer，Etcd，強一致性的項目，這些項目主要用於服務間的協調，同時又可用於服務的注冊。

服務注冊、發現有了，配置中心有了，網關呢？

Why an API Gateway?

下面這張圖可以很好的詮釋什么是網關

現在市面上的開源網關也有很多，比較Java體系的 Zuul

在眾多的網關服務中，我們選擇了基於Nginx的OpenResty實現的網關--> Kong

Why did choose Kong

Kong 是一個現成的 Api Gateway 的解決方案。

Kong有以下主要特點:

眾多的插件
基於OpenResty
可視化配置
與Consul搭配使用
Api管理、限流、授權、降級、負載、請求分發、日志等等
性能高

當然Golang也有一些開源的網關，但都不是很完善。我們選擇Kong主要是它有很多東西已經支持了，我們不需要再次進行開發。當然還有一個原因就是我們會Ngx_lua呀〜〜

鏈路追蹤-zipkin

分布式跟蹤系統，它可以幫助收集時間數據，解決在microservice架構下的延遲問題；它管理這些數據的收集和查找；每個應用程序向Zipkin報告定時數據，Zipkin UI呈現了一個依賴圖表來展示多少跟蹤請求經過了每個應用程序；

如果想解決延遲問題，可以過濾或者排序所有的跟蹤請求，並且可以查看每個跟蹤請求占總跟蹤時間的百分比。

為什么使用Zipkin

隨着業務越來越復雜，系統也隨之進行各種拆分，特別是隨着微服務架構和容器技術的興起，看似簡單的一個應用，后台可能有幾十個甚至幾百個服務在支撐；一個前端的請求可能需要多次的服務調用最后才能完成；當請求變慢或者不可用時，我們無法得知是哪個后台服務引起的，這時就需要解決如何快速定位服務故障點，Zipkin分布式跟蹤系統就能很好的解決這樣的問題。