2. 請問與傳統架構相比，Serverless有哪些優勢？
葉理燈： Serverless是最近這幾年才火起來的概念，從它的字面上去理解，就是無服務器的架構。什麽意思呢？就是你就不用買服務器去搭建你的架構。為了做到這點，要求你對這個架構做無狀態的改造，把它變成一個個函數托管起來。
從優勢來講有幾個，第一呢，它是按需付費的。傳統架構你買物理機也好，買虛擬機也好，不是真的按需付費，因為你可能用不到所買的配置。但Serverless是可以的，因為它以函數為級別，完全可以按照這個函數消耗的資源給你計費，它是非常徹底的。
第二個優勢是很明顯的，它會節省很多運維成本，因為你沒有服務器了，所以就不用你去運維它。
第三個優點我認為是，它加快了上線的速度。之前的架構，你需要買服務器，把東西部署，做些初始化的工作，但是有Serverless這個東西，有函數計算這個東西，你直接把代碼寫好，上傳上去就可以直接用了，面對的一個Serverless環境是直接可以把函數上載上去直接運行的，這樣會加快你的業務上線的速度。
3. Serverless架構有這些優點，那它適合哪些業務場景？
葉理燈： 我剛才說的是優點，其實Serverless也有缺點，一個非常明顯的是，它是要求你這個函數是無狀態的，因為Serverless是不保證你每次函數地址是一樣的，它在海量機群裏面，你函數第一次運行可能在這個節點，第一次運行在另一個節點，也就是說它這兩次運行過程中是不保存狀態的，這是第一點。
第二點，普通架構下提供的是一個常駐的進程，但Serverless它是一個函數，來一個請求，他拉起一個函數，再銷毀掉，那麽相對一個長駐鏡像來說它有一個比較高的延時。
這兩個原因，使得Serverless一般會用在一些無狀態的場景，還有一些相對來說，對延時不敏感的場景。我舉個例子，圖片處理，很簡單的例子，圖片處理也是一個圖片進來，然後推出去的操作，它本來是無狀態的。
另外，因為我們也算國內第一個做這個Serverless產品的廠商，在我跟用戶聊天，或者見用戶的過程中，發現有一些場景也是很合適的。圖片處理其實是很大的場景的，包括OCR識別，包括機器學習也是個場景，對基因數據的分析是個場景，包括我們最近去聊了一個叫醫療影像，醫療影像叫dicom格式的文件，看起來像圖片，其實是一幀幀的東西。
當然我們在內部有很多類似的場景可以挖掘的，例如我們有個多媒體事業部，裏面有些短視頻的，本身你可以把它抽象為一個不管圖片也好，短視頻也好，它是個小文件，基因數據也是小文件，你可以認為它對小文件的無狀態處理是非常合適的。在這個前提上可以推廣到很多業務場景裏去，包括直播，編解碼，這些涉及到計算的，也是無狀態的，也可以用。
葉理燈： 我們這個UCloud通用計算(UGC)產品和普通的那些所謂的FaaS還是有點不一樣的，我們抽象的層次更高一點，他們抽象的是函數的，我們的抽象的是算法，那麽既然是算法的話，我們一定要想個相對，大家都能接受，開發者能接受的方式，打包這個算法。
我們當時選了容器，因為容器從13年出現到現在，相對來說它是個標準化的東西，大家都願意接受它，也習慣它，而且它比較輕量，第三個它具有跨語言的特點，這三個特征決定我們選擇了容器作為我們打包算法的一個工具。
當然我們用這個容器的過程中也遇到很多坑，就像剛才我在演講裏說了，我們的計算資源是通過受限的虛擬機提供出去的，但是我們當時是想，既然是受限的虛擬機，那這個虛擬機所用的資源越少越好，我們當時選了CoreOS，CoreOS我們用的資源是很少的，CoreOS跑Docker性能也還不錯，但我們遇到一個坑是這樣的：因為我們的場景是說來一個請求，拉起一個Docker，然後執行完就把Docker直接銷毀掉，那麽就會有大量增刪操作。
這種操作，使我們觸發了一個內核Bug，那個Bug我們是在去年的5月份遇到的，這個Bug在4月份發現，提了一個Patch到內核，但內核的官方版本不可能那麽快合進去，我們找到內核團隊，看能不能把這個Patch去更新這個CoreOS內核，但我們發現更新CoreOS是個非常大成本的事件，CoreOS很激進，你要重新編譯一個CoreOS，你要把很多依賴也編進來，雖然可以做，但是對我們來說維護成本太高了，我們就從各方面的權衡，決定把操作系統換掉，換成CentOS，在上面搭個Docker。在CentOS上面的存儲存儲驅動，默認用的是DeviceMapper。我們對比測試發現，這個CentOS裏面，在Docker這個DeviceMapper的IO性能，比CoreOs默認的OverlayFS要慢，慢了大概兩到三倍。我們就把CentOS上面的那個DeviceMapper替換成OverlayFS，再壓測發現現在還OK，後來用了這個方案，就CentOS+Docker+OverlayFS。
我對Docker社區有點悲觀，我一直不認可它某些做法，例如說很多問題，比如內存泄露，因為我們的管理進程也是Docker管理的，進程如果有標準輸出的話就會導致docker deamon內存泄露，我們找了半天發生了這個問題之後， 發現2013年這個問題存在了，2016年還沒人解決，這麽明顯的Bug為什麽三年沒有解決，我對這個社區有點失望，感覺缺乏管理和領導。我覺得Docker最大的功勞可能就是定義了鏡像的格式和把container這種相對開發者比較難操作的東西通過一個易用的工具提供出來。
葉理燈： 因為傳統的Serverless裏面存在一個問題，來一個請求去拉起一個Docker，這就有個問題，這個初始化成本很高，尤其是說如果你這個計算結點裏面，這個計算不存在的話，你得從Docker裏面重新拉一下，Docker鏡像很大的話，這個任務非常慢了，這個操作分為幾個階段，因為我要把鏡像下載到這個本地節點裏面，再把它拉起來。
首先最明顯的優化就是我們要能做用戶Push一個鏡像上來，我們會在一批節點把它預熱，就是鏡像已經先下載下來的，當真正在請求這個算法的時候，我們把這個請求轉向這些有預下載好鏡像的節點上面，這是一個相對來說比較復雜的算法。而且因為每個節點的存儲空間是有限的，你不能說一下子把所有的鏡像都下載到本地來，這樣子存儲是撐不住的，所以算法要考慮怎麽去預熱掉一批鏡像，去淘汰一些冷鏡像，但是都是跟容器本身是沒有關系的，跟這個機制有關系，跟Docker容器啟動的時候有點關系。
還有個很大的難點是架構上面，因為這是個平臺類的產品，這個架構和穩定性和高可用，要做得非常好才行，它不像應用產品，你自己掛了，只會影響自己一個人，這個平臺掛了影響上面的很多個任務，上面的很多用戶。
那麽在高可用上面我們做了很多工作，但我們最希望能做到的容災級別和高可用級別是跨可用區的，剛好我們公司有個叫ULB(UCloud Load Balancer)的產品，非常好地滿足這個要求。ULB可以把它的所有的real server會放到不同的可用區裏面，當一個可用區掛了之後，可以快速地把故障可用區踢掉，就不會影響到用戶的任務執行，用戶的任務可以調度到另外一個可容區裏面去，這是第一個問題。
第二個難點就是你要保證整個架構的高可用，任何一個模塊，任何一個依賴點都不能有單點，所以我們當時是有想了各種辦法，因為我們的存儲層一定是可以自動擴展的，不能成為單點的，每個模塊所部署的機器，我們都盡量做到跨可容區，或者跨交換機來做容災，我們部署之後會檢查各個部署的環境。
第三個難點，架構特點是我們管理的機器非常多的，那麽任何一個節點掛了，我們來保證它不會影響這個服務，我們當時對提交任務，是做了多副本的工作，就是來一個任務時候，可能會同時發給多個副本機跑，哪個先完成了就把它跑回來，這樣的話，我們能做到，一個機器掛了，我們可以慢點處理，對我們服務不會有影響，完成這個目標，而且對用戶來說也是很好的事情。
6. 請分享一下Serverless在UCloud的落地情況。
葉理燈： 我們應該是在內部先開始用Serverless，因為我們做平臺的一個思路就說要先吃自己的狗食，把這個平臺打造的健壯了以後再對外是比較好的思路，我們落地是在內部落地的。
我們當時在ufile這個產品場景下落地，取得了很好的結果，就是真的幫用戶節省了大量的運維的人力和機器的成本。
圖片處理這個場景建完之後，我們還有一些其他的場景，例如我們最近提出短視頻的場景，短視頻的場景就是目前那些用戶上傳了短視頻，傳到我們的存儲上面去，我們做些處理，再去變成一個想要的東西，這裏面有大量的小文件處理，而且這是另外一個產品，我們公司做的一個umedia的產品，對外提供服務的，背後的計算也是通過我們這個UGC來落地的，這是第二個場景。
第三個場景是，視頻的推流，編解碼，涉及到大量的計算，這個計算是不可預測的，他們也是把推流邏輯放到UGC去跑。
還有一些就是說，我們基於我們的場景還做了一些改造，比如說目前比較火的AI，我們對這個Serverless和UGC的產品的機制做些改造，允許它支持常駐的進程，這個東西就不是個Serverless的概念，但是為了支持內部業務，我們在上面加了一層PaaS，來對外提供AI的服務，也是基於同一套的東西來做的。
Tags: Serverless 函數 架構 這個 可以 直接
文章來源：