cookieOptions = {...}; 使用雲端儲存服務時,如何避免踩坑? - 3S Market「全球智慧科技應用」市場資訊網

3S MARKET

3S MARKET
2016年5月16日 星期一

leiphone 程弢


編者按:本文整理自最新一期硬創公開課——《關於企業級雲端儲存,你必須要知道這些!》,分享嘉賓是七牛雲首席佈道師何李石。何李石熱愛技術和產品,是Go 語言/容器虛擬化技術佈道師、實踐者,互聯網產品基礎架構解決方案專家,擁有五年以上互聯網創業經驗和企業級服務產品研發、運營經驗。

使用云存储服务时,如何避免踩坑? | 硬创公开课

最近,人工智慧、無人機和 VR/AR等概念太火熱了,以至於我們忽視了另一個潛伏在行業應用背後的熱點——雲端運算。企業在選擇雲服務時有什麼樣的坑,使用雲服務時需要瞭解些什麼?

以下是演講實錄(有刪減):

雲端儲存是什麼?
所謂雲端服務,其實是一種持續在線上、持續可用的第三方服務的統稱,最常見幾個雲端服務就是雲端運算和雲端儲存服務,大多數情況下人們也用「雲端運算」一詞指代所有雲端服務,因此很多做雲端服務的公司都稱自己為雲端運算公司,實際上他們提供的服務可能並沒有包含「虛擬機」或者其它形式的運算服務。

     
也有人套用「持續在線、持續可用的第三方服務」這個概念,發明瞭「雲備胎」等詞。
通俗點說就是,雲端服務實際上是本地服務的一種延伸,也即將原來在本地提供的物理資源「雲端服務化」,這些物理資源主要包括CPU 運算資源、內存資源、磁碟資源和網路資源,因此雲端服務公司的常規業務主要有:

1.提供運算和內存虛擬化服務的雲端運算業務
2.提供儲存虛擬化的雲端儲存業務
3.提供網路虛擬化的虛擬化網絡服務


這種通過軟件虛擬化的形式,來提供的服務也稱為「軟體定義服務」,如軟件定義儲存、軟體定義網路和軟體定義數據中心。它可以將特定的硬體與軟體進行解耦,將硬件的可操控成分按需求、分階段的,通過編程接口或者以服務的方式,逐步暴露給前端應用,分階段地滿足應用對資源的不同程度、不同方面的靈活調用。

從雲端儲存的角度來說,它是一種持續在線上、持續可用的第三方儲存服務,它對外封裝了具體的物理資源,和這些資源分配的細節,只暴露幾個簡單的API,讓用戶只需要使用這幾個簡單的API 即可完成對海量文件的儲和管理。

對於企業來說,雲端儲存不僅可以提供海量的儲存資源,其規模化的集中式投入,還可以降低企業的硬體、人力和時間投入成本。同時,對於前期無法投入太多硬件資源的企業如創業公司,雲端儲存的彈性擴容縮容能力,和按需使用,按需付費能力,可以很好的降低其投入風險。


雲端儲存和網路儲存的區別在哪?
因為網路硬碟儲存是終端用戶術語,所以認知度會更廣;而雲端儲存是技術術語,只有技術人員才接觸到,所以大家對雲端儲存的概念會比較生疏。

從上下游角度講,網盤的底層是雲端儲存,也即網路儲存企業是雲端儲存企業的客戶,屬於下游。

一般來講,雲端儲存的應用場景有哪些?
雲端儲存作為磁盤這種基礎硬體資源的抽象,基本上滲透到了互聯網的各個領域,可以認為所有需要上網的服務,都可以用到雲端儲存服務,它可以儲存任何類型的文件。從文件類型來看,目前儲存量比較大的場景有:圖片儲存、影音儲存和文件儲存。不過,對於雲端儲存來說任何類型的文件的儲存都是一樣的,所以我們一般不會根據文件類型來分類。

可以從以下幾個領域來理解:

娛樂行業場景,包含的子類主要有:興趣圖片社交、短視頻社交、遊戲直播、動漫、數字音樂、電子閱讀、網絡電台和網絡KTV 等。

在線旅遊場景,包含的子類主要有:旅遊資訊/預定、遊記UGC、旅遊攻略和景區實況等。

O2O 場景,包含的子類主要有:美業導購、美業垂直社區、達人影像社區、上門服務和售後跟蹤服務等。

智能硬件場景,這類場景包含的子類有:智慧硬體平台、固件分發、數據處理和分析,以及影像監控採集等。

安防監控或監控直播場景,這類本來也屬於大的「智慧硬體場景」範疇,但它更加特殊化,因此將其單獨拎出來作為一個場景。

廣電行業場景,包含的子類主要有:新聞線索收集和管理、影像內容加工、節目點播、現場直播、節目交易和數據統計等場景。

 

線上教育場景,包含的子類主要有:大規模開放式在線課程、垂直工具類產品和直播課堂等。

除此之外,基因行業也有大量的數據儲存需求,不過這屬於比較偏的一類應用場景。

不同的應用場景,需要什麼樣的技術支持?
雲端儲存的應用場景分類很多,對雲端儲存廠商來說不同的場景是基於客戶的角度考慮的。舉幾個例子:

陌陌這種社交產品用戶量巨大,需要我們幫助他們儲存和分發大量的小文件(你們的頭像和表情之類的);

而美拍這種產品要儲和分發的則是一些相對較大的影像文件(一個 10  15 秒的短片)。

