解密雲原生---看企業雲的未來
【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】
【責任編輯：鳶瑋 TEL：（010）68476606】