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

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

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

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

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

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

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

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

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

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

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

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

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

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

這樣一來(lái)，我們的底層服務(wù)群就具有了很強(qiáng)的擴(kuò)展性，我們不需要為一個(gè)新增的客戶(hù)端來(lái)更改底層的服務(wù)代碼，而是新增一層BFF層，來(lái)專(zhuān)門(mén)針對(duì)該終端類(lèi)型去做適配。

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

擴(kuò)展性強(qiáng)，可以適應(yīng)不同的客戶(hù)端

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

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

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

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

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

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

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

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

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

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

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

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

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

我們以一個(gè)集群中的請(qǐng)求來(lái)舉個(gè)例子。

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

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

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

那么自動(dòng)化工具是什么呢？其作用是什么？在集群中扮演了什么樣的角色呢？我們通過(guò)一張圖來(lái)簡(jiǎn)單的了解一下。

簡(jiǎn)單的梳理一下邏輯。

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

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

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

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

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

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

其好處是什么呢？

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

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

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

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

構(gòu)建

部署

回滾

查看elk日志

更改docker配置

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

命令行連接具體項(xiàng)目的容器

…...

看到這大家可能會(huì)有疑問(wèn)。

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

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

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

elk日志？我的Kibana是拿來(lái)看新聞的嗎？

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

只不過(guò)對(duì)于剛剛加入項(xiàng)目的測(cè)試來(lái)說(shuō)，自己開(kāi)發(fā)的Web UI對(duì)新人更加的友好，而且可以在自動(dòng)化工具中做到權(quán)限控制。

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

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

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

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

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

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

通常我們因?yàn)槟硞€(gè)需求，需要進(jìn)入到容器中查看，然而此時(shí)我們就面臨兩種選擇。

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

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

但是有了自動(dòng)化工具，我們就有了第三種選擇。

點(diǎn)擊連接

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

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

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

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

往期文章：

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

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