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

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

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

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

GIF

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

靈活的存儲動態配置，功能標記，協調，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分散式跟蹤系統就能很好的解決這樣的問題。

架構

當我們把這套架構搭建起來後，我們看看這套服務系統中的架構情況。

上圖就是這套架構設計的微服務的流程

所有的應用及服務啟動的時候向consul註冊，然後consul會檢測你服務的健康狀態從圖上可以看出這套微服務看起來非常複雜。

雖然複雜，但它可以做到微服務的核心思想呀！

那麼問題來了

要實現上述功能，需要在代碼里嵌入大量代碼。

你願意嗎？

當然這只是基中大問題之一，微服務架構中還有以下一些問題。

微服務架構的問題

微服務的好處顯而易見，它本身所具備的可擴展性、可升級性、易維護性、故障和資源的隔離性等

產品的生產研發效率大大提高。

這麼多的微服務如何管理？

難道每部署一個微服務就得申請一個或多個虛擬機嗎？那豈不是100個微服務需要好幾百台虛擬機進行支持？

如何發布？

使用什麼工具才能方便快速度的發布各個微服務呢？

如何監控？

如何簡單的對每個服務進行監控、報警？

帶著以上這些問題，我們嘗試的CloudNative+ServiceMesh是一個很好的解決方案。這個，以後我有時間慢慢道來。

尾巴

微服務架構所涉及的技術棧很多，想入坑的或準備入坑的請謹慎。前期必須做好大量準備工作，並且要多做嘗試，別怕。

老應用建議慢慢拆，一點一點拆，新的服務就大膽嘗試。

後續我有空的話再更新:

Consul 集群搭建、如何進行服務註冊、服務發現和配置中心使用

Kong 集群打搭建有配置、使用

Zipkin、ES 集群搭建及golang如何接入ZipKin

我們是如何解決 服務侵入、微服務架構 的問題

關於 CloudNative 的方案

當進入 CloudNative 後，我們又掉入了另一個深坑

雖然之前我所設計的方案，在最終實踐上有了大的調整，這套方案我們並沒有直正實現。為了解決這些問題，我們有了更好的方案並且已成實施。

最近所積累的經驗、深淺坑足夠我發幾個月的文了。

說了這麼多，我們到底在解決什麼問題？

微服務解決了什麼問題？

CloudNative又解決了什麼問題？

留著這些問題，我們以後再說。

最後，感謝網路上的各個大神們的文獻。

謝謝大家的支持！

深情按壓, 小額讚賞, 您的讚賞就是我更新的動力。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！