輸了：傳統架構應用快速橫向擴容PK容器！

作者：三頁 2022-10-14 07:25:49

開發架構

本文通過可視化頁面搭建、no/low code 平臺、Schema 動態表單等技術思想來分析講解了如何去設計開發一個通用的數據大屏搭建平臺。

背景?

當監控平臺發現流量突增，業務系統應用或鏈路監控出現一定范圍的告警，此時我們查看問題的方向為：

APP或網站是否被攻擊了，如DDOS、CC、暴力破解等；
合作推廣帶來的業務流量增高，應用系統壓力過大；
數據庫是否出現因連接數滿、事務死鎖導致壓力過大；

以上幾種情況都是我們在處理生產故障過程中比較常見的，本次我們就應用系統壓力過大的場景，需要進行橫向擴容的方向來講解。

需求?

當應用系統壓力過大，除了臨時調整線程數或直接橫向擴容來解決外，更深入的優化代碼以及調用鏈路上的耗時接口就更加滯后了。因此我們決定通過應用橫向擴容來應對系統壓力過大，此時實現如何快速擴容就成了我們重點關注的問題。

傳統架構下，對于應用橫向擴容我們需要做的重點步驟如下：

閑置的服務器資源；
系統標準化部署步驟（應用發布、標準目錄、配置發布、應用啟動）；
應用啟動自動健康檢查；
應用啟動后自動接入負載均衡或注冊中心；
應用橫向擴容后同步到系統監控平臺；
CMDB資產同步添加到對應業務分組；
應用服務器同步至堡壘機；

以上是新的應用服務器上線在運維管理過程中流轉涉及的各個主要環節，除了提前準備閑置的服務器資源以節省不必要的時間外，其他都是需要根據我們系統架構及運維平臺的實際情況去適配，我這里只是提供了一個思路。

假設，一套比較主流的架構為：

CMDB，基礎設施統一納管
Zabbix監控，統一的健康檢查
JumpServer堡壘機，服務器統一登錄管理
Spring Cloud 框架
Eureka注冊中心
Apollo配置中心

解決方案?

在此我們通過??Pipeline支撐運維自動化??的思想來實現應用橫向擴容，以流水線的形式編排不同級別的原子模塊來實現不同運維場景的功能需求。

根據系統架構，應用橫向擴容流水線的實現涉及的功能模塊上圖中已經標注出來，其中：

CMDB+事件推送網關，可通過CMDB對空閑服務器資源分配觸發資產在Zabbix監控和堡壘中自動同步；
基礎組件安裝，實現了Java環境包括標準部署目錄、JDK環境、管理腳本等內容的自動配置；
當然我們默認空閑服務器已經是按操作系統初始化（配置初始化、標準用戶、等保安全基線）交付的，因此我們在此沒有過多介紹。
Apollo配置中心級原子模塊，實現應用的配置發布；
系統監控級原子模塊，擴容后應用的健康檢查同步添加到監控平臺；

具體實現?

1.構建?

我們只需輸入應用名、新應用IP、版本號，就可以實現應用的橫向擴容，但是目前只支持逐臺擴容，還不能批量橫向擴容。

2.構建結果?

通過對流水線的stage的時間統計，應用擴容耗主要為版本發布過程中的啟動時間。

3.Pipeline?

@Library('shared-library') _
pipeline {
   agent any
   options {
       timestamps()
   }
   stages {
       stage('基礎組件初始化') {
           steps {
               script {
                    build job: 'init_system', parameters: [text(name: 'HOST_IP', value: "${HOST}"), string(name: 'PLAYBOOK', value: 'software_install.yml'), string(name: 'TAG', value: 'java,filebeat')]
               }
           }
        }
        stage('應用初始化') {
           steps {
               script {
                   java_deploy.InitApp("${APP_NAME}")
               }
           }
        }
        stage('拉取Yunweiconfig配置') {
            steps {
                script {
                    java_deploy.PullFromYunweiconfig("${APP_NAME}")
                }
            }
        }
        stage('從制品庫拉取包文件') {
           steps {
               script {
                   java_deploy.PullFromArtifactory("${APP_NAME}", "${VERSION}")
               }
           }
        }
        stage('apollo更新') {
            steps {
                script {
                    apollo.ApolloDeploy("${APP_NAME}")
                }
            }
        }
        stage('版本發布') {
           steps {
               script {
                    app_port = apollo.ApolloGetPort("${APP_NAME}")
                    java_deploy.DeployApp("${APP_NAME}", "${VERSION}", "${HOST}")
                    ip_port = "${HOST}" + ':' + "${app_port}"
                    //健康檢查
                    java_deploy.HealthCheck("${ip_port}")
               }
           }
        }
        stage('添加zabbix健康檢查  ') {
           steps {
               script {
                    app_prot = apollo.ApolloGetPort("${APP_NAME}")
                    //println("test pass")
                    println("${app_prot},${HOST}")
                    ip_port = "${HOST}" + ':' + "${app_prot}"
                    build job: 'zabbix_newalert', parameters: [string(name: 'APP_NAME', value: "${APP_NAME}"), string(name: 'IP_PORT', value: ""), string(name: 'HTTP_URL', value: "${ip_port}")]
               }
           }
        }
    }
}

PK容器?

彈性伸縮相對于傳統架構，操作系統CPU、內存資源閾值的粒度太粗，無法精確地進行適時擴容；另外對于批量擴容，需要提前準備好資源，相對于容器的解決方案還是不夠靈活。

啟動時間無論是容器還是傳統架構，限制快速擴容的主要原因在于應用的啟動時間，這方面要提前進行優化。

IP地址分配傳統架構無法做到IP地址的自動分配，在生產環境使用DHCP不僅會導致keepalived切換產生腦裂，還會因租期問題產生其他問題。而云原生架構的可以做到自定義IP池，因此后續擴容會使用IP池中的地址。

以上幾點是通過本次對應用自動橫向擴容，與容器使用過程中的幾點對比，印象比較深刻。

總結?

本次PK，傳統架構雖然輸了，但也并不是一敗涂地。至少讓我發現只要細心，堅持標準化、原子化、場景化的原則，我們還是有很大空間可以提升的。容器給了我們目標和方向，剩下就要看我們自己了

責任編輯：武曉燕來源：木訥大叔愛運維

傳統架構容器

輸了：傳統架構應用快速橫向擴容PK容器！

背景?

需求?

解決方案?

具體實現?

3.Pipeline?

總結?

輸了：傳統架構應用快速橫向擴容PK容器！