3月17日-19日， 由CSDN重磅打造的互聯網運維開發實戰峰會、資料庫核心技術與應用實戰峰會和互聯網應用架構實戰峰會在上海舉行。 三場峰會邀請了業內頂尖的架構師和技術專家， 共同探討運維、資料庫和架構領域的話題與技術。
網易雲首席解決方案架構師劉超受邀在第一天的互聯網運維開發實戰峰會上發表了演講， 分享了人們理解和使用雲計算的誤區， 以及雲原生應用設計的正確方式。 很多人以為虛擬化了就算是雲平臺， 把應用移到虛擬機器和雲主機甚至是容器上就算完成了上雲。
雲計算的龐氏騙局？
劉超首先向在座的開發和運維人員提出了以下幾個問題：
從雲計算誕生以來， 我們經歷了物理機， 虛擬機器， OpenStack和Docker等技術：
物理機穩定， 性能好， 僅需要Linux的知識就可以運維。 但是隔離性不夠好， 資源使用率也不夠高；
於是， 傳統的虛擬化應用而生， 但是傳統虛擬化的成本比較高， 不僅License很貴， 相關的技術人員招聘也很難；
大部分廠商顯然並不會想被這種傳統虛擬化長期綁定， 於是誕生了開源的實現技術OpenStack。 OpenStack開源無綁定、相容性強。 但是開源的軟體並不穩定， 要實現商業化必然要進行定制， 反而從一個綁定切換到另一個綁定。 而且大多數採用OpenStack技術的公司， 最終都會發現運維團隊並沒有減少， 需要招聘的技術人員也會有更高的要求；
接下來Docker的橫空出世又給雲計算帶來了新的曙光，Docker羽量級，易遷移，能夠實現DevOps和持續集成/持續交付。Docker看起來很簡單，但實際上是將複雜性轉移給了平臺層。應用要運行起來，需要安裝和配置的一樣都不能省。要實現Docker在生產級別的應用，底層配備的基礎設施的複雜度不亞於OpenStack。
雲計算使用的誤區
之所以會出現這些問題，劉超認為大部分人，還是在用傳統的思路使用雲計算，應用還沒有雲化。劉超總結了雲計算使用的八大誤區：
1. 傳統單體應用不加修改，就進行虛擬機器或容器的部署。這樣做的問題是打包的東西太多，應用配置起來非常複雜，無法實現橫向擴展，更有甚者一台物理機裡只跑一個容器，完全沒有享受到容器帶來的好處。
2. 不想修改應用，而期望虛擬化層的技術改進，達到“既想馬兒跑又想馬兒不吃草”的效果。比如希望虛擬機器或容器能夠達到物理機的性能，雖然Intel等廠商在硬體層面針對虛擬化做了很多改進，但會大大降低應用的可遷移性和靈活性。所以雲計算的用戶首先要意識到，虛擬化必然會造成性能損耗，應該通過應用的改造，去利用雲計算的橫向擴展能力，從而抵銷這種性能損耗。
3. 期望對虛擬機器進行細細微性的調度，感知物理機和機架。傳統的運維通常會問為什麼雲計算不能提供遷移的功能，把應用從一個機器遷移到另一個機器，或者把應用分佈在不同的物理機甚至機架上。實際上還是把雲計算當成傳統的物理機來用。如下圖所示，左邊是Nova的架構，中間是Kubernetes的架構，他們在設計之初就提供了schedule的機制，如果使用者非要去感知底層的硬體，其實是在重複造輪子。
4. 全公司共用一個帳號，這個帳號由運維控制，所有的操作都要通過他的批准。實際上每一個雲計算平臺都是有帳號和子帳號的管理體系的，雲計算的彈性就是為了實現自運維，而不是需要層層審批的傳統方式。
5. 不規劃和使用VPC進行隔離，隔離性上有很大的問題。
6. 所有的機器都帶公網IP位址，並且使用用戶名密碼登錄，這些做法都會為系統帶來安全隱患。
7. 期望完全由基礎設施層解決應用層的高可用問題。比如記憶體的資料或硬碟的緩存，哪個重要哪個不重要，哪些資料堅決不能丟，這些都是你的應用才知道的，雲平臺並不能區分。
8. 自己搭建資料庫、大資料平臺等公共基礎設施。這會大大增加公司的運維成本，而實際上每個公有雲平臺都提供了相應的PaaS平臺來提供這些服務。
總結起來就是，基礎設施層、平臺層、應用層，每一層都應該各司其職，不要把責任壓給另外一層。特別是應用層的設計，要考慮到這個應用未來是運行在雲上的，要提供能實現彈性擴展和容災備份的機制，一般這種機制被稱為雲原生（Cloud Native）。
雲原生應用的設計要點
從基礎設施這一層來說，網易雲從虛擬機器到容器，將OpenStack和Docker做了很好的融合，比如容器運行在虛擬機器上，使用IaaS層的能力解決網路和存儲的問題，避免了容器產生的網路和存儲性能損耗。劉超從安全隔離、高性能、容器集群和日誌監控等角度進行了詳細說明：
那麼應用架構層，用戶應該如何設計才能實現雲原生應用呢？劉超總結了8個設計要點：
1
負載均衡+API閘道
線上上運維的區域中，對外連通公網的部分，最好通過雲平臺提供的負載均衡，因為大多數雲服務商的負載均衡功能中，都附加了DDoS防禦和WAF的功能；
2
服務拆分和服務發現
3
使用PaaS服務降低設計難度
下圖是網易考拉用到的網易雲平臺的PaaS服務。
4
無狀態化服務的改造
主要就是把記憶體中的資料保存到緩存中，把使用者資料保存到資料庫中，把檔保存到分散式存儲中，這樣應用中只包含商務邏輯，無論怎麼擴展都只是商務邏輯的擴展，下面的存儲也都有自己的集群，不需要應用層做過多的考慮。
5
容器作為持續集成/持續交付的工具
有些人會把容器作為虛擬機器來用，但容器的優勢更多體現在它的標準化和準確的版本控制，從而形成一套非常順暢的DevOps流程。
6
基於代碼倉庫的持續交付流程
將所有的手工操作代碼化，每個運行起來的環境都應該對應一個代碼的分支，所有的修改都要基於這些分支，對鏡像進行修改，觸發持續集成的流程。
7
集中的配置管理
配置也應該保存在代碼中，集中下發。
8
基於流和搜尋引擎的日誌分析
綜上所述，基礎架構層應該做到足夠的彈性，和一定程度的調優，但不要做太多影響擴展性的調優；應用層應該向雲原生發展，實現更好的彈性伸縮和持續集成/持續交付的流程，這樣兩者合作起來，才能有效地降低運維成本。
網易企業服務-企業資訊化服務提供者
湖南領先網路科技有限公司 163.hn.cn
接下來Docker的橫空出世又給雲計算帶來了新的曙光，Docker羽量級，易遷移，能夠實現DevOps和持續集成/持續交付。Docker看起來很簡單，但實際上是將複雜性轉移給了平臺層。應用要運行起來，需要安裝和配置的一樣都不能省。要實現Docker在生產級別的應用，底層配備的基礎設施的複雜度不亞於OpenStack。
雲計算使用的誤區
之所以會出現這些問題，劉超認為大部分人，還是在用傳統的思路使用雲計算，應用還沒有雲化。劉超總結了雲計算使用的八大誤區：
1. 傳統單體應用不加修改，就進行虛擬機器或容器的部署。這樣做的問題是打包的東西太多，應用配置起來非常複雜，無法實現橫向擴展，更有甚者一台物理機裡只跑一個容器，完全沒有享受到容器帶來的好處。
2. 不想修改應用，而期望虛擬化層的技術改進，達到“既想馬兒跑又想馬兒不吃草”的效果。比如希望虛擬機器或容器能夠達到物理機的性能，雖然Intel等廠商在硬體層面針對虛擬化做了很多改進，但會大大降低應用的可遷移性和靈活性。所以雲計算的用戶首先要意識到，虛擬化必然會造成性能損耗，應該通過應用的改造，去利用雲計算的橫向擴展能力，從而抵銷這種性能損耗。
3. 期望對虛擬機器進行細細微性的調度，感知物理機和機架。傳統的運維通常會問為什麼雲計算不能提供遷移的功能，把應用從一個機器遷移到另一個機器，或者把應用分佈在不同的物理機甚至機架上。實際上還是把雲計算當成傳統的物理機來用。如下圖所示，左邊是Nova的架構，中間是Kubernetes的架構，他們在設計之初就提供了schedule的機制，如果使用者非要去感知底層的硬體，其實是在重複造輪子。
4. 全公司共用一個帳號，這個帳號由運維控制，所有的操作都要通過他的批准。實際上每一個雲計算平臺都是有帳號和子帳號的管理體系的，雲計算的彈性就是為了實現自運維，而不是需要層層審批的傳統方式。
5. 不規劃和使用VPC進行隔離，隔離性上有很大的問題。
6. 所有的機器都帶公網IP位址，並且使用用戶名密碼登錄，這些做法都會為系統帶來安全隱患。
7. 期望完全由基礎設施層解決應用層的高可用問題。比如記憶體的資料或硬碟的緩存，哪個重要哪個不重要，哪些資料堅決不能丟，這些都是你的應用才知道的，雲平臺並不能區分。
8. 自己搭建資料庫、大資料平臺等公共基礎設施。這會大大增加公司的運維成本，而實際上每個公有雲平臺都提供了相應的PaaS平臺來提供這些服務。
總結起來就是，基礎設施層、平臺層、應用層，每一層都應該各司其職，不要把責任壓給另外一層。特別是應用層的設計，要考慮到這個應用未來是運行在雲上的，要提供能實現彈性擴展和容災備份的機制，一般這種機制被稱為雲原生（Cloud Native）。
雲原生應用的設計要點
從基礎設施這一層來說，網易雲從虛擬機器到容器，將OpenStack和Docker做了很好的融合，比如容器運行在虛擬機器上，使用IaaS層的能力解決網路和存儲的問題，避免了容器產生的網路和存儲性能損耗。劉超從安全隔離、高性能、容器集群和日誌監控等角度進行了詳細說明：
那麼應用架構層，用戶應該如何設計才能實現雲原生應用呢？劉超總結了8個設計要點：
1
負載均衡+API閘道
線上上運維的區域中，對外連通公網的部分，最好通過雲平臺提供的負載均衡，因為大多數雲服務商的負載均衡功能中，都附加了DDoS防禦和WAF的功能；
2
服務拆分和服務發現
3
使用PaaS服務降低設計難度
下圖是網易考拉用到的網易雲平臺的PaaS服務。
4
無狀態化服務的改造
主要就是把記憶體中的資料保存到緩存中，把使用者資料保存到資料庫中，把檔保存到分散式存儲中，這樣應用中只包含商務邏輯，無論怎麼擴展都只是商務邏輯的擴展，下面的存儲也都有自己的集群，不需要應用層做過多的考慮。
5
容器作為持續集成/持續交付的工具
有些人會把容器作為虛擬機器來用，但容器的優勢更多體現在它的標準化和準確的版本控制，從而形成一套非常順暢的DevOps流程。
6
基於代碼倉庫的持續交付流程
將所有的手工操作代碼化，每個運行起來的環境都應該對應一個代碼的分支，所有的修改都要基於這些分支，對鏡像進行修改，觸發持續集成的流程。
7
集中的配置管理
配置也應該保存在代碼中，集中下發。
8
基於流和搜尋引擎的日誌分析
綜上所述，基礎架構層應該做到足夠的彈性，和一定程度的調優，但不要做太多影響擴展性的調優；應用層應該向雲原生發展，實現更好的彈性伸縮和持續集成/持續交付的流程，這樣兩者合作起來，才能有效地降低運維成本。
網易企業服務-企業資訊化服務提供者
湖南領先網路科技有限公司 163.hn.cn