從 Java 應用部署方式看 IT 思潮——從開發和運維到開發自運維

前些日子，我還在西溪園區上班的時候，若是不是忙得不可開交，我都會在午餐的時候儘量選擇一個離所在辦公樓遠一些的食堂吃飯。由於午飯和晚餐是一天的工做中可貴的兩個「放風」時間，若是碰到了有趣的話題還能在路上和同事交流一二。

有一次，同事問了我一個問題：「爲何 Spring Boot 應用傾向於打 fat jar 直接啓動，而集團的應用傾向於打 war 包從應用容器啓動？」當時我從 IT 主流思潮的角度給了一個解釋，大意爲 Spring Boot 是 DevOps 時代的產物，集團大多數應用是 Dev 和 Ops 分離時代的產物。

這種說法抽象程度略高，雖然也能作爲一種解釋，可是沒能很好地把事情表達完整。因而我把當時的解釋整理完善後，寫下了如今這篇博文。

Java 應用部署於應用容器中，實際上是受到 J2EE 的影響，也算是 Java Web 有別於其餘 Web 快速開發語言的一大特點。一般咱們在交付 Java Web 應用的時候，交付件是一個後綴爲 war 的內部目錄結構符合必定規則的 zip 壓縮包，這個壓縮包裏（幾乎）完整打包了 Web 頁面（模板）、Web 站點描述、Java Web 的各個模塊的 jar 以及依賴的第三方 jar。運維將這個 war 文件部署到應用容器中，站點就能被訪問了。

在虛擬機在數據中內心開始流行之前，Java 應用是直接部署在物理機上的。可是單一的 Java Web 又很難將一個物理主機的所有資源有效利用，爲了節省成本，咱們一般會將多個 Java Web 同時部署在一臺物理機上，確切的說，是將多個 war 文件部署在一個應用容器裏。

在一個應用容器中部署多個 war 文件，就能實如今一個 Java 虛擬機進程中爲多個站點提供服務，這能有效地節省內存資源，特別是在那個內存比較金貴的年代，這種特性意義重大，甚至應用容器還能動態地部署和卸載 war 文件而無需重啓 Java 虛擬機。

剛纔咱們說 war 文件是一個 zip 壓縮包，其實咱們更常見的作法不是部署這個壓縮包，而是部署 war 文件解壓以後的目錄。那是一個運維和開發分離的年代，開發交付 war，運維部署 war（解壓以後的目錄）。隨着公司業務飛速發展，Java Web 承載了巨大的流量，應用容器開始暴露一些尋常難以發現的問題，甚至有時候這些問題會致使線上故障。因而漸漸的，開始有團隊專門去維護開源的應用容器，修復漏洞，提高性能。

因爲研發團隊交付的是 war 文件，當應用容器須要更新的時候，運維團隊可以在研發團隊不須要介入的狀況下完成 Java Web 的從新部署。甚至當一些經常使用的底層框架出現了安全漏洞的時候，運維團隊也能掃描所有機器所有 war 解壓出來的目錄中的 jar，將有問題的依賴替換以後重啓應用完成修復。

隨着硬件性能逐步提高，也隨着虛擬機技術被數據中心普遍使用，以前一個物理機上混合部署的十幾個 Java Web，搖身一變成了一個物理機上虛擬出來的十幾個虛擬機，每一個虛擬機裏部署一個應用容器和一個 Java Web。

虛擬機技術的普遍使用，給應用運維帶來了極大的便利，不再用擔憂機器環境被破壞，不再用擔憂應用之間依賴衝突，只須要幾行命令幾個腳本，一個配置完善的開箱即用的 Linux Server 就唾手可得。不再用糾結哪些應用能夠混合部署哪些應用須要獨立部署，流量低峯期就超賣來壓縮成本，流量高峯到來以前再將虛擬機飄到空閒主機上避免資源爭搶。

後來開發殺入運維領域，誕生了一種新的工種，DevOps。當開發和運維都是一個團隊甚至一我的的時候，將應用和應用容器分開來部署，就顯得十分繁瑣了。由於不管是升級容器仍是升級應用，對於 DevOps 來講，都是一次沒什麼明顯差異的升級任務，最好能用一套統一的部署流程去完成。也許 embedded servlet containers 就是在這種需求背景下誕生的，應用容器再也不是獨立於應用以外的容器，而是做爲應用的一部分，伴隨應用一塊兒部署和升級。

Spring Boot 就誕生在 DevOps 盛行的這幾年。藉助 embedded servlet containers，使用 Spring Boot 開發的應用將一個 Jetty 或者 Tomcat 嵌入在它的交付件中，整個 Java Web 應用連同應用容器打包成一個 fat jar，只須要一行 java -jar webapp.jar 就能完成應用的啓動，咱們甚至都感知不到應用容器的存在，彷彿只是在運行一個普通的 Java Application。因而升級容器的工做，就和升級一個第三方類庫同樣，修改 pom 文件，打包，發佈，垂手可得。

