摘要：本篇博客主要介紹了自動化工具這個概念，在微服務(wù)集群當(dāng)中的作用，算拋磚引玉，歡迎大家提出自己的見解。而在微服務(wù)中，單個服務(wù)重新部署的代價明顯要小的多。

本篇博客主要介紹了自動化工具這個概念，在微服務(wù)集群當(dāng)中的作用，算拋磚引玉，歡迎大家提出自己的見解。

在了解自動化工具的概念之前，我們先了解一下微服務(wù)和集群的概念。

這個概念其實有些廣泛，而我的知識廣度也有限，我會盡量用通俗的語言來描述什么是微服務(wù)，什么是集群，以及為什么我們需要微服務(wù)集群 。為什么需要集群可以去看看《小強開飯店-從單體應(yīng)用到微服務(wù)》，這篇文章用非常通俗的語言和配圖，通過一個漫畫故事簡單的解釋了為什么我們需要微服務(wù)集群。

傳統(tǒng)的后端服務(wù)多為單體應(yīng)用，例如使用Sprint Boot或者Node又或者Gin搭建的簡單的后端服務(wù)，在此基礎(chǔ)之上，實現(xiàn)了基本的業(yè)務(wù)之后再部署到服務(wù)器上運行起來，這就成為了一個單體應(yīng)用。

隨著業(yè)務(wù)需求的增加、業(yè)務(wù)代碼慢慢的累加，單體應(yīng)用變的也越來越大。同時各個模塊的大量業(yè)務(wù)代碼相互糾纏在一起，開發(fā)以及維護(hù)變得尤其困難。想象一下一個剛剛加入項目的新人看到相互糾纏的、邏輯復(fù)雜的業(yè)務(wù)代碼的絕望。

這個時候我們就需要了解微服務(wù)的概念了。如果想要講這個龐大的單體應(yīng)用可維護(hù)、可擴展以及高可用，我們就需要對單體應(yīng)用按照模塊進(jìn)行業(yè)務(wù)拆分 。

例如將用戶相關(guān)的所有邏輯多帶帶搞成一個服務(wù)，又例如訂單、庫存可以搞成一個多帶帶的服務(wù)。這樣一來，業(yè)務(wù)代碼被分散到幾個多帶帶的服務(wù)中，每個服務(wù)只需要關(guān)心、處理自己這個模塊的業(yè)務(wù)邏輯。這樣一來，業(yè)務(wù)代碼的邏輯清晰，對開發(fā)人員來說，條理以及思路都很清晰。即使是后加入的項目開發(fā)人員，面對業(yè)務(wù)邏輯清晰的代碼也十分容易上手。

其實我看到很多的文章關(guān)于微服務(wù)的介紹就基本到這了，但是還有個值得提的概念。首先，微服務(wù)怎么拆分其實是沒有一個標(biāo)準(zhǔn)的。

你按照什么樣的粒度去拆分你的服務(wù)其實是跟業(yè)務(wù)強相關(guān)的。并不是說一個服務(wù)的代碼一定就很少，根據(jù)你的業(yè)務(wù)的量度，例如你的系統(tǒng)用戶量特比的大，那么一個用戶服務(wù)的代碼量上千上萬行我覺得都很正常。

當(dāng)然我也見過用戶不是很多，只是為了高可用和快速定位，而將系統(tǒng)拆分的非常細(xì)的系統(tǒng)，有好幾十個服務(wù)。那么問題來了，有這么多服務(wù)，前端需要去維護(hù)的后端API的地址就相當(dāng)?shù)凝嫶罅恕?/p>

我們暫且先不討論所有拆分的服務(wù)是否運行在同一個服務(wù)器上，就算是，那也得是不同的端口。前端也需要根據(jù)后端拆分的服務(wù)模塊，去維護(hù)這樣一張API的映射表。所以我們需要提出一個BFF，AKA Backend For Frontend.

其實BFF層最初被提出來，其實不是為了微服務(wù)拆分模塊中提到的目的。其設(shè)計的目的是為了給不同的設(shè)備提供不同的API。例如一個系統(tǒng)的后端服務(wù)，同時需要支持不同的終端，例如移動端的iOS和Android，PC端。

這樣一來，可以根據(jù)不同設(shè)備上的需求來提供對應(yīng)的API，而且不需要更改我們現(xiàn)有的微服務(wù)。

這樣一來，我們的底層服務(wù)群就具有了很強的擴展性，我們不需要為一個新增的客戶端來更改底層的服務(wù)代碼，而是新增一層BFF層，來專門針對該終端類型去做適配。

大家從上面的圖可以看出來，客戶端都沒有直接訪問我們的底層服務(wù)。而是都先經(jīng)過BFF層提供的接口，再由BFF層來根據(jù)不同的路由來調(diào)用不同的底層服務(wù)?？偨Y(jié)一下，加了BFF層的優(yōu)點如下。

