雲原生雲伺服器

① 從雲計算到雲原生：從概念到落地

雲計算最近幾年已經火得不行， 雲原生 （Cloud Native）這個概念又來了，如果上雲不「原生」，那就等於白上雲。究竟什麼是雲原生？雲原生有何優勢？怎麼從「不原生」一步一步做到雲原生？本文將給出切實可行的雲原生落地指南。

我們先從雲計算說起 。在雲計算普及之前，一個應用想要發布到互聯網，就需要企業自己先買幾台伺服器，找一個IDC機房，租幾個機架，把伺服器放進去。接下來就是裝Linux系統，部署應用。我們就假定用Java寫了Web應用，怎麼部署上去呢？先配置Tomcat伺服器，在把編譯好的war包上傳到伺服器，有用FTP的，安全意識高一點的會選SCP，然後配置Nginx、MySQL這些服務，最後一通調試，把應用跑起來，就算齊活。

這種物理機配合自搭網路環境、自搭Linux、自配環境的方式，有很多缺點，但最主要的問題有這么幾個：

解決方案是上雲 。上雲不能解決所有問題，但部分解決了前兩個問題：

但是如果僅僅滿足上雲，把物理機換成虛擬機，把物理網換成虛擬專用網（VPC），是遠遠不夠的。這些是計算資源和網路資源層面的簡化。應用方面，如果延續舊的一套開發、測試、部署流程，做不到快速迭代。

要做到快速迭代，敏捷開發，就需要DevOps，即開發運維由一個團隊負責，開發階段，就要把部署、運維的工作考慮進去，而不是發布一個war包或者jar包後扔給運維不管了。

重開發、輕部署，直接後果就是缺少自動化發布流程。想要把部署規范化，就需要整體考慮一系列問題。

還是以Java應用為例，如果是手動部署，那麼就上傳war包到伺服器，覆蓋原有的版本，重啟Tomcat，再測試。如果發現有嚴重問題要回滾怎麼辦？把老版本再傳一遍，然後重啟Tomcat。

手動部署，每次部署都是一次生死考驗，所以最好不要安排在半夜，以免手抖敲錯了命令，本來中斷10分鍾的服務，變成了災備恢復，中斷3天。

稍微靠譜一點的是寫腳本部署，但各家寫出來的腳本都有各家特色，不通用，不易維護，所以更好的方式是用成熟的部署方案，比如Ansible，把腳本標准化，比如做成藍綠發布，把伺服器分組，比如A、B兩組，先把流量切到B組，升級A組伺服器，有問題就回滾，沒問題了，再把流量切到A組，升級B組伺服器，最後，恢復正常流量，整個部署完成。

但是回滾這個事情，遠沒有那麼簡單。做過開發的同學都知道，升級新版本，一般要加配置，改配置，如果回滾到舊版本，忘了把配置改回去，那舊版本可能也不能正常工作。

上雲，除了物理變虛擬，簡化運維外，最重要的特點——彈性計算，一定要充分利用。

理論指導實踐，實踐完善理論。如果我們分析大多數基於互聯網的應用，可以看到，一個應用，通常用到的資源如下：

上雲後，雲服務商通常都提供託管的資料庫，以及大規模存儲系統（S3），可解決存儲資源問題。通過雲服務商提供的負載均衡（Load Balancer），也無需自行部署Nginx等網關，免去了運維的問題。各種標準的業務組件如Redis、Kafka等，均可直接租用雲服務商提供的資源。

我們重點討論計算資源，也就是雲上的虛擬機資源。對於應用來說，可以設計成有狀態和無狀態兩種。一個應用在一台虛擬機內跑著，如果有本地文件的修改，它就是有狀態的。有狀態的應用既不利於擴展，也不利於部署。反過來，如果一個應用在運行期數據總是存在資料庫或者緩存集群，本地文件無任何修改，它就是無狀態的。

無狀態的應用對應的虛擬機實際上就是不變的計算資源。這里的「不變」非常重要，它是指，一台虛擬機通過一個固定的鏡像（預先內置好必要的支持環境，如JRE等）啟動後，部署一個應用（對應一個war包或者jar包），該虛擬機狀態就不再變化了，直接運行到銷毀。

有的同學會問：如果給這台虛擬機重新部署一個新的應用版本，它的狀態不就發生了變化？

確實如此。為了確保虛擬機的不變性，一旦啟動後部署了某個版本，就不允許再重新部署。這樣一來，對虛擬機這種計算資源來說，就具有了不變性。不變性意味著某個虛擬機上的應用版本是確定的，與之打包的配置文件是確定的，不存在今天是版本1，明天變成版本2，後天回滾到版本1的情況。

