為什么潮人都喜歡玩LED創意3D燈bearbrick KAWS解剖暴力熊燈

LED創意3D燈，bearbrick KAWS解剖，暴力熊燈，KAWS空山基，積木熊燈。

節能省電，24小時常亮不需要0.2度。面板為亞克力面板，不是玻璃，不易碎，快遞運輸安全放心。

生日禮物或者送朋友都非常合適，很有創意的一款臺燈，潮人必備！

如果你還想看或者買更多的款式就上網搜：童曉周工作室

作者介紹

韓偉，騰訊科技互娛研發部架構師，曾在網易任職8年，擔任無線事業部產品總監。多年來一直從事技術開發，擅長開發高性能系統，對于軟件架構設計也有豐富的經驗。個人的技術興趣在設計模式、軟件體系架構等提高軟件開發效率方面的知識。個人公眾號：韓大（handa1740168）。

一、起因

PaaS作為“云”的概念，已經流行了很久。從使用的角度上看，似乎就是：寫一個PHP，然后可以直接傳到服務器上，用戶就能通過某個URL訪問你寫的PHP了。——這確實極大地節省了開發和運維的工作量，因為這幾乎完全不用去部署安裝任何服務器端的軟件，甚至數據庫也給你裝好了。

但是因為各種各樣的原因，在國內PaaS的使用并不非常廣泛，有可能是因為沒有好的服務提供商（由于偉大墻的原因導致某些服務無法訪問）。另外，作為一個游戲服務器端的開發者，也在試圖從PaaS的概念中，學習如何提高游戲開發、運營效率的方法。所以就有了以下的研究。

本文主要的研究對象是Google出品的App Engine，以及Amazone的AWS兩個產品。實際上微軟、IBM也有類似的PaaS（Azure），由于時間精力原因只是粗粗瀏覽，并未深入。另外國內如阿里云也有一些近似PaaS的服務，但由于名氣不大，也不在這里描述了。

作為一個PaaS，我們可以注意到，主要會分成幾個層面來看，能比較準確地把握其特性。否則紛繁的技術名詞，各種支持方案，會讓人眼花繚亂。這幾個層面就是：

應用場景：一款PaaS希望解決的重點問題。

開發支持：PaaS是一種允許用戶的代碼運行的服務，那么可以運行怎樣的代碼，怎樣方便用戶上傳自己的代碼（或程序），如何管理這些代碼，是一個重要的問題。

運維管理：PaaS最讓人感到方便的，就是幾乎都號稱“無需用戶干預”的自動化運維，不需要用戶自己去部署服務器、配置軟件等，但這種能力到底是怎樣，也是一個非常重要的部分。

關聯配套：一個在PaaS上運行的程序，是完成不了太多的任務的，起碼需要有一個數據庫之類的存儲軟件。實際上的商業應用中，除了數據庫以外，還可能需要大量其他的配套程序，才能讓你的業務邏輯程序運行完整，比如Memcache，甚至Crontab這樣的程序。由于PaaS號稱“幫你運維”一切，所以很多都直接把這些服務也安裝部署好給你用，你只要用服務商提供的接入參數，直接使用即可。那么服務商提供怎樣的配套服務，有什么能力，是PaaS服務里面一個至關重要的特性，也是各種服務商“爭奇斗艷”的主戰場。

GAE(Google App Engine)

應用場景

Google自己的Web服務，是具備一整套“基礎設施”的，包括Web應用（如PHP）的運行框架、BigTable、GFS等廣為人知的服務器端軟件。所以Google App Engine的設計目標，就是讓用戶可以很方便地使用這一整套“基礎設施”。

從某種意義上來說，為了使用Google的配套服務，可能會比托管運行自己的Web應用程序更吸引人。Google的基礎設施，一般都是以“分布式”為賣點，提供超大承載量，和高度可用性。如果要自己去重建這一整套體系，對于一般的公司來說都幾乎是不可能的。但實際上真正需要用到這么大的承載量，也很可能不是“一般的公司”。不過慕名而來的使用者，在Google的保證下獲得信心上的安慰，也是一種重要的價值。

開發支持

Google不愧是以技術著稱的公司，其運行容器，支持Python/Java/PHP/Go等幾乎所有主流的編程語言，及這些編程語言在Web應用程序方面的標準框架，如Servlet for Java。看到這里，不禁嘆息于，游戲領域并沒有什么“應用框架標準”——所以游戲服務器程序的模型真是五花八門無奇不有，這也讓游戲服務的提供變得異常繁復困難。

