小公司的應用服務部署歷程

先宣告一下：我所在的公司是一個小團隊，做物聯網相關的，前後端、硬體、測試加起來也就五六十個人左右；本人的崗位是Java開發（兼DBA、運維。。。）；我進公司時整個專案的部署架構為 簡單jar包部署微服務叢集形式；去年公司將部分服務使用docker進行部署；因為現在服務稍微有點多導致容器管理起來也比較難，再加上我們公司沒有專門的運維人員，所以現在打算使用雲商的k8s來對容器統一進行管理。因為運維相關的事情我一直在負責，上週老大讓我畫一下用k8s部署介面呼叫鏈路圖，所以我便順便總結了一下，以下大部分內容為我自己理解，如果有什麼不對的地方還請大家多多指出。

一.常見服務部署架構

1.傳統伺服器jar執行部署（公司之前使用的部署方式）

服務部署架構圖

 優點

•  學習成本低：只需要掌握Linux命令即可操作，不需要掌握其他特殊命令；

缺點

•   隔離性差： 1.各個叢集中所有服務共用相同執行環境，如果環境發生錯誤將會影響叢集當前節點上所有的服務；2.如果其中某一個服務發生死鎖、記憶體漏失等異常，此服務部署的所有節點（伺服器）的記憶體/CPU可能會被佔滿，也將影響整個叢集的其他服務，導致所有應用不可用；[之前一個專案CPU佔用過高進而影響到節點上所有的服務]
• 部署步驟繁瑣：想要部署一個服務，必須得一臺一臺的進行部署； 
• 有操作風險：開發人員直接操作伺服器，有存在誤操作的風險（sudo rm -rf /*）。
• 服務啟動速度慢。

2.docker 容器化部署（公司目前使用的部署方式）

服務部署架構圖

優點

• 使用方便：只需要拉取映象、執行映象 兩步操作即可執行一個服務;
• 隔離性好：一個容器一個執行環境，互不影響，執行時分配好記憶體，如果某一個服務出現記憶體漏失、CPU佔用高等問題，只會影響當前容器，不會觸及到其他容器;
• 快速回滾：當前版本如果出現問題，可以快速的拉取前一個容器的版本，如果使用上面那個部署形式則需要使用git回滾完，再重新打包部署;
• 系統利用率高：docker對系統資源的利用率更高，無論是應用執行速度，記憶體損耗或者檔案儲存速度，都要比傳統虛擬機器器技術更高效。因此，相比虛擬機器器技術，一個相同設定的主機往往可以執行更多數量的應用;
• 啟動服務的速度更快。

缺點

• 管理麻煩：隨著業務的不斷髮展，微服務不斷的增加，導致容器太多管理麻煩，增加運維成本；
• 誤操作風險：跟上面那一張部署方式一樣，開發人員直接操作伺服器，有一定的風險；
• 學習成本：稍微需要一點容器相關的知識，需要學習docker常見的一些命令
• 其他的暫時沒太關心。

3.k8s容器化部署（現在公司需要升級的部署方式）

服務部署架構圖

名詞解釋

• Node：單臺主機，可以是物理的或虛擬的計算機。結點分為主結點(master)和工作結點(worker) – 個人理解：一個節點就是一臺伺服器（範例）
• Master：k8s 叢集控制節點，對叢集進行排程管理，接受叢集外使用者去叢集操作請求
• Pod ：K8s中的工作單元，服務執行的最小單元。每個Pod中包含一至多個容器；一個Pod的容器在K8s叢集中有相同的地址和埠範圍，即容器暴露於K8s叢集的埠號不可重複- 個人理解：一個每個Pod就是k8s虛擬出來的一個微型伺服器，它有自己的虛擬IP、埠等等
• Deployment：無狀態工作負載，個人理解：就是管理Pod的，負載Pod的擴縮容等操作。
• StatefulSet：有狀態工作負載，與Deployment一樣。不同點在於 Deployment的Pod名稱,主機名稱 ,儲存等都是隨機,不穩定的，所以不適合資料庫等需要持久化的伺服器執行，而StatefulSet就可以。

優點

• 自動部署和回滾：我們可以直接通過k8s控制檯一鍵實現目標版本程式碼的回滾、部署。
• 服務發現和負載均衡：Kubernetes 可以使用 DNS 名稱或自己的 IP 地址來曝露容器。 如果進入容器的流量很大， Kubernetes 可以負載均衡並分配網路流量，從而使部署穩定。
• 自我修復：Kubernetes 將重新啟動失敗的容器、替換容器、殺死不響應使用者定義的執行狀況檢查的容器。
• 不需要直接操作伺服器：控制檯操作，簡化了部署流程，減少了運維成本，開發人員無需關注伺服器運維相關事情。
• 資源排程：當node節點上的CPU、記憶體不夠用的時候，可以擴充node節點，新建的pod就會被排程到新擴充的node節點上。
• 故障遷移：當某一個node節點關機或掛掉後，node節點上的服務會自動轉移到另一個node節點上，這個過程所有服務不中斷
• 資源隔離：可以通過建立開發、測試、預發、生產等名稱空間實現不同環境的隔離，各環境之間互不影響。
• 擴縮容方便：只需要在控制檯調整每個Deployment中Pod的數量就可以實現自動擴縮容。
• 減少了公司運維成本
• Docker有的其他優點。

缺點

• 部署麻煩（自己搭建）
• 佔用資源多（自己搭建）
• 運維成本高（自己搭建）

綜上所述：咱們使用雲商搭建好的k8s，所以說目前對我們來說沒有什麼缺點 -- 嘿嘿~。

二．k8s部署、服務呼叫鏈路相關

1.簡介

就不介紹了，有興趣的可以看一下官方檔案：https://kubernetes.io/zh-cn/docs/concepts/overview/

2.基本概念

 

Pod裡是容器，Pod被ReplicaSet管理，ReplicaSet控制pod的數量；

ReplicaSet被Deployment管理，Deployment控制pod應用的升級、回滾，當然也能控制pod的數量。

Service提供一個統一固定入口，負責將前端請求轉發給Pod

3.呼叫鏈路

1.目前公司前後端服務呼叫鏈路

前端

1、   前端存取域名；

2、   域名DNS解析到部署前端專案的伺服器（叢集：則解析到叢集對應的SLB負載均衡公網IP上—SLB負責具體將請求打在某一臺伺服器上）；

3、   被請求的伺服器用Nginx通過域名加目錄的形式將請求轉發到不同的前端專案。

後端介面

1、   存取api介面

2、   域名DNS解析到部署閘道器伺服器（叢集：則解析到叢集對應的SLB負載均衡公網IP上—SLB負責具體將請求打在某一臺伺服器上）；

3、   被請求的伺服器用Nginx將請求轉發到當前伺服器的Gateway閘道器

4、   閘道器對請求介面進行鑑權、匹配路由等操作。

5、   通過Nacos自帶負載均衡Ribbon負載到具體某一個應用服務

6、   返回結果請求結束。

2.使用k8s部署後，前後端呼叫鏈路

前端

1、SLB監聽80和443埠。

2、請求進來進行域名DNS解析，解析到叢集暴露出來的公網SLB的IP上。

3、經過nginx Ingress 轉發匹配請求路徑，將請求轉發到不同的Server(一個Server對應一個Deployment，對應一個專案)上。

4、Server會通過k8s自身的負載均衡演演算法將請求負載到某一個Pod上面（這一步k8s內部有一個負載均衡選擇具體服務的哪一個Pod）

5、存取到具體的Pod，返回結果。

後臺介面

1、  SLB監聽80和443埠。

2、  請求進來進行域名DNS解析，解析到叢集暴露出來的公網SLB的IP上。

3、  經過nginx Ingress 轉發到對應的gateway閘道器Server上。

4、  Server會通過k8s自身的負載均衡演演算法將請求負載到某一個閘道器Pod上面。

5、  閘道器對請求介面進行鑑權、匹配路由等操作。

6、  通過Nacos自帶負載均衡Ribbon負載到具體某一個應用服務

7、  返回結果請求結束。

4.阿里雲流水線 + Kubernetes 映象升級部署實踐

K8s映象部署

先進行映象構建 如下兩步操作並執行流水線

在k8s管理介面的 [工作負載] --> [無狀態] 目錄根據需要部署的環境切換名稱空間，如：測試環境(namespace-dev)

 建立對應的 Deployment 與 pod

點選右上角「使用映象建立」、對k8s編排掌握好的可以直接使用 yaml 建立，推薦使用映象建立。

a.填寫對應的應用服務資訊

b.選擇對應的映象和版本（剛才建立的）

其他的不需要填、如果有提示不能為空的直接刪掉就可以了

c.下一步直接點選建立、完成後出來到無狀態目錄下找到建立的Deployment，點選去 ---> 容器組 -->  點進去 --->  紀錄檔 （進行紀錄檔檢視）

k8s映象升級

回到流水線頁面在構建映象的基礎上新建一個 部署任務--Kubernetes 映象升級，注意:  名稱空間、Deployment名稱、容器名稱 不要填錯。

這樣就完成了k8s映象的升級