計算資源不變，能確保啟動一台虛擬機，對應發布的應用版本和配置是確定的且不變的，對於運維、排錯非常重要。

那麼如何在保持計算資源不變的前提下發布新版本？

我們以AWS的CodeDeploy服務為例，假設一組正在運行的某應用v1集群包含3台虛擬機：

現在，我們要把應用從v1升級到v2，絕不能直接把現有的3台虛擬機的應用直接升級，而是由CodeDeploy服務啟動3台新的一模一樣的虛擬機，只是部署的應用是v2。現在，一共有6台虛擬機，其中3台運行v1版本，另外3台運行v2版本，但此刻負載均衡控制的網路流量仍然導向v1集群，用戶感受不到任何變化：

v2集群部署成功後，做一些自動化冒煙測試和內網測試，如果有問題，直接銷毀，相當於本次部署失敗，但無需回滾。如果沒有問題，通過負載均衡把流量從v1集群切到v2，用戶可無感知地直接訪問v2版本：

穩定一段時間（例如15分鍾）後，銷毀v1集群。至此，整個升級完成。

上述的藍綠部署就是CodeDeploy的一種標准部署流程。CodeDeploy也支持灰度發布，適用於更大規模的應用。

把計算資源不可變應用到部署上，實際上是充分利用了彈性計算這個優勢，短時間創建和銷毀虛擬機，只有上雲才能做到，並且針對雲計算，把部署流程變得更加簡單可靠，每天發幾個版本甚至幾十、幾百個版本都變得可能，DevOps能落地，有點「雲原生」的味道了。

說到AWS的CodeDeploy，最早我使用AWS時，對於它的計費採用Reserved Instance預付模型感到很不理解，租用一台虛擬機，按國內阿里雲、騰訊雲包年包月預付享折扣不是更直觀嗎？如果僅僅把上雲變成租用虛擬機，那就完全喪失了彈性計算的優勢，相當於租用了一台虛擬機在裡面自己折騰。AWS的Reserved Instance計費並不綁定某一台虛擬機，而是一種規格的虛擬機。

我們還是舉例說明，如果我們有1台2v4G規格的虛擬機，並購買了1年的Reserved Instance，那麼，我隨時可以銷毀這台虛擬機，並重新創建一台同樣規格的新的虛擬機，Reserved Instance計費會自動匹配到新的虛擬機上，這樣才能實現計算資源不變，頻繁實施藍綠部署，真正把部署變成一種雲服務。最近阿里雲終於推出了節省計劃的付費模式，有點真正的雲計算的付費味道了，但是騰訊雲、華為雲還停留在包年包月和按量付費這兩種原始租賃模型。

講了這么多自動化部署，實際上一個指導思想就是如何充分利用雲的彈性計算資源。從充分利用雲的彈性資源為出發點，設計一整套開發、部署、測試的流程，就是雲原生。彈性資源利用得越充分，雲原生的「濃度」就越高，就越容易實施小步快跑的快速迭代。

那麼虛擬機是不是彈性最好的計算資源呢？從應用的角度看，顯然容器是一種比虛擬機更具彈性，更加抽象，也更容易部署的計算資源。

容器和虛擬機相比，它實際上是一種資源隔離的進程，運行在容器中的應用比獨佔一個虛擬機消耗的資源更少，啟動速度更快。此外，容器的鏡像包含了完整的運行時環境，部署的時候，無需考慮任何額外的組件，比其他任何部署方式都簡單。使用容器，開發部署流程就變成了開發，生成鏡像，推送至Docker Hub或雲服務商提供的Registry，直接啟動容器，整個過程大大簡化。

使用容器比使用CodeDeploy部署還要更加簡單，因為CodeDeploy需要在虛擬機鏡像中預置Agent，由於沒有統一的發布標准，還需要配置CodeDeploy，告訴它去哪拉取最新版本，這又涉及到一系列許可權配置。而容器作為標準的部署方案，連發布系統都以Registry對各個鏡像版本進行了有效管理，所以部署非常簡單。

容器作為一種彈性計算資源，也應遵循計算不變性，即不要給容器掛載可變的存儲卷。一組不變的容器集群才能更容易地升級。容器的運行方式本身就遵循了不變性原則，因為通過一個鏡像啟動一個容器，在運行過程中，是不可能換一個鏡像的。容器本身也強烈不建議應用寫入數據到文件系統，因為重啟後這些修改將全部丟失。

