云計算的定義
對云計算的定義有很多方式，其實每種定義都能反映云計算的一些特點，比較常見的定義如下：
- 美國國家標準與技術研究院（NIST）：云計算是一種按使用量付費的模式，這種模式提供可用的、便捷的、按需的網路訪問，進入可配置的計算資源共享池（資源包括網路、服務、存盤、應用軟體、服務），這些資源能夠快被快速提供，只需投入很少的管理作業，或與服務進行很少的互動，
- 劉鵬教授對云計算給出了長、短兩種定義：
- 長定義是：云計算是一種商業計算模型，它將計算任務分布在大量計算機構成的資源池上，使各種應用系統能夠根據需要獲取計算力、存盤空間和資訊服務，
- 短定義是：云計算是通過網路按需提供可動態伸縮的廉價計算服務
云計算的特點
- 并行計算(Parallel Computing)、
- 分布式計算(Distributed Computing)
- 網格計算(Grid Computing)
- 虛擬化(Virtualization)
- 效用計算(Utility Computing)
- 將基礎設施作為服務IaaS(Infrastructureas a Service)： 消費者通過internet可以從完善的的計算機基礎設施獲取服務（硬體服務器租用）
- 將平臺作為服務PaaS(Platform as a Service) ：軟體的個性化定制開發
- 將軟體作為服務SaaS(Software as a Service)：通過internet提供軟體的模式
云化的基本概念
Cloud Native概念：核心改變是應用適合基礎設施，而不是基礎設施適合應用
應用上云
- 微服務架構：不是開發一個巨大的單體式的應用，而是將應用分解為小的、互相連接的微服務，一個微服務一般完成某個特定的功能，如下單管理、客戶管理等，每個服務都有自己的資料庫，微服務之間的資料傳遞可以通過服務暴露出的API來完成，
- Docker: 構建在LXC之上、基于行程容器的輕量級VM，非常適合微服務，
大資料上云
資料上云，一般來說有兩種經典模式：
- 托管模式： 核心是通過云的能力簡化了集群的創建、運維，以Amazon EMR為典型代表，
- 服務化模式：進一步簡化了大資料的使用，用戶不用關心集群、資源這些事情，只需要將大資料任務提交給大資料云，享受相應的服務即可，經典代表是微軟的Azure Data Lake Analytics，
上云測驗
功能性測驗點
- 功能測驗：即確保被測系統所提供的服務符合預期，主要包括如下方面：
- 系統驗證測驗：端到端的測驗
- 用戶驗收測驗：
- 互操作性測驗：切換基礎設施，仍然能無縫作業
非功能性測驗點
這些非功能性硬核關鍵點和云計算的特性有著必然的關系，同時也和服務的可靠性，服務的計量和治理有著密切的關系，簡單來說你要保證你的云服務的可靠性，可用性，可管理性，必須具有一些云化后的非功能性指標，因為你業務功能再好用，不可靠，對用戶來說是沒有保障的，如下8個硬核點就是云化的非功能指標，后續一節再分別講述，這些硬核點的的定義以及如何來測驗這些點，特別是第1，第2，第3，這三個缺一不可，否則你的軟體只是搬到云端，并不具備任何云計算的特性，也就是假云，
- 彈性，也叫自動伸縮
- 說起彈性，先從常說的云服務器，ecs 說起，它就是Elastic Compute Service的縮寫 ，是一種處理能力可彈性伸縮的計算服務器，這是從IAAS （更偏硬體資源：CPU,記憶體，磁盤，網路）層來實作彈性，這解決了硬體或是底層資源的彈性;實際從提供云服務的軟體層現來看，還要有軟體自身的彈性，例如，需要根據時間或是其他的策略(基于流量，或是硬體資源的特定基線)橫向擴展，如高峰期，掛號服務需要10個節點才能保證支撐高峰期的并發量，非高峰期，再減少掛號服務節點，騰出計算資源做其他事情，在云上，實作集群節點的擴展是很簡單的事，配置好擴展策略即可，測驗的時候， 必須把彈性作為一個check point ,如何驗證，從前面其定義就能明白，這里就不再重復了，現在問題來了，動態擴的服務，如何讓集群感知，且可用呢，請看如下第2項
- 服務無狀態
-
接上一個問題，動態擴的服務，如何讓集群感知，且可用呢?讓集群感知有兩個辦法，一是服務在橫擴的時候，向ELB（負載均衡）動態注冊(如果擴展了節點，需要手動配配置并重啟負載均勻相關組件，這不叫彈性)，或是通過服務發現注冊組件來實作，這有很多成熟的技術，這里就不多說明，重點是，新橫擴出來的服務，加到集群后，要讓他能對處提供服務，這要求服務是無狀態的 ( 比如會話session ,或其他背景關系，不依賴服務所在屬主容器，如tomcat ,jetty,weblogic ,iis等)，否則某個請求被路由到新擴的服務節點時，可能會為因為會話或背景關系的問題，導致服務在業務上不可用，測驗的時候， 必須把服務無狀態作為一個 check point，如果服務實作方，是通過在負載均衡上通過“ 黏住” 策略，來實作會話共享，的話，有一個大問題，當服務節點減少，或是某些服務節點掛掉時，之前這些服務節的服務的客戶端后續的請求，轉移到其他節點，session 就會丟失，通常做法是，把session或上文下外置在服務執行緒所在容器(tomcat ,jetty,weblogic ,iis等)之外，如memcache 中，redis 中，
-
如何驗證這個無服務的檢查點呢?假定是一個Web 程式，通過關閉單一節點，再重啟檢查，是否為同一個session，測驗這個完全可以在非云環境來驗證，用一個單單一節點來測驗（非集群模式），比如先登錄，進入到某頁面，且準備做某個對session 有依賴的操作，這時，停下正要操作的功能，先停掉這個節點，然后重啟這個節點，，重啟后再在之前登錄的頁面上，接著做這前的作操作，并沒有提示要重登錄，或是session過期，操作成功，可以驗證；當然也可以用兩個節點來驗證(集群模 式)，每個節點上，放兩個相面的頁面，在上面，列印出session id ,以及節點的名稱，先請求這頁面，記下列印的session id 及節點名，關掉任意一個節點，再重繪這頁面，看看列印的session id 一樣不，如一樣，只是節點名變了，說明服務是無狀態的，還有其他方法，這里只是拋磚引玉，提供一下思路，如純后臺API ,只要檢認證資訊是否過期，或是是否是同一個認證資訊，
- 多租戶支持
- 既然是云上的服務，必須要求不同的客戶（租戶/單位/組織）都能使用，且互不影響，實作多租戶，通常有兩種隔離方式，邏輯隔離和物理隔離；邏輯隔離指，大家其用一套系統，只是在資料庫層在表中加一個欄位，資料所屬租戶；物理隔離，這每個租戶單獨部一套系統，測驗的時候， 必須把多租戶支持作為一個 check point，測驗方法，通過對隔離的闡述，自然就知道如驗證，支不支持多租戶，以及是以什么方式隔離，上面示例中，租戶注冊成功后，呼叫CloudFormation介面，自動部署的云進銷存業務系統，這實際是物理隔離
- 故障轉移/隔離
- 云服務，一定會有出故障的時候，為了保政故障產生的影響最小，必須有應對故障的策略，故障轉移也分兩個層面的，，一個是IAAS層的，一個是業務服務自身的故障轉移，如整個系統宕機，或是有故障，利用鏡像，自動重新實體化一個實體，只是網路屬性未變，這是IAAS層面的,在PAAS看來，實際是和之前是無差別的，相當于，傳統方式下，快速啟用冗余或備用的服務器、系統、或者硬體接替它們作業；另一個是軟體層面，業務服務系統，在服務不可用時，支持的重試邏輯，同時支持重試，就要求保持冪等性（簡單說，對同一個資料做同一個操作，做一次和做N次，結果是一樣的），或對出錯的服務進行隔離，不隔離會引發雪蹦效應，或是采用服務降低的錯施，一句話，測驗的時候， 必須把故障轉移/隔離作為一個 check point， IAAS層的轉移，只需向云廠商確認即可，基本上云廠商這層面都已實作，軟體方面的故障處理，需要根據隔離策略來執行相應的測驗，細節具體根據具體應用再詳查，主要是不要漏過這個測驗點
- 服務限流保護
-
既然是公有云，面向的是所有你的客戶，某些情況下，訪問量會爆增，或是受到惡意的訪問攻擊，這時服務的可靠性，隱定性也必須得到保障，通過對并發訪問/請求進行限制或者一個時間視窗內的請求進行限速來保護系統，一旦達到限制速率則可以拒絕服務或者排隊等待，從而使服務不會引過多的訪問而崩潰,這就是限流，
-
測驗方法，通過壓測，或是增加到并發量，到系統支持的極限后，系統有沒有因訪問量太大而崩潰，測驗的時候， 必須把服務限流保護作為一個 check point
- 應用安全
- 服務放云上，面向整個互連網，除了要應對惡意的攻擊，還要防止服務器被劫持，還要保證資料安全，和授權內訪問等等，安全是一個很專業的一個方向，測驗的時候， 也必須把安全作為一個 check point, 測驗人員在這方面，只能做一些常規的安全測驗，如SQL 注入，XSS跨站攻擊，敏感資訊是否明文傳輸， API的訪問是否要通過驗證,一些等存級別高的業務，還需要雙向認證,甚至實名認證等，其他的則需要請專業的安全公司進行全面的安全測驗，他們能掃描出系統存在的安全漏洞和不安全的因素，并給出好的整改建議，
- 呼叫鏈追蹤
- 這要看服務是否是一個分布式應用，分布式應用中，系統存在互相呼叫的情況，形成一個 呼叫鏈，通常一個請求，會引發A組件，呼叫B,組件，B組件呼叫C ，C呼叫D，可能還有更長的呼叫鏈，實話說，呼叫鏈追蹤，有點偏向于運維，在測驗時，分布式環境下，不借助呼叫鏈追蹤有些問題根本沒法定位，比如說，某個請求出錯了，實際是錯呼叫鏈的哪個節點上，或是某個功能很慢，慢在哪，不借助于呼叫鏈追蹤，你都沒辦法跟程式，就算讓研發自己打斷點，也要搞死人的，分布式加集群，同一個服務，每次呼叫時，呼叫鏈都可能不一樣，上云的應用，通常是分布式用，作為測驗人員，也有必要把呼叫鏈追蹤作為一個 check point,才能在分布式場景下，提出定位更準，更專業的問題，而不只在BUG的表像上，開源呼叫鏈追蹤有zipkin,pinpoint，skywalking等，呼叫鏈跟蹤需要研發那邊來集成，測驗這邊要get到這個點和會使用，下圖是昨天用zipkin 的一個截屏示例
- 可視化服務治理（可觀測，可自動健康檢查，服務優雅關閉等）
- 服務治理，也是偏運維的東東，他自身的定義，各位可以自行百度；在這里，我只簡單場景上來說明，服務治理的大概意思，你的服務在云上，可靠性要有保障，主要在于預防，不能抓瞎，真正問題發生了，就炸鍋了，需要通過可視化的方式，觀測到服務的狀態，健康狀態，流量情況，回應速度，并發量，資源使用情況等，并根據于些，采用自動或半自動的方式啟動彈性擴展，或是采取隔離，熔斷等措施，以保障服務的可用性，在devOps 大行其道的當下，測驗人員向運維多靠一點不是壞事，會給測驗提供更多靈感和帶來更多測驗手段，云上的服務，服務優雅關閉，順帶提一下，要關閉某個服務時，正在服務中運行相關業務執行緒會同進被關掉，也就意味著這些業務操作肯定要失敗，與之相反服務優雅關閉,指在關閉前，他會拒絕新的進求進來，同時要完成當前的所有業務后，才關閉，有點像銀行的視窗，不接受業務了，但要把當前正辦理的業務處理完，測驗人員以此作為一個 check point ，可用來驗證云服務實作水平的高低，又能為服務的可靠性測驗提代相關測驗手段/方法，這個點也要get 到，
參考文章：
- 大資料架構詳解從資料獲取到深度學習2016版第9章-大資料云華
- https://blog.csdn.net/MYPM_AndyLiu/article/details/90170835
- https://blog.csdn.net/weixin_41918841/article/details/95218043
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/233116.html
標籤：其他