整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
智能手機普及之前，互聯網的能力還是有限的，那時候的互聯網還可以說是自由的。那這幾年到底發(fā)生了什么？什么殺死了分布式的互聯網，使之變成了商業(yè)壟斷為主？
我曾經寫過好幾篇和隱私相關的話題，閱讀量都不高。這不意外，沒有重大事件，通常人們不會關心這類話題。
最近有幾件事被引爆了，這個話題突然重新回到了人們視野中，所以可以再寫一篇了。
這幾件事分別是：Facebook 數據泄漏事件、互聯網公司是否偷偷用麥克風監(jiān)聽用戶，以及所謂大數據殺熟。
說到根本上，這幾件事是相關的，背后指向的是同一個問題，即：人們到底出讓了多少隱私，以及用戶為什么會在不知不覺中出讓這么多隱私。
在智能手機普及之前，互聯網的功能還很有限，人們的使用時長也不長。就算是 Facebook 這樣的霸主，在那個時代無非也就是諸多網頁中的一個。
人們沒有把那么多數據交給互聯網公司，離線和在線狀態(tài)還非常分明，遠不像今天絕大多數人實際上已經永遠在線，就算在飛機飛行途中也未必能獲得清凈。
在那個時候，雖然互聯網的模式早就是免費+廣告，人們出賣的隱私數據仍然是相當有限的。
然而幾年之后，事情就變成了完全不同的樣子，數據和流量變得極度集中，使得泄漏隱私和通過大數據計算給不同用戶標定不同價格成為可行。
在 2010 年之前，人們在互聯網上主要使用開放協議，我們用電子郵件傳遞消息、用 IRC/Gtalk(XMPP)聊天、用瀏覽器上網瀏覽信息、通過鏈接把各種資源連起來。
開放協議意思是：每個人都可以架設自己的服務，只要按照協議規(guī)范來，就可以讓不同人架設的服務器之間正常傳遞信息。
今天，區(qū)塊鏈興起之后，人們管這種模式叫做“分布式”，或者“去中心系統(tǒng)”。但僅僅幾年之前，互聯網本來就是去中心和分布式的，并不是像今天這樣所有數據和流量都掌握在幾家巨頭手里。
這幾年到底發(fā)生了什么？什么殺死了分布式的互聯網，使之變成了商業(yè)壟斷為主？
2009 年，智能手機的興起，不僅僅是提供了一種新的使用方式，同時以這種方式使得大量的傳統(tǒng)網絡通信協議不可用。前者被廣泛討論，后者人們往往意識不到。
簡單來說，智能手機的興起，至少殺死了 IRC/XMPP 這樣的及時通訊協議，部分消滅了 HTML/URL 這種互聯網基礎協議。
講述這段歷史不可能跳過蘋果這家公司，在 iPhone 出現的年代，蘋果還是一家有特色但不重要的公司，但它幾乎是憑自己一家公司開啟了整個移動互聯網時代，沒有蘋果的一系列決策，就沒有移動設備的普及。在這個過程中，有意或者無意的，蘋果也在另外一方面推動了歷史，使得我們進入了一個壟斷更密集、更封閉，但是更方便的時代。
先說第一個問題，IRC/XMPP 協議是如何被殺死以及如何改變生態(tài)的？
很多人指責微信是個封閉的花園，這個指責沒有問題。
但解決方案是什么呢？
這些人提供的解決方案通常是：使用另外一個商業(yè)軟件（Whatsapp/Telegram/iMessage）來代替微信。
這時候如果你提出一個問題，為什么不使用一個開放協議？比如 ：IRC 或者 XMPP 來代替微信這種聊天工具，對方給出的回應通常是“那些太難用了，普通人不會用”。
這個回答是錯誤的。
正確的回答是：移動互聯網時代開始之后，所有的傳統(tǒng)及時通訊協議都變得不可用了。不是因為難用，是因為在技術上不可用。
傳統(tǒng)的聊天協議，都包含了在線和離線狀態(tài)。用戶使用之前，首先要完成登錄，標記在線狀態(tài)，建立一條到服務器的永久鏈接，然后才可以發(fā)消息。（如果你用過 MSN 的話，應該會比較形象理解這個過程）。
移動互聯網開始之后，諾基亞 S60 和 Android 使用這些協議尚且沒問題。但 iOS 早期版本做了一個不可思議的舉動，這個系統(tǒng)上沒有后臺進程，一個應用進入后臺或者關閉屏幕之后，所有鏈接都會被系統(tǒng)斷開，但是系統(tǒng)會接收推送消息，幫助用戶再次喚醒應用。
早年諾基亞的粉絲是一直嘲笑 iPhone 這種設計愚蠢“一個沒有后臺進程的智能手機怎么能叫智能手機呢？”
事實的發(fā)展證明他們錯了，iPhone 成功了，其他人都死了。
為了待機時間和兼容當時運算能力仍然比較低的移動設備，無后臺進程，關閉鏈接，這些都是必要的優(yōu)化，不然手機待機時間會快速下降，使之不可用。
但這種措施給傳統(tǒng)通訊協議帶來了巨大的挑戰(zhàn)，沒有后臺進程（以及設備在移動帶來的網絡切換造成的網絡鏈接不穩(wěn)定），造成了 IRC 和 XMPP 這種有在線狀態(tài)的協議，要頻繁處理上線下線，用戶體驗極差。鏈接被關閉或者網絡切換時，對于服務器表現為 Session 超時，在桌面互聯網上這是一種異常狀態(tài)，需要等一段時間之后才能清理掉。
但在移動設備上這是頻繁發(fā)生的，這導致了服務器堆積了大量超時未釋放的Session，這使得服務器難以負荷，當時很多 XMPP 服務器上每天處理的鏈接請求甚至超過每天傳遞的消息數量。
這樣的服務當然不可持續(xù)下去，但是開放協議的修改效率是很低的，需要社區(qū)經過廣泛討論才能制訂出新的標準，然后各種開發(fā)者和廠商才能支持它。移動互聯網來勢兇猛，所有人都知道，這是未來，人們等不及了。
（網上還能找到在 Nokia Chat 中使用 Gtalk 的截圖，不容易）
誰填補了這個空白了？
是那些意識到了過去的開放協議缺點，又有很好基礎的人。
今天我們已經知道了最終的勝利者，他們是——基于郵件投遞模式的微信、基于短信投遞模式的 whatsapp、基于大規(guī)模分發(fā)地震等緊急消息模式的Line。它們有一個共同點：都是基于某種大規(guī)模的消息投遞模式開發(fā)的，沒有在線和離線狀態(tài)。
這個問題在后面的很多年，甚至一直到今天還有人會提出：“為什么微信沒有 QQ 那樣的在線狀態(tài)？”
張小龍回答過這個問題，答案是：“手機是永遠在線的”。
這句話是產品邏輯，同時也是技術邏輯。除了產品上用戶期待是手機持有者隨時能收到并回應，技術上也必須采用更輕型的“消息推送”類協議。
這三個產品出現的時間是：
都是在 2010 這個關鍵時間點前后出現的。
蘋果消滅后臺進程的原因當然不是為了殺死傳統(tǒng)互聯網協議，而是為了省電和移動設備可用性。但是這種突然的轉變，事實上造就了一段足夠長的真空時間，從而使得傳統(tǒng)開放協議更新協議的迭代模式不可持續(xù)。
新的商業(yè)公司拿到 MQTT 這些協議包裝一下，就成了自己的私有封閉協議，他們沒有和其他產品互相鏈接的意愿也沒必要，也就不會再跟隨開放協議。
蘋果以一家公司之力，通過一個小小的決策，直接改變了互聯網發(fā)展方向，造就了新的巨頭，進而這些巨頭又影響和改變了人類社會。順著這條脈絡看到今天，簡直是壯觀又可怕。
做為一個對比，IRC 協議從 2016 年開始討論下一代標準 irc v3，其中包括了一系列移動設備需要的功能。包括：無狀態(tài)鏈接，推送消息，歷史記錄……等。
但到現在 2018 年，距離可用還頗有距離，等到有好用的客戶端產品支持不知道要到哪一年了。和微信的成長對比一下，商業(yè)公司的優(yōu)勢的確太大了。
然后說第二個問題，HTML 和 URL 是如何幾乎被殺死？被 URL 連起來的互聯網是如何變成一個個孤島的？
如果你同時使用桌面互聯網和手機互聯網，也許能感覺到這是兩個邏輯完全不同的世界。
前者仍然保持著頁面+鏈接模式，后者是完全不同的一種模式，你用的是一個個 App。前者你仍然可以自由的挑選組合自己需要的信息，接受來自不同渠道的信息并且組合它們。但是后者，只有一個個巨型 App 做為入口，接受他們提供的被排序或者沒被排序的內容。
使用桌面互聯網的人，仍然在使用網址（URL）這種東西，別人通常會貼一個鏈接給你，你在瀏覽器里面打開它就可以使用了。但在移動設備上，別人給你一個鏈接，似乎沒什么地方可以貼，在這里，功能是一個個 App 組成的，瀏覽器在手機上不是核心位置。
桌面互聯網上 URL 和 Link 使得不同的網站鏈接在一起，用戶使用互聯網的過程，是通過鏈接在不同網站之間無縫跳轉的過程。
但在移動互聯網上，App 之間是割裂的，它們之間幾乎沒有跳轉關系。僅有的一些鏈接應用的場景，也遇到了各種商業(yè)競爭導致的干擾，中文有微信和支付寶互相干擾對方的鏈接跳轉；英文有 Twitter 阻斷Instagram鏈接；Facebook/Whatsapp 阻斷 Telegram 鏈接。
在移動互聯網上，不同品牌之間關系是對抗，而不是桌面互聯網的合作，當人們開始使用這種以 App 為核心的系統(tǒng)的時候，桌面互聯網的核心，瀏覽器/HTML/URL 就已經死了一半了。
這到底是怎么發(fā)生的？
移動互聯網和桌面互聯網都叫做被叫做“互聯網”，這是一個非常具有迷惑性的說法，它使得人們下意識認為移動互聯網是傳統(tǒng)互聯網的延伸。實際上不對，這是一個完全不一樣的世界，應用完全不一樣的規(guī)則。
2010 年，中文和英文業(yè)內同時有過一場大爭論，叫做 HTML5 和原生 App 之爭。爭論這兩個東西哪個更有未來？
2008 年雖然蘋果已經在 iOS 中提供了 App Store，但是實際上的快速增長是從 2010 年下半年才開始的，這場爭論不早不晚，確實是一個重要時間點。
這個爭論的重要意義在于——它最終決定了傳統(tǒng)互聯網的html頁面+鏈接，以瀏覽器為中心的模式是否能生存下去。
爭論的另外一方——原生 App，提供了一個完全相反的模式：它沒有頁面，沒有鏈接，數據被封閉在 App 之內形成孤島，以傳統(tǒng)互聯網擁護者看來，這是歷史的倒退。我們本來就是從數據封閉在每個軟件之內的時代走向的頁面+鏈接的互聯網時代，怎么突然就要倒退回去了？
事實證明了人們接受了App，拋棄了 HTML 和瀏覽器。
App Store 里面，幾乎沒有什么 App 是顯式表達鏈接存在的。雖然數據在 RESTful API 這一層仍然以鏈接形式存在，但是從 App 這個入口內，通常沒有輸入鏈接的地方。
想把 App 中看到的東西分享給朋友，如果這個 App 本身沒提供分享功能，幾乎是沒辦法的，只有截圖一條路。
雖然后期 iOS 提供了一系列分享相關的 API，但是這種模式就決定了，URL 所代表的“唯一定位符”，“每一個唯一的資源對應一個URL”這種模式在app的世界里已經消失了，HTML 和 App 之爭也很快就結束了。
2012 年，曾經擁護 HTML5 的 Facebook 投降認輸，重新開發(fā)原生 App，最終在后面的幾年里一路猛漲成為了中文世界之外的巨頭。
2014 年，Facebook 收購了聊天工具 Whatsapp，人們相當恐慌，所有的數據都集中在一個巨頭手里這還了得？少部分人轉投 Telegram，這個事件在 Telegram 用戶增長歷史曲線圖上清晰可見，是早期 Telegram 獲得的最大一波用戶增長。
人們的擔心是有道理的，在 PC 互聯網上，廠商獲取的信息少很多，那個時代最準確的廣告投放方式是 ——Google 提供的基于關鍵詞的廣告，因為搜索關鍵詞透露了用戶明確的意圖。
但移動時代到來之后，通過 App 獲取的用戶數據種類就多得太多了。
同樣也是 2014 年， Facebook 發(fā)布了跨應用廣告網絡，號稱可以跨越應用，從網站到手機 App 來統(tǒng)一完成用戶畫像。2012 年Facebook 收購的照片應用 Instagram，使得 Facebook 在移動平臺上可以獲得更多的用戶和數據，其他廠商沒有這種優(yōu)勢。
（Telegram Geek 網站做的用戶歷史數量統(tǒng)計圖，注意 2014 年 4 月份的用戶數量，2 月份的時候 Whatsapp 被收購）
之后 Facebook 逐年增長的廣告收入告訴了其他廠商，這樣做是對的。
社交關系+最大限度獲取用戶日?；钴S數據，最終可以轉換成巨額廣告收入。
于是所有廠商都沿用這個模式，用盡辦法去獲取能獲取的每一條用戶信息，無論是否之前被認為是用戶隱私。由此帶來的一系列“應用濫用權限”，是最終用戶能感受到的表面現象。背后的原因——就是這個盡量多的獲取數據，轉換成廣告盈利的模式相當有效。
到了這兩年，廣告網絡已經準確到前所未有的狀況，某些情況下已經不是廣告追著人走，而是廣告先于人一步出現。這一套用戶畫像模式威力巨大，不僅可以準確投放商業(yè)廣告，還可以投放政治宣傳，最終影響人的社會行為。
Facebook 數據泄漏影響了美國大選，這不是競選失敗的一方找理由，這就是真實發(fā)生的情況。同樣的道理，廣告準確到這種程度的時候，普通用戶已經難以理解背后發(fā)生了什么，干脆按照奧卡姆剃刀原則，找了一個最簡單的解釋：這些科技廠商在監(jiān)聽我。
不采用這一套模式的移動互聯網產品，差不多都死了。
今天流行的這些 App，無論是 Facebook/Instagram，還是中國的微信/微博/頭條/抖音/快手…都有一個共同的形容詞——“刷的停不下來”。
這種停不下來的背后，是這些 App 吞噬了用戶的使用時長。在手機的小屏幕上，通常情況 App 之間是零和競爭，被這個 App 搶走了，別的 App 就沒了。于是拿走用戶數據越多，越準確的 App 就會占領更多的時間，獲得更多的盈利同時順便擠死對手。這里不再有互相鏈接的互聯網了，每個 App 本身就是世界的一部分。
如果回到 2010 年，回到 HTML5 和 App 之爭的時間點看，還有其他可能性嗎？其實仍然是有的。
2012 年 Facebook 宣布放棄 HTML5 App 的時候，說過理由：“瀏覽器性能太差了，無法負擔應用的需要，并且還說了希望各廠商改進瀏覽器。”
理想情況下瀏覽器廠商會競爭，推出性能更好的瀏覽器。但現實情況很悲慘，蘋果很長一段時間內 iOS 系統(tǒng)上不允許使用其他瀏覽器內核，必須只能使用 iOS 自帶的 Webkit 內核和js解析器，并且在 iOS9 之前第三方瀏覽器不能使用 JIT 引擎，所以效率永遠比 Safari 低一個級別。
后來這種限制稍微放寬了一點，性能上可以和 Safari 一樣了，但安全模型仍然不同，功能上還有很多限制。這些限制都導致了第三方瀏覽器不可能在 iOS 平臺上有所做為，只能跟著蘋果緩慢殘缺的步驟走。
盡管在 P C市場上 Chrome 高效的 V8 引擎已經徹底改變了瀏覽器市場的局面，使得一系列 W3C 標準可以落實被用戶使用，但在 iOS 上仍然是沒有辦法的。
當然，Chrome 還是接受了這種羞辱，在 iOS 上使用和 Safari 一樣的內核，受更多的限制。但是即使如此，Chrome仍然表現比 Safari 更出色。
憑借對Google相關服務支持更好，勉強也在 iOS 上獲得了足夠的用戶。但是其他獨立瀏覽器廠商，比如：Firefox可就悲慘了，蘋果即使后來放寬了這個限制，也只允許使用WebKit 內核，不允許使用 Firefox 自己的內核，Firefox就沒存在價值了。
當然過了很多年，Firefox 也上了一個使用 WebKit 內核的版本，勉強在 iOS 上占了個位置，但這有什么用呢？
在 Android 和 PC 上，Firefox的獨立引擎性能是能和 Chrome 這種怪物抗衡的，在 iOS 上不存在性能的競爭，大家都受一樣的限制。存在一個獨立的瀏覽器引擎，可以保證整個行業(yè)是中立和標準的。
Firefox 標準化的更好，在瀏覽器里面加入廠商專有內容的動力更小，考慮到微軟專屬的 IE4 曾經如何拖累了整個行業(yè)，保持Firefox獨立瀏覽器占據足夠的份額，是保持整個互聯網世界開放的重要基礎。
很難說蘋果刻意殺死了瀏覽器廠商，但客觀上，蘋果的限制，以及很長時間內 iOS 自帶的 webkit 內核和 JS 引擎效率低下（比同時期 Chrome 內核低幾個數量級），使得 HTML5 App 難以獲得流暢的用戶體驗，最終結果就是導致 HTML 在移動平臺應用競爭中失敗，Web App 成了一個不可行的想法。
蘋果確立了以 App 和 App Store 分發(fā)為基礎的移動設備事實上的標準，其他廠商也都紛紛跟進，再也沒有人想在移動設備上復制更開放的傳統(tǒng)互聯網了。
獨立瀏覽器引擎只剩下了Firefox憑借龐大的歷史積累的粉絲群體，勉強抗到了今天。
2013 年，我在給紐約時報做技術顧問的時候，曾經和他們討論過，是否可以以 Web App 做為移動設備的核心？
因為眾所周知的原因，大家都心知肚明它的 App 必然沒法在中國地區(qū)通過 App Store 分發(fā)，當時 ft.com 主推 Web，在瀏覽器里面實現全部功能（2011 年 FT 和蘋果因為訂閱用戶發(fā)生了糾紛，就此 FT 放棄原生 App，有點類似公眾號打賞分成之爭），但再三比較之后，我們最后還是在 Web 和 App 之間選擇了App。
原因和 Facebook 一樣，Web 應用難以滿足需求。
這件事最尷尬的地方在于：Android 上瀏覽器體驗不錯，有好的多性能也高的多的瀏覽器。但 Android 上分發(fā) App 限制不大，就算不通過 Store 分發(fā)，仍然可以自己下載 apk 安裝，這種情況下如果不是為了情懷，傾向 Web App 的動力不足。
iOS 上只能通過 Store 分發(fā)，在這里使用 Web App 可以繞開分發(fā)的限制，但同時瀏覽器體驗非常差，幾乎是不可用的，開發(fā) Web App意義不大。
（ft.com 還一直維護著一個如何開發(fā) HTML5 web app 的教程…可惜沒多少人真的和他們一樣這樣做）
Web app 有沒有成功的可能性？
到了最近微信倒是給出了一個證據：微信小程序就是HTML5 app。歷史繞了一圈之后，它在另外一個巨頭的圍墻內復活了……
盡管微信小程序的模式，仍然是需要審核上架的 Store模式。但是，它畢竟是 HTML5 App，這足以說明如果有合適的條件，HTML5 App 曾經是有可能戰(zhàn)勝原生 App 的。如果 HTML5 勝利了，今天的移動互聯網，理應比我們現在看到的開放的多。
和前面所說的移動互聯網殺死聊天協議，最終導致改變了人類社會一樣。以蘋果為主要推動者的移動互聯網，嚴重傾斜于 App 模式，有意或無意的使得基于頁面和鏈接的傳統(tǒng)互聯網模式，在移動平臺上消亡，從而推動了收集更多數據的廣告商業(yè)模式發(fā)展，形成了幾大超級 App。在吞噬傳統(tǒng)互聯網的同時，也順便改變了人類社會。
互聯網到移動互聯網的發(fā)展歷史，就是人類社會放棄隱私的歷史。安全、方便、隱私、體驗這些概念本身都是沖突的，這些年互聯網的發(fā)展，是充分使用了人類“懶惰”（此處無貶義）這種特質，形成了今天這樣的商業(yè)模式，這是人類與生俱來的特征，難以被打破。
前面說了很多蘋果在這個過程中起到的作用，但這并不是蘋果的錯，蘋果所有的做法在那個時代都是正確的，這些辦法綜合起來讓體驗和耗電量達到了平衡，使得移動設備變得可用。
Push 喚醒 App、力推 App 模式打壓瀏覽器、殺死 Flash…如果沒有這些極端的辦法，我們到今天可能還在使用黑莓，移動互聯網時代也難以開啟。
整個過程中，Android 雖然更加開放，但在開始的幾年里面 Android 性能和體驗慘不忍睹，用戶和整個行業(yè)一起站在了蘋果模式這邊。
我們現在看到的更封閉，更集中的移動互聯網世界，是人們自己選擇的結果。
歷史一次又一次證明了，人們在方便和隱私之間，大多數人會選擇方便。李彥宏說的中國人會如此選擇，這有點片面了，事實證明全世界人都會這么選。
不信你看，這邊 Facebook 鬧出這么大風波，另外一邊各種智能音箱的銷量還在上漲，似乎沒人覺得有問題。智能音箱就是一種出賣更多隱私，換取一點點方便的產品。
我不否認市場上存在非常注意保護隱私的語音助理類設備和軟件，但無論廠商多注意隱私保護，它為了換取方便而導致了更多用戶數據離開自己的控制，這是毫無疑問的，人們不在乎。
2010年是移動互聯網興起的年代，可惜實際結果是把互聯網切成了幾個小塊。2010 年同時還是比特幣興起的年代，那個時候它開始脫離創(chuàng)始人的那個小圈子，被更多普通人所知，但仍然沒引起廣泛注意。
但到了最近，區(qū)塊鏈的熱潮已經難以阻擋了，即使最近幣價下跌不少，仍然是不可阻擋的熱潮。
區(qū)塊鏈是這些年來除了BT 下載之外應用最廣泛的分布式應用，在幾年之前，所有 P2P 系統(tǒng)都難逃被冠以“黑暗”，“犯罪”之名，很難成為大眾話題，更難以讓普通人嘗試。但區(qū)塊鏈通過資產增值的預期竟然做到了這一點，人們開始談論它、嘗試它，并且親身投入這個領域。
盡管這個領域仍然非常早期，充滿了風險，但也必須看到另外一個角度，它帶來了前所未有的變化。
在一個人們如此在乎產品體驗的時代，區(qū)塊鏈應用使得人們愿意嘗試和接受各種非常早期、不成熟的產品，重新開啟了競爭，這就是未來的希望所在。
作者：霍炬，科技 blogger，連續(xù)創(chuàng)業(yè)者，技術愛好者，有一個公眾帳號 “歪理邪說”（ID：wxieshuo）。
者按：高可用架構分享及傳播在架構領域具有典型意義的文章，本文由桑世龍在高可用架構群分享。轉載請注明來自高可用架構公眾號「 ArchNotes 」。
桑世龍，天津空弦科技 CTO，開源項目 Moajs 作者，Node.js 技術傳道者。曾就職在新浪、網秦，曾做過前端、后端、數據分析、移動端負責人、做過首席架構師、技術總監(jiān)，全棧技術實踐者。目前主要關注技術架構和團隊梯隊建設方向。
“JavaScript 是世界上使用最廣泛的語言，沒有之一，包括后端開發(fā)工程師也更愛使用 JavaScript?！?——stackoverflow
雖然 Node.js 在國內沒有盛行，但據 StackOverflow 2016 年開發(fā)者調查，其中 Node.js 、全棧、JavaScript 相關的技術在多個領域（包括全棧、后端）都有排名領先。
（http://stackoverflow.com/research/developer-survey-2016）
后端分布
（http://stackoverflow.com/research/developer-survey-2016）
Node.js 與生俱來的 2 個特性：
event-driven
non-blocking I/O
以前總強調的異步特性，到今天異步已經不是明顯優(yōu)勢。因此除了性能，其他都是?。ú蛔悖?？
1、Callback hell 問題
目前已經很好的解決了。promise / generator / async 后面會講。
2、包管理
npm 已經是開源世界里最大的包管理器了，模塊非常豐富（25.6萬 ）。
Node.js’ package ecosystem, npm, is the largest ecosystem of open source libraries in the world.
以前我們總是喜歡拿異步說事兒，現在我們拿 Node.js 的強大的生態(tài)來炫耀。
空弦科技做的是基于云倉儲的 SaaS 服務，給中小賣家提供服務，核心系統(tǒng)是進銷存、訂單池、WMS。
先看一下我們的瓶頸在哪里
人（天津不好招人）。Node.js 招不到，好多都是從 Java 轉的，前端也不好找，好多也是從 Java 轉的，我們相當于從 0 開始組建團隊
開發(fā)速度。創(chuàng)業(yè)公司 5 分鐘要造火箭，大家都懂。所以讓開發(fā)快速進入狀態(tài)，提高開發(fā)速度，對我們來說至關重要。
穩(wěn)定。在沒有專業(yè)運維人員的情況下，如何保證系統(tǒng)可用、穩(wěn)定。
于是就引出了我認為的Node.js 好處
同樣不優(yōu)化，性能比大部分語言好。即使優(yōu)化，也比其他語言簡單，比如Java。
有足夠多的選擇和架構的平衡。
如實在不夠，Java 補。
Node.js 給了我們足夠的選擇工具
可以采用面向過程
可以面向對象
可以函數式
甚至可以用各種編譯器 coffee、typescript、babel（es）等。對于從 0 開始的團隊來講，可以先面向過程、然后隨著團隊的成熟度，一點一點增加難度。
提供好的基礎和包管理工具
測試相關 tdd / bdd 測試覆蓋率
規(guī)范化 standard、各種 lint、hint
構建相關 gulp、grunt、webpack，大量插件
生成器 yo 等
包管理工具 npm 足夠簡單易用
以上這些都做大型軟件的基礎，Node.js 在這方面做得非常好
特定場景的快速
很多人把 MEAN 組合（比如 mean.io）起來，這樣做的好處是如果熟悉，開發(fā)速度確實會非?？?，但是難度太大，很少有人能搞的定。metetor 模糊了服務端和客戶端，是同構的典型應用，對于實時場景是非常高效的。這種東西都算特定場景的快速，一般不敢輕易上，調優(yōu)難度非常大，如果有人能 cover 的住，在初期是非常高效的。
總結需求：可以簡單，可以難；可以快、也可以慢；可以開發(fā)大型軟件
如果以上不滿足咋辦？這時就需要架構平衡了。
在架構中各自做各自合適的事兒就好，我們很坦然的面對 Node.js 的優(yōu)點和缺點，做好架構平衡。
1、在語言層面可以做，那語言層面做
已有大量 npm 上的模塊 ( 目前在 25.6 萬個以上 )
自己造輪子 ( 站在海量包上 簡單語法 npm = 快速 )
使用 Node.js 里的 （nan https://github.com/nodejs/nan）自己包裝 C/C++ 輪子
從上面看，絕大部分需求都可以滿足了
2、如果語言層面搞不定，那就架構層面做
業(yè)務邊界、模塊拆分、面向服務
MQ、RPC、cache
運維、監(jiān)控、自動化
稍微解釋一下，首先，架構與 Node.js 沒直接關系。其次，架構師常用的東東有足夠的 Node.js 模塊支持，比如 MQ，像 Rabbitmq 有比較好的 Node 模塊支持，RPC 里 Thrift、Grpc、Tchannel 支持的都不錯，我們使用的 senecajs，Redis，ioredis 等軟件，后面做 HA 都是一樣的。
3、如果架構層面也解決不了……
合適的場景用合適的東西。有很多東西是 Node.js 不擅長，又不在架構范疇里的，咋辦？如實在不夠，Java 補（嚴格點，應該叫其他語言補）
比如復雜 excel 生成
比如 apns 推送（Go 做其實也很好，不過除了我，沒人能維護）
但凡是 Java 或其他語言里比較成熟的庫，可以作為獨立服務使用的，都可以做 Node.js 的支持。避免過多的時間用在造輪子上，影響開發(fā)進度。
4、Node.js 優(yōu)劣分析
執(zhí)行效率，同樣不優(yōu)化，性能比大部分語言好。
開發(fā)效率，Node.js 本身比較簡單，開發(fā)效率還是比較高的。完善的生態(tài)，比如測試、工具、npm 大量模塊。
缺少 Rails 一樣的大殺器，scaffold 腳手架，ORM 太弱。
Node.js 的 Web 開發(fā)框架 Express、Koa 等，簡單，小巧，精致，缺點是集成度不夠，目前已有的 MEAN 或 yo 或 sails 等總有某種方面的不滿意
選擇 Node.js 我們需要做的包括：固化項目結構；限定 ORM；自定義腳手架。
由于 Node.js 已經提供以下特性，因此你可以在 30 分鐘完成一個腳手架。
cli 命令模塊，編寫非常容易
基于 JavaScript的模板引擎（知名的 30 ）
我們用Node.js做什么？
API服務
前端（moa-frontend）
SDK（OAuth Provider）
輔助開發(fā) cli 工具
目前進度
使用 0.10.38，開發(fā) Moajs 框架，Express / MongoDB
pm2 部署,前后端分離，阿里云的 slb 負載，alinode 監(jiān)控
moa-api,moa-frontend,moa-h5 (未能用)
使用 Redis 緩存，Rabbitmq，senaca 作為 RPC
一些正在建設的方面
使用 kong 作為 API gateway
consul 做服務發(fā)現和配置
上 elk 作為日志分析處理
使用 docker compose 作為本地開發(fā)環(huán)境
線上 docker
打算進行技術棧更新，包括Nodejs 4.x（預計今年 6 月份；Koa（generator/co）；es6/es7 ( babel )。
4.x 在內存和性能上都有非常大的提升，新的語言特性上，異步流程和語法上都需要學習，故不急于升級，待人才梯隊完善。
目前的做法是小步快走，一次只上一樣新技術；另外形成梯隊，即可準備上新東西；善用 npm，實現 3 化：模塊化、最小化、服務化
MEAN 架構
MEAN 是目前最潮的全棧 JavaScript架構。MEAN 是一個 JavaScript平臺的現代 Web 開發(fā)框架總稱，它是 MongoDB Express AngularJS Node.js 四個框架的第一個字母組合。它與傳統(tǒng) LAMP 一樣是一種全套開發(fā)工具的簡稱。
從我的角度看
MySQL 用 MongoDB 替換，NoSQL 里最像 rdbms 的，從開發(fā)和性能都是有優(yōu)勢的（參看老畢在高可用架構群分享文章：MongoDB 2015回顧：全新里程碑式的WiredTiger存儲引擎）。
Angular 的出現是一個時代，IoC，雙向綁定，指令等都曾讓無數熱血沸騰。
Node.js 提供了完全的生態(tài)和工具鏈，你要的它基本都有，感謝 npm，早些年 Node.js 的性能甩 php 幾條街的。
Express 作為 Node.js 示范項目，它非常精簡，是比較合適的 Web 框架
我為什么選擇 MEAN 架構？
成熟、穩(wěn)定，簡單，有問題我們能 cover 住，所以我們選了 Node.js。
把握趨勢，以后 Node.js 的前景非常看好，尤其前后端統(tǒng)一，全棧方向。
在架構上可以屏蔽可能風險，不孤注一擲，也不會一葉障目，合理的使用其他語言，只要每個功能都以服務出現，至于它是什么語言寫的，并不重要。
招人成本的性價比相對較高，技術棧新，容易吸引人才。
最重要的一件事兒，是當有問題的時候，有人能 cover 住，在創(chuàng)業(yè)初期這是最最重要的事兒。
Node.js最新Web技術棧
https://cnodejs.org/topic/55651bf07d4c64752effb4b1
異步流程控制
JavaScript流程控制的演進過程，分以下 5 部分：
回調函數Callbacks
異步JavaScript
Promise / a+ 規(guī)范
生成器Generators/ yield ( es6 )
Async/ await ( es7 )
目前所有版本都支持 Promise / a+ 規(guī)范
目前 Node.js 4.0 支持 Generators/ yield
目前不支持 es7 里的 Async/await，但可以通過 babel 實現
整體來說，對異步流程控制解決的還是比較好的。
Node.js 最新技術棧之 Promise 篇
https://cnodejs.org/topic/560dbc826a1ed28204a1e7de
業(yè)務邊界優(yōu)化
創(chuàng)業(yè)公司有很多可變性，要做的系統(tǒng)也無數，如何保證業(yè)務系統(tǒng)的邊界是非常難的，我們其實走了很多彎路。
靜態(tài) API 理論
當需求和 UE 定下來之后，就開始編寫靜態(tài) API，這樣 APP、H5、前端就可以使用靜態(tài) API 完成功能，而后端也可以以靜態(tài) API 為標準來實現，整體效率還是比較高的。
API 的最佳實踐
http://developer.github.com/v3/ （嚴格的restful）
微博 API (可讀性強，相對比較傳統(tǒng))，我們采用的微博 API 類似的，約定結構也是類似的。
res.api is an express middleware for render json api , it convention over api format like this :
{
data : {},
status: {
code : x,
msg : ‘some message’
}
}
客戶端 API 開發(fā)總結
https://cnodejs.org/topic/552b3b9382388cec50cf6d95
約定結構
和 Java 開發(fā)里的目錄結構類似，該分層的分層，適當的按照 Express/Koa 增加中間件、路由等目錄，便于開發(fā)。
使用 npm 模塊化
使用 npmjs 的 private 私有模塊（目前做法）
使用 npm 的本地模塊開發(fā)方法（測試和部署都非?？欤?/p>
搭建 npm 私服（todo）
編寫生成器
在 Web 開發(fā)里，寫了 Moajs 生成器，類似于 rails
moag order name:string password:string
其他開發(fā)，如 iOS 開發(fā)里模型校驗非常煩,于是寫了一個 json2objc 命令行工具，讀取 json，生成 oc 代碼，可以節(jié)省不少時間
Moajs 框架和前后端分離
前端 （moa-frontend https://github.com/moajs/moa-frontend）
public下面的采用 Nginx 做反向代理
其他的采用 Express Jade 精簡代碼（ajax與后端交互）
后端（moa-api https://github.com/moajs/moa-api）
moa 生成器，即上面講的生成器 scaffold。
moa-frontend技術棧：Express /Jade /bootstrap、bootstrap-table /jQuery /gulp /Nginx
moa-api技術棧：
base2(mirco kernel) https://github.com/base-n/base2-core
mongoose https://github.com/Automattic/mongoose
bluebird https://github.com/petkaantonov/bluebird
res.api https://github.com/moajs/res.api
Features
自動加載路由，自帶用戶管理，使用 jsonwebtoken 做用戶鑒權
支持 MongoDB 配置，集成 mongoosedao，快速寫 CRUD 等 dao 接口
支持 migrate 測試，Mocha 測試
默認集成 res.api，便于寫接口
集成 supervisor，代碼變動，自動重載，gulp 自動監(jiān)控文件變動，跑測試
gulp routes 生成路由說明
使用 log4js 記錄日志
從開發(fā)效果上看，還是非?？斓?，非常穩(wěn)定的。
Moajs框架演進之路
https://cnodejs.org/topic/567e2388aacb6923221de469
Node.js 相關工具
grunt/gulp/fis/webpack
bower/spm/npm
tdd/bdd cucumber/mocha
standard
babel/typescript/coffee
前端開發(fā)四階段
Html/css/js（基礎）
jQuery、jQuery-ui，Extjs（曾經流行）
Backbone（mvc），Angularjs、Vuejs（當前流行）
React組件化（未來趨勢）、Vuejs
Vuejs 綜合 Angular 和 React 的優(yōu)點，應該是下一個流行趨勢。
Hybrid 開發(fā)
Hybrid 混搭開發(fā)是指使用 H5 技術開發(fā)的跨瀏覽器應用，并最終可以將 html5/js/css 等打包成 apk 和 ipa 包的開發(fā)方式。它也可以上傳到應用商店，提供給移動設備進行安裝。它最大的好處是通過 H5 開發(fā)一次，就可以在多個平臺上安裝。
未來將會是JavaScript一統(tǒng)天下（Node.js 做后端，傳統(tǒng) Web 和 H5 使用 Javasctipt，更智能的工具如 gulp，更簡單的寫法如 coffeescript 等）。H5 大行其道（網速變快，硬件內存增長）。
跨平臺
C/S 架構到 B/S 架構，這個大部分都清楚，不多說。
移動端加殼，在瀏覽器上做文章，把頁面生成各個移動端的 app 文件。
PC 端加殼，一樣是延續(xù)瀏覽器做文章，不過這次把頁面生成各個 PC 平臺的可執(zhí)行文件。
node-webkit is renamed （NW.js https://github.com/nwjs/nw.js）
Electron https://github.com/atom/electron - Build cross platform desktop apps with web technologies
目前比較火的編輯器都是基于 Electron 打包：
Atom https://github.com/atom/atom
vscode https://github.com/Microsoft/vscode
組件化：統(tǒng)一用法
React 的出現影響最大的是 JSX 的出現，解決了長久以來組件化的問題：
我們反復的折騰 JavaScript，依然無法搞定
我們嘗試 OO，比如 extjs
我們最終還是找個中間格式 JSX
單純的 React 只是 view 層面的，還不足以應用，于是又有 Redux。核心概念：Actions、Reducers 和 Store，簡單點說就是狀態(tài)控制，然后再結合打包加殼，變成 app 或可執(zhí)行文件。iOS、Android 上用 Cordova，PC 上使用 Electron。
總結
組件定義好（React）
控制好組件之間的狀態(tài)切換（Redux）
打包或加殼（Cordova or Electron）
這部分其實組件化了前端，那么能否用這樣的思想來組件化移動端呢？
react-native
https://github.com/facebook/react-native)
A framework for building native apps with React.
http://facebook.github.io/react-native/
簡單點說，就是用 React 的語法來組件化 iOS 或 Android SDK。它們都在告訴我們，你們以后就玩這些組件就好了，你不需要知道復雜的 SDK 是什么。
當下流行玩法
Medis is a beautiful, easy-to-use Redis management application built on the modern web with Electron, React, and Redux. It’s powered by many awesome Node.js modules, especially ioredis and ssh2.
https://github.com/luin/medis
技術點
使用 Node.js 模塊
使用 Webpack 構建
使用 React（視圖） Redux（控制邏輯）
使用 Electron 加殼打包
親，你看到未來了么？
講了 Node 工具，前端 4 階段，hybrid，各種跨平臺，目前就是為了介紹 Node 全棧的各種可能，下面講一下如何能做到 Node 全棧？
全棧核心，后端不會的 UI（界面相關），前端不會的 DB（業(yè)務相關），只要打通這 2 個要點，其他就比較容易了。
1、從后端轉
做后端的人對數據庫是比較熟悉，無論 MongoDB，還是 Mysql、Postgres，對前端理解比較弱，會基本的Html，Css，模板引擎等比較熟悉。
4 階段循序漸進，build 與工具齊飛，前端開發(fā) 4 階段，我的感覺是按照順序，循序漸進。
Html / Css / JavaScript（基礎）
jQuery、jQuery-ui，Extjs（曾經流行）
Backbone，Angularjs（當前流行）、Vuejs
React（未來趨勢）、Vuejs
Vuejs 綜合 Angular 和 React 的優(yōu)點，應該是下一個流行趨勢
2、從前端轉
從前端往后端轉，API 接口非常容易學會，像 Express、Koa 這類框架大部分人一周就能學會，最難的是對 DB、ER 模型的理解，說直白點，還是業(yè)務需求落地的理解
我們來想想一般的前端有什么技能？
Html
Css（兼容瀏覽器）
JavaScript會點（可能更多的是會點 jQuery）
PS切圖
Firebug 和 Chrome debuger會的人都不太多
用過幾個框架，大部分人是僅僅會用
英語一般
Svn / Git 會一點
那么他們如果想在前端領域做的更深有哪些難點呢？
基礎：OO，設計模式，命令，Shell，構建等
編程思想上的理解（MVC、IoC，規(guī)約等）
區(qū)分概念
外圍驗收，如 H5 和 hybird 等
追趕趨勢，如何學習新東西
以上皆是痛點。所以比較好的辦法：
玩轉 npm、gulp 這樣的前端工具類（此時還是前端）
使用 Node 做前后端分離（此時還是前端）
Express、Koa 這類框架
Jade、ejs 等模板引擎
Nginx
玩轉【后端】異步流程處理 promise / es6 的 ( generator | yield) / es7 ( async|await )
玩轉【后端】MongoDB、Mysql 對應的 Node 模塊
從我們的經驗看，這樣是比較靠譜的。https://github.com/moajs/moa-frontend就是最簡單前后端分離，里面沒有任何和 DB 相關。
技術棧
Express
Jade
bootstrap，bootstrap-table
jQuery
gulp
Nginx
一般的前端都非常容易學會，基本 2 周就已經非常熟練了，我的計劃是半年后，讓他們接觸【異步流程處理】和【數據庫】相關內容，學習后端代碼，就可以全棧了
3、從移動端轉
移動端分：native 原生開發(fā)，hybrid 混搭式開發(fā)。原生開發(fā)就是 iOS 用 oc/swift，Android 用 Java 或 Scala 等，就算偶爾嵌入 webview，能玩 JavaScript的機會也非常好少。所以移動端轉全棧的方法，最好是從 cordova（以前叫 phonegap）開始做 hybrid開發(fā)。只要關注 www 目錄里的 H5 即可，比較簡單。如果 H5 不足以完成的情況下，可以編寫 cordova 插件，即通過插件讓 JavaScript調用原生s dk 里功能。cordova 的 cli 可以通過 npm 安裝，學習 npm 的好方法，學習 gulp 構建工具。
只要入了 H5 的坑，其實就非常好辦了。
然后 H5、Zeptojs、iScroll、fastclick 等
然后微信常用的，如weui、vux（vue weui）、jmui（react weui）
然后可以玩點框架，比如 jQuery mobile，Sencha touch
然后可以玩點高級貨，ionicframework（基于Angularjs、cordova）
然后前端 4 階段，依次打怪升級
然后 Node.js
這個基本上是我走的路，從 2010 年寫 IOS、做 phonegap（當時是0.9.3）一路走到現在的總結吧。
Node.js 可能是一場春夢，
也可能一個變革機遇；
我們更相信它是變革機遇，
請拭目以待！
Q1 第一季度
IO.js 1.0.0 發(fā)布
Joyent 推進建立 Node.js 基金會
Joyent，IBM，Microsoft，PayPal，Fidelity，SAP and The Linux Foundation Join Forces to Support Node.js Community With Neutral and Open Governance
IO.js 和 Node.js 和解提案
Q2 第二季度
npm 支持私有模塊
Node 項目領導人 TJ Fontaine 逐步解除核心身份并離開 Joyent 公司
A changing of the guard in Nodeland
Node.js 和 IO.js 在 Node 基金會下合并情況
Q3第三季度
4.0 版本發(fā)布，即新的 1.0 版本
Q4第四季度
Node v4.2.0，首個長期支持版本（LTS）
Apigee，RisingStack 和 Yahoo 加入 Node.js 基金會
Node Interactive
The first annual Node.js conference by the Node.js Foundation
版本帝？去年從 v0.10.35 開始
2015-01-14 發(fā)布了 v1.0.0 版本（IO.js）
2.x（IO.js）
3.x（IO.js）
2015 年 09 月 Node.js 基金會已發(fā)布 Node.js v4.0 版 與 IO.js 合并后的第一個版本
2015 年 10 月 Node.js v4.2.0 將是首個 LTS 長期支持版本
年底發(fā)布到 4.2.4 && 5.4.0
目前（2016 年 3 月 20 日）的 2 個版本
v4.4.0 LTS（長期支持版本）
v5.9.0 Stable（穩(wěn)定版本）
整體來說趨于穩(wěn)定。
成立了 Node 基金會，能夠讓 Node.js 在未來有更好的開源社區(qū)支持。
發(fā)布了 LTS 版本，意味著 API 穩(wěn)定。
快速發(fā)版本，很多人吐槽這個，其實換個角度看，這也是社區(qū)活躍的一個體現，但如果大家真的看 CHANGELOG，其實都是小改進，而且是邊邊角角的改進，也就是說 Node.js 的 core（核心）已經非常穩(wěn)定了，可以大規(guī)模
使用。
Node.js 的企業(yè)級大事兒記
2014年 nearform （NODE.JS 為什么會成為企業(yè)中的首選技術？http://www.nearform.com/nodecrunch/node-js-becoming-go-technology-enterprise/）
2015年 IBM （收購 StrongLoop，拓展云服務業(yè)務 http://www-03.ibm.com/press/us/en/pressrelease/47577.wss）
Node.js 基金會的創(chuàng)始成員包括 Joyent、IBM、Paypal、微軟、Fidelity 和 Linux 基金會。
對于企業(yè)級開發(fā)，Node.js 是足夠的，無論從性能、安全、穩(wěn)定性等都是非常棒的。
空弦科技做的是基于云倉儲的 SaaS 服務，給中小賣家提供服務，核心系統(tǒng)是進銷存、訂單池、WMS。目前來看不存在任何問題，
es && babel
2015 年 ECMA 國際大會宣布正式批準 ECMA-262 第 6 版，亦即 ECMAScript 2015（曾用名：ECMAScript 6、ES6）的語言規(guī)范。
babel （http://babeljs.io/）作為 es 編譯器，已經大量開始使用了，模塊做的非常棒，還有人用babel寫其他語言編譯器。Node.js 里在 0.12 之后才增加 es6 特性，es7 的目前還不支持。所以在 Node.js 里使用 es 里比較高級的特性，是需要 babel 去編譯處理的。這是 Node 追逐的標準。
2016 年 01 月 22 日，（微軟請求 Node.js 支持 ChakraCore https://github.com/nodejs/node/pull/4765）
未來 Node.js 不只是基于 chrome v8 內核，它還可以支持更多其他瀏覽器內核，對生態(tài)、效率提升等非常有好處。
蔡偉小兄弟的查克拉 benchmark 的對比（https://github.com/DavidCai1993/ES6-benchmark）基本結論是 V8 ES5 > 查克拉 ES6 > 查克拉 ES5 > V8 ES6
1.在全棧的語言選擇上，除了 Node.js，是否還考慮過其他語言？
桑世龍：有的，未來 swift 和 Lua 是有可能的。swift 的語法和性能上有很大優(yōu)勢，Lua 在 openresty 的推動下也有機會，不過沒有 swift 大。像 WebAssembly 之類的就不太看好了。
2.請教桑老師：剛才你說的并發(fā)開發(fā)流程中靜態(tài)API指的是API文檔？如果是的話誰負責編寫？你們目前已經是一個人分模塊從前端寫到后端了嗎？
桑世龍：目前沒做到文檔即靜態(tài) API，所以目前是直接提供 json 和部分（json-server https://github.com/typicode/json-server），負責是后端開發(fā)的 leader 在寫，他的進度會比正常開發(fā)要早一周左右。目前不是一個人寫所有的前后端，團隊成立不久，天津 Node.js 會的不多，所以還是前后端分離。但是通過 moa-frontend 可以讓前端了解 Express 等后端知識，適當的時候會給予機會，前端轉后端。
3.貴司在開發(fā)協作中提到了靜態(tài) API，請問是不是有什么比較好的工具可以推薦？
桑世龍：Node.js 里（json-server https://github.com/typicode/json-server） 比較好
我其實很想圍繞靜態(tài) API，寫各種請求的生成器，只要 API 出來，文檔和各平臺的 HTTP 請求代碼就生成出來，同時可以對正式 API 進行壓測，可惜目前還沒精力寫。
4.做 hybrid app 在移動端會遇到性能問題吧，有沒有什么優(yōu)化經驗可以分享？
桑世龍：足夠輕量級，少選大框架，做好前端該有的優(yōu)化。注意 touch 和 click 的區(qū)別，比如 fastclick 或 Zeptojs 的 tap 手勢。Chrome profile（css3動畫）。使用 weinre 真機測試。參考：（我的 H5 實踐 http://mp.weixin.qq.com/s?__biz=MzAxMTU0NTc4Nw==&mid=222892082&idx=1&sn=ba1cdb42b43fbec08e4328c5080774e5#rd）。
5.如果都全棧了，當前你們團隊是如何分工的？
桑世龍：我們團隊還是傾向于分工專業(yè)化，各個服務粒度非常小，便于輪崗、還有就是可以為以后像 Google 那樣代碼開放做準備。但是有很多情況下，是需要有機動的突擊隊的（尤其是創(chuàng)業(yè)時期），這樣可以隨便組合，另外就是全棧為 remote 提供了更多便利性。
6. H5 在手機上用 iScroll 坑比較多啊 尤其三星打開硬件加速的時候 render 頁面，桑老師怎么看？
桑世龍：可以嘗試一下淘寶系的 H5 虛擬化，鬼道曾經在 as 大會上講過的，我們目前還沒能力做這么深層次的優(yōu)化。
7.Node.js 做業(yè)務金額計算的金額性能和精度夠嗎
桑世龍：你問的不是 Node.js，而是 Node.js 要操作的數據庫。耗性能的計算可以在架構上平衡的，如果可以延時，MQ 就可以了。如果是非延時情況，可以采用其他語言編寫對應服務，沒必要非要一定要 Node.js。我們目前的場景，還沒有在計算遇到瓶頸。
8.關于 API 返回格式那里，對于 status 為什么不打平了把 code 和 message 放出來？這么設定有什么好處么？
桑世龍：語義上更加清晰。整個返回的 json 就只有 data 和 status，如果 status.code != 0,我取 msg 就好了，如果等于 0，處理 data 數據這種設計不見得多好，不過結構清晰，對于開發(fā)者來說，是比較容易接受的。
最后桑老師還要補充最重要的一句，大家別忘了互相轉告。
空弦科技招聘全棧相關架構師、高級程序員，語言不限，坐標天津，郵箱：sang@aircos.com
本文策劃李慶豐，編輯王杰，審校 Tim Yang，想討論更多 NodeJS 全棧開發(fā)，請關注公眾號獲取進群機會。轉載請注明來自高可用架構「ArchNotes」微信公眾號及包含以下二維碼。
高可用架構
改變互聯網的構建方式
長按二維碼 訂閱「高可用架構」公眾號
片來源@視覺中國
文｜航通社，作者｜書航
從頭開始制作一個手機操作系統(tǒng)，并讓它至少站穩(wěn)腳跟，甚至取得成功，這聽起來像是天方夜譚。
甚至比爾·蓋茨都承認，他們不能在手機領域復制 Windows 當年的成功，聽憑 Android 崛起，并帶來了一個 4000 億美元的教訓。[1]
但是，在內憂外患的催化之下，華為還是開發(fā)了用于替代 Android 的“鴻蒙”系統(tǒng)，它正準備向世界發(fā)出第一聲啼哭。
“鴻蒙”的出現恰逢其時——相比歷史上的那些艱難時刻，現在正是無限接近一個新的操作系統(tǒng)能走向成功的時機。
在大阪 G20 峰會結束后，美方稱有望解除當前對華為的制裁，給了華為手機的海外業(yè)務一個意外驚喜。[2]
受制裁影響，谷歌服務套件將在 90 天寬限期之后也即今年 8 月底開始，無法在華為海外新機預裝。諸多國外流行 Android 應用必須依賴此套件才可以運行。
這一紙禁令意味著華為手機將暫別谷歌一手搭建的海外應用生態(tài)，讓用戶恐慌，甚至在新加坡出現了低至 7 折的二手拋售。只是隨后，因為有人覺得可以轉手賣給中國大陸，價格又開始漲回來。[3]
在中國大陸，因為谷歌應用市場從未被正式準入，有需要使用谷歌服務和國外應用的用戶，一般都能自學知識破解，也出現了一鍵傻瓜式的“谷歌安裝器”。但對海外而言，這是否合法暫且不論，哪怕讓用戶手動多做一個操作，都會擋住很多只會一路下一步的人。
華為宣布他們有一個自研的備用操作系統(tǒng)，用于這種極端情形。它在媒體報道中有很多不同的名字，但最常用的是“鴻蒙”。據稱這個系統(tǒng)可以跨手機、電腦、電視、汽車等多種設備使用，同時支持運行網頁應用以及 Android 應用。[4]
跟自制芯片相比，自制操作系統(tǒng)聽起來更“不靠譜”。消息公布一個多月以來，不斷有人梳理國內外挑戰(zhàn) iOS、Android、Windows 和 macOS 四大系統(tǒng)的各種失敗史。
現代操作系統(tǒng)從運行邏輯、界面、交互、硬件適配等多個方面，都已經高度趨同且非常成熟。雖然可能存在一些專利壁壘，但大家也多少都有規(guī)避的辦法—— iOS 曾因為高通起訴，而微調多任務切換的動畫效果。
唯一不同的地方，就在于生態(tài)。為你這個系統(tǒng)開發(fā)的第三方軟件是否足夠多？是否夠用？該有的東西是不是都有？開發(fā)者和用戶社群是否能夠互相促進，像滾雪球一般越滾越大？
數不清過去有多少錢投入到操作系統(tǒng)開發(fā)之后打了水漂。像 WebOS 這樣把用戶體驗做得超越時代的優(yōu)秀系統(tǒng)，沒能獲得一線生機；而 Symbian、Windows Mobile 這樣曾叱咤風云的舊日霸主，也都在短時間內匆匆隕落。
一切都可以歸結于生態(tài)建設的失敗，這真是關生死，定勝負的因素。
如何從頭開始構建一個成功的生態(tài)？我們從 iOS 講起。
iPhone 初代并不支持第三方應用的安裝，但是它在功能和操控上的劃時代突破，吸引了全世界的關注。產品本身做得足夠好，以至于人們產生巨大興趣，這是讓它馬上能吸引到開發(fā)者的誘因。
多點觸控加上支持桌面 Web 功能的瀏覽器，讓當時的開發(fā)者只要做一個適合手機屏幕寬度的網頁，就足以成為一個“App”。
Safari 瀏覽器支持把網頁快捷方式放到桌面，圖標也跟原生 App 一模一樣。在 App Store 誕生初期，有很多 App 實際上只是一個瀏覽器的殼，把網頁做了封裝就上架了。放到現在，這是不可想象的。
App Store 一旦推出，蘋果對 iPhone 的宣傳重心就完全改為應用，對商店體系下開發(fā)者的宣傳、推薦和培養(yǎng)過程，也基本是從此時開始成型，并被后人效仿。
另一方面，已有足夠應用數量兜底的 App Store 保持了嚴格的準入機制，對直接安裝商店外應用的“越獄”圍追堵截，確保了收費應用開發(fā)者的權益。等到應用下載數、安裝數、付費應用收入等指標紛紛創(chuàng)下新高，iOS 生態(tài)的地位已經不可撼動。
只是對于其它后面來的玩家而言，蘋果獲得這般成功的關鍵幾乎就是三個字——做得早。
在另一邊的開放陣營中，Android 成功的秘訣也是做得早。
在體驗也不算差的 Windows Phone 7 出來的時候，它面對兩個問題：一個是原先 Windows Mobile 的應用全都不能沿用，甚至不能移植過去，對微軟而言相當于一切都要從零開始；二是既然是從零開始，這時候對面 Android 已經做了兩年。而這兩年里，微軟致力于讓大多數上市的 WM 6.5 手機支持全鍵盤，以發(fā)揮它移動 Office 的所謂“生產力”優(yōu)勢。
大體上，這就是蓋茨慨嘆的 4000 億美元怎么損失掉的原因。
要建設一個經典的應用生態(tài)，需要的并不是大力出奇跡，反而用力過猛會適得其反。特別是，直接引用別人（說白了就是 Android）的生態(tài)系統(tǒng)，并且無腦移植過來的做法，只會搭建一座了無生氣的“死城”。
我還記得微軟當初在華推廣 Windows Phone 應用開發(fā)之初，曾經許諾給報名的開發(fā)者都送一臺外殼靚麗的諾基亞手機，所需要的僅僅是把開發(fā)者已有的安卓程序，以簡單步驟轉制為一個 Metro 應用就可以了。[5]
前面說過，因為“做得早”，iOS App Store 和谷歌應用商店，最早期都可以允許一些網頁套了個殼的簡單應用上架，僅僅過了兩年，用戶就再也不可能接受這種東西了。
而一鍵轉換而來的應用，有時出現無法正常啟動或界面錯位等現象，商店也沒有及時發(fā)現和處理，這導致用戶看到各種各樣跟安卓同名的應用，但使用體驗卻極為差勁。
種種原因讓 Windows Phone 的應用商店被大小開發(fā)者拋棄。2015 年 3 月，支付寶發(fā)布 Apple Watch 適配卻不愿更新已沉睡 3 年的 WP 客戶端，引發(fā)用戶不滿。官微回復了一句：“你是1%，為什么要選擇1%的生活？” [6]
這句話讓“1%”成為中國 WP 用戶的自嘲專有名詞，直到微軟徹底放棄自己的手機操作系統(tǒng)為止。
iOS 封閉的應用生態(tài)被人們形象的稱為“圍墻花園”，因為開發(fā)者想要突破這個“圍墻”是基本不可能的；相比之下，Android 可以自由地分發(fā)和安裝后綴為 APK 的安裝包，因此走上了不同的發(fā)展道路。
人們對 iOS 的粘性，很大程度上是由眾多開發(fā)者貢獻的優(yōu)質應用帶來的。蘋果卻利用這種難以掙脫的粘性，對平臺內的應用內付費（IAP）征收 30% 的手續(xù)費，開發(fā)者只能將這一成本轉嫁到消費者身上。
這導致對于一些跨平臺的產品，如果是在 iOS 客戶端內購買諸如電影、音樂、游戲道具等商品，支付的費用要比在安卓或網頁版購買貴三分之一。
2017 年，蘋果針對中國部分應用中出現的對作者“打賞”的情況，宣稱這也屬于應用內付費。也就是說，在微信公眾號、知乎專欄、視頻直播應用等地的打賞也要被抽成 30%。這對于風行一時的內容創(chuàng)業(yè)生態(tài)是一大暴擊。
iOS 形成的天然市場壟斷地位，導致其中幾乎每一個默認位置，對合作伙伴都是不菲的花銷。今年 2 月份有分析指出，為了保住在 Safari 瀏覽器中的默認搜索引擎地位，谷歌在 2018 年度向蘋果支付了 95 億美元，相當于蘋果 2018 年營收的 1/5。
該分析師計算，谷歌的這部分貢獻，加上 App Store 的分成收入，兩項占蘋果 2018 年服務營收的比例高達51%，占毛利潤比例更高達 70%。[7]
今年春季，蘋果發(fā)布了一系列的內容訂閱產品，收“蘋果稅”的習慣也沿襲到了這些新的服務身上，由于蘋果提出的分成比例過高，一些主流的出版商選擇抵制蘋果雜志訂閱服務 Apple News +。
從 2011 年開始，就有美國消費者提出對 App Store 高額抽成的訴訟。他們認為這增加了消費者獲取同類服務的時候，相對安卓等其它用戶付出的成本。
蘋果認為他們不是合適的原告，因為商店抽成是面對開發(fā)者，而不是用戶，應該由開發(fā)者來起訴。不過按照這個邏輯，開發(fā)者真的起訴了蘋果之后，還能不能繼續(xù)在 App Store 愉快的玩耍呢？
歷經 8 年多的不斷反復，直到今年 5 月，美國最高法院才以 5:4 的比例，判定蘋果在這一階段性的訴訟過程中敗訴。也就是說，任何 iOS 的用戶，而不僅限于開發(fā)者，也都可以提起反壟斷訴訟。消息一出，蘋果的股價大跌，投資者擔心這會影響到蘋果服務產品的盈利模式。[8]
受到這一判決結果的激勵，在 iOS 開發(fā)者群體當中也有人挺身而出。6 月初，有兩名開發(fā)者向蘋果所在的圣何塞地方法院提起反壟斷訴訟，稱 iOS 只允許一家單獨的應用商店運轉，不允許其他第三方的商店，削弱了用戶的自主選擇權。如果這一訴求獲得法院的支持，那其實也意味著在海外安卓系統(tǒng)當中只有 Google Play 商店的情況也要改變。[9]
目前這些案件都還在審理過程當中。唯一可以確定的是，這些小小的變化正推動著已經穩(wěn)定運轉了 10 多年的 App Store 模式發(fā)生變化。圍墻花園的高墻開始出現了裂縫。
推動這一裂縫變得越來越大的，還有兩個重要的因素。
在國內，全民普及的超級 App 紛紛推出了小程序，總算把手機網頁充當 App 的多年志向部分實現。
小程序是一種封裝好的基于 XML 變種語言的軟件包，依賴母體 App 獲得讀取個人信息及調用手機硬件能力的權限，跨越 iOS 和 Android 平臺限制，能夠共享一致的用戶體驗。
不管是此前百度、UC 瀏覽器的“輕應用”，還是之后手機廠商推出的“快應用”，都不能像微信、支付寶、百度系、字節(jié)跳動系 App 一樣，對所謂“網頁應用”的推廣起到這么大的推動作用。
在中國，人們習慣于在少數幾個超大型的 App 當中完成幾乎所有的事情。早在 PC 互聯網時代，英語用戶習慣使用 AOL、雅虎和谷歌的搜索框來獲取信息，而中國人則鍛煉出了使用密密麻麻的網址大全的習慣。
同樣的風格差異也體現在中英文購物網站的區(qū)別上。淘寶、京東等網站擺滿了商品信息，而亞馬遜的每次改版都反其道而行之，盡可能追求頁面的簡潔。你很難簡單評判兩種習慣的優(yōu)劣。
在移動互聯網時代，人們也需要一個包攬一切的入口。微信、支付寶、百度等產品擔當了這樣的角色。它們都擁有可以閱覽資訊（公眾號-生活號-百家號），進行一定程度的交流（聊天-螞蟻森林-貼吧），以及購物、繳費、支付的能力。
這些超級 App 成為一個籠罩在操作系統(tǒng)之上的新的平臺層。華為要做“鴻蒙”，只要這幾個超級 App 分別實現了適配，那么架設在上面的所有小程序生態(tài)都可以無縫轉移過去，大大減少了人們適應新系統(tǒng)的障礙。
超級 App 挾用戶而令商店，跟蘋果和谷歌之間形成了亦敵亦友的關系。蘋果曾強迫微信贊賞功能抽成 30% ，微信干脆先撤下贊賞能力，談判一年，最后毫發(fā)無傷。在蘋果的發(fā)布會上，微信經常被放在 iOS 的相關幻燈片上，作為中文應用的代表出現。
在國外，利用最新 Web 技術的漸進式網頁應用（PWA）正成為潮流。新的 Web 標準令 PWA 不同于以前的手機版網頁，具備了本地存儲、調用分享接口等能力。
已經醞釀了 10 年以上的“網頁應用”，之所以到了近一兩年才有跟原生應用分庭抗禮的跡象，是因為技術終于到了成熟的時候。這就好像微軟早在 2002 年就推出了平板電腦版的 Windows，但是最終實現平板電腦的“完全體”形態(tài)，卻要等到蘋果的 iPad。如果技術不到那個程度，揠苗助長不會有好結果。
早期的網頁應用，因為操作系統(tǒng)的運算能力和后臺駐留能力不足，導致頁面不斷的刷新，表單信息容易丟失。而且如果不在室內的 WiFi 環(huán)境之下，在手機上還容易因為斷線而無法繼續(xù)操作。當時的網頁技術也不具備離線緩存的能力，也無法調用系統(tǒng)的攝像頭、麥克風等硬件。
隨著互聯網標準的完善，除了以上提到的能力之外，網頁的繪圖效率也因為 CSS 和 HTML5 Canvas 的改進而提高；一些 3D 效果可以通過 WebGL 等技術，不用插件，直接在瀏覽器中實現。
甚至支付都不是問題—— Facebook 宣布推出的穩(wěn)定幣 Libra 必定會應用在眾多內嵌 Facebook 框架的網頁，即使是網頁版的用戶，也可以正常的收付款或查看錢包狀態(tài)。
與此同時，5G 網絡的普及和網絡信號覆蓋率的提升都意味著操作網頁元素時，可以加載和緩存更多內容，避免應用崩潰。
PWA 最激動人心的地方，就是它的本質是一個網頁。這意味著任何現代瀏覽器和操作系統(tǒng)都可以支持它們，并獲得完全一致的使用體驗。
PWA 已經獲得了谷歌和微軟應用商店的官方支持，可以獲得跟原生應用類似的圖標和啟動方式；在 Windows 10 的將來版本中，PWA 更可像原生應用一樣在“設置”里卸載。[10]
沒有獲得移動互聯網“船票”的微軟，和正打算推出新操作系統(tǒng) Fuchsia 的谷歌，都把 PWA 看作是在當前的原生應用體系之外，新建生態(tài)的突破口。
在用戶和開發(fā)者“以卵擊石”般悲壯的法律挑戰(zhàn)之外，中國的超級 App 和全球合作的 PWA 開放環(huán)境，共同給花園的圍墻撕開更大的缺口。
不管是強大的廠商希望自己打破操作系統(tǒng)的區(qū)隔，還是小開發(fā)者以 Web 標準實現終極的跨平臺編程，都是在實踐一個由來已久的心愿：當初 Java 所提出的“寫一次就到處運行”的理想，將在這些繼承者身上得到延續(xù)。
今年 4 月，有人因為主力辦公電腦送修，所以不得不使用 10 年前的筆記本電腦工作。結果他意外地發(fā)現，雖然有點慢，但是不影響使用。10年前的電腦依然能夠滿足日常工作。開發(fā)者阮一峰評論說：[11]
“如果 2009 年讓你去用 1999 年的電腦，那是不可想象的，根本沒有實用性。但是，2019 年去用 2009 年的電腦，卻是完全可行的。這說明，過去十年的硬件進展不太大，導致 10 年前的硬件不是那么過時。過去十年，進展主要體現在軟件上面：軟件功能更強大、使用更友好、界面更美觀?！?/p>
多年前，航通社寫過《軟件應不應該更新到最新版》，表達了類似的看法。[12]
很多情況下，軟件并不是越新越好。有些新版要求單機軟件強制聯網，加入你并不需要的會員功能和消息推送；有些新版和舊版，甚至同一版本的自家軟件不兼容；有些產品更是從頭到尾蛻變成另一款你不認識的軟件。
上述問題都是操作系統(tǒng)原生應用普遍存在的。如果同一款軟件有對應的網頁版，那么只需要一個瀏覽器，就可以避免大部分煩惱。在桌面電腦上，瀏覽器就是我們所說的“超級 App”。
歷史上，PC 操作系統(tǒng)的軟件生態(tài)經歷了從純粹的單機軟件，到出現 c/s（使用客戶端與服務器交互）再到 b/s （使用瀏覽器與服務器交互）的過程。這一過程也在手機操作系統(tǒng)上得到重現，雖然其中經歷了曲折反復。
眼下，由超級 App 和小程序、PWA、統(tǒng)一的 Web 標準以及 5G 等通信技術的進步，共同催化了在應用商店之外，一個全新的、開放的、跨平臺的生態(tài)。
蘋果曾經以 Flash 是一個閉源的技術為理由，在 iOS 中取消對 Flash 的支持，促成了這個風靡一時的網頁技術的凋敝。但 iOS 和 Android 本身也不能免俗于掌控一個封閉平臺的誘惑。
作為 iOS 和 Android “護城河”的應用商店，是再典型不過的“圍墻花園”，正是花園的高墻擋住了歷史上其它競爭操作系統(tǒng)的道路?，F在，高墻終于開始出現了裂縫。
如果華為“鴻蒙”系統(tǒng)能僅僅憑借對大量 PWA 和小程序的兼容性，就成功站穩(wěn)腳跟，這將是一個重要的標志，意味著頭部操作系統(tǒng)長期積累而成的應用生態(tài)壁壘，今后將不再扮演像現在這么關鍵的角色。
而操作系統(tǒng)的地位，也將下降到作為一個承載瀏覽器和個別超級 App 的容器，不同系統(tǒng)之間的操作習慣幾乎可以無感知地移植，這樣用什么操作系統(tǒng)就再也不是一個問題。
這是“鴻蒙”的機會，也是我們所有人的機會。
[1] https://techcrunch.com/2019/06/22/bill-gates-on-making-one-of-the-greatest-mistakes-of-all-time/
[2] http://tech.sina.com.cn/i/2019-07-01/doc-ihytcerm0437333.shtml
[3] https://www.zaobao.com/znews/singapore/story20190523-958860
[4] https://news.mydrivers.com/1/630/630953.htm
[5] https://tech.qq.com/a/20110219/000090.htm
[6] https://www.ithome.com/html/windowsphone/134028.htm
[7] https://www.cnbeta.com/articles/tech/817521.htm
[8] http://finance.sina.com.cn/stock/relnews/us/2019-05-15/doc-ihvhiqax8865477.shtml
[9] http://www.techweb.com.cn/world/2019-06-05/2738826.shtml
[10] https://tech.sina.com.cn/n/k/2019-06-19/doc-ihytcitk6190308.shtml
[11] http://www.ruanyifeng.com/blog/2019/04/weekly-issue-51.html
[12] http://www.geekpark.net/news/187221
尋求轉載授權，請聯系航通社助理（ID：hangtongshe）或發(fā)郵件給 coop@lishuhang.me
更多精彩內容，關注鈦媒體微信號（ID：taimeiti），或者下載鈦媒體App
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
