雲原生基礎架構是通向雲原生時代的基石，對於很多架構師來說，上雲之後，架構為什麼成為了雲原生架構而不是傳統的架構，兩者有何區別？雲原生基礎架構是如何演進的？本文進行了全面梳理。
什麼不是雲原生基礎架構？
雲原生被談的很多了，導致概念很亂。有人把雲原生基礎架構和公有云、容器、容器編排系統等劃等號，之所以出現這種情況，原因是雲原生架構並沒有一個統一的概念。
為了更好的理解雲原生系統，這裡先做一些排除。
首先，雲原生並不等於公有云。雲原生基礎架構不僅僅是在公有云上運行基礎架構，這是因為僅僅從雲服務商那裡租用服務器時長，並不會使你的基礎架構雲原生化，管理IaaS和運行物理數據中心本質上沒區別。
其次，雲原生基礎架構不等於在容器中運行應用程序。當Netflix率先推出雲原生基礎架構時，幾乎所有的應用程序都是用虛擬機鏡像部署，而不是容器。打包應用程序的方式並不意味著將擁有自治系統的可擴展性和優勢。即使應用程序是通過持續集成和持續交付流水線自動構建和部署的，也並不意味著可以從補充API驅動部署的基礎架構中受益。
第三，雲原生基礎架構不意味著只運行一個容器編排器就是雲原生。容器編排器提供了雲原生基礎架構所需的許多平臺功能，但並未按預期方式使用這些功能，這意味著應用程序將被動態調度為在一組服務器上運行。這是非常好的起步，但並不是終點，還有很多工作要做。
第四，雲原生不是關於微服務或基礎架構即代碼。微服務可以在較小的不同功能上實現更快的開發週期，但是單塊應用程序可以具有相同的特性，使它們能夠通過軟件有效管理，並且還可以從雲原生基礎架構中獲益。
這是當前的主要幾個認知誤區。當然，如果用排除法，不可能將當前的認知一一列舉。從熱門的詞彙看，容器、容器編排器、微服務……如果回到《理解了雲原生，才能正確迎接雲時代的到來》一文中，會發現當時講過它們都是雲原生的元素，但都不能和雲原生基礎架構劃等號。
什麼是雲原生基礎架構？
要回答這個問題，得先從基礎架構說起。最早談的基礎架構，是服務器，後來有了虛擬化，再到IaaS、PaaS，基礎架構的演變可以說伴隨著時代的變遷。這其中基礎架構的演進路線是越來越靈活、低成本、維護簡便、易獲取。應該說，雲原生基礎架構還是在按這條路線繼續演進。
那究竟什麼是雲原生基礎架構？
核心定義
其實，底層資源如計算、存儲、網絡沒有太大的改變，核心在於資源的調用、使用方式。如果給雲原生基礎架構關聯幾個關鍵詞，有三個：由API控制，由軟件管理，目標是運行程序。這其中透露的最核心的信息，為了業務，不用過多人為干預的基礎架構。
之所以強調業務本身，是因為基礎架構的不同是由上層應用決定的。而運行雲原生應用程序和傳統應用程序所需的基礎架構最大的不同在於，原本許多本屬於基礎架構的職責已經轉移到了應用程序。
過去及現在的基礎架構負責的是整體資源管理、動態協調、服務發現等，與業務之間的關聯並不緊密。換句話說，基礎架構管理與應用管理是脫節的，未來二者的管理將是一體的，應用程序自己會完成原本需要大量人工干預的環節。當前所說的“解耦”，可以適用於此。不僅僅指資源和應用程序之間的解耦，也指資源之間的解耦、API和應用之間的解耦。每一個組件（模塊、資源）都是單獨成為服務可被發現可被調用的，唯一的就是要看這些組件的定義和顆粒度的問題。
要彌合應用與基礎架構之間的鴻溝，需要一箇中間平臺層，它能夠通過API調用，能夠自治。
這裡強調一下自治，它和自動化不能劃等號。自動化是人類輸入的一個完整的業務流程，一個流程只能做一件事。而自治不需要人類做出決定，它仍然使用自動化，但只有當系統不能自動確定正確要做的事情時才應該通知人。自治比自動化多了智能化。
總的來看，雲原生基礎架構一個較為通俗的描述，應用可以通過平臺層自動完成資源調用、協調，無需人工干預，所有的資源都是可以隨時拉起，隨時釋放，同時以API的方式提供彈性、按需的計算、存儲能力。
如果這種解釋令人費解，那麼，我們可以這麼比喻，只要符合“杯子”的概念都是“杯子”，但是製作流程和工藝、材質有本質的不同。而大體上，市面上有默認的幾種模式，這也就形成了通用的標準。
所以，雲原生基礎架構也沒有業內“放之四海而皆準”的標準，它本身也在隨著技術的演變而在演變中，只要符合“靈活、低成本、易維護”等特點，就是雲原生。我們不必拘泥於概念，而是要不斷往前看，為什麼要採用“雲原生”，為用戶帶來的好處是什麼？
這才是核心。
能帶來什麼好處？
雲原生基礎架構帶來最大的變革在於API機制。API機制允許用戶從標準化基礎架構即代碼中獲益，並增加了隨著時間的推移版本化和更改表述的能力。
具體而言，實現了雲原生基礎架構後，技術人員部署服務器、管理服務器模板、更新服務器和定義基礎設施的模式都是通過代碼來完成的，並且是自動化的，不需要通過手工安裝或克隆的方式來管理服務器資源，運維人員和開發人員一起以資源配置的應用代碼為中心，不再是一臺臺機器。
值得一提的是，基礎設施的包含範圍也會很廣泛，不僅包括機器，還包括不同的機櫃或交換機、同城多機房、異地多機房等。
換句話說，只需要調整相應的API就能實現資源使用方式的調整，整個過程無需關心底層基礎架構的變化。雲原生基礎架構的理想狀態是，它非常容易被忽略，它簡單、自動化、可自服務，也就是沒有基礎架構。
因此好處顯而易見，對運維人員是一種解放，對企業而言，能將更多精力投入業務開發、運營中，公司整體運營效率將大幅提升。當前，這種模式已經被證明了可以擴展到巨大數據的基礎架構和應用程序的。
雲原生基礎架構實現
弄清楚了雲原生基礎架構的本質，這部分簡單介紹下雲原生基礎架構的實現，主要分三部分：設計、開發和測試。
至於具體的方法實踐倒是其次，這部分最重要的是轉變觀念。原本傳統的基礎架構運維人員要成為基礎架構軟件工程師，只有適應了身份的轉變，才能更好地到達雲原生基礎架構的彼岸。
作為一名基礎架構工程師，不僅要掌握設計、管理和運維基礎架構的基本原則，還要把專業知識應用在構建強健的應用程序中，這些應用程序代表了將要管理和改變的基礎架構。
迴歸技術關鍵，最重要的一個環節就是API，設計、開發，乃至最後的應用，API關乎成敗。因為基礎架構將需要隨著時間的推移而變化或者變異，這是雲原生環境的本質。當運維承擔改變基礎架構的任務時，API的真實價值就體現出來了。
有關API的設計，及更多技術細節這裡不做太多討論，有興趣的朋友可以找相關書籍查閱，每本書的思想、方法都可能不一致，要學會兼容幷蓄，取長補短。
總結全文，雲原生基礎架構是基礎架構的自然而可能預期的演變。實現雲原生基礎架構是比較難的，如果你認為雲原生基礎架構是你可以購買的產品，或者可以運行服務的供應商，顯然要失望了，就目前階段而言，只有極少數產品實現了雲原生，比如今年，各大雲服務商都在推的雲原生數據庫算是其中的典型代表。實現雲原生這條路還很長，要慢慢學，慢慢深入。
閱讀更多 阿里云云棲號 的文章