再後來，伴隨着以 Docker 爲首的一衆容器技術的興起，咱們正在漸漸進入 Immutable Infrastructure 的時代。

不可變基礎設施，是 Chad Fowler 於 2013 年提出的一個頗有前瞻性的構想：在這種模式中，任何基礎設施的實例（包括服務器、容器等各類軟硬件）一旦建立以後便成爲一種只讀狀態，不可對其進行任何更改。若是須要修改或升級某些實例，惟一的方式就是建立一批新的實例以替換。

在容器時代到來以前，雖然咱們已經在 Spring Boot 之類的框架的引導下，將 Java 應用打成了一個 fat jar 來分發和部署，但實際上咱們分發到生產環境中的內容，遠不止這個 fat jar。爲了讓應用代碼可以在不一樣環境中部署，咱們會將各個環境不一致的內容抽取出來，保存在配置文件中供 Java Web 應用啓動時讀取，好比數據庫鏈接串、密碼，好比 ZooKeeper 集羣的 IP 列表。爲了可以動態調節日誌等級和格式，咱們還會單獨爲 logback 等日誌器提供配置文件，還要監聽這個日誌配置的變化。

這些 fat jar 以外的配置，給應用的部署、擴容帶來了外的負擔。容器想要爲咱們處理這一切。若是咱們將配置文件打包進容器鏡像中，咱們就能獲得一個隨時能夠部署的鏡像，應用的部署和擴容變得簡單起來。可是包含配置的鏡像徹底沒有對環境變化的適應能力，在集羣 A 上跑的好好的鏡像，也許就無法部署在集羣 B 裏頭。因而咱們開始使用環境變量去描述各個環境不一致的內容，在啓動 Java Web 以前先用環境變量渲染出一份適合當前環境的配置。因而，咱們又得使用一個配置管理數據庫來管理這許多環境中的許多環境變量，用一箇中心化的 CMDB 去取代以前散落在各個集羣的應用配置。

Java Web 應用部署的方式，從最初的應用容器 + 物理機 + 多應用混合部署，到應用容器 + 虛擬機 + 獨立部署，再到 fat jar + 虛擬機，最後是現在的 fat jar + Linux 容器，伴隨着業界運維自動化智能化的浪潮一路走來，也讓咱們看到了工程師從「術業有專攻」向 DevOps 乃至全棧工程師轉變的趨勢。經過提供隨時隨地輕鬆獲取的 API 化的計算資源，雲計算正在加速這一轉變，雲計算也讓正處在轉變過程當中的工程師的工做愈來愈輕鬆有趣。

創業去作雲計算並無比以前任何一個時代輕鬆，真正變得容易的是基於雲計算的創業

很幸運身處這樣一個時代，可以參與到雲的建設之中，爲了沒法計算的價值。據可靠消息，阿里雲 ApsaraDB 管控團隊近期正在招聘，加入團隊就有機會在雲計算環境下管理和自動化運維海量服務器，瞭解多機房容災的原理，深度瞭解 MySQL、SQL Server、PostgreSQL、Redis 和 MongoDB 等各類數據庫的原理和實戰應用。咱們但願你和咱們同樣，具有以下能力：

1. 掌握紮實的 Java/Python 基礎，熟悉集合類，I/O 及多線程/協程編程，理解各類容器類的內部實現
2. 三年以上 Java 進行 Web，API 或中間件的全流程開發經驗，熟悉 Spring，iBatis，緩存，鏈接池等常見基礎框架的使用、原理和實現
3. 熟悉經常使用設計模式，熟悉基本 JVM 原理、參數及問題排查，掌握 JVM 性能調優的常見方法及故障排查方法
4. 熟練掌握 SQL 和 MySQL，對 SQL 優化有必定經驗，掌握事務的基本原理及實現
5. 熟練掌握 Linux 下經常使用的 shell 命令，掌握 Linux 基礎性能指標及線上問題排查與解決方法
6. 對分佈式系統及分佈式存儲理論，如 CAP，一致性哈希，MVCC 等原理及算法有必定了解
7. 熟悉平常開發流程，熟悉經常使用開發、調試工具、代碼管理工具，如 Git、Maven、Eclipse 等
8. 思路清晰，良好的溝通能力與技術學習能力
9. 有線上大規模分佈式系統開發、部署或運維經驗者優先
10. 有 Python、Perl 等其它腳本語言開發經驗者優先

若是你願意和咱們一塊兒打造最優秀的雲數據庫平臺，請不要吝嗇你的簡歷，發送郵件至 xile@alibaba-inc.com 盡情勾搭吧！