如何基於Golang設計一套微服務架構
微服務（Microservices），這個近幾年咱們常常聽到。那麼如今市面上的的微服務架構技術有不少，好比比較成熟的 Spring Boot、Spring Cloud 全家桶。若是在非 Java 體系裏如何實現微服務架構呢？golang
通過幾個月的折騰，咱們就來聊聊Golang在微服務架構是如何實現？web
What are microservices?
微服務 —— 也稱爲微服務架構 —— 是一種架構風格，它將應用程序構建爲鬆散耦合服務的集合，這些服務實現了各類業務功能。微服務體系結構支持大型複雜應用程序的持續交付/部署。它還使組織可以發展其技術堆棧。redis
- 微 狹義來說就是體積小
- 服務 相對較小且獨立的功能單元
簡單來講，微服務架構就是將一個完整的應用從數據存儲開始垂直拆分多個不一樣的服務，每一個服務能獨立部署、獨立維護、獨立擴展。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每一個微服務僅關注於完成一件任務並很好地完成該任務。一般，每一個任務表明着一個小的業務能力。數據庫
傳統單體式應用
咱們先來看看傳統的單體式應用架構:後端
Java 應用程序被打包成 WAR 文件部署在如 Tomcat上，他們很容易開發、部署，由於咱們的 IDE 和其餘工具就是專一於構建單體應用。 這種簡單的方法有很大的侷限性，咱們來看看這種單體式架構它有哪些問題。api
-
複雜性逐漸變高服務器
項目有幾十萬行代碼，各個模塊之間區別比較模糊，邏輯比較混亂，代碼越多複雜性越高，越難解決遇到的問題。restful
-
技術債務逐漸上升網絡
人員流動問題
-
部署速度逐漸變慢
代碼越多編譯越慢，部署越慢
-
阻礙技術創新
想要改變些什麼，但歷史包袱過重
-
沒法按需伸縮
好比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分佈式跟蹤系統就能很好的解決這樣的問題。
架構
當咱們把這套架構搭建起來後，咱們看看這套服務系統中的架構狀況。
上圖就是這套架構設計的微服務的流程
全部的應用及服務啓動的時候向consul註冊，而後consul會檢測你服務的健康狀態從圖上能夠看出這套微服務看起來很是複雜。
雖然複雜，但它能夠作到微服務的核心思想呀！
那麼問題來了
要實現上述功能，須要在代碼裏嵌入大量代碼。
你願意嗎？
固然這只是基中大問題之一，微服務架構中還有如下一些問題。
微服務架構的問題
微服務的好處顯而易見，它自己所具有的可擴展性、可升級性、易維護性、故障和資源的隔離性等
產品的生產研發效率大大提升。
這麼多的微服務如何管理？
難道每部署一個微服務就得申請一個或多個虛擬機嗎？那豈不是100個微服務須要好幾百臺虛擬機進行支持？
如何發佈？
使用什麼工具才能方便快速度的發佈各個微服務呢？
如何監控？
如何簡單的對每一個服務進行監控、報警？
帶着以上這些問題，咱們嘗試的 CloudNative + ServiceMesh 是一個很好的解決方案。這個，之後我有時間慢慢道來。
尾巴
微服務架構所涉及的技術棧不少，想入坑的或準備入坑的請謹慎。前期必須作好大量準備工做，而且要多作嘗試，別怕。
老應用建議慢慢拆，一點一點拆，新的服務就大膽嘗試。
後續我有空的話再更新:
- Consul 集羣搭建、如何進行服務註冊、服務發現和配置中心使用
- Kong 集羣打搭建有配置、使用
- Zipkin、ES 集羣搭建及golang如何接入ZipKin
- 咱們是如何解決 服務侵入、微服務架構 的問題
- 關於 CloudNative 的方案
- 當進入 CloudNative 後，咱們又掉入了另外一個深坑
雖然以前我所設計的方案，在最終實踐上有了大的調整，這套方案咱們並無直正實現。爲了解決這些問題，咱們有了更好的方案而且已成實施。
最近所積累的經驗、深淺坑足夠我發幾個月的文了。
說了這麼多，咱們到底在解決什麼問題？
微服務解決了什麼問題？
CloudNative又解決了什麼問題？
留着這些問題，咱們之後再說。
最後，感謝網絡上的各個大神們的文獻。
謝謝你們的支持！
深情按壓, 小額讚揚, 您的讚揚就是我更新的動力。