容器的啟動和銷毀非常容易，不過，容器的管理卻並不簡單。容器的管理涉及到創建、調度、彈性擴容、負載均衡、故障檢測等等，Kubernetes作為事實上的容器編排標准平台，已經成為各個雲服務商的標配。

如果要直接使用K8s，在雲環境中首先要有一組虛擬機資源作為底層資源，然後搭建K8s環境，定義好容器編排並啟動容器。雲服務商幾乎都提供託管的K8s服務，但直接管理K8s仍然需要非常熟悉K8s的工程師。

還有一種更簡單的使用容器的方式，即完全將底層虛擬機和K8s託管給雲服務商，企業客戶只需關心如何部署容器，底層的K8s和虛擬機對企業不可見或者無需關心。AWS的Elastic Container和阿里雲的彈性容器均為此類服務。對於中小規模的應用來說，計算資源直接使用容器，再配合雲服務商提供的負載均衡，託管的資料庫、消息系統、日誌系統等組件服務，應該是目前最「雲原生」的一種方案。

最後，我們總結一下雲原生的特點：

所謂雲原生，就是在上雲的過程中，充分發揮雲平台的彈性計算、彈性存儲的優勢，盡量把應用設計成適合雲計算的架構，把部署設計成簡單易用的流程，這樣才能實現業務快速上線，快速迭代。

雲原生是一個大方向，在上雲的過程中，逐步改造應用架構和部署流程，從手動往自動轉，逐步增加計算資源的彈性，就能把雲原生一步步落地。

② 安晟培半導體公布雲原生伺服器處理器數據，它到底有多強大

安晟培半導體材料高新科技有限責任公司於此前發布了雲原生網路伺服器CPUAmpereAltraMax樣照的標准數據測試。AmpereAltraMax是Ampere繼上年三月公布的80核AltraCPU後將要發布的重磅消息新產品，核心總數做到業內領跑的128核，專為雲原生架構打造出，展示出再創佳績的特性和擴展性。

Ampere運用工程項目高級主管NarenNayak表明大家服務承諾，將維持迅速且可預測分析的發布產品節奏感。雲服務供應商也覺得它是維持可持續性、持續增長的前提條件。AmpereAltraMax是大家商品方案中的又一個重特大飛越，它有希望在幾個月內資金投入生產製造。AmpereAltraMax專為橫著拓展而設計方案，另外持續了大家核心相對密度領域領跑的一貫設計風格。憑著全世界第一款雲原生CPU，Ampere著眼於營造集成電路工藝雲計算技術和邊緣計算的將來。

③ 雲原生應用是什麼它的特點有哪些

雲並非把原先在物理伺服器上跑的東西放到虛擬機里跑，真正的雲化不僅是基礎設施和平台的事情，應用也要做出改變，改變傳統的做法，實現雲化的應用——應用的架構、應用的開發方式、應用部署和維護技術都要做出改變，真正的發揮雲的彈性、動態調度、自動伸縮……一些傳統IT所不具備的能力。這里說的「雲化的應用」也就是「雲原生應用」。雲原生架構和雲原生應用所涉及的技術很多，如容器技術、微服務等，

而雲原生應用最大的特點就是可以迅速部署新業務。在企業里，提供新的應用程序環境及部署軟體新版本通常所需時間以日、周甚至以月計算。這種速度嚴重限制了軟體發布所能承受的風險，因為犯錯及改錯也需要花費同樣的時間成本，競爭優勢就會由此產生。

所以雲原生不是一個產品，而是一套技術體系和一套方法論，而數字化轉型是思想先行，從內到外的整體變革。雲原生包括DevOps、持續交付、微服務、敏捷基礎設施、康威定律等，以及根據商業能力對公司進行重組的能力，既包含技術、也包含管理，可以說是一系列雲技術和企業管理方法的集合，通過實踐及與其他工具相結合更好地幫助用戶實現數字化轉型。

CNCF(雲原生計算基金會)認為雲原生系統需包含的屬性：

1、容器化封裝：以容器為基礎，提高整體開發水平，形成代碼和組件重用，簡化雲原生應用程序的維護。在容器中運行應用程序和進程，並作為應用程序部署的獨立單元，實現高水平資源隔離。

2、自動化管理：統一調度和管理中心，從根本上提高系統和資源利用率，同時降低運維成本。

3、面向微服務：通過松耦合方式，提升應用程序的整體敏捷性和可維護性。