翻譯的有點爛，歡迎提出修改意見，如果是在看不下去請閱讀文末的原文。
要點：
- 匆忙採用微服務，可能會出現架構穩定方面的差距和反模式。
- 瞭解歷史範式轉變的警告和陷阱，會使我們能夠從以前的錯誤中吸取教訓，並使我們的組織能夠在最新的技術浪潮中蓬勃發展。
- 重要的是要了解不同的架構風格（例如整體式應用程序，微服務和無服務器功能）的利弊。
- 架構演進的重複週期：初始階段不瞭解新範例的最佳實踐，這加速了技術負擔。隨着行業開發新的模式來解決差距，團隊採用了新的標準和模式。
- 架構模式有利於技術快速發展並保護業務應用免受波動影響。
近年來微服務、雲計算和容器化等技術趨勢一直在迅速升級，以至於其中大多數技術已成爲高級IT工程師，架構師和領導者日常職責的一部分。我們生活在一個支持雲的世界中。但是，啓用雲功能並不意味着成爲雲原生。實際上，如果不具備雲原生功能，是很危險的。
在我們研究這些趨勢並討論是否充分利用基於雲的架構和組織變革之前，重要的是要了解架構的過去，現在和將來。瞭解歷史範式轉變的弊端和陷阱，會使我們能夠從以前的錯誤中吸取教訓，並使我們的組織能夠在最新技術浪潮中蓬勃發展。
反模式
在我們簡要介紹這一演變過程時，我們將探索反模式的概念，反模式是對重複出現的問題的常見應對方式，這些應對方式通常無效且可能適得其反。本系列文章將描述提到的反模式。
架構演變
在過去約50年的時間裏，軟件架構和應用程序託管模型經歷了從大型機到微服務和無服務器的重大轉變。
集中式
上世紀70年代和80年代，大型機是計算的方式。大型機基於集中式數據存儲和計算模型，終端在原始屏幕上進行數據輸入和數據顯示。最初的大型計算機使用打孔卡，並且大多數計算都在批處理過程中進行。沒有在線處理，並且延遲爲100％，因爲沒有實時處理。隨着在線處理和用戶界面終端的推出，大型機範式發生了一些變化。但是，包含在單個組織的四面牆中的大規模中央處理單元的整體範例仍然採用“一刀切”的方法，並且只能部分提供大多數業務應用程序所需的功能。
集中式-> 分散式
客戶端/服務器體系結構將大多數邏輯放在服務器端，並將某些處理放在客戶端上。客戶端/服務器是分佈式計算中首次嘗試取代大型機作爲業務應用程序的主要託管模型。在該體系結構的最初幾年中，開發社區仍在使用與大型機開發相同的過程，單層原則來爲客戶端/服務器編寫軟件，從而產生了諸如意大利麪條代碼和Blob之類的反模式。軟件的這種有機增長還產生了其他反模式，例如大泥巴。業界必須找到阻止團隊遵循這些不良做法的方法，因此必須研究編寫良好的客戶/服務器代碼所必需的內容。
這項研究工作規劃了幾種反模式以及最佳實踐設計和編碼模式。它引入了一項稱爲面向對象程序設計（OOP）的重大改進，該改進具有繼承，多態性和封裝功能，以及處理分散數據的範例（與具有真實版本的大型機相對），並提供了有關如何進行行業開發的指南，可以應對新挑戰。
客戶/服務器模型基於三層體系結構，包括展示（UI），業務邏輯和數據層。但是大多數應用程序是使用兩層模型編寫的，胖客戶端將所有展示，業務和數據訪問邏輯封裝在一起，直接訪問數據庫。儘管業界已經開始討論將展示與業務與數據訪問分開的必要性，但是這種做法直到基於Internet的應用程序問世才真正變得至關重要。
通常，此模型是對大型機限制的一種改進，但是該行業很快就遇到了其限制，例如需要在每臺用戶的計算機上安裝客戶端應用程序，並且無法作爲業務功能進行細粒度的擴展。
去中心化->關聯/共享（www）
在90年代中期，互聯網革命發生了，並且出現了一個全新的範例。 Web瀏覽器成爲客戶端軟件，而Web和應用程序服務器託管所有處理和邏輯。萬維網（www）範式促進了真正的三層體系結構，其中在Web服務器上託管了展示（UI）代碼，在應用程序服務器上託管了業務邏輯（API），並在數據庫服務器中存儲了數據。
開發社區開始從胖（桌面）客戶端遷移到瘦（Web）客戶端，這主要是由諸如面向服務的體系結構（SOA）之類的想法所推動的，這種想法加強了對三層體系結構的需求，並受到客戶端技術改進的推動以及網絡瀏覽器的快速發展。此舉加快了產品上市時間，並且不需要安裝客戶端軟件。但是開發人員仍在將軟件設計爲緊密耦合的設計，從而導致混亂和其他反模式。作爲解決辦法，業界提出了三層體系結構和實踐，例如域驅動設計（DDD），企業集成模式（EIP），SOA和松耦合技術。
虛擬機託管 -> 雲託管
21世紀前10年見證了當託管以雲計算作爲服務可用的時候託管形式的重大改變。應用程序需要的一些能力，比如：分佈式計算、網絡、存儲以及計算等，與傳統的基礎架構相比，合理的成本提供的雲託管的方式會更容易。另外用戶可以根據需求靈活的調整資源的大小。他們只需要爲他們使用的存儲和計算資源付費。在Iaas和Paas中引入的彈性能力可以讓單個的實例按需拓展，消除了爲了伸縮性而重複的實例。但是這些能力不能補償因爲其他目的而做的重複實例，比如持有多個版本，或者作爲單個部署的副產品。基於雲託管的方式吸引人的地方是開發和運維工程師不再需要關注基礎設施。它提供了三種不同的託管方式：
- 基礎架構即服務（IaaS）：開發人員選擇服務器規格來託管其應用程序，而云則提供硬件，操作系統和網絡。這是這三種形式中最靈活的一種，但是確實給必須指定服務器的開發團隊帶來了一些負擔。
- 平臺即服務（PaaS）：開發人員只需要擔心他們的應用程序和配置。雲提供商負責所有服務器基礎架構，網絡和監視任務。
- 軟件即服務（SaaS）：雲提供商提供了託管在雲上的實際應用程序，因此客戶端組織可以對整個應用程序進行使用，甚至對應用程序代碼也不承擔任何責任。此選項提供開箱即用的軟件服務，但是如果客戶需要提供商提供的功能之外的任何自定義業務功能，則該選項不靈活。
PaaS成爲雲選項中的最佳選擇，因爲它使開發人員可以託管自己的自定義業務應用程序，而不必擔心置備或維護基礎架構。儘管雲託管鼓勵模塊化應用程序的設計和部署，但許多組織發現，它誘使將尚未設計用於彈性分佈式架構的遺留應用程序直接遷移和遷移到雲中，從而產生了一種稱爲“整體式”的現代反模式地獄”。爲了應對這些挑戰，業界提出了新的架構模式，例如微服務和12要素應用程序。遷移到雲還給行業帶來了管理第三方庫和技術上的應用程序依賴項的挑戰。開發人員開始爲太多的選擇而苦苦掙扎，沒有足夠的標準來選擇第三方工具，我們開始看到一些依賴地獄。
依賴地獄可以發生在不同的級別：
- 庫：庫依賴關係（Java世界中的JAR和.NET世界中的DLL）的不當管理可能導致問題。例如，典型的Spring Boot應用程序包含140多個庫JAR文件。確保在應用程序中沒有打包不必要的庫。
- 類：闡明應用程序內部對象的所有依賴關係。例如，Controller類依賴於Business Service類，而Service類又依賴於Repository類。花一些時間在代碼檢查期間檢查應用程序內的依賴關係，並確保沒有不正確的依賴關係。
- 服務：如果您在系統中使用微服務，請確認不同服務之間沒有直接依賴關係。
基於庫的依賴關係是一個打包挑戰，後兩個是設計挑戰。本系列的後續文章將更詳細地研究這些依賴地獄的場景，並提供設計模式，以避免產生意料之外的後果。
微服務：細粒度的可重用性
諸如DDD和EIP之類的軟件設計實踐自2003年左右就已經可以使用，然後一些團隊將應用程序開發爲模塊化服務，但是傳統的基礎結構（如Java應用程序的重量級J2EE應用程序服務器和.NET應用程序的IIS）對模塊化部署沒有幫助。 。隨着雲託管的出現，尤其是諸如Heroku和Cloud Foundry之類的PaaS產品的出現，開發人員社區擁有了真正的模塊化部署和可擴展業務應用所需的一切。這引起了微服務的發展。微服務提供了細粒度，可重用的功能和非功能服務的可能性。
微服務在2013年至2014年變得越來越流行。微服務功能強大，可以使較小的團隊擁有特定業務和技術功能的全週期開發。開發人員可以隨時部署或升級代碼，而不會對系統的其他部分（客戶端應用程序或其他服務）產生不利影響。還可以根據需求在單個服務級別上按比例縮放服務。
使用微服務，開發人員從頭開始編寫解決方案或將解決方案打包爲應用程序中的庫，可以直接調用相應的解決方案。微服務方法鼓勵服務提供商和服務使用者之間以合同爲驅動的發展。這樣可以縮短開發時間，並減少團隊之間的依賴性。換句話說，微服務使團隊之間的聯繫更加鬆散，並加速瞭解決方案的開發，這對於組織，尤其是業務初創公司而言至關重要。微服務還有助於在業務流程和域之間建立明確的界限（例如，客戶，訂單，庫存）。它們可以在組織中稱爲“有界上下文”的垂直模塊內獨立開發。這種演進還加快了其他良好實踐（如DevOps）的演進，並在組織級別提供了敏捷性和更快的上市時間。每個開發團隊將在其域中擁有一個或多個微服務，並負責設計，編碼，部署到生產以及生產後支持和維護的整個過程。
但是，類似於以前的體系結構模型，微服務方法遇到了自己的問題：自下而上未被設計爲微服務的傳統應用程序開始被蠶食，試圖迫使它們進入微服務體系結構，從而導致了被稱爲整體式地獄的反模式。其他嘗試試圖將單片應用程序人爲地拆分爲多個微服務，即使這些最終的微服務在功能上不是孤立的，仍然嚴重依賴於從同一單片應用程序中分解出來的其他微服務。這是稱爲微石的反圖案。值得注意的是，整體和微服務是兩種不同的模式，後者並不總是可以替代前者。如果我們不小心的話，最終可能會創建緊密耦合，混雜的微服務。正確的選擇取決於應用程序功能的業務和可伸縮性要求。
微服務爆炸的另一個不希望出現的副作用是所謂的“死亡之星”反模式。在服務交互和服務到服務的安全性（身份驗證和授權）方面，如果沒有治理模型，微服務的泛濫通常會導致任何服務都可以隨意調用任何其他服務的情況。監視不同的客戶端應用程序正在使用多少服務而又不協調這些服務調用也成爲一個挑戰。下圖顯示了像Netflix和Twitter這樣的組織如何陷入這種噩夢，並且不得不想出新的模式來應對“死亡之星的死亡”問題。
儘管上圖中所示的示例看起來像只發生在巨人身上的極端情況，但不要低估了雲反模式的指數破壞力。業界必須學習如何操作比世界任何時候都大得多的武器。富蘭克林·羅斯福說：“強大的權力涉及重大的責任。”諸如服務網格，邊車，服務編排和容器之類的新興架構模式可以有效地防禦基於雲的世界中的瀆職行爲。組織應該瞭解這些模式，並儘早推動採用。
快速瞭解雲優先設計模式
服務網（Service mesh）
隨着雲平臺的出現，特別是像Kubernetes這樣的容器編排技術，服務網格已經引起了人們的關注。服務網格是應用程序服務之間的橋樑，可添加其他功能，例如流量控制，服務發現，負載平衡，彈性，可觀察性，安全性等。它允許應用程序從應用程序級庫中卸載這些功能，並允許開發人員專注於業務邏輯。諸如Istio之類的某些服務網格技術還支持諸如混沌注入之類的功能，以便開發人員可以測試其應用程序及其潛在的數十種相互依賴的微服務的彈性和健壯性。服務網格非常適合放在平臺即服務（PaaS）和容器即服務（CaaS）之上，並通過上述通用平臺服務增強了雲採用體驗。以後的文章將深入探討基於服務網格的體系結構，並討論特定的用例，並比較有無服務網格的解決方案。
無服務器架構（Serverless architecture）
在過去的幾年中，另一個備受關注的趨勢是無服務器架構，也稱爲無服務器計算。 Serverless比PaaS模型更進一步，因爲它完全從應用程序開發人員中抽象了服務器基礎結構。在無服務器中，我們將業務服務編寫爲功能並將這些功能部署到雲基礎架構中。無服務器技術的一些示例是Amazon Lambda，Spring Cloud Function，Google Cloud Functions和Microsoft Azure Functions。無服務器模型位於雲託管範圍內的PaaS和SaaS之間，如下圖所示。
與關於單服務與微服務的討論類似的結論中，並非所有解決方案都應實現爲功能。此外，我們不應使用無服務器功能替換所有微服務，就像我們不應替換所有單片應用程序或將其分解爲微服務一樣。僅將諸如用戶身份驗證或客戶通知之類的細粒度的業務和技術功能設計爲無服務器功能。根據我們的應用程序功能和非功能性要求（例如性能和可伸縮性以及事務邊界），我們應該爲每個特定用例選擇適當的整體式，微服務或無服務器模型。通常，我們可能需要在解決方案體系結構中使用所有這三種模式。如果設計不當，無服務器解決方案最終將變成納米片，其中每個功能都與其他功能或微服務緊密結合，並且無法獨立運行。
容器技術（Container technologies）
類似於容器技術的互補趨勢與微服務同時出現，以幫助在微服務器環境中部署服務和應用程序，從而實現業務服務的真正隔離和單個服務的可擴展性。Docker，contained，rkt和Kubernetes等容器技術可以很好地補充微服務的開發。如今，我們不能不提及其中之一-微服務或容器。
整體、微服務與無服務器對比
如前所述，瞭解三種體系結構樣式的優缺點非常重要：整體式應用程序，微服務和無服務器功能。關於整體服務與微服務的書面案例研究詳細描述了避免微服務的一個決定。
| 架構風格 | 什麼時候使用 | 什麼時候不實用 | 例子 |
|---|---|---|---|
| 整體 | 應用程序具有不同的模塊，這些模塊在事務上下文中完全相互依賴。需要所有數據操作的即時一致性。 | 應用程序模塊可以分爲原子業務或技術功能。 | ERP或CRM系統 |
| 微服務 | 應用程序模塊在其運行時生命週期和事務管理中彼此獨立。可以以無狀態方式執行每個模塊中的數據操作。如果模塊之間存在任何依賴關係，它們仍然可以與最終的一致性支持鬆散地結合在一起。注意：有時，團隊會人爲地將相關功能分解爲微服務，並遇到微服務模型的侷限性。 | 如果不嚴格依賴其他模塊，則無法獨立部署和使用應用程序模塊。 | 客戶服務、訂購服務、庫存服務 |
| 無服務器 | 具有完全獨立性和單獨可伸縮性策略的應用程序模塊可以分解爲業務或技術的單個功能。沒有流量時，應用程序將完全關閉。開發團隊不必關心基礎架構。 | 長時間運行的作業，CRUD服務或有狀態服務。 | 認證方式、通知、事件流 |
穩定差距
對於我們而言，務必注意隨着時間的流逝，我們的軟件架構和代碼中可能會出現的反模式。反模式不僅造成技術債務，而且更重要的是，它們可能將主題專家趕出組織。一個組織只能與那些不關心架構偏差或反模式的人一起找到自己。回顧以上簡短的歷史後，讓我們集中討論在匆忙使用微服務時可能會出現的穩定漏洞和反模式。諸如組織中的團隊結構，業務領域以及團隊中的技能等特定因素決定了哪些應用程序應實現爲微服務，哪些應保留爲整體解決方案。但是我們可以考慮選擇將解決方案設計爲微服務的一些一般注意事項。
Eric Evans的著作《域驅動設計（DDD）》改變了我們開發軟件的方式。埃裏克（Eric）提倡從域的角度而不是基於技術的角度看業務需求的想法。該書認爲微服務是聚合模式的派生。但是，許多軟件開發團隊通過嘗試將其所有現有應用程序轉換爲微服務，將微服務設計概念推向了極致。這導致了反模式，例如整體式地獄，微晶石等。以下是架構和開發團隊需要注意的一些反模式：
- 整體地獄：monolithic hell
- 微石：microliths
- 積木塔：Jenga tower
- 科學怪人：logo slide (also known as Frankenstein)
- 方輪：square wheel
- 死亡之星：Death Star
不斷髮展的架構模式
爲了彌補在不同的應用程序託管模型中發現的穩定差距和反模式，業界提出了不斷髮展的體系結構模式和最佳實踐來彌補差距。下表總結了這些體系結構模型，穩定差距和模式
| 託管模式 | 描述 | 穩定差距/反模式 | 模式 |
|---|---|---|---|
| 集中式 | 中央數據存儲和計算模型。客戶終端僅用於數據輸入和數據顯示。 | ||
| 去中心化 | 客戶端/服務器體系結構，其中大多數應用程序邏輯在服務器端處理。基本驗證和某些處理在客戶端上進行。 | 意大利麪條代碼，混亂 | OOP |
| 連接/共享 | Web應用程序通過在Web服務器上承載的表示邏輯（UI），在應用程序服務器上承載的業務邏輯（API）和數據庫服務器中的數據來促進三層體系結構。 | 混亂 | DDD、SOA、企業集成模式 |
| 雲託管 | 雲計算模型改變了託管和擴展應用程序的方式。除了舊的“購買還是構建”選項之外，還爲我們提供了“在雲上託管”的第三個選項。 | 整體地獄，依賴地獄 | 微服務 |
| 微服務 | 細粒度的服務模型，將特定的業務功能封裝到輕量級應用程序（微服務）中，並在業務域之間建立清晰的邊界。 | 整體地獄，微石，死亡之星 | 服務網格，邊車，服務編排 |
下圖展示了所有這些體系結構模型，反模式形式的穩定性差距以及不斷髮展的設計模式和最佳實踐。
歷史告訴我們什麼
下圖列出了體系結構演進的步驟，包括不瞭解新範例中的最佳實踐的初始階段，這會加速技術負擔。隨着行業開發新的設計模式來解決穩定性方面的差距，團隊在其體系結構中採用了新的標準和模式。
IT領導者必須在不斷髮展和優化的技術基礎上提供穩定的業務應用程序的同時，保護其投資免受不斷增長的技術快速變革的影響。全球IT主管已經越來越頻繁地處理此問題。他們和我們應該擁抱技術的發展，但不應以支持業務的應用程序持續不穩定的代價爲代價。紀律嚴明的系統架構應該能夠做到這一點。將本系列文章中討論的模式視爲有利於技術快速發展並保護業務應用程序免受波動影響的策略。讓我們在下一篇文章中探討如何做到這一點。
總結
從大型機到最新的雲原生架構，各種託管模型都會影響我們開發，部署和維護業務應用程序的方式。業界每次發現一種新的託管模式時，團隊在獲取架構的全部優勢時都會面臨挑戰。這導致了意想不到的後果，例如體系結構偏差和反模式，導致了巨大的技術負擔。隨着時間的流逝，新的設計模式不斷髮展，以解決新託管模式所帶來的穩定差距。技術債務管理在整個系統以及團隊的健康中發揮着至關重要的作用。不及時處理技術債務的IT領導者有可能造成與軟件相關的損害和組織損害。技術債務可以自給自足併產生更多債務，同時導致不良做法的制度化和排斥頂尖人才。
如果出現這些跡象，請立即停止並進行評估。然後採取堅定的行動。確保您授權團隊解決所有形式的技術債務。本系列的後續文章將研究我的組織在採用微服務架構期間開發的通用服務平臺。我們還將討論該公司如何利用不同的雲原生架構組件，例如容器，PaaS和服務網格。下一篇文章將深入探討團隊應注意的反模式以及應在架構中採用的雲原生設計模式。我們將討論採用企業雲原生服務網格策略的細節，該策略將幫助許多這些功能。最後，我們將分享一些針對體系結構和組織的建議。
原文地址：https://www.infoq.com/articles/cloud-native-architecture-adoption-part1/#idp_register/
歡迎關注公衆號，在這裏會記錄一些反思和行爲的改變
