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

先宣告一下：我所在的公司是一個小團隊，做物聯網相關的，前后端、硬體、測驗加起來也就五六十個人左右；本人的崗位是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鏡像的升級

本文來自博客園，作者：Tom-shushu，轉載請注明原文鏈接：https://www.cnblogs.com/Tom-shushu/p/16913567.html

標籤：架構設計

上一篇：JFramesetIconImage()適用于Windows但不適用于Mac

下一篇：小公司的應用服務部署歷程