聊聊微服務集羣當中的自動化工具

本篇博客主要介紹了自動化工具這個概念，在微服務集羣當中的做用，算拋磚引玉，歡迎你們提出本身的看法。

寫在前面

在瞭解自動化工具的概念以前，咱們先了解一下微服務和集羣的概念。

什麼是微服務

這個概念其實有些普遍，而個人知識廣度也有限，我會盡可能用通俗的語言來描述什麼是微服務，什麼是集羣，以及爲何咱們須要微服務集羣 。爲何須要集羣能夠去看看《小強開飯店-從單體應用到微服務》，這篇文章用很是通俗的語言和配圖，經過一個漫畫故事簡單的解釋了爲何咱們須要微服務集羣。

微服務

傳統的後端服務多爲單體應用，例如使用Sprint Boot或者Node又或者Gin搭建的簡單的後端服務，在此基礎之上，實現了基本的業務以後再部署到服務器上運行起來，這就成爲了一個單體應用。

隨着業務需求的增長、業務代碼慢慢的累加，單體應用變的也愈來愈大。同時各個模塊的大量業務代碼相互糾纏在一塊兒，開發以及維護變得尤爲困難。想象一下一個剛剛加入項目的新人看到相互糾纏的、邏輯複雜的業務代碼的絕望。

這個時候咱們就須要瞭解微服務的概念了。若是想要講這個龐大的單體應用可維護、可擴展以及高可用，咱們就須要對單體應用按照模塊進行業務拆分 。

例如將用戶相關的全部邏輯單獨搞成一個服務，又例如訂單、庫存能夠搞成一個單獨的服務。這樣一來，業務代碼被分散到幾個單獨的服務中，每一個服務只須要關心、處理本身這個模塊的業務邏輯。這樣一來，業務代碼的邏輯清晰，對開發人員來講，條理以及思路都很清晰。即便是後加入的項目開發人員，面對業務邏輯清晰的代碼也十分容易上手。

微服務的拆分

其實我看到不少的文章關於微服務的介紹就基本到這了，可是還有個值得提的概念。首先，微服務怎麼拆分實際上是沒有一個標準的。

你按照什麼樣的粒度去拆分你的服務實際上是跟業務強相關的。並非說一個服務的代碼必定就不多，根據你的業務的量度，例如你的系統用戶量特比的大，那麼一個用戶服務的代碼量上千上萬行我以爲都很正常。

固然我也見過用戶不是不少，只是爲了高可用和快速定位，而將系統拆分的很是細的系統，有好幾十個服務。那麼問題來了，有這麼多服務，前端須要去維護的後端API的地址就至關的龐大了。

咱們暫且先不討論全部拆分的服務是否運行在同一個服務器上，就算是，那也得是不一樣的端口。前端也須要根據後端拆分的服務模塊，去維護這樣一張API的映射表。因此咱們須要提出一個BFF，AKA Backend For Frontend.

BFF

其實BFF層最初被提出來，其實不是爲了微服務拆分模塊中提到的目的。其設計的目的是爲了給不一樣的設備提供不一樣的API。例如一個系統的後端服務，同時須要支持不一樣的終端，例如移動端的iOS和Android，PC端。

這樣一來，能夠根據不一樣設備上的需求來提供對應的API，並且不須要更改咱們現有的微服務。

這樣一來，咱們的底層服務羣就具備了很強的擴展性，咱們不須要爲一個新增的客戶端來更改底層的服務代碼，而是新增一層BFF層，來專門針對該終端類型去作適配。

你們從上面的圖能夠看出來，客戶端都沒有直接訪問咱們的底層服務。而是都先通過BFF層提供的接口，再由BFF層來根據不一樣的路由來調用不一樣的底層服務。總結一下，加了BFF層的優勢以下。

• 擴展性強，能夠適應不一樣的客戶端
• 統一的API管理，客戶端無須再維護API的映射表
• 可作集中鑑權，全部的請求都會先通過BFF，可在這一層對調用接口的合法性進行驗證