GAE提供的開發工具，可以幫助開發者很方便地測試和部署代碼到PaaS上。這些開發工具包括一套結合Eclipse的IDE插件，以及一組命令上傳部署工具。用戶可以使用這些工具，好像開發測試本地程序一樣來使用。當然使用之前還是需要配置自己在GAE上的帳號之類的參數。

GAE另外一個很有特色（也許是缺點）的地方，就是開發者只能在“沙箱”里運行自己的程序，因此你不能用到代碼去操作socket、本地文件、線程等“原生資源”。因為有這樣的約束，所以開發者上傳的APP可以被認為是“無損”的自動部署到不同的硬件、網絡環境上。同時，GAE也提供了大量的配套服務，用來補償沙箱環境帶來的功能缺失。

運維管理

GAE的運維管理從代碼部署開始就是全套的。首先是支持從Maven這類代碼管理庫拉取程序部署，其次是可以部署到Google提供的全球機房，期間提供自動擴容和負載均衡。其中比較值得注意的是，它的運維環境還支持負載灰度和資源配額，也就是可以設置各種參數，來限制緩存空間、實例數、最大線程數、存儲空間、使用帶寬等。這些配額并不是簡單地基于IaaS的功能繼承而來，而是可以針對應用容器，或者各種配套服務為目標來設置。

GAE另外一個很棒的功能是所謂GoogleAnalytics功能。幾乎所有云服務商都會帶統計功能，但Google Anlytics因為是針對GAE這種全托管沙箱服務做統計分析的，所以可以獲得很多具體的服務統計的細節指標，而不僅僅是操作系統層次的CPU、內存、帶寬這種大路貨。我們自己部署任何一個服務，對于特定的服務進程，也會想要詳盡的統計分析數據，用以監控問題，如果是用GAE，這些服務都是Google提供的，當然統計也是它的應盡職責。

作為一個Web App的容器，GAE在運維配置工具上，提供了全套Web界面的操作軟件——Google Cloud Platform Console，可以配置諸如URL、靜態資源、MIME類型、根目錄、SSL等幾乎所有WebServer的配置內容。用了多年的Web Server配置文件終于可以束之高閣了。

當然，其它的管理服務也都提供了WEB的配置管理工具。如果你不想手工去配置這些，也可以使用GAE提供的Restful接口，去用代碼操作這些服務配置，這樣你可以自己寫一個喜歡的管理軟件，或者是寫個自動化的工具去做這類的配置工作。

關聯配套

GAE提供的配套服務，都是那些大名鼎鼎的Google系基礎服務，分為兩大類型，數十種細類：

1、存儲服務

App Engine Datastore：NoSQL對象存儲服務

Google Cloud SQL：在GAE上的MySQL，由于是關系數據庫，所以不能自動擴容

Google Cloud Storage：以Restful接口使用的分布式文件系統

2、輔助服務

定時任務：類似crontab這種

Memcache：最常見的Web后端緩存服務

Blobstore：一種“數據塊”存儲服務

Oauth API：身份鑒權認證服務

各種Messaging服務，包括電子郵件、短信、語音等……

全文搜索服務

圖形處理的API庫

各種常用的服務器端編程庫

從上面來看，最值得關注就是存儲類服務，畢竟Google是處理大數據的互聯網鼻祖。由于一般的商業互聯網服務，都很依賴一個容量大、方便擴容的數據存儲層，所以Google這套東西是非常有價值的。可惜作為游戲領域，數據大倒是大，就是其數據關系一般比較簡單，就是玩家的存檔數據而已，所以游戲開發商如果用這些BigTable、GFS為基礎的服務，從延遲性和成本上看，好像都不是特別有必要。

另外從輔助服務來看，細節到連crontab都提供，更不用說各種服務器開發庫，只有你想不到，沒有他沒準備到的。這對于開發者來說是一個很方便的地方，因為一來不需要到處找各種開源庫，二來也無需費口舌去和同事統一各種開發庫，只需要用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遜色。它們大體來看分為兩類：

1、存儲產品

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協議的，所以其延遲性應該是一個問題。如果在游戲里面使用，估計只有一些不太在乎延遲的，觸發量較少的操作，會適合用這個服務，比如用戶從游戲大廳進入到游戲房間這種。

2、離線計算產品

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云。