簡介
IBM® 收購 Red Hat® 後，現在擁有更多的 Java 應用程式執行時，包括：
傳統的 IBM WebSphere® Application ServerJBoss® EAP / WildFlyWebSphere Liberty / Open LibertyQuarkus這樣一來，客戶不免會提出兩個問題：
我應該選擇哪個執行時？“執行時 A 和 B”何時得到合理化？第二個問題的答案很簡單 – 我們不計劃移除或合併任何執行時。每個執行時都有大量忠實的客戶群，他們需要所使用執行時的連續性。透過在開源專案（如 SmallRye 和 Apache CXF）中進行協作，已經實現了開發效率。
本文將解決第一個問題。答案並不像“使用執行時 X”那麼簡單，甚至比“對於微服務，請使用執行時 X”還要複雜。為了選擇一個或多個執行時，瞭解以下三點很重要：
執行時的演變要了解每個執行時的特性以及如何應用它們，有必要回顧一下它們的歷史，因為這會極大地影響它們最適合的應用程式型別。
傳統企業應用程式全球資訊網的商業化和 Java 應用程式伺服器技術的標準化導致不少供應商都在開發應用程式伺服器產品。WebSphere Application Server 以及後來的 Wildfly 和 JBoss EAP 是在 20 世紀 90 年代末首次釋出的。按照現在的標準，執行這些產品的硬體的計算能力相當普通：網路速度慢得多，尚未圍繞乙太網進行標準化，並且記憶體和磁碟容量受到限制（距離第一個 1TB 硬碟的釋出還有 10 年時間）。Waterfall 和相關工程實踐也主導了軟體交付。這自然導致了整體式應用程式的開發和交付。當然，由於在當時沒有其他型別，它們只被稱為“應用程式”。值得一提的是，整體式應用程式並不差，糟糕的是難以維護的整體結構，並且可以使用任何架構樣式來構建難以維護的系統。在 21 世紀初，VM 出現了，這是一種簡化伺服器部署的方法，但是叢集是以特定於您所部署的每種執行時型別的方式完成的（例如，WebSphere ND Cell）。
約束、實踐和長交付週期導致需要對 Enterprise Java 執行時進行最佳化才能實現長期、穩定、高效能的正常執行時間。一旦您部署了伺服器和應用程式，您就希望它無論如何都可以繼續執行。
業務敏捷性要求執行時敏捷性在隨後的幾年中，對速度更快、擴充套件性更強的交付的日益增長的需要推動了基礎架構和方法學的重大進步。處理器、網路和儲存的速度和容量都在增長，並且軟體交付包含了敏捷實踐。加快上市時間的壓力導致對輕量級執行時的需求不斷增長，這有助於更快地交付應用程式。為響應這些要求，IBM 在 2012 年開發了 WebSphere Liberty。
Liberty 重新審視瞭如何滿足應用程式快速開發和交付的需求：輕量級、易於配置、易於部署並支援新興的最佳實踐和工具。此時開發的應用程式仍然主要是整體式程式，但是在 Liberty 的幫助下，可以更輕鬆、更快地交付。Liberty 最初支援簡單的 Web 應用程式，但是根據客戶需求，不久便開始支援完整的 Java EE 功能。Liberty 能夠安裝和配置“剛好足夠的執行時”，也就是僅限應用程式所需的功能，這意味著它不會出現通常與企業應用程式伺服器相關的執行時膨脹問題。Liberty 還在容器和容器編排平臺之前增加了企業所需的叢集和健康管理功能（圍繞 Liberty Collective）。
在接下來的五年中，開源已成為軟體採用中越來越重要的方面。為了支援這一轉變，Liberty 在 2017 年轉變為開源優先的開發模型，具體措施是根據 Eclipse Public License 將 WebSphere Liberty 開源為 Open Liberty。
用於快速、靈活、可擴充套件部署的架構這些年來，許多整體式應用程式不斷增長，並且經常完全不考慮模組性，從而使其難以維護和擴充套件。一些企業尋求進一步減少交付時間並提高可伸縮性以應對大得多的工作負載需求，卻發現自己受到了整體式架構固有的“全部部署、全部擴充套件”性質的束縛。為了獲得更大的靈活性和可伸縮性，需要將這些應用程式重新想象為許多較小的單元，這些單元可以獨立開發、部署和擴充套件，也就是所謂的微服務和函式（通常部署到為函式即服務 [FaaS] 環境中的雲）。
從單個整體式應用程式到許多微服務或函式的這種轉變推動了對既簡化操作又降低基礎架構成本的技術的需求。以 Red Hat OpenShift® 為代表的容器和基於 Kubernetes 的容器編排平臺已迅速成為微服務的代名詞。支援輕量級隔離部署的容器以及支援一致容器部署、管理和叢集的 Kubernetes，不再需要以執行時為中心的叢集方法（例如 ND Cell 和 Liberty Collective）。
微服務的普及導致對新 API 標準的需求，因此不少供應商和 Java 使用者群體聚集在一起，建立了 Eclipse MicroProfile 規範。MicroProfile 發展迅速，提供了一組完整的開放式微服務 API，並且還有不少提供支援的執行時，包括 Liberty、WildFly、JBoss EAP、Payara、TomEE 和 Quarkus。
對作為微服務或函式而部署的更細粒度元件的需求導致了對更輕便、更快速的執行時的日益增長的需求。在 2019 年，Red Hat 釋出了 Quarkus，這是專門針對這些架構樣式量身定製的執行時。這樣，它就將 Quarkus 牢固地定位於新函式和微服務，僅支援原生編譯所涵蓋的 Java API 子集。
Liberty 和 Quarkus 都為微服務提供了基於 JVM 的出色執行時配置檔案，可在一秒左右響應首批請求。另外，Quarkus 還提供了原生編譯功能，提供了非常適合函式的執行配置檔案，其中針對單一請求進行最佳化很重要。
各種架構樣式在過去的幾年中，微服務架構的交付受到日益增長的關注。與任何新概念一樣，該行業經歷了發現過程，並最終學習瞭如何最好地加以應用。在達到這種開明狀態之前，技術往往會被過度應用，導致不良的結果。Gartner 將此學習過程稱為“Gartner Hype Cycle”，目前將微服務定位為“幻覺破滅期”。這並不意味著微服務不好；只是表示我們才剛剛開始真正認識到微服務在哪些情況下適合，在哪些情況下不適合。
在網際網路上快速搜尋一下就可以發現越來越多的文章討論了整體式、微服務和函式。也有一些示例使用諸如“宏服務”或“宏整體”之類的術語談論整體與微服務之間的樣式。在某些情況下，這是對過度分解為過於細粒度的微服務的一種反應，因為過度分解導致系統過於複雜，複雜性的壞處已經超過了收益。在其他情況下，則是直接嘗試在每種架構樣式的功能和非功能特性之間找到合適的平衡。公司隨時間而改變架構樣式的著名例子有 Uber 團隊目前在部署粗粒度宏服務以及微服務，還有 Segment 從整體式切換到微服務，然後又切換回整體式。
顯而易見的是，大家日益瞭解不同架構樣式的利弊，預計在未來幾年中這種趨勢會繼續增長。我們不應假設所有應用程式都將是微服務，而是更好地瞭解應用程式需求、基礎架構和團隊功能，以明智地選擇適當的架構樣式。大家會越來越多地傾向於部署多種架構樣式以及隨著需求的發展而在不同架構樣式之間發展。
架構樣式的特徵在選擇哪種架構樣式可能適合時，瞭解它們的特徵很重要。下面顯示了一些關鍵特徵以及它們在不同架構樣式之間的變化。請務必瞭解，某些特徵不會在您選擇了架構樣式之後就會自動實現；它們是潛在的利益，需要技術或組織投入才能獲得這些利益。例如，如果您不投資自動化技術，就需要費力地更加頻繁地交付微服務更新。
我們從最底層的特徵開始，來更詳細地瞭解這些特徵：
定價：資本支出（一次性的前期獲取成本）和運營支出（授權/使用的定期費用）各有利弊。函式即服務本質上是運營支出，並且具有所有模型中最細粒度的度量。整體式程式通常是資本支出，但是有一些方法可以將該成本更多地平滑轉移到運營支出模型（例如，承諾期限許可）。交付頻率/複雜性和操作複雜性：這兩者都與以下事實有關：隨著我們從粗粒度架構樣式過渡到更細粒度架構樣式，我們將增加我們建立、部署、管理、除錯和維護的工件數量。這會導致相關的成本，但也會帶來益處。模組性：整體式結構的一大缺點是難以使其模組化，並長久保持這種模組性。隨著我們從粗粒度過渡到細粒度，我們將應用程式進一步分解為越來越小的部分，但同時也引入了過程和網路邊界，以作為增強模組性的一種方式。這提高了建立更為鬆散耦合、更靈活的解決方案的機會。不過要小心，因為有些人發現建立分散式整體非常容易，但這是兩頭都不討好的事情（沒有什麼好的代替架構）。網路需求和故障隔離：這兩個是齊頭並進的。隨著越來越多的元件的分發，對網路的使用和依賴性也越來越高。網路效能成為影響整體解決方案效能的關鍵限制因素。網路可靠性還會影響整體解決方案的可用性。增加隔離度有助於避免級聯故障導致整個解決方案癱瘓，但是需要採用防禦性容錯技術（例如隔板、重試和回退）來利用隔離度。執行時要求：不同的架構模式不僅有利於不同的執行時特徵，而且也有利於以不同方法來採用執行時。對於粗粒度的應用程式，交付週期通常更長，因此偏好長時間的執行時穩定性。首要考慮事項是讓執行時更長的在應用程式部署期間保持出色的效能。此外，您通常會直接管理和最佳化伺服器，然後向其部署一個或多個應用程式。對於更細粒度的應用程式，由於交付週期更短，請求數量更少，例項數量多得多，因此重點在於執行時要輕量、啟動速度快。還有一種傾向是從以伺服器為中心的部署轉變為以應用程式為中心的部署，在這種情況下，伺服器與應用程式結合一起（例如，在較底層的容器映像層中）。在下一部分中，我們將探討最後一點，也就是 API 需求與架構模式之間的關聯。對於粗粒度的應用程式，您通常在單個應用程式中使用許多不同的 API，而對於更細粒度的應用程式，每個函式或微服務的 API 需求都更小。選擇執行時我們瞭解了每個執行時的歷史和演變如何極大地影響它們最適合的架構樣式。我們瞭解了企業如何逐漸認識到不同架構樣式的好處以及有多少企業能夠靈活地使用這些架構。我們還了解了與每種架構樣式相關的許多特徵，以及如何使用這些特徵來幫助確定使用哪些樣式，並且很可能隨著時間的推移來混合或更改樣式。但是，這在執行時選擇方面有什麼意義呢？
根據每個執行時的歷史和發展，下圖顯示了每個執行時適用的架構樣式，並針對應用程式的“API 需求”進行了繪製（應用程式的 API 需求往往與應用程式的“規模”相關）。
這張圖表明，無論選擇哪種架構樣式，IBM 和 Red Hat 都可以涵蓋。透過仔細檢查，我們發現整體式有三種選擇（傳統的 WebSphere Application Server、JBoss EAP 和 Liberty），微服務有兩種選擇（Liberty 和 Quarkus）。但是，與其討論針對特定的架構風格哪種選擇最適合，更重要的是考慮每個執行時的遺留特色、每個應用程式的策略以及您可能使用的架構風格。以下示例場景應該會有所幫助：
如果您目前採用的是整體式，並且希望以最小的工程投資來使其保持穩定執行，那麼應將其保留在傳統的 WebSphere Application Server 和 EAP 上。如果您打算部署新的函式和新的微服務，那麼 Quarkus 是個不錯的選擇，因為它具備針對性 API 和原生編譯。Quarkus 的原生映像功能將為您提供非常適合函式的執行時特徵。如果您希望對現有的企業應用程式進行現代化改造，那麼 Liberty 的輕量級完整 Java 執行時是一個不錯的選擇。這些應用程式通常是用 Java EE 編寫的，因此從長遠來看，選擇具有完整 Java EE 功能的現代執行時對您有益。如果您要從傳統的 WebSphere Application Server 進行現代化，那麼 WebSphere Liberty 還提供了一些 API，旨在簡化您的現代化之路。如果您希望建立新的現代化整體式結構、新的微服務或介於這兩者之間的任何結構，那麼 Liberty 是個不錯的選擇，因為它具備合適的功能和靈活性。這是因為 Liberty 設計為用於整體式應用程式的現代化完整 Java 執行時，並且已針對輕量級高效能微服務進行了最佳化，從而使您可以靈活地選擇架構樣式並在這些架構樣式之間切換。結束語本文介紹了行業對不同應用程式架構樣式的認識如何演變為更細緻的觀點，也就是：要根據應用程式的業務需要以及技術和組織能力來選擇架構樣式。本文還討論了 Java 執行時的歷史如何強烈地影響其對不同架構樣式的適用性。最後，透過利用少量場景，本文提供了一種方法來選擇一種或多種合適的執行時，以適應您喜歡的一種或多種架構樣式。我們希望以上內容對您有幫助。