隨著互聯網科技的發展，互聯網行業的分工也會像其它行業一樣逐漸細化，后端服務也是這樣被抽象出來，即BaaS（后端即服務）。在移動后端服務系統（MBaaS）中，云服務公司為移動應用、智能設備開發者提供整合云后端的邊界服，包括文件數據存儲、實時推送、即時通訊等實現難度較高的功能，以幫助開發者快速開發應用。

為什么Facebook、蘋果和Google都盯上后端云服務？

物聯網時代，在國外BaaS服務已經受到巨頭的重視，Facebook收購Parse、蘋果發布了CloudKit、Google收購了Firebase：Parse、CloudKit、Filrebase都是國外知名的BaaS類產品，巨頭們都希望通過BaaS服務來完善生態。在今年三月舉行的谷歌全球云用戶會議上，谷歌云服務高級副總裁黛安·格林（Diane Greene）表示，“這將是一個長期性、永久性業務”。

除了國外巨頭，國內也有數家創業公司瞄準于后端服務市場。云巴就是這樣一種后端云服務產品，主要面向智能硬件提供跨平臺、跨設備的實時消息交換服務。

云巴CEO張虎表示，對于開發者而言，有了后端服務，他們只需專注于具體業務和邏輯的實現，無需關心后端基礎設施構建、運維、服務器托管、網絡、性能調優等工作。對各巨頭來說，則各有各的布局：

對于Facebook來說，

在收購Parse后，該公司創始人IIya Sukhar已經成了僅次于馬克·扎克伯格的角色。在這次會議上，Facebook希望結束應用之間的信息孤島狀態，讓不同應用之間的內容能夠互通和無縫跳轉，于是就發布了一個名為AppLinks“協議”，但這個協議背后則需要Parse這樣的后端服務提供數據存儲、計算能力、Push通知等一系列技術支撐。

但很不幸的是，在激烈的云服務競爭中，Parse戰況不利，Facebook也于今年初關閉該服務。

而對于蘋果來說，

CloudKit可以提供完善且有彈性的后端解決方案，幫助開發者減輕編寫服務器代碼和維護服務器的需求。很明顯，蘋果此舉也是為了降低開發iOS應用的成本，維護iOS生態圈的繁榮。

除了收購Firebase，Google還在去年10月收購應用開發平臺Divshot，并將其整合至Firebase，使得應用開發變得更為簡單。

就像Firebase創始人James Tamplin在博客上說的那樣，Firebase和Google Cloud Platform可以很好的互補。也許像蘋果為iOS開發者提供了CloudKit那樣，Google也可以利用類似的服務來為Android生態圈的開發者們提供便利。

歸根結底，還是生態系統建設問題。

后端服務解決的是創業公司幾千萬成本的問題

比如，做出一個視頻的彈幕應用也會困難到要找第三方嗎？

后端服務出現之前，應用、智能硬件的開發需要為其消息傳輸、數據統計、儲存、實時通訊等功能自行搭建服務器架構，包括搭建數據庫與服務器集群等等。但是，產品本身和互聯網基礎工作關系不大，這些工作屬于產品企業的非主流業務，不僅復雜繁重，消耗的經歷和資源過多，并將拉長產品最終走向市場的開發周期。張虎透露，一個不熟悉后端服務的應用或智能硬件創業團隊，如果要自建后端服務，投入30人左右也需要耗時兩到三年才能完成，而且效果未必能夠專業，比如出現通訊延遲、消息發送成功率較低等。比如，某些通過藍牙傳輸的智能手表，在實時顯示上存在大約兩秒的延遲。而這些投入——包括租用服務器等，甚至要耗費數千萬人民幣的成本，使得非主流業務成本還高于主產品。

所以，除了包辦后端搭建，后端服務更重要的是解決效率問題——雙向通信、數據采集和統計等過程的快速和穩定。以實時通信功能為例，張虎解釋稱，在一個家庭的智能水網系統中，后端服務可以實時采集每個感應水流的傳感器的數據，然后分析每一段管道的水流速、流量，來達到監測水流是否泄漏的目的，同時可將結果發送到PC、手機端。如果發現水流速度和流量數據異常，那么系統可定位找出泄漏的部位。根據傳感器的密集程度，最高可定位到米級范圍。又比如說，智能兒童手表的對講功能，一端的用戶發出的音頻首先經過服務器轉錄，再到達另一端設備接收，等等。

