Cloud Native 101 Video
 |
| 瀚錸科技代理「ForceShield」，採用革命性的「動態應用安全架構」 |
來源：51CTO 作者：物联网智库
隨著虛擬化技術的成熟和分布式架構的普及，用來部署、管理和運行應用的雲平台，被越來越多的提及。IaaS、PaaS和SaaS是雲計算的三種基本服務類型，它們是關注硬體基礎設施的基礎設施即服務、關注軟體和中間件平台的平台即服務，以及關注業務應用的軟體即服務。
在容器技術、可持續交付、編排系統等開源社區的推動下，以及微服務等開發理念的帶動下，應用上雲已經是不可逆轉的趨勢。隨著雲化技術的不斷進展，雲原生的概念也應運而生。
雲原生概念的誕生
雲原生(Cloud Native)的概念，由來自Pivotal的Matt Stine於2013年首次提出，被一直延續使用至今。
這個概念是Matt Stine 根據其多年的架構和咨詢經驗，總結出來的一個思想集合，並得到了社區的不斷完善，內容非常多，包括DevOps、持續交付(Continuous Delivery)、微服務(MicroServices)、敏捷基礎設施(Agile Infrastructure)和12要素(The Twelve-Factor App)等幾大主題，不但包括根據業務能力，對公司進行文化、組織架構的重組與建設，也包括方法論與原則，還有具體的操作工具。
採用基於雲原生的技術和管理方法，可以更好地把業務生於「雲」或遷移到雲平台，從而享受「雲」的高效和持續的服務能力。
這個概念是Matt Stine 根據其多年的架構和咨詢經驗，總結出來的一個思想集合，並得到了社區的不斷完善，內容非常多，包括DevOps、持續交付(Continuous Delivery)、微服務(MicroServices)、敏捷基礎設施(Agile Infrastructure)和12要素(The Twelve-Factor App)等幾大主題，不但包括根據業務能力，對公司進行文化、組織架構的重組與建設，也包括方法論與原則，還有具體的操作工具。
採用基於雲原生的技術和管理方法，可以更好地把業務生於「雲」或遷移到雲平台，從而享受「雲」的高效和持續的服務能力。
The Twelve-Factor App
顧名思義，雲原生是面向「雲」而設計的應用，因此技術部分依賴於傳統雲計算的三層概念，基礎設施即服務(IaaS)、平台即服務(PaaS)和軟體即服務(SaaS)，例如，敏捷的不可變基礎設施交付類似於IaaS，用來提供計算網路儲存等基礎資源，這些資源是可編程且不可變的，直接透過API，可以對外提供服務；有些應用透過PaaS服務，本來就能組合成不同的業務能力，不一定需要從頭開始建設；還有一些軟體只需要「雲」的資源，就能直接運行起來為雲用戶提供服務，即SaaS能力，用戶直接面對的就是原生的應用。
雲原生並不是一個產品
最近討論雲原生應用越來越多。關於雲原生應用，簡單地說，就是大多數傳統的應用，不做任何改動，都是可以在雲平台運行起來，只要雲平台支持這個傳統應用，所運行的電腦架構和操作系統。只不過這種運行模式，僅僅是把虛擬機當物理機一樣使用，不能夠真正利用起來雲平台的能力。
雲並非把原先在物理伺服器上跑的東西，放到虛擬機裡跑，真正的雲化不僅是基礎設施和平台的事情，應用也要做出改變，改變傳統的做法，實現雲化的應用——應用的架構、應用的開發方式、應用部署和維護技術都要做出改變，真正的發揮雲的彈性、動態調度、自動伸縮……一些傳統IT所不具備的能力。
這裡說的「雲化的應用」也就是「雲原生應用」。雲原生架構和雲原生應用所涉及的技術很多，如容器技術、微服務、可持續交付、DevOps等。
這裡說的「雲化的應用」也就是「雲原生應用」。雲原生架構和雲原生應用所涉及的技術很多，如容器技術、微服務、可持續交付、DevOps等。
而雲原生應用最大的特點，就是可以迅速部署新業務。在企業里，提供新的應用程式環境，及部署軟體新版本，通常所需時間以日、周甚至以月計算。這種速度嚴重限制了，軟體發佈所能承受的風險，因為犯錯及改錯，也需要花費同樣的時間成本，競爭優勢就會由此產生。
所以雲原生不是一個產品，而是一套技術體系和一套方法論，而數位化轉型是思想先行，從內到外的整體變革。更確切地說，它是一種文化，更是一種潮流，是雲計算的一個必然導向。意義在於讓雲成為雲化策略成功的基石，而不是障礙。
它可以根據商業能力，對公司進行重組的能力，既包含技術、也包含管理，可以說是一系列雲技術和企業管理方法的集合，透過實踐及與其他工具，相結合更好地幫助用戶，實現數位化轉型。
它可以根據商業能力，對公司進行重組的能力，既包含技術、也包含管理，可以說是一系列雲技術和企業管理方法的集合，透過實踐及與其他工具，相結合更好地幫助用戶，實現數位化轉型。
雲原生計算基金會(CNCF)
CNCF，即雲原生計算基金會，2015年由谷歌牽頭成立，基金會成員目前已有一百多企業與機構，包括亞馬遜、微軟、思科等巨頭。
目前CNCF所托管的應用已達14個，下圖為其公佈的Cloud Native Landscape，給出了雲原生生態的參考體系。
Cloud Native Landscape新版
CNCF(雲原生計算基金會)認為雲原生系統需包含的屬性：
容器化封裝：以容器為基礎，提高整體開發水平，形成代碼和組件重用，簡化雲原生應用程式的維護。在容器中運行應用程式和進程，並作為應用程式部署的獨立單元，實現高水平資源隔離。
自動化管理：統一調度和管理中心，從根本上提高系統和資源利用率，同時降低運維成本。
面向微服務：通過松耦合方式，提升應用程式的整體敏捷性和可維護性。
正因為如此，你可以專注於創新，解決業務問題，而不是把時間花在「靜態、不靈活的傳統架構」存在的許多技術問題。
雲原生的四要素：持續交付、DevOps、微服務、容器
從雲原生的概念中，我們總是能看到持續交付、DevOps、微服務、容器等技術的出現，那麼它們到底是什麼，這裡引用Pivotal台灣雲計算資深架構師的部分觀點，為大家逐一揭開他們的神秘面紗!
01 持續交付——縮小開發者認知，靈活開發方向
首先是持續交付，什麼樣的時候，客戶要求持續交付？敏捷開發要求持續交付，因為敏捷開發要求隨時，有一個版本可以上到大群環境，所以要持續交付。
而換句話說，持續交付就是不誤時開發。舉一個例子，有些公司非常喜歡談需求，談很久，可是開發只剩1/3時間就開發完成，然後交付，再上線營運。
這就會碰到一個問題，就是你開始談需求，到最後交付產品的時間，短則三月，長則半年，這中間市場已經變化了，需求也隨之變化了。
這就會碰到一個問題，就是你開始談需求，到最後交付產品的時間，短則三月，長則半年，這中間市場已經變化了，需求也隨之變化了。
因此市場上出現了新的想法，即是不是能夠小步快跑，把交付的週期縮短一點，我可以實現快速交付，每次交付都可以重新確認方向，這樣盡量避免與未來期待的落差。
用小步快跑的方式，打破瀑布式開發流程
那麼問題來了，持續交付對於開發的人談的需求、開發的方式有改變，那它對於開發有影響嗎？
如果說公司的開發團隊一天可以交付五次，那研發團隊要幫忙部署一次嗎？
現在公司大部分部署，都是研發團隊幫忙部署應用的，研發團隊部署五次，要改版五次就需要部署一次，這是無法實現的。
而且每次部署的時候都要面對停機，而實際公司的應用，經不起一天停機五次部署，在互聯網的思維之下，零宕機時間已經是現在企業的基本要求。
於是「藍綠部署」的概念營運而生。即在一個環境裡面，第一版還在線上服務，第二版先做封測，封測完成後，讓外面的流量進來一些，看log是不是開發人員要的，確認後再把全部的流量導到新的版本上。
圖：藍綠(Blue-Green) 部署
但「藍綠部署」，在系統過多過複雜的情況下，在傳統架構上實現非常困難，所以企業要做到zero down time的持續交付，就需要有良好的平台與工具協助。因此，持續交付的優勢在於，它可以縮小開發者認知，重新確認開發方向。
02 微服務——內聚更強，更加敏捷
第二部分是微服務。微服務是什麼？有客戶表示，提供商出產品，客戶把應用全部放上去，結果就是一個微服務。這種認知是錯誤的，因為微服務是一個架構的改變。那麼微服務是怎麼做的呢?它所面臨的最大挑戰是什麼?
是切割。那麼如何切割呢？其實這件事情早在1968年，康威就提出了——康威定律，系統的服務劃分，應該是根據組織架構的功能來劃分。1968年康威就提出了這個想法，我認為拿來做微服務的切割非常適用。
Going Agile - Breaking the monolith
Conway's Law and Microservices
這樣按照組織架構劃分的優勢在於：
1.內聚更強，所有遵循同一種業務准則的人內聚在一起，就容易解決問題。
2.服務解耦，變更容易，更加敏捷。當做到解耦合的時候，要變更就容易。所以微服務應該是切分成這個樣子，由上而下來切，根據Function來切。
另外一個劃分微服務的技巧，可以運用領域驅動設計(Domain Driven Design)的理論，而領域驅動設計，亦可算是面向物件的一種設計思維；聚合可以讓微服務劃分更有依據，也讓未來的系統變更具有彈性。
值得一提的是領域驅動設計，也提供微服務中的事物問題。因為過去巨石應用，進行兩個報數的階段，相當容易也常見，但在微服務架構中，如何在分散的服務中進行事物，就顯得相當困難。利用領域驅動設計的Event Souring進行設計，是目前最好的解決辦法。
值得一提的是領域驅動設計，也提供微服務中的事物問題。因為過去巨石應用，進行兩個報數的階段，相當容易也常見，但在微服務架構中，如何在分散的服務中進行事物，就顯得相當困難。利用領域驅動設計的Event Souring進行設計，是目前最好的解決辦法。
那麼在什麼情況下需要微服務？我認為有三個標準：
1.有HA(High Available)的需求需要微服務。
2.有性能調校的需求(例如：圖片的呈現或者搜尋)需要微服務。
3.經常變更的需要微服務。
實際上，微服務需要關注的源代碼範圍比較小，使得各個服務解耦、變更容易，內聚更強，因為都會集中在服務裡。另外，它更容易單獨改版，因為微服務之間，是用RESTful間接起來的，用RESTful只要API的介面不改，原則上則不會錯，也更敏捷。
但微服務也會留下一些問題，例如App團隊如何分工？環境怎麼配合？如何實現自動化部署？
03容器技術——使資源調度、微服務更容易
再來看看容器。在機器上運行的容器，只是主機操作系統上的一個進程，與任何其他進程無異。那麼，為什麼容器如此受歡迎呢？原因在於這個進程被隔離和限制的方式。這種方式很特殊，可簡化開發和運維。
其實1979年就有容器技術，很多人會以為說Docker是不是等於容器，其實Docker不等於容器。容器的歷史可追溯到Linux操作系統。容器利用了Linux的內核功能。Linux中容器的核心概念(cgroup、namespaces和filesystems)在獨立的區域運行。容器的神奇之處在於將這些技術融為一體，以實現最大的便利性。
VMware之前的技術專家，在2011年發展出一個技術，把這個技術貢獻出來，成立了一個Cloud Foundry基金會。Docker在2013年才開始有，而且它第一版是用SLC的技術去做的。後來陸續一路成長，使得為服務的實現更容易了。
從 Infra 角度來看技術演進
從上面這個表中可以看出，從左邊開始，IaaS，虛擬化技術有了之後，剛剛提到的所謂第三代平台，這四個區塊開發人員，交付的內容不一樣。所有的IaaS、CaaS、PaaS、FaaS一路的變化演進，對於客戶的負擔越到後面越小，而對於開發人員的想象力則愈發抽象。
大家一定會遇到下列這些計算，一個是所謂的單體應用，或者翻譯成巨石應用。此外，你們一定會有一些批次的管理，另外就是所謂的數據庫的部分，開始可能會有容器技術，像K8S、Dock。
Docker是軟體行業，最受歡迎的軟體容器項目之一。思科、谷歌和IBM等公司，在其基礎設施和產品中，使用Docker容器。
Kubernetes，是軟體容器領域的另一個值得關注的項目。Kubernetes是一個允許自動化部署、管理和伸縮容器的工具。為了便於管理其容器，谷歌建立了Kubernetes。它提供了一些強大的功能，例如容器之間的負載均衡，重啓失敗的容器，以及編排容器使用的儲存。
容器生態圖 /作者：Jimmy Song
容器為雲原生應用程式，增加了更多優勢。使用容器，你可以將微服務及其所需的所有配置、依賴關係和環境變量，移動到全新的伺服器節點上，而無需重新配置環境，這樣就實現了強大的可移植性。
04DevOps——以終為始，運維合一
最後讓我們走向DevOps，它不是一種工具，DevOps其實要談的是運維合一。
DevOps如果從字面上來理解只是Dev(開發人員)+Ops(運維人員)，實際上，它是一組過程、方法與系統的統稱，其概念從2009年首次提出發展到現在，內容也非常豐富，有理論也有實踐，包括組織文化、自動化、精益、反饋和分享等不同方面。
首先，組織架構、企業文化與理念等，需要自上而下設計，用於促進開發部門、運維部門和品質保障部門之間的溝通、協作與整合，簡單而言組織形式類似於系統分層設計。
其次，自動化是指所有的操作都不需要人工參與，全部依賴系統自動完成，比如上述的持續交付過程，必須自動化才有可能完成快速迭代。
再次，DevOps的出現是由於軟體行業，日益清晰地認識到，為了按時交付軟體產品和服務，開發部門和運維部門必須緊密合作。
再次，DevOps的出現是由於軟體行業，日益清晰地認識到，為了按時交付軟體產品和服務，開發部門和運維部門必須緊密合作。
總之，DevOps強調的是高效組織團隊之間，如何通過自動化的工具協作和溝通，來完成軟體的生命週期管理，從而更快、更頻繁地交付更穩定的軟體。
在內部溝通上，你可以想像DevOps是一個敏捷思維，是一個溝通的文化。當營運和研發有良好的溝通效率，才可以有更大的生產力。如果你的自動化程度夠高，可以自主可控，工作負擔降低，DevOps能夠帶來更好的工作文化、更高的工作效率。
在內部溝通上，你可以想像DevOps是一個敏捷思維，是一個溝通的文化。當營運和研發有良好的溝通效率，才可以有更大的生產力。如果你的自動化程度夠高，可以自主可控，工作負擔降低，DevOps能夠帶來更好的工作文化、更高的工作效率。
總結
綜上所述，雲原生的DevOps、平台、持續交付、微服務都是雲原生不可或缺的一部分，需要以全局地眼光看待問題，脫離任何一個元素，對於企業來說都是「管中窺豹」、「一葉障目」，只有加以整合才能見到雲原生的全局風貌。
面對業態各異的業務上雲，以及碎片化的物聯網解決方案部署，利用雲原生思維和模式，構建基於雲原生的物聯網平台，以及解決方案，勢必將加速企業，甚至整個社會的數位化轉型。
0 comments:
張貼留言