固然，BFF也有缺點。

• 處理不當會有大量的代碼冗餘
• 因須要調用不一樣底層的服務而增大開發的工做量

固然在實際的生產環境下，咱們也不多會將BFF層直接暴露給客戶端。咱們一般會在BFF層上再加一層網關。網關能夠在請求尚未到BFF的時候，實現權限認證，限流熔斷等等其餘的功能。

集羣

上面簡單的聊了一下什麼是微服務，如今咱們來聊聊什麼是集羣。咱們知道，當一個單體應用大的已經很難維護的時候，最好的辦法就是將其拆分紅微服務。這樣有什麼好處呢？

• 便於維護。每一個微服務專一於本身這個模塊的業務邏輯，不會存在各個模塊的業務邏輯纏在一塊兒的情況。
• 提升可用性。當單體應用掛掉的時候，咱們系統的全部模塊都將不可用。而拆分紅微服務就能夠儘可能的避免這個問題。單個服務掛掉了，不會影響到其餘服務的正常運行。
• 便於運維。單體應用從新部署的時候，會使整個系統不可用。而在微服務中，單個服務從新部署的代價明顯要小的多。

概念

說了這麼多，咱們來給集羣一個概念吧。集羣就是將同一套服務部署在不一樣的服務器上，對外提供服務。

例子

我舉個具體的例子。例如咱們使用Docker Swarm來提供容器的集羣服務。

在Docker Swarm中有節點這樣一個概念，凡是運行了Docker的主機均可以主動的建立一個Swarm集羣或者加入一個已經存在的集羣，一旦加入，這個主機就成爲了這個集羣中的一個節點。在集羣中節點分爲兩類，分別是管理節點（manager）和工做節點（worker）。咱們能夠用Portainer來管理Docker主機和Swarm集羣。

咱們以一個集羣中的請求來舉個例子。

首先進入系統以後會先進入一個統一鑑權的系統去鑑權，鑑權成功以後就會到咱們的微服務網關，若是這個地方還有系統本身的特殊鑑權的話，再次進行鑑權。以後網關這邊會將咱們的請求根據配置的路由來分發到具體的某個服務器上的某個容器中。

自動化工具

自動化工具的都包含了哪些技術呢？

其中的Java只是一個類比，表明你的編程語言。微服務中其實不是很關心具體用的什麼語言，甚至每一個服務都用不一樣的技術棧都行。

那麼自動化工具是什麼呢？其做用是什麼？在集羣中扮演了什麼樣的角色呢？咱們經過一張圖來簡單的瞭解一下。

構建

簡單的梳理一下邏輯。

• 首先自動化工具將Jenkins構建所須要的參數組織好，調用Jenkins的構建API，並記錄構建操做到自動化工具的數據庫
• 而後Jenkins用配置好的憑證去Gitlab的對應的項目的分支拉取代碼，根據配置好的構建腳本開始構建，記錄構建記錄到自動化工具的數據庫
• 構建好後再推送到docker的倉庫中，並記錄到自動化工具的數據庫

到此構建的邏輯結束。

其餘的功能

自動化工具還能夠直接在項目列表中，選擇查看當前項目的日誌，而不須要每次從新打開Kibana而後再加篩選filter。

自動化工具的項目設置中，咱們還能夠更改docker容器的配置，而不須要再去portainer中或者經過命令行去修改；若是想要命令行進入容器，首先咱們得找到對應的service，而後找到對應運行的service實例，而後才能進入，而若是咱們直接使用portainer的Api，在endpoint已知的狀況下，能夠直接將這個功能作到自動化工具中，直接使用webshell一鍵鏈接。

其好處是什麼呢？

• 對大部分開發屏蔽Swarm集羣。對項目中非管理員的開發屏蔽Portainer，由於這個權限很是大，一旦不熟悉致使了誤操做，那麼有可能直接影響到線上的服務
• 統一權限控制。在自動化工具裏作權限以及環境的統一控制
• 上手成本低。比起直接操做portainer和Jenkins和Kibana，本身搭建的自動化工具十分容易上手