在這些場景下，信息傳輸的速度和穩定性成為了決定設備服務性能好壞的關鍵因素。張虎表示，如今智能硬件早已不限于手機、平板、可穿戴的范疇，也加入了機器人、智能家居等等，面對逐漸增長的場景和海量數據，降低通訊延遲、保證推送穩定等提高通訊效率的做法就成為了后端云服務的主要任務。目前，國外頂尖的水平是，PubNub公司創造的全球網絡范圍內最大250毫秒的延遲，相對而言，云巴面對國內網絡則做到了60毫秒以內的延遲（注意是國內網絡）。

智能硬件與移動應用后端云服務有何不同？

以往，后端云服務主要針對于應用，張虎在創立云巴前，就主導創立了專注于為移動app提供后端服務的極光推送。而隨著物聯網和智能硬件的興起，屬于張虎第二次創業的云巴則針對智能硬件的實時通訊領域。

張虎表示，對比移動應用，智能設備開發對消息延遲更加敏感，對流量功耗上要求更高。在云巴的客戶中，主動申請付費服務的更多來自于智能硬件用戶。“移動應用的使用門檻較低，損失代價較少，消費者和開發者對其的期望較低。智能硬件不同，每一件產品都需要一定價格或成本來生產、買入，如果因為功能服務表現不佳，則更容易引來消費者的投訴，智能硬件商為了保證產品體驗，寧愿選擇付費。兩者的差異是互聯網的產品特點決定的。”這些選擇付費的客戶，云巴會為其提供通信的獨場通道。

那么問題來了：60毫秒的通信延遲是如何做到的？

張虎表示，目前兩個終端之間的通訊需要經過網關、路由等組成的二三十次跳數，那么保證消息的準確發送、快速發送，就需要減少網關的跳數，且突破單機限制。張虎表示，除了給付費用戶提供獨場通道這樣的普遍模式，云巴做得更多的是“細活”，從架構上進行調整。

將服務器分成多個集群

“也許我們都發現一個有趣的現象，一般游戲房間、聊天室等等一般最多容納300或500人，這個特別的數字主要來源于：對一臺服務器來說，300人的數據量是能夠維持較好體驗的水平。”張虎表示，一個架構的設計，即物理基因已經決定服務器的最佳容量，“但我們可以想辦法突破這個單機限制，把數據分布到不同的服務器上，讓通訊終端突破300人的限制。”

那為什么不可以把服務器變得更強大？

“其實最理想的方式也是把通訊降低到一跳，即所有任務在一個服務器完成然后發送，但這樣有一個悖論：當把一個服務器做到強大時，一旦這個服務器出現問題，那么所有服務都將失效。”為此，云巴把服務器按照業務邏輯分成若干集群，當一個集群由于壓力或者其他一些因素導致服務出現問題，那么另一個對等的集群就可以替代頂上，使服務穩定下來。

據悉，云巴目前使用的Cache集群是Couchbase集群和Redis集群。其中Couchbase可以讓數據自動在多個節點備份，單節點小，不會影響業務，而且支持業務自動分片(autosharing)。所謂自動分片，就是把同類型的業務自動分配到不同的機器上。

Erlang語言支持大量并發

每一個優秀的產品除了技術上的完善，還需要根據業務場景的打磨細節，根據細節做出一些取舍。比如，語言方面，云巴選擇了非常冷門的Erlang語言。

Erlang是一種面向并發和消息的函數式編程語言。Erlang設定的是競爭式的協程，在Erlang編程語言中，Erlang進程是并發并且獨立執行的，輕量并且有自己的堆棧空間。也就是說，每一個Erlang進程完全是私有的，兩個Erlang進程之間的堆棧空間不會被共享。這就好比高架橋和并行的車道，相互是獨立的，不能竄道，這樣很大程度提高了運輸的效率和速度。

對比C++、Java，Erlang只在一個小圈子內流行，但是，將線程放在用戶空間內自行調度（協程）是為了獲得盡可能大規模的并發能力，與go odejs的協作式不同，競爭式的決策則為大規模的多人開發提供了保證，避免某個協程的死循環或過量運算影響其他任務的進行。同時，erlang維護和開發了一整套中間層工具OTP（一次性可編程），而這些工具、框架也正是被用來開發諸如分布式服務器、錯誤處理、數據庫等應用的利器。Erlang不提倡防御式編程，它認為程序既然遇到錯誤就應該讓它崩潰，這樣一旦出現錯誤就可以第一時間被發現，加以補救措施，可以將損失降到最小。