物理機部署
傳統發布流程（以Java spring boot為例）
- 編譯jar包
- 分發到服務器A,B,C
- 服務啟動，監聽到指定端口
- 配置負載均衡到已啟動服務端口
- 服務發布成功
關於服務更新，為了實現滾動更新，可以讓LB綁定的服務逐漸更新
傳統更新流程
- 編譯jar包
- 分發到服務器A,B,C
- 將服務器A從LB上解綁，更新服務器A上的服務
- 啟動服務，通過健康檢查和QA之后，將服務器A綁定到LB上
- 繼續更新服務器B和C
- 服務完全更新成功
拓容流程
- 新增機器節點
- 啟動jar包
- 將新節點注冊到LB上
特點
- 單機端口有限，同一個服務如果在同一個服務器更新，需要不同的端口
- 動態更新LB
- 拓容成本高
服務化部署（這里以kubernetes為例）
k8s發布流程
- 構建docker鏡像
- 創建deployment和service，可以限制服務的CPU、Memory等資源，k8s尋找空閑節點啟動服務
- 更新iptables將物理機上指定端口路由到VIP(虛擬服務IP)
- 綁定物理機端口到LB
k8s更新流程
- 構建docker鏡像
- 更新deployment和service，k8s更新某個pod
- 輪流更新pod，直到所有pod更新完成
k8s拓容
- 尋找空閑節點啟動服務，直到達到指定數量
特點
- 幾乎無物理端口限制（k8s需要物理端口作為轉發，默認為30000+，數量有限）
- 服務間通信，可以使用serviceName或者服務的VIP進行訪問，內網訪問更方便
- 虛擬化物理機資源，隔離物理資源的細節，資源控制如拓容、服務資源限制方便
Kubernetes vs Docker swarm
- 穩定性上，k8s上基於iptables的網絡路由比docker swarm的網絡更加穩定
- 配置性上，k8s比docker swarm要復雜，swarm采用manager-worker架構，由manager調度worker，docker 1.12以上對於swarm原生支持，方便啟動集群，不過k8s在新版本之后也越來越易於配置
- 管理系統上，swarm比k8s的UI界面更友好，操作性更強
微服務架構下的應用
- 外部訪問可以暴露gateway到LB上，外部通過訪問LB進行訪問
- 使用k8s或者swarm，服務間通信可以使用serviceName進行訪問，也可以利用容器的IP，使用服務注冊進行服務查詢
- 自動拓容，當檢測到服務的CPU和內存利用率升高，通過水平拓展，增加服務節點；服務壓力減少后，逐漸減少服務節點數量
I thirst for magic...