物理機部署
傳統發佈流程（以Java spring boot爲例）
- 編譯jar包
- 分發到服務器A,B,C
- 服務啓動，監聽到指定端口
- 配置負載均衡到已啓動服務端口
- 服務發佈成功
關於服務更新，爲了實現滾動更新，能夠讓LB綁定的服務逐漸更新java
傳統更新流程
- 編譯jar包
- 分發到服務器A,B,C
- 將服務器A從LB上解綁，更新服務器A上的服務
- 啓動服務，經過健康檢查和QA以後，將服務器A綁定到LB上
- 繼續更新服務器B和C
- 服務徹底更新成功
拓容流程
特色
- 單機端口有限，同一個服務若是在同一個服務器更新，須要不一樣的端口
- 動態更新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和內存利用率升高，經過水平拓展，增長服務節點；服務壓力減小後，逐漸減小服務節點數量