接PaaS 調研:GAE與 AWS（上）
按理說，AWS應該不算PaaS，而應該算IaaS。那為什麼會放在這裡說，其實主要有兩個原因：一是AWS并不是很簡單的IaaS，因為它提供了大量的配套管理服務，雖然這些服務大多數都是通過Restful API的形式提供，但确實是可以程式設計來調用的；二是AWS本身也一個很有特色的“可程式設計”服務：Lambda服務。這個服務是可以嵌入在它提供的各種服務中，提供使用者自定義控制這些配套服務的能力，是以讓這些服務看起來更像平台PaaS，而脫離單純的IaaS。從嵌入Lambda的角度來看，AWS比GAE更加的激進，而不是遵循傳統的Web服務存在，是以能被更廣泛的網際網路業務所使用，而不僅僅是網際網路電商客戶。據說最近一些在Steam上很火的新遊戲，都有用到AWS的服務，包括Lambda。
AWS因為核心是圍繞其IaaS伺服器EC2來設計的，是以并沒有所謂的開發架構。而更多是針對EC2提供的各種透明的、基于網絡的優化功能。比如AutoScaling，就是基于使用時間、負載情況，對EC2執行個體進行伸縮，這裡補充一點，EC2的虛拟機也是支援Docker技術的，是以能比較友善的啟動、遷移。而另外一個叫ELB的服務，則是比較傳統的類似L5的負載均衡器。
能夠真正對AWS“程式設計”的，就是他們的Lambda服務。你可以多種語言來程式設計，包括 Node.js/Java/C#/Python ，來編寫一些觸發器産生的事件處理回調。在AWS的各種服務中，有很多服務都支援Lambda，如S3/DynamoDB/Kinesis，這些服務在收到請求，或者發生狀态變化的時候，都會觸發很多不同種類的事件，進而調用使用者自定義的這些代碼。比如對象存儲S3收到資料的時候，就會觸發代碼。這個功能就能很友善的用來做遊戲的存檔和讀檔。又或者資料庫服務DynamoDB在對資料進行Put或者Get操作的時候，也可以觸發你的代碼。當然，像Kinesis這種流式計算服務，本身就是需要使用者代碼來做離線的統計或資料處理的。
把使用者代碼嵌入到服務當中，而不是提供一個使用者代碼的服務容器，這個設計也許是需要服務IaaS而産生的。但這種靈活的設計，也把使用者從“标準開發架構”中解放出來，作為服務提供者，也無需像Google那樣提供各種語言和五花八門的WEB程式設計架構。由于遊戲伺服器端一般的通信模型和Web相去很遠，有大量的主動通知，以及線上資料回報的需求，是以使用Web那套架構肯定是不能滿足需求的，但好像AWS這種，遊戲客戶就可以自己寫一個簡單功能的GameServer，比如隻做簡單的廣播服務，而其他的存儲功能，都以Lambda的方式把遊戲邏輯和存儲服務結合起來，比較的省事。
AWS由于主要目标是賣EC2虛拟機，是以擁有很多更“通用”的運維管理工具。其中一個就是Benstalk，這是一個一個Web應用部署工具，通過內建Git來拉取和存儲你的軟體。對于僅僅是需要部署WEB應用的客戶來說，非常友善。而另外一個工具叫OpsWorks，這個是更通用的運維部署工具，看起來非常像Chef，你可以用它來部署任何軟體。這類工具都是通過先在你的虛拟機（部署目标機器）上，安裝一個Agent（代理程式），然後這個代理程式就可以從一個集中的軟體部署任務伺服器上，接受各種部署或配置的任務。使用者可以集中在一個界面上去部署軟體，修改配置，而且可以通過JSON格式的資料表，記錄各伺服器相同或者不同的配置，通過工具或自定義的腳本，自動化的在目标機器上做任何的部署操作。
AWS把對于EC2虛拟機的彈性部署，按負載自動伸縮能力，也應用在計費上。是以有一個叫CloudTrial的服務，其實就是按需付費的功能。這對于各種還在推廣開發期的業務特别友好，國外有很多獨立遊戲或者創業項目，都直接在AWS上開發測試。同時AWS也提供了所謂的CodePipeline工具，其實是一種持續內建工具，但部署部分就預設結合在AWS上。雖然GAE也有各種開發工具，但直接以持續內建（CI）的面貌來提供服務，并且結合雲服務，還是非常值得點贊的。畢竟現在在持續內建方面，大家都還是比較繁瑣的去設定各種伺服器環境，結合上運維系統，才能真正的“自動化內建”。而使用CodePipeline，開發者可以直接一鍵就把代碼部署到EC2虛拟機上，中間還經過自動化測試等等內建任務。這樣就又省了折騰持續內建軟體的工夫了。
最後說說CloudWatch服務，這和GAE的Analytics服務有一種重要不同，就是他主要面向的虛拟機的資料，而不是具體的服務。這個系統另外一個特色，就是可以從日志生成、搜集、監控、告警、報表一體化。可以說是一個通用的日志分析系統。使用者可以向CloudWatch發送自定義的名額，然後設定監控門檻值，這樣CloudWatch不但會在你設定的範圍内進行監控報警，而且還會存儲所有的這些日志，并用以生成統計報表和圖形。
所有的這些服務，給我的感覺，就是雖說AWS服務看起來沒有GAE那麼“有技術含量”，但由于其高度注重易用性，是以非常容易吸引人去使用。就是不管你是什麼平台或者架構，似乎都能用的上它的某幾個服務。而且所有的這些服務界面，都是統一接口模型、統一界面風格，讓人可以觸類旁通，學習起來一點不費勁。（當然這裡也有可能因為本身沒有提供太過複雜的功能）
由于AWS的主力産品是IaaS的EC2虛拟機，是以其線上計算的雲服務幾乎是沒有的。但是有豐富的其他配套服務，一點不比GAE遜色。它們大體來看分為兩類：
S3：對象存儲服務，以二進制塊的方式直接存放。一些遊戲開發商直接用來存使用者存檔資料。
EFS：和古老的NFS标準相容的分布式檔案系統。
CloudFront：具備全球節點的CDN服務。CDN國内使用者是比較熟悉的，但AWS的優勢在于其全球的機房和帶寬優勢。
RDS：這一塊就是“關系型資料庫”的服務類，包括了MySQL \ Orcale \ SQL Server \ PostgreSQL \ Aurora這些資料庫伺服器。這個服務就非常典型的是PaaS平台同的類型，但是AWS同樣也提供。而且最後這個Aurora資料庫，是AWS自己研發的，相容MySQL的産品，據他自己說比MySQL快很多。
DynamoDB：一種NoSQL資料庫，屬于Schemeless，也就是無需預建資料結構的。可以使用Hash搜尋（大概是等于号比對），也可以使用Range搜尋（大概是大于和小于号比對），這一點是很多NoSQL都不具備的。
ElastiCache：類似Memcached/Redis這樣的緩存伺服器叢集。這裡AWS直接提供叢集功能，就不需要自己去想辦法搭Redis叢集了。這也是比較典型的PaaS服務商會提供的服務。
SQS：分布式消息隊列服務。這個服務很特别，一般來說消息隊列服務，是用于比較大規模的伺服器系統，需要把計算任務分布放在多個硬體（虛拟機）上運作，而彼此之間又需要互相通訊，是以需要這種消息隊列服務。如開源的有ActiveMQ或ZeroMQ這種，但直接做成分布式的，還是比較少見的。這樣不用自己維護消息隊列服務叢集，隻需要使勁買EC2來添加計算節點，還是比較爽的。問題是這個服務的接口是Restful的，也就是說基于HTTP協定的，是以其延遲性應該是一個問題。如果在遊戲裡面使用，估計隻有一些不太在乎延遲的，觸發量較少的操作，會适合用這個服務，比如使用者從遊戲大廳進入到遊戲房間這種。
EMR：用來分析所有AWS提供的服務的日志。是一個強大的日志統計分析系統。
Kinesis：一種流式計算，類似Storm/Spark Streaming這種系統。值得注意的是，它同樣是可以直接調用所有的AWS服務生成的日志。這是AWS離線計算産品的一個通用特征，就是“本系統”類的服務，都可以直接調用，無需使用者自己去做各種接口或格式的轉換。
Machine Learning：著名的機器學習服務，同樣可以從AWS全線服務的日志中作為學習、測試資料集。秉承AWS的易用性設計目标，這個服務内置了大量的學習模型，很多功能都不需要使用者去自己編寫各種學習公式。而隻是需要開發者使用其互動式視覺工具，就可以完成對機器學習任務的配置和運作。
Redshift：PB級别的資料倉庫，屬于列式存儲系統（一般大容量的資料庫都是這種）
PaaS作為一個“雲”時代非常重要的概念，在實際的業務中應用卻遠沒有IaaS和SaaS的廣泛。究其原因，我覺得無非是其靈活性受限導緻的。比如GAE這種教科書式的PaaS平台，盡管提供了各種管理服務和多種語言架構，但最後還是受一個大的Web服務的框框所限制。而且背景關聯服務和PaaS服務存于一個沙箱中，雖然提供了很好的自動化運維的能力，但也造成了很多不便。除了一些很簡單的、典型的網際網路業務，很多其他的服務，都多多少少可能需要突破這些限制。——不過話說回來，這種PaaS對于标準的Web服務，确實是非常的友善，幾乎完全不需要自己去運維。
而以AWS為代表的，這種不太純正的PaaS，提供了大量的運維工具，實際上還是需要使用者自己去做很多運維的工作。但這樣也提供了極大的靈活性：你可以用IaaS的模式去使用AWS。同時AWS也提供了很多PaaS的配套管理服務，使用者同樣可以不去自己部署、配置這些服務。可以說AWS同時IaaS的靈活性，和PaaS的強大功能。不過AWS也不是天衣無縫，其中Lambda服務，就不屬于通用的業界标準，如果你把很多業務代碼用Lambda的方式來實作，那麼你就無法切換到别的雲服務商上去了。加上AWS服務大部分都是Restful API，是以網絡造成的延遲和帶寬占用，都不适合大量互動的線上服務——網絡遊戲。
最後展望一下PaaS的發展，個人覺得通用型PaaS應該是沒前途的。因為業務模型千差萬别，模型上的通用必然帶來功能上的限制，以及易用性上的确實。是以PaaS還是應該按不同的業務領域具體細分下去。現在網際網路業務比較大的業務領域有三類：一是電子商務類，二是遊戲類，三是資源社群類（如B站、今日頭條、各種FM、雲音樂APP等）。這三類業務都有其非常明顯的模式和需求差異。
比如電商類服務，一般所謂的“業務流”是一個重要需求，而且對于存儲安全性非常重視，但對于延遲要求就很低；而遊戲類則無法接受單向的HTTP協定，而且多數都要和遊戲用戶端引擎（Unity/Unreal什麼的）結合，對于延遲的要求非常高，大多數不能忍受超過300ms，存儲隻要可以無限擴容，安全性無需達到金融級都可以；社群類則對于大量的檔案存儲很分發是硬需求，需要更廣的部署地點，但業務邏輯一般不會過于複雜。
是以我們很難通過簡單原始的一個Web App應用架構，就把這三個方面的業務需求都框進去，而且除了處理HTTP請求，還有大量的業務通用功能，是可以作為服務做出來賣錢的，比如電商的訂單系統、遊戲的同步服務、社群的基礎社群功能等等。
最後的總結，就是PaaS服務必須要立足業務領域，面向業務中的通用邏輯，才能真正的做好一個PaaS雲。
無恥的小廣告，騰訊遊戲服務，專為遊戲開發服務： http://gcloud.qq.com/
【聲明】以上廣告本人沒有一分錢廣告費
本文來源于 韓大微信公衆号