擴展性強，可以適應(yīng)不同的客戶端

統(tǒng)一的API管理，客戶端無須再維護(hù)API的映射表

可做集中鑒權(quán)，所有的請求都會先經(jīng)過BFF，可在這一層對調(diào)用接口的合法性進(jìn)行驗證

當(dāng)然，BFF也有缺點。

處理不當(dāng)會有大量的代碼冗余

因需要調(diào)用不同底層的服務(wù)而增大開發(fā)的工作量

當(dāng)然在實際的生產(chǎn)環(huán)境下，我們也很少會將BFF層直接暴露給客戶端。我們通常會在BFF層上再加一層網(wǎng)關(guān)。網(wǎng)關(guān)可以在請求還沒有到BFF的時候，實現(xiàn)權(quán)限認(rèn)證，限流熔斷等等其他的功能。

上面簡單的聊了一下什么是微服務(wù)，現(xiàn)在我們來聊聊什么是集群。我們知道，當(dāng)一個單體應(yīng)用大的已經(jīng)很難維護(hù)的時候，最好的辦法就是將其拆分成微服務(wù)。這樣有什么好處呢？

便于維護(hù)。每個微服務(wù)專注于自己這個模塊的業(yè)務(wù)邏輯，不會存在各個模塊的業(yè)務(wù)邏輯纏在一起的狀況。

提高可用性。當(dāng)單體應(yīng)用掛掉的時候，我們系統(tǒng)的所有模塊都將不可用。而拆分成微服務(wù)就可以盡量的避免這個問題。單個服務(wù)掛掉了，不會影響到其他服務(wù)的正常運行。

便于運維。單體應(yīng)用重新部署的時候，會使整個系統(tǒng)不可用。而在微服務(wù)中，單個服務(wù)重新部署的代價明顯要小的多。

說了這么多，我們來給集群一個概念吧。集群就是將同一套服務(wù)部署在不同的服務(wù)器上，對外提供服務(wù)。

我舉個具體的例子。例如我們使用Docker Swarm來提供容器的集群服務(wù)。

在Docker Swarm中有節(jié)點這樣一個概念，凡是運行了Docker的主機都可以主動的創(chuàng)建一個Swarm集群或者加入一個已經(jīng)存在的集群，一旦加入，這個主機就成為了這個集群中的一個節(jié)點。在集群中節(jié)點分為兩類，分別是管理節(jié)點（manager）和工作節(jié)點（worker）。我們可以用Portainer來管理Docker主機和Swarm集群。

我們以一個集群中的請求來舉個例子。

首先進(jìn)入系統(tǒng)之后會先進(jìn)入一個統(tǒng)一鑒權(quán)的系統(tǒng)去鑒權(quán)，鑒權(quán)成功之后就會到我們的微服務(wù)網(wǎng)關(guān)，如果這個地方還有系統(tǒng)自己的特殊鑒權(quán)的話，再次進(jìn)行鑒權(quán)。之后網(wǎng)關(guān)這邊會將我們的請求根據(jù)配置的路由來分發(fā)到具體的某個服務(wù)器上的某個容器中。

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

其中的Java只是一個類比，代表你的編程語言。微服務(wù)中其實不是很關(guān)心具體用的什么語言，甚至每個服務(wù)都用不同的技術(shù)棧都行。

那么自動化工具是什么呢？其作用是什么？在集群中扮演了什么樣的角色呢？我們通過一張圖來簡單的了解一下。

簡單的梳理一下邏輯。

首先自動化工具將Jenkins構(gòu)建所需要的參數(shù)組織好，調(diào)用Jenkins的構(gòu)建API，并記錄構(gòu)建操作到自動化工具的數(shù)據(jù)庫

然后Jenkins用配置好的憑證去Gitlab的對應(yīng)的項目的分支拉取代碼，根據(jù)配置好的構(gòu)建腳本開始構(gòu)建，記錄構(gòu)建記錄到自動化工具的數(shù)據(jù)庫

構(gòu)建好后再推送到docker的倉庫中，并記錄到自動化工具的數(shù)據(jù)庫

到此構(gòu)建的邏輯結(jié)束。

自動化工具還可以直接在項目列表中，選擇查看當(dāng)前項目的日志，而不需要每次重新打開Kibana然后再加篩選filter。

自動化工具的項目設(shè)置中，我們還可以更改docker容器的配置，而不需要再去portainer中或者通過命令行去修改；如果想要命令行進(jìn)入容器，首先我們得找到對應(yīng)的service，然后找到對應(yīng)運行的service實例，然后才能進(jìn)入，而如果我們直接使用portainer的Api，在endpoint已知的情況下，可以直接將這個功能做到自動化工具中，直接使用webshell一鍵連接。