需要注意的是,一個客戶的同一個產品中也可能包含多種功能,它們分別對應不同的場景,比如現在很多社交產品裡面都在整合直播功能,美拍就屬於這種情況。
在娛樂行業、旅遊行業和 O2O 場景中,一般以圖片或者短視頻社交為主,儲之外,還可能會涉及到圖片和音視頻的處理技術。

圖片很簡單,直接實時處理即可。但是對於影音來說卻不能直接實時處理,因為影音的處理一般比較耗時,大規模的實時影音處理併發請求容易把服務端拖垮,而客戶端也可能因為網路等待超時,而拿不到處理後的信息。因此我們會建議採用異步處理的方式來做。

在需要對內容進行審核影像社區的應用中有兩種做法:第一是採取抽幀審核的方式,可以調用鑒黃服務識別其健康程度;第二可以將視頻轉換成體積更小的 GIF 圖片快速下載到本地在瀏覽器端快速瀏覽。

對於短片社交來說,影音的跨平台播放是必不可少的特性,比如大家希望微信打開可以直接播放,在電腦上打開也能夠正常播放,在儲存外圍構建一個數據處理平台就顯得非常重要了,這也是七牛採用的方案。
 

選擇和使用雲端儲存的陷阱在哪?如何避免?
一般情況下,企業會關心兩個點:產品好用不好用以及成本。成本方面比較好評估,對比一下就行,大不了我先用用看看要花多少錢,因為都比較透明瞭。所以我就從另一個角度來談談:
項目前期,我們選擇雲端儲存方案的時候可能有很多選擇,我們可能自建,可能選擇第三方,即便是自建,也可能有多種不同的方案。而第三方的選擇則更是讓人眼花繚亂。

因為現在很多公司都說自己是雲端運算公司,都說有能力提供雲服務。實際上我們通過 API 的形式,將基礎能力開放出去之後,很多公司只需要再這基礎之上,包裝一下即可打造成一個雲產品。

那麼,除了成本之外,我們到底應該關心哪些東西,才不至於前期投入巨大,更不需要在後期陷入資源投入無底洞的陷阱(自建)。

首先,我們做雲存儲服務的,做過成本分析,自建在很大情況下不如使用雲服務省錢、省力。因此,我今天只講對第三方雲端儲存服務的評估和選擇。

1.公司資質的判斷。這些雲端服務公司到了什麼階段,它們的產品和服務確實靠譜嗎?核心競爭力是在哪裡?

2.這些雲服務目前的主要客戶有哪些,這些客戶中有我們的競爭對手嗎?如果有,他們用了這個雲端服務之後是不是能夠解脫開來,讓自己更加專注於自身的業務?

3.如果我選擇這家第三方服務,除了雲端儲存服務本身之外,我是否能享受到其它如數據處理這樣的便利性,未來是否能享受到專業的長期服務?雲端服務不是一個簡單的系統開發,完了就放在那裡跑就可以賺錢的,它的完善是一個持續的過程,托管這麼多客戶的業務,它跑的過程中可能遇到各種問題,都是需要深入到具體的技術中去解決。



4.我選擇的這家服務提供商足夠安全嗎?受版權保護的數據如何儲存和分發?

我們再來看看使用過程中應該注意什麼:

1.應該盡量將業務架構解耦,把動態資源和靜態資源分離開來,盡量將靜態資源獨立托管在第三方。

2.雲端儲存是只幫你保存文件的,讀取文件都通過你給的唯一標識符和相應的授權來讀。因此,有必要在自己伺服器上保存一份原始記錄。保存原始記錄不是說你要把儲存在雲端的文件都備份一份,而是把這些文件的名字都保存起來。這樣你才能知道在雲端存了什麼東西。 

未來還會有新服務出現?
對用戶而言,雲端儲存其實很簡單,就是一個讀寫接口。因此從儲存的功能來講,未來也不會有太大的變化。

但是我們講雲端儲存服務,其實更加關注一整套服務,也即圍繞儲存在我們這裡的數據能夠提供哪些對客戶有價值的服務。

因此可以換個角度看這個問題,除了現有的儲存服務,圍繞儲存或者數據,未來還會有其它更酷更方便客戶的服務嗎?

 
精彩問答
問:雲端儲存的上傳和下載都需要用到大量的頻寬資源,這個頻寬和雲端儲存是一起提供的嗎?

答:這個頻寬是一起提供的。我們會在外圍佈署一些加速上傳下載的節點,所有的上傳下載都走這些節點代理到核心儲存機房。

問:請問病人的片子包括病例資料可以實現適時上傳到伺服器上,同時設置密碼,再由我們轉給醫生,由醫生解密這個過程嗎?

答:可以實現,這裡面涉及到和你業務伺服器的交互。雲端儲存可以提供運算力讓你實時加密處理,但是醫生那邊的解密以及密鑰的頒發需要你業伺服務器配合。

追問:怎麼個實現形式,通過賬戶密碼的形式嗎,如果是老年人不會使用,可有其他解決辦法?

答:不是通過帳戶密碼的形式的,要用自動化的方式,用公鑰、密鑰的方式進行加密解密。你這種處理方式比較特別,並且上傳到雲端的時候一般是集中上傳的,並不是 UGC 場景,建議在本地加密好後再上傳到雲端。


在客戶端比如醫生的 iPad 裡面下載下來後再解密。解密的時候可以讓他授權登入,通過服務端頒發私鑰。具體的實現方式可以咨詢一下你們工程師。

                                                                                                                                                                                                                            

0 comments: