整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
智能手机普及之前，互联网的能力还是有限的，那时候的互联网还可以说是自由的。那这几年到底发生了什么？什么杀死了分布式的互联网，使之变成了商业垄断为主？
我曾经写过好几篇和隐私相关的话题，阅读量都不高。这不意外，没有重大事件，通常人们不会关心这类话题。
最近有几件事被引爆了，这个话题突然重新回到了人们视野中，所以可以再写一篇了。
这几件事分别是：Facebook 数据泄漏事件、互联网公司是否偷偷用麦克风监听用户，以及所谓大数据杀熟。
说到根本上，这几件事是相关的，背后指向的是同一个问题，即：人们到底出让了多少隐私，以及用户为什么会在不知不觉中出让这么多隐私。
在智能手机普及之前，互联网的功能还很有限，人们的使用时长也不长。就算是 Facebook 这样的霸主，在那个时代无非也就是诸多网页中的一个。
人们没有把那么多数据交给互联网公司，离线和在线状态还非常分明，远不像今天绝大多数人实际上已经永远在线，就算在飞机飞行途中也未必能获得清净。
在那个时候，虽然互联网的模式早就是免费+广告，人们出卖的隐私数据仍然是相当有限的。
然而几年之后，事情就变成了完全不同的样子，数据和流量变得极度集中，使得泄漏隐私和通过大数据计算给不同用户标定不同价格成为可行。
在 2010 年之前，人们在互联网上主要使用开放协议，我们用电子邮件传递消息、用 IRC/Gtalk(XMPP)聊天、用浏览器上网浏览信息、通过链接把各种资源连起来。
开放协议意思是：每个人都可以架设自己的服务，只要按照协议规范来，就可以让不同人架设的服务器之间正常传递信息。
今天，区块链兴起之后，人们管这种模式叫做“分布式”，或者“去中心系统”。但仅仅几年之前，互联网本来就是去中心和分布式的，并不是像今天这样所有数据和流量都掌握在几家巨头手里。
这几年到底发生了什么？什么杀死了分布式的互联网，使之变成了商业垄断为主？
2009 年，智能手机的兴起，不仅仅是提供了一种新的使用方式，同时以这种方式使得大量的传统网络通信协议不可用。前者被广泛讨论，后者人们往往意识不到。
简单来说，智能手机的兴起，至少杀死了 IRC/XMPP 这样的及时通讯协议，部分消灭了 HTML/URL 这种互联网基础协议。
讲述这段历史不可能跳过苹果这家公司，在 iPhone 出现的年代，苹果还是一家有特色但不重要的公司，但它几乎是凭自己一家公司开启了整个移动互联网时代，没有苹果的一系列决策，就没有移动设备的普及。在这个过程中，有意或者无意的，苹果也在另外一方面推动了历史，使得我们进入了一个垄断更密集、更封闭，但是更方便的时代。
先说第一个问题，IRC/XMPP 协议是如何被杀死以及如何改变生态的？
很多人指责微信是个封闭的花园，这个指责没有问题。
但解决方案是什么呢？
这些人提供的解决方案通常是：使用另外一个商业软件（Whatsapp/Telegram/iMessage）来代替微信。
这时候如果你提出一个问题，为什么不使用一个开放协议？比如 ：IRC 或者 XMPP 来代替微信这种聊天工具，对方给出的回应通常是“那些太难用了，普通人不会用”。
这个回答是错误的。
正确的回答是：移动互联网时代开始之后，所有的传统及时通讯协议都变得不可用了。不是因为难用，是因为在技术上不可用。
传统的聊天协议，都包含了在线和离线状态。用户使用之前，首先要完成登录，标记在线状态，建立一条到服务器的永久链接，然后才可以发消息。（如果你用过 MSN 的话，应该会比较形象理解这个过程）。
移动互联网开始之后，诺基亚 S60 和 Android 使用这些协议尚且没问题。但 iOS 早期版本做了一个不可思议的举动，这个系统上没有后台进程，一个应用进入后台或者关闭屏幕之后，所有链接都会被系统断开，但是系统会接收推送消息，帮助用户再次唤醒应用。
早年诺基亚的粉丝是一直嘲笑 iPhone 这种设计愚蠢“一个没有后台进程的智能手机怎么能叫智能手机呢？”
事实的发展证明他们错了，iPhone 成功了，其他人都死了。
为了待机时间和兼容当时运算能力仍然比较低的移动设备，无后台进程，关闭链接，这些都是必要的优化，不然手机待机时间会快速下降，使之不可用。
但这种措施给传统通讯协议带来了巨大的挑战，没有后台进程（以及设备在移动带来的网络切换造成的网络链接不稳定），造成了 IRC 和 XMPP 这种有在线状态的协议，要频繁处理上线下线，用户体验极差。链接被关闭或者网络切换时，对于服务器表现为 Session 超时，在桌面互联网上这是一种异常状态，需要等一段时间之后才能清理掉。
但在移动设备上这是频繁发生的，这导致了服务器堆积了大量超时未释放的Session，这使得服务器难以负荷，当时很多 XMPP 服务器上每天处理的链接请求甚至超过每天传递的消息数量。
这样的服务当然不可持续下去，但是开放协议的修改效率是很低的，需要社区经过广泛讨论才能制订出新的标准，然后各种开发者和厂商才能支持它。移动互联网来势凶猛，所有人都知道，这是未来，人们等不及了。
（网上还能找到在 Nokia Chat 中使用 Gtalk 的截图，不容易）
谁填补了这个空白了？
是那些意识到了过去的开放协议缺点，又有很好基础的人。
今天我们已经知道了最终的胜利者，他们是——基于邮件投递模式的微信、基于短信投递模式的 whatsapp、基于大规模分发地震等紧急消息模式的Line。它们有一个共同点：都是基于某种大规模的消息投递模式开发的，没有在线和离线状态。
这个问题在后面的很多年，甚至一直到今天还有人会提出：“为什么微信没有 QQ 那样的在线状态？”
张小龙回答过这个问题，答案是：“手机是永远在线的”。
这句话是产品逻辑，同时也是技术逻辑。除了产品上用户期待是手机持有者随时能收到并回应，技术上也必须采用更轻型的“消息推送”类协议。
这三个产品出现的时间是：
都是在 2010 这个关键时间点前后出现的。
苹果消灭后台进程的原因当然不是为了杀死传统互联网协议，而是为了省电和移动设备可用性。但是这种突然的转变，事实上造就了一段足够长的真空时间，从而使得传统开放协议更新协议的迭代模式不可持续。
新的商业公司拿到 MQTT 这些协议包装一下，就成了自己的私有封闭协议，他们没有和其他产品互相链接的意愿也没必要，也就不会再跟随开放协议。
苹果以一家公司之力，通过一个小小的决策，直接改变了互联网发展方向，造就了新的巨头，进而这些巨头又影响和改变了人类社会。顺着这条脉络看到今天，简直是壮观又可怕。
做为一个对比，IRC 协议从 2016 年开始讨论下一代标准 irc v3，其中包括了一系列移动设备需要的功能。包括：无状态链接，推送消息，历史记录……等。
但到现在 2018 年，距离可用还颇有距离，等到有好用的客户端产品支持不知道要到哪一年了。和微信的成长对比一下，商业公司的优势的确太大了。
然后说第二个问题，HTML 和 URL 是如何几乎被杀死？被 URL 连起来的互联网是如何变成一个个孤岛的？
如果你同时使用桌面互联网和手机互联网，也许能感觉到这是两个逻辑完全不同的世界。
前者仍然保持着页面+链接模式，后者是完全不同的一种模式，你用的是一个个 App。前者你仍然可以自由的挑选组合自己需要的信息，接受来自不同渠道的信息并且组合它们。但是后者，只有一个个巨型 App 做为入口，接受他们提供的被排序或者没被排序的内容。
使用桌面互联网的人，仍然在使用网址（URL）这种东西，别人通常会贴一个链接给你，你在浏览器里面打开它就可以使用了。但在移动设备上，别人给你一个链接，似乎没什么地方可以贴，在这里，功能是一个个 App 组成的，浏览器在手机上不是核心位置。
桌面互联网上 URL 和 Link 使得不同的网站链接在一起，用户使用互联网的过程，是通过链接在不同网站之间无缝跳转的过程。
但在移动互联网上，App 之间是割裂的，它们之间几乎没有跳转关系。仅有的一些链接应用的场景，也遇到了各种商业竞争导致的干扰，中文有微信和支付宝互相干扰对方的链接跳转；英文有 Twitter 阻断Instagram链接；Facebook/Whatsapp 阻断 Telegram 链接。
在移动互联网上，不同品牌之间关系是对抗，而不是桌面互联网的合作，当人们开始使用这种以 App 为核心的系统的时候，桌面互联网的核心，浏览器/HTML/URL 就已经死了一半了。
这到底是怎么发生的？
移动互联网和桌面互联网都叫做被叫做“互联网”，这是一个非常具有迷惑性的说法，它使得人们下意识认为移动互联网是传统互联网的延伸。实际上不对，这是一个完全不一样的世界，应用完全不一样的规则。
2010 年，中文和英文业内同时有过一场大争论，叫做 HTML5 和原生 App 之争。争论这两个东西哪个更有未来？
2008 年虽然苹果已经在 iOS 中提供了 App Store，但是实际上的快速增长是从 2010 年下半年才开始的，这场争论不早不晚，确实是一个重要时间点。
这个争论的重要意义在于——它最终决定了传统互联网的html页面+链接，以浏览器为中心的模式是否能生存下去。
争论的另外一方——原生 App，提供了一个完全相反的模式：它没有页面，没有链接，数据被封闭在 App 之内形成孤岛，以传统互联网拥护者看来，这是历史的倒退。我们本来就是从数据封闭在每个软件之内的时代走向的页面+链接的互联网时代，怎么突然就要倒退回去了？
事实证明了人们接受了App，抛弃了 HTML 和浏览器。
App Store 里面，几乎没有什么 App 是显式表达链接存在的。虽然数据在 RESTful API 这一层仍然以链接形式存在，但是从 App 这个入口内，通常没有输入链接的地方。
想把 App 中看到的东西分享给朋友，如果这个 App 本身没提供分享功能，几乎是没办法的，只有截图一条路。
虽然后期 iOS 提供了一系列分享相关的 API，但是这种模式就决定了，URL 所代表的“唯一定位符”，“每一个唯一的资源对应一个URL”这种模式在app的世界里已经消失了，HTML 和 App 之争也很快就结束了。
2012 年，曾经拥护 HTML5 的 Facebook 投降认输，重新开发原生 App，最终在后面的几年里一路猛涨成为了中文世界之外的巨头。
2014 年，Facebook 收购了聊天工具 Whatsapp，人们相当恐慌，所有的数据都集中在一个巨头手里这还了得？少部分人转投 Telegram，这个事件在 Telegram 用户增长历史曲线图上清晰可见，是早期 Telegram 获得的最大一波用户增长。
人们的担心是有道理的，在 PC 互联网上，厂商获取的信息少很多，那个时代最准确的广告投放方式是 ——Google 提供的基于关键词的广告，因为搜索关键词透露了用户明确的意图。
但移动时代到来之后，通过 App 获取的用户数据种类就多得太多了。
同样也是 2014 年， Facebook 发布了跨应用广告网络，号称可以跨越应用，从网站到手机 App 来统一完成用户画像。2012 年Facebook 收购的照片应用 Instagram，使得 Facebook 在移动平台上可以获得更多的用户和数据，其他厂商没有这种优势。
（Telegram Geek 网站做的用户历史数量统计图，注意 2014 年 4 月份的用户数量，2 月份的时候 Whatsapp 被收购）
之后 Facebook 逐年增长的广告收入告诉了其他厂商，这样做是对的。
社交关系+最大限度获取用户日常活跃数据，最终可以转换成巨额广告收入。
于是所有厂商都沿用这个模式，用尽办法去获取能获取的每一条用户信息，无论是否之前被认为是用户隐私。由此带来的一系列“应用滥用权限”，是最终用户能感受到的表面现象。背后的原因——就是这个尽量多的获取数据，转换成广告盈利的模式相当有效。
到了这两年，广告网络已经准确到前所未有的状况，某些情况下已经不是广告追着人走，而是广告先于人一步出现。这一套用户画像模式威力巨大，不仅可以准确投放商业广告，还可以投放政治宣传，最终影响人的社会行为。
Facebook 数据泄漏影响了美国大选，这不是竞选失败的一方找理由，这就是真实发生的情况。同样的道理，广告准确到这种程度的时候，普通用户已经难以理解背后发生了什么，干脆按照奥卡姆剃刀原则，找了一个最简单的解释：这些科技厂商在监听我。
不采用这一套模式的移动互联网产品，差不多都死了。
今天流行的这些 App，无论是 Facebook/Instagram，还是中国的微信/微博/头条/抖音/快手…都有一个共同的形容词——“刷的停不下来”。
这种停不下来的背后，是这些 App 吞噬了用户的使用时长。在手机的小屏幕上，通常情况 App 之间是零和竞争，被这个 App 抢走了，别的 App 就没了。于是拿走用户数据越多，越准确的 App 就会占领更多的时间，获得更多的盈利同时顺便挤死对手。这里不再有互相链接的互联网了，每个 App 本身就是世界的一部分。
如果回到 2010 年，回到 HTML5 和 App 之争的时间点看，还有其他可能性吗？其实仍然是有的。
2012 年 Facebook 宣布放弃 HTML5 App 的时候，说过理由：“浏览器性能太差了，无法负担应用的需要，并且还说了希望各厂商改进浏览器。”
理想情况下浏览器厂商会竞争，推出性能更好的浏览器。但现实情况很悲惨，苹果很长一段时间内 iOS 系统上不允许使用其他浏览器内核，必须只能使用 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 上不存在性能的竞争，大家都受一样的限制。存在一个独立的浏览器引擎，可以保证整个行业是中立和标准的。
Firefox 标准化的更好，在浏览器里面加入厂商专有内容的动力更小，考虑到微软专属的 IE4 曾经如何拖累了整个行业，保持Firefox独立浏览器占据足够的份额，是保持整个互联网世界开放的重要基础。
很难说苹果刻意杀死了浏览器厂商，但客观上，苹果的限制，以及很长时间内 iOS 自带的 webkit 内核和 JS 引擎效率低下（比同时期 Chrome 内核低几个数量级），使得 HTML5 App 难以获得流畅的用户体验，最终结果就是导致 HTML 在移动平台应用竞争中失败，Web App 成了一个不可行的想法。
苹果确立了以 App 和 App Store 分发为基础的移动设备事实上的标准，其他厂商也都纷纷跟进，再也没有人想在移动设备上复制更开放的传统互联网了。
独立浏览器引擎只剩下了Firefox凭借庞大的历史积累的粉丝群体，勉强抗到了今天。
2013 年，我在给纽约时报做技术顾问的时候，曾经和他们讨论过，是否可以以 Web App 做为移动设备的核心？
因为众所周知的原因，大家都心知肚明它的 App 必然没法在中国地区通过 App Store 分发，当时 ft.com 主推 Web，在浏览器里面实现全部功能（2011 年 FT 和苹果因为订阅用户发生了纠纷，就此 FT 放弃原生 App，有点类似公众号打赏分成之争），但再三比较之后，我们最后还是在 Web 和 App 之间选择了App。
原因和 Facebook 一样，Web 应用难以满足需求。
这件事最尴尬的地方在于：Android 上浏览器体验不错，有好的多性能也高的多的浏览器。但 Android 上分发 App 限制不大，就算不通过 Store 分发，仍然可以自己下载 apk 安装，这种情况下如果不是为了情怀，倾向 Web App 的动力不足。
iOS 上只能通过 Store 分发，在这里使用 Web App 可以绕开分发的限制，但同时浏览器体验非常差，几乎是不可用的，开发 Web App意义不大。
（ft.com 还一直维护着一个如何开发 HTML5 web app 的教程…可惜没多少人真的和他们一样这样做）
Web app 有没有成功的可能性？
到了最近微信倒是给出了一个证据：微信小程序就是HTML5 app。历史绕了一圈之后，它在另外一个巨头的围墙内复活了……
尽管微信小程序的模式，仍然是需要审核上架的 Store模式。但是，它毕竟是 HTML5 App，这足以说明如果有合适的条件，HTML5 App 曾经是有可能战胜原生 App 的。如果 HTML5 胜利了，今天的移动互联网，理应比我们现在看到的开放的多。
和前面所说的移动互联网杀死聊天协议，最终导致改变了人类社会一样。以苹果为主要推动者的移动互联网，严重倾斜于 App 模式，有意或无意的使得基于页面和链接的传统互联网模式，在移动平台上消亡，从而推动了收集更多数据的广告商业模式发展，形成了几大超级 App。在吞噬传统互联网的同时，也顺便改变了人类社会。
互联网到移动互联网的发展历史，就是人类社会放弃隐私的历史。安全、方便、隐私、体验这些概念本身都是冲突的，这些年互联网的发展，是充分使用了人类“懒惰”（此处无贬义）这种特质，形成了今天这样的商业模式，这是人类与生俱来的特征，难以被打破。
前面说了很多苹果在这个过程中起到的作用，但这并不是苹果的错，苹果所有的做法在那个时代都是正确的，这些办法综合起来让体验和耗电量达到了平衡，使得移动设备变得可用。
Push 唤醒 App、力推 App 模式打压浏览器、杀死 Flash…如果没有这些极端的办法，我们到今天可能还在使用黑莓，移动互联网时代也难以开启。
整个过程中，Android 虽然更加开放，但在开始的几年里面 Android 性能和体验惨不忍睹，用户和整个行业一起站在了苹果模式这边。
我们现在看到的更封闭，更集中的移动互联网世界，是人们自己选择的结果。
历史一次又一次证明了，人们在方便和隐私之间，大多数人会选择方便。李彦宏说的中国人会如此选择，这有点片面了，事实证明全世界人都会这么选。
不信你看，这边 Facebook 闹出这么大风波，另外一边各种智能音箱的销量还在上涨，似乎没人觉得有问题。智能音箱就是一种出卖更多隐私，换取一点点方便的产品。
我不否认市场上存在非常注意保护隐私的语音助理类设备和软件，但无论厂商多注意隐私保护，它为了换取方便而导致了更多用户数据离开自己的控制，这是毫无疑问的，人们不在乎。
2010年是移动互联网兴起的年代，可惜实际结果是把互联网切成了几个小块。2010 年同时还是比特币兴起的年代，那个时候它开始脱离创始人的那个小圈子，被更多普通人所知，但仍然没引起广泛注意。
但到了最近，区块链的热潮已经难以阻挡了，即使最近币价下跌不少，仍然是不可阻挡的热潮。
区块链是这些年来除了BT 下载之外应用最广泛的分布式应用，在几年之前，所有 P2P 系统都难逃被冠以“黑暗”，“犯罪”之名，很难成为大众话题，更难以让普通人尝试。但区块链通过资产增值的预期竟然做到了这一点，人们开始谈论它、尝试它，并且亲身投入这个领域。
尽管这个领域仍然非常早期，充满了风险，但也必须看到另外一个角度，它带来了前所未有的变化。
在一个人们如此在乎产品体验的时代，区块链应用使得人们愿意尝试和接受各种非常早期、不成熟的产品，重新开启了竞争，这就是未来的希望所在。
作者：霍炬，科技 blogger，连续创业者，技术爱好者，有一个公众帐号 “歪理邪说”（ID：wxieshuo）。
者按：高可用架构分享及传播在架构领域具有典型意义的文章，本文由桑世龙在高可用架构群分享。转载请注明来自高可用架构公众号「 ArchNotes 」。
桑世龙，天津空弦科技 CTO，开源项目 Moajs 作者，Node.js 技术传道者。曾就职在新浪、网秦，曾做过前端、后端、数据分析、移动端负责人、做过首席架构师、技术总监，全栈技术实践者。目前主要关注技术架构和团队梯队建设方向。
“JavaScript 是世界上使用最广泛的语言，没有之一，包括后端开发工程师也更爱使用 JavaScript。” ——stackoverflow
虽然 Node.js 在国内没有盛行，但据 StackOverflow 2016 年开发者调查，其中 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
以前总强调的异步特性，到今天异步已经不是明显优势。因此除了性能，其他都是病（不足）？
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 的强大的生态来炫耀。
空弦科技做的是基于云仓储的 SaaS 服务，给中小卖家提供服务，核心系统是进销存、订单池、WMS。
先看一下我们的瓶颈在哪里
人（天津不好招人）。Node.js 招不到，好多都是从 Java 转的，前端也不好找，好多也是从 Java 转的，我们相当于从 0 开始组建团队
开发速度。创业公司 5 分钟要造火箭，大家都懂。所以让开发快速进入状态，提高开发速度，对我们来说至关重要。
稳定。在没有专业运维人员的情况下，如何保证系统可用、稳定。
于是就引出了我认为的Node.js 好处
同样不优化，性能比大部分语言好。即使优化，也比其他语言简单，比如Java。
有足够多的选择和架构的平衡。
如实在不够，Java 补。
Node.js 给了我们足够的选择工具
可以采用面向过程
可以面向对象
可以函数式
甚至可以用各种编译器 coffee、typescript、babel（es）等。对于从 0 开始的团队来讲，可以先面向过程、然后随着团队的成熟度，一点一点增加难度。
提供好的基础和包管理工具
测试相关 tdd / bdd 测试覆盖率
规范化 standard、各种 lint、hint
构建相关 gulp、grunt、webpack，大量插件
生成器 yo 等
包管理工具 npm 足够简单易用
以上这些都做大型软件的基础，Node.js 在这方面做得非常好
特定场景的快速
很多人把 MEAN 组合（比如 mean.io）起来，这样做的好处是如果熟悉，开发速度确实会非常快，但是难度太大，很少有人能搞的定。metetor 模糊了服务端和客户端，是同构的典型应用，对于实时场景是非常高效的。这种东西都算特定场景的快速，一般不敢轻易上，调优难度非常大，如果有人能 cover 的住，在初期是非常高效的。
总结需求：可以简单，可以难；可以快、也可以慢；可以开发大型软件
如果以上不满足咋办？这时就需要架构平衡了。
在架构中各自做各自合适的事儿就好，我们很坦然的面对 Node.js 的优点和缺点，做好架构平衡。
1、在语言层面可以做，那语言层面做
已有大量 npm 上的模块 ( 目前在 25.6 万个以上 )
自己造轮子 ( 站在海量包上 简单语法 npm = 快速 )
使用 Node.js 里的 （nan https://github.com/nodejs/nan）自己包装 C/C++ 轮子
从上面看，绝大部分需求都可以满足了
2、如果语言层面搞不定，那就架构层面做
业务边界、模块拆分、面向服务
MQ、RPC、cache
运维、监控、自动化
稍微解释一下，首先，架构与 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 的支持。避免过多的时间用在造轮子上，影响开发进度。
4、Node.js 优劣分析
执行效率，同样不优化，性能比大部分语言好。
开发效率，Node.js 本身比较简单，开发效率还是比较高的。完善的生态，比如测试、工具、npm 大量模块。
缺少 Rails 一样的大杀器，scaffold 脚手架，ORM 太弱。
Node.js 的 Web 开发框架 Express、Koa 等，简单，小巧，精致，缺点是集成度不够，目前已有的 MEAN 或 yo 或 sails 等总有某种方面的不满意
选择 Node.js 我们需要做的包括：固化项目结构；限定 ORM；自定义脚手架。
由于 Node.js 已经提供以下特性，因此你可以在 30 分钟完成一个脚手架。
cli 命令模块，编写非常容易
基于 JavaScript的模板引擎（知名的 30 ）
我们用Node.js做什么？
API服务
前端（moa-frontend）
SDK（OAuth Provider）
辅助开发 cli 工具
目前进度
使用 0.10.38，开发 Moajs 框架，Express / MongoDB
pm2 部署,前后端分离，阿里云的 slb 负载，alinode 监控
moa-api,moa-frontend,moa-h5 (未能用)
使用 Redis 缓存，Rabbitmq，senaca 作为 RPC
一些正在建设的方面
使用 kong 作为 API gateway
consul 做服务发现和配置
上 elk 作为日志分析处理
使用 docker compose 作为本地开发环境
线上 docker
打算进行技术栈更新，包括Nodejs 4.x（预计今年 6 月份；Koa（generator/co）；es6/es7 ( babel )。
4.x 在内存和性能上都有非常大的提升，新的语言特性上，异步流程和语法上都需要学习，故不急于升级，待人才梯队完善。
目前的做法是小步快走，一次只上一样新技术；另外形成梯队，即可准备上新东西；善用 npm，实现 3 化：模块化、最小化、服务化
MEAN 架构
MEAN 是目前最潮的全栈 JavaScript架构。MEAN 是一个 JavaScript平台的现代 Web 开发框架总称，它是 MongoDB Express AngularJS Node.js 四个框架的第一个字母组合。它与传统 LAMP 一样是一种全套开发工具的简称。
从我的角度看
MySQL 用 MongoDB 替换，NoSQL 里最像 rdbms 的，从开发和性能都是有优势的（参看老毕在高可用架构群分享文章：MongoDB 2015回顾：全新里程碑式的WiredTiger存储引擎）。
Angular 的出现是一个时代，IoC，双向绑定，指令等都曾让无数热血沸腾。
Node.js 提供了完全的生态和工具链，你要的它基本都有，感谢 npm，早些年 Node.js 的性能甩 php 几条街的。
Express 作为 Node.js 示范项目，它非常精简，是比较合适的 Web 框架
我为什么选择 MEAN 架构？
成熟、稳定，简单，有问题我们能 cover 住，所以我们选了 Node.js。
把握趋势，以后 Node.js 的前景非常看好，尤其前后端统一，全栈方向。
在架构上可以屏蔽可能风险，不孤注一掷，也不会一叶障目，合理的使用其他语言，只要每个功能都以服务出现，至于它是什么语言写的，并不重要。
招人成本的性价比相对较高，技术栈新，容易吸引人才。
最重要的一件事儿，是当有问题的时候，有人能 cover 住，在创业初期这是最最重要的事儿。
Node.js最新Web技术栈
https://cnodejs.org/topic/55651bf07d4c64752effb4b1
异步流程控制
JavaScript流程控制的演进过程，分以下 5 部分：
回调函数Callbacks
异步JavaScript
Promise / a+ 规范
生成器Generators/ yield ( es6 )
Async/ await ( es7 )
目前所有版本都支持 Promise / a+ 规范
目前 Node.js 4.0 支持 Generators/ yield
目前不支持 es7 里的 Async/await，但可以通过 babel 实现
整体来说，对异步流程控制解决的还是比较好的。
Node.js 最新技术栈之 Promise 篇
https://cnodejs.org/topic/560dbc826a1ed28204a1e7de
业务边界优化
创业公司有很多可变性，要做的系统也无数，如何保证业务系统的边界是非常难的，我们其实走了很多弯路。
静态 API 理论
当需求和 UE 定下来之后，就开始编写静态 API，这样 APP、H5、前端就可以使用静态 API 完成功能，而后端也可以以静态 API 为标准来实现，整体效率还是比较高的。
API 的最佳实践
http://developer.github.com/v3/ （严格的restful）
微博 API (可读性强，相对比较传统)，我们采用的微博 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 开发总结
https://cnodejs.org/topic/552b3b9382388cec50cf6d95
约定结构
和 Java 开发里的目录结构类似，该分层的分层，适当的按照 Express/Koa 增加中间件、路由等目录，便于开发。
使用 npm 模块化
使用 npmjs 的 private 私有模块（目前做法）
使用 npm 的本地模块开发方法（测试和部署都非常快）
搭建 npm 私服（todo）
编写生成器
在 Web 开发里，写了 Moajs 生成器，类似于 rails
moag order name:string password:string
其他开发，如 iOS 开发里模型校验非常烦,于是写了一个 json2objc 命令行工具，读取 json，生成 oc 代码，可以节省不少时间
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 自动监控文件变动，跑测试
gulp routes 生成路由说明
使用 log4js 记录日志
从开发效果上看，还是非常快的，非常稳定的。
Moajs框架演进之路
https://cnodejs.org/topic/567e2388aacb6923221de469
Node.js 相关工具
grunt/gulp/fis/webpack
bower/spm/npm
tdd/bdd cucumber/mocha
standard
babel/typescript/coffee
前端开发四阶段
Html/css/js（基础）
jQuery、jQuery-ui，Extjs（曾经流行）
Backbone（mvc），Angularjs、Vuejs（当前流行）
React组件化（未来趋势）、Vuejs
Vuejs 综合 Angular 和 React 的优点，应该是下一个流行趋势。
Hybrid 开发
Hybrid 混搭开发是指使用 H5 技术开发的跨浏览器应用，并最终可以将 html5/js/css 等打包成 apk 和 ipa 包的开发方式。它也可以上传到应用商店，提供给移动设备进行安装。它最大的好处是通过 H5 开发一次，就可以在多个平台上安装。
未来将会是JavaScript一统天下（Node.js 做后端，传统 Web 和 H5 使用 Javasctipt，更智能的工具如 gulp，更简单的写法如 coffeescript 等）。H5 大行其道（网速变快，硬件内存增长）。
跨平台
C/S 架构到 B/S 架构，这个大部分都清楚，不多说。
移动端加壳，在浏览器上做文章，把页面生成各个移动端的 app 文件。
PC 端加壳，一样是延续浏览器做文章，不过这次把页面生成各个 PC 平台的可执行文件。
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
组件化：统一用法
React 的出现影响最大的是 JSX 的出现，解决了长久以来组件化的问题：
我们反复的折腾 JavaScript，依然无法搞定
我们尝试 OO，比如 extjs
我们最终还是找个中间格式 JSX
单纯的 React 只是 view 层面的，还不足以应用，于是又有 Redux。核心概念：Actions、Reducers 和 Store，简单点说就是状态控制，然后再结合打包加壳，变成 app 或可执行文件。iOS、Android 上用 Cordova，PC 上使用 Electron。
总结
组件定义好（React）
控制好组件之间的状态切换（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（业务相关），只要打通这 2 个要点，其他就比较容易了。
1、从后端转
做后端的人对数据库是比较熟悉，无论 MongoDB，还是 Mysql、Postgres，对前端理解比较弱，会基本的Html，Css，模板引擎等比较熟悉。
4 阶段循序渐进，build 与工具齐飞，前端开发 4 阶段，我的感觉是按照顺序，循序渐进。
Html / Css / JavaScript（基础）
jQuery、jQuery-ui，Extjs（曾经流行）
Backbone，Angularjs（当前流行）、Vuejs
React（未来趋势）、Vuejs
Vuejs 综合 Angular 和 React 的优点，应该是下一个流行趋势
2、从前端转
从前端往后端转，API 接口非常容易学会，像 Express、Koa 这类框架大部分人一周就能学会，最难的是对 DB、ER 模型的理解，说直白点，还是业务需求落地的理解
我们来想想一般的前端有什么技能？
Html
Css（兼容浏览器）
JavaScript会点（可能更多的是会点 jQuery）
PS切图
Firebug 和 Chrome debuger会的人都不太多
用过几个框架，大部分人是仅仅会用
英语一般
Svn / Git 会一点
那么他们如果想在前端领域做的更深有哪些难点呢？
基础：OO，设计模式，命令，Shell，构建等
编程思想上的理解（MVC、IoC，规约等）
区分概念
外围验收，如 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 原生开发，hybrid 混搭式开发。原生开发就是 iOS 用 oc/swift，Android 用 Java 或 Scala 等，就算偶尔嵌入 webview，能玩 JavaScript的机会也非常好少。所以移动端转全栈的方法，最好是从 cordova（以前叫 phonegap）开始做 hybrid开发。只要关注 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 发布
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 版本发布，即新的 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 发布了 v1.0.0 版本（IO.js）
2.x（IO.js）
3.x（IO.js）
2015 年 09 月 Node.js 基金会已发布 Node.js v4.0 版 与 IO.js 合并后的第一个版本
2015 年 10 月 Node.js v4.2.0 将是首个 LTS 长期支持版本
年底发布到 4.2.4 && 5.4.0
目前（2016 年 3 月 20 日）的 2 个版本
v4.4.0 LTS（长期支持版本）
v5.9.0 Stable（稳定版本）
整体来说趋于稳定。
成立了 Node 基金会，能够让 Node.js 在未来有更好的开源社区支持。
发布了 LTS 版本，意味着 API 稳定。
快速发版本，很多人吐槽这个，其实换个角度看，这也是社区活跃的一个体现，但如果大家真的看 CHANGELOG，其实都是小改进，而且是边边角角的改进，也就是说 Node.js 的 core（核心）已经非常稳定了，可以大规模
使用。
Node.js 的企业级大事儿记
2014年 nearform （NODE.JS 为什么会成为企业中的首选技术？http://www.nearform.com/nodecrunch/node-js-becoming-go-technology-enterprise/）
2015年 IBM （收购 StrongLoop，拓展云服务业务 http://www-03.ibm.com/press/us/en/pressrelease/47577.wss）
Node.js 基金会的创始成员包括 Joyent、IBM、Paypal、微软、Fidelity 和 Linux 基金会。
对于企业级开发，Node.js 是足够的，无论从性能、安全、稳定性等都是非常棒的。
空弦科技做的是基于云仓储的 SaaS 服务，给中小卖家提供服务，核心系统是进销存、订单池、WMS。目前来看不存在任何问题，
es && babel
2015 年 ECMA 国际大会宣布正式批准 ECMA-262 第 6 版，亦即 ECMAScript 2015（曾用名：ECMAScript 6、ES6）的语言规范。
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 内核，它还可以支持更多其他浏览器内核，对生态、效率提升等非常有好处。
蔡伟小兄弟的查克拉 benchmark 的对比（https://github.com/DavidCai1993/ES6-benchmark）基本结论是 V8 ES5 > 查克拉 ES6 > 查克拉 ES5 > V8 ES6
1.在全栈的语言选择上，除了 Node.js，是否还考虑过其他语言？
桑世龙：有的，未来 swift 和 Lua 是有可能的。swift 的语法和性能上有很大优势，Lua 在 openresty 的推动下也有机会，不过没有 swift 大。像 WebAssembly 之类的就不太看好了。
2.请教桑老师：刚才你说的并发开发流程中静态API指的是API文档？如果是的话谁负责编写？你们目前已经是一个人分模块从前端写到后端了吗？
桑世龙：目前没做到文档即静态 API，所以目前是直接提供 json 和部分（json-server https://github.com/typicode/json-server），负责是后端开发的 leader 在写，他的进度会比正常开发要早一周左右。目前不是一个人写所有的前后端，团队成立不久，天津 Node.js 会的不多，所以还是前后端分离。但是通过 moa-frontend 可以让前端了解 Express 等后端知识，适当的时候会给予机会，前端转后端。
3.贵司在开发协作中提到了静态 API，请问是不是有什么比较好的工具可以推荐？
桑世龙：Node.js 里（json-server https://github.com/typicode/json-server） 比较好
我其实很想围绕静态 API，写各种请求的生成器，只要 API 出来，文档和各平台的 HTTP 请求代码就生成出来，同时可以对正式 API 进行压测，可惜目前还没精力写。
4.做 hybrid app 在移动端会遇到性能问题吧，有没有什么优化经验可以分享？
桑世龙：足够轻量级，少选大框架，做好前端该有的优化。注意 touch 和 click 的区别，比如 fastclick 或 Zeptojs 的 tap 手势。Chrome profile（css3动画）。使用 weinre 真机测试。参考：（我的 H5 实践 http://mp.weixin.qq.com/s?__biz=MzAxMTU0NTc4Nw==&mid=222892082&idx=1&sn=ba1cdb42b43fbec08e4328c5080774e5#rd）。
5.如果都全栈了，当前你们团队是如何分工的？
桑世龙：我们团队还是倾向于分工专业化，各个服务粒度非常小，便于轮岗、还有就是可以为以后像 Google 那样代码开放做准备。但是有很多情况下，是需要有机动的突击队的（尤其是创业时期），这样可以随便组合，另外就是全栈为 remote 提供了更多便利性。
6. H5 在手机上用 iScroll 坑比较多啊 尤其三星打开硬件加速的时候 render 页面，桑老师怎么看？
桑世龙：可以尝试一下淘宝系的 H5 虚拟化，鬼道曾经在 as 大会上讲过的，我们目前还没能力做这么深层次的优化。
7.Node.js 做业务金额计算的金额性能和精度够吗
桑世龙：你问的不是 Node.js，而是 Node.js 要操作的数据库。耗性能的计算可以在架构上平衡的，如果可以延时，MQ 就可以了。如果是非延时情况，可以采用其他语言编写对应服务，没必要非要一定要 Node.js。我们目前的场景，还没有在计算遇到瓶颈。
8.关于 API 返回格式那里，对于 status 为什么不打平了把 code 和 message 放出来？这么设定有什么好处么？
桑世龙：语义上更加清晰。整个返回的 json 就只有 data 和 status，如果 status.code != 0,我取 msg 就好了，如果等于 0，处理 data 数据这种设计不见得多好，不过结构清晰，对于开发者来说，是比较容易接受的。
最后桑老师还要补充最重要的一句，大家别忘了互相转告。
空弦科技招聘全栈相关架构师、高级程序员，语言不限，坐标天津，邮箱：sang@aircos.com
本文策划李庆丰，编辑王杰，审校 Tim Yang，想讨论更多 NodeJS 全栈开发，请关注公众号获取进群机会。转载请注明来自高可用架构「ArchNotes」微信公众号及包含以下二维码。
高可用架构
改变互联网的构建方式
长按二维码 订阅「高可用架构」公众号
片来源@视觉中国
文｜航通社，作者｜书航
从头开始制作一个手机操作系统，并让它至少站稳脚跟，甚至取得成功，这听起来像是天方夜谭。
甚至比尔·盖茨都承认，他们不能在手机领域复制 Windows 当年的成功，听凭 Android 崛起，并带来了一个 4000 亿美元的教训。[1]
但是，在内忧外患的催化之下，华为还是开发了用于替代 Android 的“鸿蒙”系统，它正准备向世界发出第一声啼哭。
“鸿蒙”的出现恰逢其时——相比历史上的那些艰难时刻，现在正是无限接近一个新的操作系统能走向成功的时机。
在大阪 G20 峰会结束后，美方称有望解除当前对华为的制裁，给了华为手机的海外业务一个意外惊喜。[2]
受制裁影响，谷歌服务套件将在 90 天宽限期之后也即今年 8 月底开始，无法在华为海外新机预装。诸多国外流行 Android 应用必须依赖此套件才可以运行。
这一纸禁令意味着华为手机将暂别谷歌一手搭建的海外应用生态，让用户恐慌，甚至在新加坡出现了低至 7 折的二手抛售。只是随后，因为有人觉得可以转手卖给中国大陆，价格又开始涨回来。[3]
在中国大陆，因为谷歌应用市场从未被正式准入，有需要使用谷歌服务和国外应用的用户，一般都能自学知识破解，也出现了一键傻瓜式的“谷歌安装器”。但对海外而言，这是否合法暂且不论，哪怕让用户手动多做一个操作，都会挡住很多只会一路下一步的人。
华为宣布他们有一个自研的备用操作系统，用于这种极端情形。它在媒体报道中有很多不同的名字，但最常用的是“鸿蒙”。据称这个系统可以跨手机、电脑、电视、汽车等多种设备使用，同时支持运行网页应用以及 Android 应用。[4]
跟自制芯片相比，自制操作系统听起来更“不靠谱”。消息公布一个多月以来，不断有人梳理国内外挑战 iOS、Android、Windows 和 macOS 四大系统的各种失败史。
现代操作系统从运行逻辑、界面、交互、硬件适配等多个方面，都已经高度趋同且非常成熟。虽然可能存在一些专利壁垒，但大家也多少都有规避的办法—— iOS 曾因为高通起诉，而微调多任务切换的动画效果。
唯一不同的地方，就在于生态。为你这个系统开发的第三方软件是否足够多？是否够用？该有的东西是不是都有？开发者和用户社群是否能够互相促进，像滚雪球一般越滚越大？
数不清过去有多少钱投入到操作系统开发之后打了水漂。像 WebOS 这样把用户体验做得超越时代的优秀系统，没能获得一线生机；而 Symbian、Windows Mobile 这样曾叱咤风云的旧日霸主，也都在短时间内匆匆陨落。
一切都可以归结于生态建设的失败，这真是关生死，定胜负的因素。
如何从头开始构建一个成功的生态？我们从 iOS 讲起。
iPhone 初代并不支持第三方应用的安装，但是它在功能和操控上的划时代突破，吸引了全世界的关注。产品本身做得足够好，以至于人们产生巨大兴趣，这是让它马上能吸引到开发者的诱因。
多点触控加上支持桌面 Web 功能的浏览器，让当时的开发者只要做一个适合手机屏幕宽度的网页，就足以成为一个“App”。
Safari 浏览器支持把网页快捷方式放到桌面，图标也跟原生 App 一模一样。在 App Store 诞生初期，有很多 App 实际上只是一个浏览器的壳，把网页做了封装就上架了。放到现在，这是不可想象的。
App Store 一旦推出，苹果对 iPhone 的宣传重心就完全改为应用，对商店体系下开发者的宣传、推荐和培养过程，也基本是从此时开始成型，并被后人效仿。
另一方面，已有足够应用数量兜底的 App Store 保持了严格的准入机制，对直接安装商店外应用的“越狱”围追堵截，确保了收费应用开发者的权益。等到应用下载数、安装数、付费应用收入等指标纷纷创下新高，iOS 生态的地位已经不可撼动。
只是对于其它后面来的玩家而言，苹果获得这般成功的关键几乎就是三个字——做得早。
在另一边的开放阵营中，Android 成功的秘诀也是做得早。
在体验也不算差的 Windows Phone 7 出来的时候，它面对两个问题：一个是原先 Windows Mobile 的应用全都不能沿用，甚至不能移植过去，对微软而言相当于一切都要从零开始；二是既然是从零开始，这时候对面 Android 已经做了两年。而这两年里，微软致力于让大多数上市的 WM 6.5 手机支持全键盘，以发挥它移动 Office 的所谓“生产力”优势。
大体上，这就是盖茨慨叹的 4000 亿美元怎么损失掉的原因。
要建设一个经典的应用生态，需要的并不是大力出奇迹，反而用力过猛会适得其反。特别是，直接引用别人（说白了就是 Android）的生态系统，并且无脑移植过来的做法，只会搭建一座了无生气的“死城”。
我还记得微软当初在华推广 Windows Phone 应用开发之初，曾经许诺给报名的开发者都送一台外壳靓丽的诺基亚手机，所需要的仅仅是把开发者已有的安卓程序，以简单步骤转制为一个 Metro 应用就可以了。[5]
前面说过，因为“做得早”，iOS App Store 和谷歌应用商店，最早期都可以允许一些网页套了个壳的简单应用上架，仅仅过了两年，用户就再也不可能接受这种东西了。
而一键转换而来的应用，有时出现无法正常启动或界面错位等现象，商店也没有及时发现和处理，这导致用户看到各种各样跟安卓同名的应用，但使用体验却极为差劲。
种种原因让 Windows Phone 的应用商店被大小开发者抛弃。2015 年 3 月，支付宝发布 Apple Watch 适配却不愿更新已沉睡 3 年的 WP 客户端，引发用户不满。官微回复了一句：“你是1%，为什么要选择1%的生活？” [6]
这句话让“1%”成为中国 WP 用户的自嘲专有名词，直到微软彻底放弃自己的手机操作系统为止。
iOS 封闭的应用生态被人们形象的称为“围墙花园”，因为开发者想要突破这个“围墙”是基本不可能的；相比之下，Android 可以自由地分发和安装后缀为 APK 的安装包，因此走上了不同的发展道路。
人们对 iOS 的粘性，很大程度上是由众多开发者贡献的优质应用带来的。苹果却利用这种难以挣脱的粘性，对平台内的应用内付费（IAP）征收 30% 的手续费，开发者只能将这一成本转嫁到消费者身上。
这导致对于一些跨平台的产品，如果是在 iOS 客户端内购买诸如电影、音乐、游戏道具等商品，支付的费用要比在安卓或网页版购买贵三分之一。
2017 年，苹果针对中国部分应用中出现的对作者“打赏”的情况，宣称这也属于应用内付费。也就是说，在微信公众号、知乎专栏、视频直播应用等地的打赏也要被抽成 30%。这对于风行一时的内容创业生态是一大暴击。
iOS 形成的天然市场垄断地位，导致其中几乎每一个默认位置，对合作伙伴都是不菲的花销。今年 2 月份有分析指出，为了保住在 Safari 浏览器中的默认搜索引擎地位，谷歌在 2018 年度向苹果支付了 95 亿美元，相当于苹果 2018 年营收的 1/5。
该分析师计算，谷歌的这部分贡献，加上 App Store 的分成收入，两项占苹果 2018 年服务营收的比例高达51%，占毛利润比例更高达 70%。[7]
今年春季，苹果发布了一系列的内容订阅产品，收“苹果税”的习惯也沿袭到了这些新的服务身上，由于苹果提出的分成比例过高，一些主流的出版商选择抵制苹果杂志订阅服务 Apple News +。
从 2011 年开始，就有美国消费者提出对 App Store 高额抽成的诉讼。他们认为这增加了消费者获取同类服务的时候，相对安卓等其它用户付出的成本。
苹果认为他们不是合适的原告，因为商店抽成是面对开发者，而不是用户，应该由开发者来起诉。不过按照这个逻辑，开发者真的起诉了苹果之后，还能不能继续在 App Store 愉快的玩耍呢？
历经 8 年多的不断反复，直到今年 5 月，美国最高法院才以 5:4 的比例，判定苹果在这一阶段性的诉讼过程中败诉。也就是说，任何 iOS 的用户，而不仅限于开发者，也都可以提起反垄断诉讼。消息一出，苹果的股价大跌，投资者担心这会影响到苹果服务产品的盈利模式。[8]
受到这一判决结果的激励，在 iOS 开发者群体当中也有人挺身而出。6 月初，有两名开发者向苹果所在的圣何塞地方法院提起反垄断诉讼，称 iOS 只允许一家单独的应用商店运转，不允许其他第三方的商店，削弱了用户的自主选择权。如果这一诉求获得法院的支持，那其实也意味着在海外安卓系统当中只有 Google Play 商店的情况也要改变。[9]
目前这些案件都还在审理过程当中。唯一可以确定的是，这些小小的变化正推动着已经稳定运转了 10 多年的 App Store 模式发生变化。围墙花园的高墙开始出现了裂缝。
推动这一裂缝变得越来越大的，还有两个重要的因素。
在国内，全民普及的超级 App 纷纷推出了小程序，总算把手机网页充当 App 的多年志向部分实现。
小程序是一种封装好的基于 XML 变种语言的软件包，依赖母体 App 获得读取个人信息及调用手机硬件能力的权限，跨越 iOS 和 Android 平台限制，能够共享一致的用户体验。
不管是此前百度、UC 浏览器的“轻应用”，还是之后手机厂商推出的“快应用”，都不能像微信、支付宝、百度系、字节跳动系 App 一样，对所谓“网页应用”的推广起到这么大的推动作用。
在中国，人们习惯于在少数几个超大型的 App 当中完成几乎所有的事情。早在 PC 互联网时代，英语用户习惯使用 AOL、雅虎和谷歌的搜索框来获取信息，而中国人则锻炼出了使用密密麻麻的网址大全的习惯。
同样的风格差异也体现在中英文购物网站的区别上。淘宝、京东等网站摆满了商品信息，而亚马逊的每次改版都反其道而行之，尽可能追求页面的简洁。你很难简单评判两种习惯的优劣。
在移动互联网时代，人们也需要一个包揽一切的入口。微信、支付宝、百度等产品担当了这样的角色。它们都拥有可以阅览资讯（公众号-生活号-百家号），进行一定程度的交流（聊天-蚂蚁森林-贴吧），以及购物、缴费、支付的能力。
这些超级 App 成为一个笼罩在操作系统之上的新的平台层。华为要做“鸿蒙”，只要这几个超级 App 分别实现了适配，那么架设在上面的所有小程序生态都可以无缝转移过去，大大减少了人们适应新系统的障碍。
超级 App 挟用户而令商店，跟苹果和谷歌之间形成了亦敌亦友的关系。苹果曾强迫微信赞赏功能抽成 30% ，微信干脆先撤下赞赏能力，谈判一年，最后毫发无伤。在苹果的发布会上，微信经常被放在 iOS 的相关幻灯片上，作为中文应用的代表出现。
在国外，利用最新 Web 技术的渐进式网页应用（PWA）正成为潮流。新的 Web 标准令 PWA 不同于以前的手机版网页，具备了本地存储、调用分享接口等能力。
已经酝酿了 10 年以上的“网页应用”，之所以到了近一两年才有跟原生应用分庭抗礼的迹象，是因为技术终于到了成熟的时候。这就好像微软早在 2002 年就推出了平板电脑版的 Windows，但是最终实现平板电脑的“完全体”形态，却要等到苹果的 iPad。如果技术不到那个程度，揠苗助长不会有好结果。
早期的网页应用，因为操作系统的运算能力和后台驻留能力不足，导致页面不断的刷新，表单信息容易丢失。而且如果不在室内的 WiFi 环境之下，在手机上还容易因为断线而无法继续操作。当时的网页技术也不具备离线缓存的能力，也无法调用系统的摄像头、麦克风等硬件。
随着互联网标准的完善，除了以上提到的能力之外，网页的绘图效率也因为 CSS 和 HTML5 Canvas 的改进而提高；一些 3D 效果可以通过 WebGL 等技术，不用插件，直接在浏览器中实现。
甚至支付都不是问题—— Facebook 宣布推出的稳定币 Libra 必定会应用在众多内嵌 Facebook 框架的网页，即使是网页版的用户，也可以正常的收付款或查看钱包状态。
与此同时，5G 网络的普及和网络信号覆盖率的提升都意味着操作网页元素时，可以加载和缓存更多内容，避免应用崩溃。
PWA 最激动人心的地方，就是它的本质是一个网页。这意味着任何现代浏览器和操作系统都可以支持它们，并获得完全一致的使用体验。
PWA 已经获得了谷歌和微软应用商店的官方支持，可以获得跟原生应用类似的图标和启动方式；在 Windows 10 的将来版本中，PWA 更可像原生应用一样在“设置”里卸载。[10]
没有获得移动互联网“船票”的微软，和正打算推出新操作系统 Fuchsia 的谷歌，都把 PWA 看作是在当前的原生应用体系之外，新建生态的突破口。
在用户和开发者“以卵击石”般悲壮的法律挑战之外，中国的超级 App 和全球合作的 PWA 开放环境，共同给花园的围墙撕开更大的缺口。
不管是强大的厂商希望自己打破操作系统的区隔，还是小开发者以 Web 标准实现终极的跨平台编程，都是在实践一个由来已久的心愿：当初 Java 所提出的“写一次就到处运行”的理想，将在这些继承者身上得到延续。
今年 4 月，有人因为主力办公电脑送修，所以不得不使用 10 年前的笔记本电脑工作。结果他意外地发现，虽然有点慢，但是不影响使用。10年前的电脑依然能够满足日常工作。开发者阮一峰评论说：[11]
“如果 2009 年让你去用 1999 年的电脑，那是不可想象的，根本没有实用性。但是，2019 年去用 2009 年的电脑，却是完全可行的。这说明，过去十年的硬件进展不太大，导致 10 年前的硬件不是那么过时。过去十年，进展主要体现在软件上面：软件功能更强大、使用更友好、界面更美观。”
多年前，航通社写过《软件应不应该更新到最新版》，表达了类似的看法。[12]
很多情况下，软件并不是越新越好。有些新版要求单机软件强制联网，加入你并不需要的会员功能和消息推送；有些新版和旧版，甚至同一版本的自家软件不兼容；有些产品更是从头到尾蜕变成另一款你不认识的软件。
上述问题都是操作系统原生应用普遍存在的。如果同一款软件有对应的网页版，那么只需要一个浏览器，就可以避免大部分烦恼。在桌面电脑上，浏览器就是我们所说的“超级 App”。
历史上，PC 操作系统的软件生态经历了从纯粹的单机软件，到出现 c/s（使用客户端与服务器交互）再到 b/s （使用浏览器与服务器交互）的过程。这一过程也在手机操作系统上得到重现，虽然其中经历了曲折反复。
眼下，由超级 App 和小程序、PWA、统一的 Web 标准以及 5G 等通信技术的进步，共同催化了在应用商店之外，一个全新的、开放的、跨平台的生态。
苹果曾经以 Flash 是一个闭源的技术为理由，在 iOS 中取消对 Flash 的支持，促成了这个风靡一时的网页技术的凋敝。但 iOS 和 Android 本身也不能免俗于掌控一个封闭平台的诱惑。
作为 iOS 和 Android “护城河”的应用商店，是再典型不过的“围墙花园”，正是花园的高墙挡住了历史上其它竞争操作系统的道路。现在，高墙终于开始出现了裂缝。
如果华为“鸿蒙”系统能仅仅凭借对大量 PWA 和小程序的兼容性，就成功站稳脚跟，这将是一个重要的标志，意味着头部操作系统长期积累而成的应用生态壁垒，今后将不再扮演像现在这么关键的角色。
而操作系统的地位，也将下降到作为一个承载浏览器和个别超级 App 的容器，不同系统之间的操作习惯几乎可以无感知地移植，这样用什么操作系统就再也不是一个问题。
这是“鸿蒙”的机会，也是我们所有人的机会。
[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）或发邮件给 coop@lishuhang.me
更多精彩内容，关注钛媒体微信号（ID：taimeiti），或者下载钛媒体App
*请认真填写需求信息，我们会在24小时内与您取得联系。