其好處是什么呢？

對大部分開發(fā)屏蔽Swarm集群。對項目中非管理員的開發(fā)屏蔽Portainer，因為這個權(quán)限非常大，一旦不熟悉導(dǎo)致了誤操作，那么有可能直接影響到線上的服務(wù)

統(tǒng)一權(quán)限控制。在自動化工具里做權(quán)限以及環(huán)境的統(tǒng)一控制

上手成本低。比起直接操作portainer和Jenkins和Kibana，自己搭建的自動化工具十分容易上手

總結(jié)一下，其功能主要為以下幾個。

構(gòu)建

部署

回滾

查看elk日志

更改docker配置

管理集群的環(huán)境、項目和容器

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

…...

看到這大家可能會有疑問。

構(gòu)建？你的意思是我Jenkins是擺設(shè)咯？

部署？更改 docker配置？命令行連接具體項目的容器？我的Iterm2也是個擺設(shè)？

回滾？等于是我之前的docker鏡像的tag白打了？

elk日志？我的Kibana是拿來看新聞的嗎？

其實在構(gòu)建這塊，我個人認(rèn)為自動化工具和Jenkins都很方便。而且自動化工具本身就是用的Jenkins，只不過是調(diào)用了Jenkins的API，傳遞了構(gòu)建的參數(shù)，最終真正去構(gòu)建的還是Jenkins。

只不過對于剛剛加入項目的測試來說，自己開發(fā)的Web UI對新人更加的友好，而且可以在自動化工具中做到權(quán)限控制。

部署在自動化工具的后端通過docker-client實現(xiàn)。首先我們根據(jù)配置，創(chuàng)建docker client。然后如果已經(jīng)有在運行的服務(wù)了，就調(diào)用update service更新服務(wù)，否則就創(chuàng)建服務(wù)。

回滾與其本質(zhì)相同，只不過是用了之前的參數(shù)和不同的tag。

首先，每個環(huán)境的配置中，會配置上kibana_host以及kibana_index，然后根據(jù)系統(tǒng)的projectKey，拼接成相應(yīng)的Kibana日志的url，然后使用iframe嵌入到自動化工具中。這樣一來就不用再手動的打開Kibana再去設(shè)置對應(yīng)的filter了。特別是當(dāng)你系統(tǒng)特別多的時候，添加和刪除filter是很廢時間的。

這里也同樣是調(diào)用對應(yīng)的API更新對應(yīng)服務(wù)的配置，而不用登錄portainer去修改。

同時，在自動化工具中還可以針對不同的環(huán)境配置不同的Base Setting。后續(xù)在該環(huán)境下添加的應(yīng)用不用再多帶帶配置，直接繼承環(huán)境的Docker Setting即可。

可以通過自動化工具統(tǒng)一的來創(chuàng)建和管理環(huán)境，同樣有三種環(huán)境，研發(fā)、測試、生產(chǎn)環(huán)境。然后可以在自動化工具中創(chuàng)建角色和用戶，分配給不同的角色不同的權(quán)限來達(dá)到控制權(quán)限的目的。

通常我們因為某個需求，需要進(jìn)入到容器中查看，然而此時我們就面臨兩種選擇。

通過portainer進(jìn)入對應(yīng)service，找個某個具體的container，點擊連接

命令行到容器具體運行的某個服務(wù)器上，然后再通過命令行連接

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

點擊連接

怎么實現(xiàn)的呢？實際上就是通過endpointId去獲取到所有的container的信息，然后遍歷所有的container，找到與當(dāng)前選中的containerId相同的容器，獲取到其NodeName，這樣一來我們就知道當(dāng)前這個容器到底運行在哪個節(jié)點上的了。

然后通過已有的信息，構(gòu)建WebSocket的url，最后前端通過xterm來建立ws連接，就這樣直接連接了正在運行的容器實例。

自動化工具只是一種思路，一種解決方案，它的好處在上面也列出了很多。當(dāng)然，它肯定也有壞處，那就是需要專門投入人力和資源去開發(fā)。

這對于人手緊缺和項目周期較短的項目組來說，十分的不現(xiàn)實。但是如果一旦有精力和時間，我覺得值得一試。同時，基于portainer的API，我們還有可能將更多與集群相關(guān)的功能，集成到自動化工具上。

往期文章：

什么？你竟然還沒有用這幾個chrome插件？
手把手教你從零開始搭建SpringBoot后端項目框架
用go-module作為包管理器搭建go的web服務(wù)器
WebAssembly完全入門——了解wasm的前世今身
小強開飯店-從單體應(yīng)用到微服務(wù)

相關(guān)：
微信公眾號：   SH的全棧筆記（或直接在添加公眾號界面搜索微信號LunhaoHu）