功能總結

總結一下，其功能主要爲如下幾個。

• 構建
• 部署
• 回滾
• 查看elk日誌
• 更改docker配置
• 管理集羣的環境、項目和容器
• 命令行鏈接具體項目的容器
• …...

看到這你們可能會有疑問。

• 構建？你的意思是我Jenkins是擺設咯？
• 部署？更改 docker配置？命令行鏈接具體項目的容器？個人Iterm2也是個擺設？
• 回滾？等因而我以前的docker鏡像的tag白打了？
• elk日誌？個人Kibana是拿來看新聞的嗎？

功能詳解

構建

其實在構建這塊，我我的認爲自動化工具和Jenkins都很方便。並且自動化工具自己就是用的Jenkins，只不過是調用了Jenkins的API，傳遞了構建的參數，最終真正去構建的仍是Jenkins。

只不過對於剛剛加入項目的測試來講，本身開發的Web UI對新人更加的友好，並且能夠在自動化工具中作到權限控制。

部署和回滾

部署在自動化工具的後端經過docker-client實現。首先咱們根據配置，建立docker client。而後若是已經有在運行的服務了，就調用update service更新服務，不然就建立服務。

回滾與其本質相同，只不過是用了以前的參數和不一樣的tag。

elk日誌

首先，每一個環境的配置中，會配置上kibana_host以及kibana_index，而後根據系統的projectKey，拼接成相應的Kibana日誌的url，而後使用iframe嵌入到自動化工具中。這樣一來就不用再手動的打開Kibana再去設置對應的filter了。特別是當你係統特別多的時候，添加和刪除filter是很廢時間的。

更新容器配置

這裏也一樣是調用對應的API更新對應服務的配置，而不用登陸portainer去修改。

同時，在自動化工具中還能夠針對不一樣的環境配置不一樣的Base Setting。後續在該環境下添加的應用不用再單獨配置，直接繼承環境的Docker Setting便可。

管理集羣的環境、項目和容器

能夠經過自動化工具統一的來建立和管理環境，一樣有三種環境，研發、測試、生產環境。而後能夠在自動化工具中建立角色和用戶，分配給不一樣的角色不一樣的權限來達到控制權限的目的。

命令行鏈接具體項目的容器

一般咱們由於某個需求，須要進入到容器中查看，然而此時咱們就面臨兩種選擇。

• 經過portainer進入對應service，找個某個具體的container，點擊鏈接
• 命令行到容器具體運行的某個服務器上，而後再經過命令行鏈接

可是有了自動化工具，咱們就有了第三種選擇。

• 點擊鏈接

怎麼實現的呢？實際上就是經過endpointId去獲取到全部的container的信息，而後遍歷全部的container，找到與當前選中的containerId相同的容器，獲取到其NodeName，這樣一來咱們就知道當前這個容器到底運行在哪一個節點上的了。

而後經過已有的信息，構建WebSocket的url，最後前端經過xterm來創建ws鏈接，就這樣直接鏈接了正在運行的容器實例。

總結

自動化工具只是一種思路，一種解決方案，它的好處在上面也列出了不少。固然，它確定也有壞處，那就是須要專門投入人力和資源去開發。

這對於人手緊缺和項目週期較短的項目組來講，十分的不現實。可是若是一旦有精力和時間，我以爲值得一試。同時，基於portainer的API，咱們還有可能將更多與集羣相關的功能，集成到自動化工具上。

往期文章：

• 什麼？你居然尚未用這幾個chrome插件？
• 手把手教你從零開始搭建SpringBoot後端項目框架
• 用go-module做爲包管理器搭建go的web服務器
• WebAssembly徹底入門——瞭解wasm的前世今身
• 小強開飯店-從單體應用到微服務

相關：

• 微信公衆號： SH的全棧筆記（或直接在添加公衆號界面搜索微信號LunhaoHu）