【51CTO.com原創稿件】共享、敏捷和創新是互聯網時代下企業信息化建設較大的轉變。近幾年企業云的發展也進入到了一個縱深階段，是兼顧新老不同應用還是基于新的架構平臺重建下一代應用，是我們必須要思考的課題。

對于大部分的企業來說，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基礎設施轉移到云平臺的方式，只能是市場體量較小、技術發展程度不高的現實條件下，采取的過渡方案。引入智能化，實現服務自動發現、告警自動檢測、故障自治處理，改變這種傳統的服務方式下的效率低下、人力成本過高、手工運維過程中的誤操作，也會大大提高企業云的可用性，日益擴大企業級的云服務市場。

總的來說，Cloud Native云原生是更好的工具、自我修復系統和自動化系統的集合，可以讓應用和基礎設施的部署和故障修復更加快速和敏捷，極大的降低企業在云計算方面的部署成本，加快企業云的變革。

展望：企業云的未來

在多云時代，企業的數據和應用不僅分布在企業私有云和公有云上，也分布在遠程辦公室或分公司以及邊緣計算的環境中。如今的企業希望實現不同云之間的應用移動性，同時保持對硬件、管理程序或云的開放性。因此建立一個以業務為中心的運作方式，構建云原生的應用程序和基礎設施是一個必然的趨勢。實現對業務的快速部署以及彈性動態調整，而且整個架構是以非常簡單的方式來打造的，而這就是以應用驅動的企業云原生，隱隱地卻又注定將帶動一股潮流。

我們相信云原生不僅僅是一種構建和運行應用程序的新方法，而是一種更有生命力的文化。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】