雲原生時代下微服務架構演進之路 (1)

透過本篇文章您可以瞭解到以下內容：

雲原生（Cloud Native）歷史簡介與定義
關於微服務架構設計的思考

雲原生（Cloud Native）歷史簡介與定義

雲原生（Cloud Native）這個詞相信大家再熟悉不過了，談到這個詞不得不先從一家公司說起，那就是Pivotal（目前已經回歸到了VMware）。讓我們把時間倒回到2013年，回過頭來看一看雲原生的發展歷史。

2013年Pivotal的Matt Stine首次提出了雲原生（Cloud Native）的概念。

2015年Pivotal的Matt Stine在他的《Migrating to Cloud Native Application Architectures – 遷移到雲原生應用架構》書中對雲原生應用架構進行了深入的討論。此書開篇從四大方面談到了為什麼要建構雲原生應用架構：

此外在說明了為什麼建構雲原生應用架構的原因之後，進一步討論了如何定義雲原生應用架構：

（符合12因素應用、面向微服務架構、自服務敏捷架構、基於API的協作、抗脆弱性）

在此五大要素中的《符合12因素應用》一項又包括如下內容：

代碼庫、依賴關係、配置、後備服務、建構、發佈、運行、進程、埠綁定、併發性、可處置性、開發/生產奇偶校驗、日誌、管理進程

2015年Google作為發起者成立了雲原生運算基金會（CNCF），隨著雲運算不斷的發展，雲原生的定義也不斷的進行完善，到目前為止，讓我們來看下CNCF對於雲原生的定義（部分截取）

雲原生技術使組織能夠在現代動態環境（如公有雲、私有雲和混合雲）中建構和運行可擴展的應用程式。容器、服務網格、微服務、不可變基礎結構和聲明式 API 就是這種方法的例證。

這些技術可實現具有彈性、可管理和可觀察性的鬆耦合系統。結合強大的自動化功能，它們使工程師能夠以最少的工作量頻繁且可預測地進行高影響的更改。

雲原生技術有利於各組織在公有雲、私有雲和混合雲等新型動態環境中，和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。

這些技術能夠建構容錯性好、易於管理和便於觀察的鬆耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。

2017年Matt Stine對雲原生架構進行了進一步說明，總體來說概括為六個方面：

2019年Pivotal回歸到了VMware，關於雲原生的定義又給出了進一步的說明，同時也包括雲原生架構的原則。

詳細資訊可參閱VMware官網：https://tanzu.vmware.com/cloud-native

以上就是關於雲原生（Cloud Native）的歷史簡介。透過上面的介紹不難看出，無論是Pivotal（VMware）最早提出的關於雲原生的五個關鍵詞（符合12因素應用、面向微服務架構、自服務敏捷架構、基於API的協作、抗脆弱性）還是CNCF對雲原生的定義，都包含了一個詞，那就是微服務架構。

關於微服務架構設計的思考

微服務這個詞相信大家早已經耳熟能詳，談到微服務架構就不得不先說到另外一個詞語它就是 Monolithic architecture（單體式架構）。

Monolithic architecture是軟體程式的傳統模型，它被建構為一個獨立於其他應用程式的統一單元。它具有一個將所有業務關注點耦合在一起的代碼庫。接下來讓我們來看看這種技術架構的優勢：

易於部署：一個可執行的檔或者目錄使得部署更加容易。
簡化部分測試：由於Monolithic architecture是集中的單元，因此像End-To-End這種類型的測試相比分散式系統來說會更加快速，方便。
易於調試：所有的代碼位於同一個專案工程內部，很容易跟蹤請求流程並找到問題所在。
應用早期階段成本較低：所有的代碼位於同一個專案工程內部，打包在一個部署單元中，基礎設施成本和開發成本都沒有而外的費用。

正是由於上述的優勢，Monolithic architecture通常會用於項目開發的早期階段。但是隨著時間的推移，業務功能需求不斷的增加，專案工程逐漸變大，一些弊端也逐步顯現出來：

緩慢的開發速度：隨著業務功能不斷的增加，單體應用的規模也會越來越大，隨之而來的是使得開發越來越複雜和緩慢
比較弱的擴展性：因為所有代碼位於同一工程內部，無法針對特定的業務功能模組進行獨立擴展，除非將整個應用再次重新部署
基礎設施的成本增加：在出現性能問題的情況下，您需要擴展整個服務，而不是具體某一功能，這樣會帶來額外的成本開銷
測試變得越來越困難：即使是微小的改動，也要對整個工程進行回歸測試
可靠性降低：如果任何模組出現不可預見的錯誤，都可能會影響整個應用程式
在採用新技術方面存在障礙：由於框架和語言的改變可能對整個應用程式產生影響，因此這種改變無論是在時間成本還是經濟成本上都是非常昂貴的

面對上面描述的問題，有一個想法應運而生，那就是我們是否可以將這種Monolithic architecture根據業務屬性拆分成若干個互相連接的服務而不是建構單一的應用程式。這些服務有著自己的業務邏輯（對應獨立的代碼庫）和數據。這些服務公開REST、RPC或者是基於Message的API用於互相通信。從而透過這種轉變來解決上述所說的弊端。

答案是肯定的，同時也可以理解為是一種技術架構的演進，即從Monolithic architecture到Microservices architecture。

這時候微服務架構終於登場了，但是此時相信大家也會有以下一些疑問：

微服務架構的由來、歷史是怎樣的？
微服務架構帶來的好處到底有哪些？以及相比傳統單體應用的優勢又有哪些？
怎樣把單體應用進行拆分並建構微服務架構？以及這個拆分的原則又是什麼？

在下期的文章中會繼續和大家進行交流分享，敬請期待！如您有任何建議，歡迎隨時聯繫我們！

參考連結：

作者簡介

李剛，VMware 大中華區應用現代化部門高級系統架構師，資深企業級軟體開發和軟體系統架構師。 Spring Cloud開源社區項目貢獻者、Netflix開源社區貢獻者。近幾年，參與並主導了許多大型企業客戶的應用現代化數位轉型專案，涉及物流、製造、金融等諸多領域。特別對微服務實現方法、現代化應用架構設計、雲原生實施落地、開源軟體技術等方面有著豐富經驗。

雲原生時代下微服務架構演進之路 (1)

Comments