本文就項目上線部署發佈做一些探討，只做拋磚引玉，錯漏之處歡迎評論指出，+V luosanlechang
背景
我們日常的生產發佈很多團隊都是停服發佈新版，其實在用戶量訪問頻繁，規模大的系統，很多是不允許停服升級的，或者他們選擇半夜發佈，其實都是很不明智的做法，不僅花時間而且花精力。
試想一下，一個正在運行 Java 應用如果突然將其停止，影響不止數據丟失,還會造成其他影響。比如：
- 請求丟失：內存隊列中等待執行請求丟失
- 數據丟失：處於內存緩存中數據未持久化到磁盤
- 文件損壞：正在寫的文件沒有沒有更新完成，導致文件損壞
- 業務中斷：處理一半的業務被強行中斷，如支付成功了，卻沒有更新到數據庫中
- 服務未下線：上游服務依然往停止節點發送請求
所以在關閉服務之前，我們需要先做好善後工作，比如保存數據，清理資源，下線服務，然後才退出應用。這種有計劃平滑的關閉應用相對直接停止應用，就顯得非常『優雅』。
同理，前端發佈頁面版本也會出現這種訪問和緩存錯誤問題。
因爲選擇合理的發佈方式尤其重要，不同規模的團隊和應用也有不同階段的發佈方式選型。
常見發佈方式
- 停機發布
- 功能開關發佈：利用代碼中的功能開關（Feature Flag/Toggle/Switch）來控制發佈邏輯。
- 藍綠髮布：兩套環境交替升級，舊版本保留一定時間便於回滾。
- 金絲雀發佈（灰度發佈）：小比例發佈，測試通過後再全量，例如 2% 的服務器，主要做流量驗證用，也稱爲金絲雀 (Canary) 測試（國內常稱），以前曠工開礦下礦洞前，先會放一隻金絲雀進去探是否有有毒氣體，看金絲雀能否活下來，金絲雀發佈由此得名。
- 滾動發佈：在金絲雀發佈基礎上的進一步優化改進，是一種自動化程度較高的發佈方式，用戶體驗比較平滑，是目前成熟型技術組織所採用的主流發佈方式
更多可以進入如下
https://www.cnblogs.com/apanly/p/8784096.html
https://www.cnblogs.com/nulige/articles/10929182.html
![在這裏插入圖片描述]()
發佈願景
相信很多人都希望不再停機發布，減少開發和運維無謂的等待，在服務器較多情況下使用滾動式發佈，按批次更新發布，
每次發佈時
- 先將老版本 V1 流量從 LB（Load Balance） 上摘除
- 清除老版本V1
- 發新版本 V2
- 再將 LB 流量接入新版本V2
這樣可以儘量保證用戶體驗不受影響。
從流程可以看出，主要涉及到了負載均衡切換（動態擴容縮容）和服務的優雅關閉
優雅關閉、擴容縮容
爲了實現上述願景，流程如下，而對於下面這個流程。其實大團隊普遍自動化了或者更加豐富細化，小團隊或者傳統團隊基本就是手動切換流量，手動啓停服務。方案也是各有各家輪子。
目前的幾種Web容器都沒有現成的優雅升級方案. 意味着重啓過程中總會存在部分請求失敗的情況。如果結合nginx, 理論上可以做到無感升級：
-
把準備停機的節點從Nginx上摘除, 這樣新的請求就不會再發往待停機節點
-
在Web容器停機之前，讓系統處理完已有請求併成功返回給客戶端後再徹底停機。
-
升級成功後，再把該節點掛載到Nginx上.
優雅關閉
因此首先是需要對於Tomcat容器的優雅關閉進行編碼，在清除老版本V1上就涉及到了優雅關閉的問題主要思路是
Tomcat容器的優雅關閉 -> Spring容器的關閉->其他容器或中間件
主要涉及到的技術如
- Spring Boot Actuator
- ShutdownHook（鉤子）
- SignalHandler
- Servlet的destory
方面的一些代碼嵌入或者改造。
Spring Boot Actuator 是 Spring Boot 的一大特性，它提供了豐富的功能來幫助我們監控和管理生產環境中運行的 Spring Boot 應用。
感謝生哥分享下面這篇親身實戰經驗好貼！！！
擴容縮容
對於nginx的上線下線機器，主要是涉及到了擴容縮容的方案
因爲下面方案涉及到了一些微服務的方案，所以先拿一個微服務框架預熱下。
Dubbo簡答概述
首先要補一下基礎知識
RPC微服務框架Dubbo的設計模型
Dubbo 的RPC 調用流程，這裏主要涉及到4個模塊：
-
Registry：服務註冊，我們一般會採取Zookeeper 作爲我們的註冊中心，其他服務發現框架詳情
-
Provider：服務提供者（生產者），提供具體的服務實現
-
Consumer：消費者，從註冊中心中訂閱服務
-
Monitor：監控中心，RPC調用次數和調用時間監控
從上圖中我們可以瞭解到整個RPC 服務調用的過程主要爲：
- 生產者發佈服務到服務註冊中心中
- 消費者在服務註冊中心中訂閱服務
- 消費者調用已經註冊的服務
擴容縮容
自動化擴容和縮容還有智能化運維也是我的目標。
但在傳統的Nginx後端配置中，修改upstream的server配置是需要reload或者restart。對於應用爲長鏈接、流量大系統，這會影響用戶體驗。
大多數團隊主要區別在於，有些手動修改配置文件的upstream，有些整合了其他微服務的中間件自動化更新配置文件、不同的upstream插件模板、有的整合lua腳本。附京東Nginx平臺化實踐
-
降低權重到0 或 移除主機 都能保證服務的安全的退出【但是本人未實踐】
-
Consul+Nginx Consul基於Go語言開發， 輕量級， 用於實現分佈式系統的服務發現與配置
-
Nacos + Confd 模式 confd 是一個輕量級的配置管理工具，可以通過查詢後端存儲系統來實現第三方系統的動態配置管理，結合 Nacos 中已註冊的 Tomcat 節點信息，並配合 Confd 實時更新 Nginx upstream 來做到 對接入層的 動態擴容與所容。
順便蜻蜓點水下前端，前端打包發佈升級上面的工程化問題也是涉及到了很多設計思想，感謝浴池大佬分享的這篇乾貨
其中一個比較值得了解的是Rails中的Assets Pipeline 詳情見：大公司裏怎樣開發和部署前端代碼
？
服務的監控和管理
先了解下集羣的一些技術知識基礎
https://www.cnblogs.com/hadoop-dev/p/5925916.html
下面很多工具已經集監控、調度、負載均衡於一身，提供了極大地便利。
微服務化、Docker容器化後的應用比較多現有方案做部署發佈和監控。
然而傳統應用，一般就是直接使用Nginx做負載均衡，然後搭建Tomcat集羣，集羣數多，涉及到配置文件管理和集羣每個機器的性能指標監控，於是監控工具和部署配置管理尤爲重要。
一、監控工具
Java Web做集羣部署，最直接需要注意如：
- 緩存共享，如session共享、項目中用到的內存緩存等，
- 定時任務
對於上線發佈是否成功，已經之後的運行狀態，監控至關重要
分佈式應用容器化部署的監控方式五花八門：
普通的Tomcat集羣的話監控方式比較原始，比如
- 利用JMX結合Zabbix監控Tomcat集羣
- Grafana+Telegraf+Influxdb監控Tomcat集羣
- 六款開源java應用性能監控工具
- Stagemonitor 、Terracotta、Tangosol、Haproxy，Terracotta是一款由美國Terracotta公司開發的著名開源Java集羣平臺，允許用戶在不改變現有系統代碼的情況下實現單機Java應用向集羣化應用的無縫遷移
二、集羣調度系統
- Google Borg
- Kubernetes
- Docker Swarm
- 騰訊 Torca
- 阿里飛天伏羲
- Apache Mesos
- Apache Hadoop YARN
- Google Omega
三、集羣配置和發佈管理
下面是一些業界和自研發的一些方案可作爲參考
- 噹噹的Config Toolkit
- Apollo（阿波羅）：是攜程框架部門研發的配置管理平臺，能夠集中化管理應用不同環境、不同集羣的配置，配置修改後能夠實時推送到應用端，並且具備規範的權限、流程治理等特性。
- K8S：容器編排工具，Kubernetes是Google 2014年創建管理的，是Google 10多年大規模容器管理技術Borg的開源版本。它是容器集羣管理系統，是一個開源的平臺，可以實現容器集羣的自動化部署、自動擴縮容、維護等功能
- Rancher、Mesosphere 、Openshift
- Etcd+Confd實現Nginx配置文件自動管理，這種方式可以參照使用到Java的應用配置文件管理
使用Jenkins停機發布方案
上面是一些應用發佈升級方案包含擴容縮容等的探討，那麼接下來大篇幅交給停機發布篇，基於當前項目實際情況，我主要介紹下比較原始但是大多數普通團隊能用的應用升級方案。
下面大量篇幅進入Jenkins構建發佈技術詳解
Jenkins構建項目簡易教程
https://blog.csdn.net/u011456337/article/details/103344140
錯漏之處歡迎評論指出！
附上本人的V luosanlechang，內部價格，技術交流歡迎！同時歡迎諮詢購買都有最優惠！
