引語：雲原生是一個不斷豐富的理念和技術體系，它在基礎架構、應用程式和管理上都将深刻的影響和改變企業雲的未來！
共享、靈活和創新是網際網路時代下企業資訊化建設最大的轉變。近幾年企業雲的發展也進入到了一個縱深階段，是兼顧新老不同應用還是基于新的架構平台重建下一代應用，是我們必須要思考的課題。
對于大部分的企業來說，IT是有曆史包袱的。因為原來的IT應用部署模式，都是豎井式的，不同的應用都由不同的軟體開發商提供的，系統之間還有網絡安全隔離，各系統間還有協同關系，網絡、應用拓撲很複雜。企業IT上雲是一個系統性的工程，原來的應用可能還需要結合雲上提供的虛拟機、網絡和存儲的特點進行必要的改造，不能簡單的“原來實體機什麼配置，虛拟機什麼配置，原來應用什麼架構，上雲後什麼架構”的遷移方法，這其實完全失去了“上雲”的優勢，要防止為了上雲而雲的做法。
雲原生是一種建構和運作應用程式的方法，它充分利用了雲計算傳遞模型的優勢，更天然的貼合雲的特點。雲原生（Cloud Native），是Matt Stine提出的一個概念，它是一個思想的集合，包括DevOps、持續傳遞（Continuous Delivery）、微服務（MicroServices）、靈活基礎設施（Agile Infrastructure）、康威定律（Conways Law）等，以及根據商業能力對公司進行重組。Cloud Native既包含技術（微服務，靈活基礎設施），也包含管理（DevOps，持續傳遞，康威定律，重組等）。Cloud Native也可以說是一系列Cloud技術、企業管理方法的集合。
雲原生是一個不斷豐富的理念和技術體系，它在基礎架構、應用程式和管理上都将深刻的影響和改變企業雲的未來！
1、 基礎架構的變革與雲原生
基礎架構即服務（IaaS）是雲供應商的衆多産品之一。它提供了原始的計算、網絡和存儲，客戶可以根據需要消費。它還包括支援服務，如身份和通路管理（IAM）、供應和庫存系統。
企業傳統的資料中心基礎架構具有這樣幾個特點：1、評估難。采購規模無依據，伺服器和存儲過量采購，硬體折舊快，很容易在降低IT成本和滿足業務需求之間産生沖突關系。2、部署慢。部署需要數周時間，設計複雜、範圍大、人員協調難，遲滞于業務的快速變化，靈活性差。3、管理成本高。不具備自恢複能力，管理成本高，難以應對業務規模增大帶來的複雜管理需求，系統彈性差。4、可維護性差。缺乏端對端的可見性，出問題往往定位不清楚，互相扯皮，導緻營運管理成本随業務規模呈幾何級增長，可維護性差。
雲的特點就是彈性、靈活、分布式、可擴充、自管理自恢複，符合雲的特點的基礎架構就可以稱為雲原生基礎架構。雲原生基礎架構需要在提供自主應用程式管理的IaaS之上建立一個平台。該平台建立在動态建立的基礎架構之上，以抽象出各個服務并促進動态資源配置設定排程和擴充。雲原生的基礎架構需要在以下幾個方面做出變革：1、科學評估，按需采購。改變采購模式，無需一次性大規模采購，抓取平台監控資料科學評估，按需采購及時補充；不依賴于特定的底層虛拟化（esxi/kvm/xen/hyper-v）,解耦虛拟化平台，按需使用。2、部署快速。從上機架開始30分鐘内即可傳遞使用，部署快速，這更多的需要軟硬一體化的能力，軟硬體的融合不僅可以降低使用者使用雲計算的複雜度，也大大降低的企業的應用風險。超融合通過對軟硬體一體化的改造，不斷提升産品的性能、密度、成本效益和易用性等，切實讓使用者體驗到什麼叫“開箱即用”，快速部署。3、統一管理。通過軟體統一管理計算、存儲、虛拟化等資源，使運維管理簡單化集約化。4、自管理高可用。全鍊路所有節點可見，分布式架構，線性擴充，無節點數限制，無單點故障，内置同城和異地容災能力。
總結：當軟體功能越來越強大之後，原來必須在硬體層面的支援就可以轉移到軟體上來實施。在基礎架構這一層，技術驅動的結果就是企業使用者越來越沒必要花那麼多錢去搞那麼多昂貴複雜的專業裝置了，軟體定義的基礎架構會越來越流行和重要。
2、雲原生應用程式的建構和部署
一般說來，企業傳統應用向雲環境的遷移往往是一個應用重新部署的過程，而向PaaS或SaaS環境遷移，則要對應用系統進行重新拆分、重新設計架構和重新建構。很多應用系統PaaS化是為了更好的利用容器、微服務等技術和理念，實作彈性和靈活，滿足軟體服務化的需求。
我們看到過去幾年雲平台在不斷地發展，但應用程式在雲平台運作，仍然需要為不同的開發語言安裝相應的運作時環境。雖然自動化運維工具可以降低環境搭建的複雜度，但仍然不能從根本上解決環境的問題。
容器的出現成為軟體開發行業新的分水嶺；容器技術的成熟，也标志技術新紀元的開啟。Docker讓開發工程師可以将他們的應用和依賴封裝到一個可移植的容器中，并且擺脫了環境依賴的問題。通過集裝箱式的封裝，開發和運維都以标準化的方式釋出的應用，異構語言不再是桎梏團隊的枷鎖。
而Kubernetes則統一了容器編排系統，為雲原生應用提供了一站式的服務。Kunernetes的出色表現，為運維工程師的工作模式帶來了颠覆性的改變。他們再也無需像照顧寵物那樣精心的照顧每一台伺服器，而當出問題時，直接将出問題的伺服器換掉即可。業務開發工程師不必再過分關注非功能需求，隻需專注自己的業務領域即可。而中間件開發工程師，則需要開發出健壯的雲原生中間件，用來連接配接業務應用與雲平台。
随着雲化的深入，越來越多的應用被部署在雲端，以往單體應用的劣勢就展現的愈加明顯。因為應用變更的範圍和周期被捆綁在一起，即使隻變更應用的一部分，也需要重新建構并部署整個單體應用，而且無法對需要更多資源的部分子產品單獨擴充，而是必須将整個應用整體擴充。這樣粗粒度的劃分，不利于系統的管理和資源的利用。是以，人們越來越傾向于将應用進行合理的拆分。于是，微服務應運而生。它将一個複雜的單體應用分解成為多個獨立部署的微型服務，每個服務運作在自己的程序中，服務間通信采用輕量級通信機制，如：RESTFul API。服務可以使用不同的開發語言和資料存儲技術。通過微服務的拆分，系統可以更加自由的将所需資源配置設定到所需的應用中，而不是直接擴充整個應用，同時這種擴充在垂直或水準方向都非常靈活簡便。
總結：雲原生應用系統需要與作業系統等基礎設施分離，不應該依賴Linux或Windows等底層平台，或依賴某個雲平台。也就是說，應用從開始就設計為運作在雲中，無論私有雲或公有雲；其次，該應用必須能滿足擴充性需求，垂直擴充（向上和向下）或水準擴充（跨節點伺服器）。
3、雲原生與管理自動化、智能化
當在應用軟體傳遞生命周期當中引入雲原生機制之後，我們可以快速為軟體添加新功能，同時又不影響其在生産環境下的穩定性與安全性水準的能力。衆所周知，我們的應用程式在運作過程中需要基礎設施、中間件以及支援服務的多方配合，而雲原生方案則通過對這些因素的自動化改造實作上述目标。
一套全面的雲原生架構當中包含自動化與編排管理兩類機制，能夠幫助使用者直接獲得相關能力，而無需再将自動化流程作為可定制設計進行編寫。比如K8S其内置的自動化管理、自我修複和自動擴充。換句話來說，這類自動化管理的内置特性使我們得以更輕松地建構出可以自動化方式管理的應用程式。
當然，這些新特性同時也會對軟體的開發方式提出新的要求。開發人員必須利用一整套新的架構實踐組合——例如微服務與容器技術，進而確定應用程式能夠在雲平台之上得到很好的管理，這也是我們在軟體開發提速之外需要認真考量的保障前提。在營運層面也帶來多項助益，具體包括應用程式執行個體可遷移、統一化登入以及通過監控手段保障應用程式及資料流正常運作等等。另外就是DevOps的引入能對産品傳遞、測試、功能開發和維護（包括──曾經罕見但如今已屢見不鮮的──“熱更新檔”）起到意義深遠的影響。在缺乏DevOps能力的組織中，開發與營運之間存在着資訊“鴻溝”──例如營運人員要求更好的可靠性和安全性，開發人員則希望基礎設施響應更快，而業務使用者的需求則是更快地将更多的特性釋出給最終使用者使用。這種資訊鴻溝就是最常出問題的地方，DevOps的出現正是由于軟體行業日益清晰地認識到：為了按時傳遞軟體産品和服務，開發和營運工作必須緊密合作。
要發揮雲原生管理的固有優勢，較為理想的途徑之一就是引入智能化實作自治管理。目前企業在上雲後，大多依靠“以人為本”的方式，憑借大量從業人員的個人能力和經驗、自覺來進行運維工作，這種将勞動密集型服務簡單粗暴的從傳統IT基礎設施轉移到雲平台的方式，隻能是市場體量較小、技術發展程度不高的現實條件下，采取的過渡方案。引入智能化，實作服務自動發現、告警自動檢測、故障自治處理，改變這種傳統的服務方式下的效率低下、人力成本過高、手工運維過程中的誤操作，也會大大提高企業雲的可用性，日益擴大企業級的雲服務市場。