可扩展性的那些事儿：最真实的城市模拟

前一阵子，EA 重新发布了 SimCity 这款游戏的最新版本：SimCity 2013（或者叫做 SimCity 5）。神作续集往往粉丝很多，于是很快时间就有很多玩家掏腰包进入游戏。但是呢，这次的 SimCity 是无法离线玩的，这意味着你在没有网络的时候不能玩，同时也意味着 EA 服务器宕机的时候你也不能玩……杯具的是，SimCity 的服务器宕机的很惨，导致 EA 不得不宣布关闭了一些“不重要的”特性以确保游戏能够继续进行。这一事件被广泛称之为“ SimCity Disaster ”。

1. 一篇有关技术债务、SQL 与NoSQL 的文章讲述了四个优化做的很烂甚至技术本身很烂但是生存的很好的初创企业，在 Reddit 上引起了热议，其观点是：编写 Map/Reduce 任务相当于在技术层面上偿还自己还没欠下的债务。
2. 客户端 MVC 不是银弹。“客户端处理与解耦过程既拖慢开发速度、也会影响应用程序性能。”
3. 为啥我们放弃了 MongoDB 而投向了 DynamoDB ：几位玩 MongoDB 的童鞋觉得 MongoDB 的托管服务太贵了，于是投奔了 DynamoDB，结果被某位匿名人士喷到：“结果，你们在应用代码里面维护一个 DynamoDB 域的二级索引？脑子没有秀逗吧？”
4. 历史学家 George Dyson（他也是物理学家 Freeman Dyson 的儿子）在 7thavenueproject 的广播节目中的一次采访：图灵大教堂与数字宇宙的黎明。基于模板的定位。基于模板进行 DNA 的搜索。我们不需要了解蛋白质的确切位置，匹配不需要绝对准确。Google 是数据搜索的模板。Dyson 认为这种模板化思维堪称计算史上的第三次革命。更灵活，更强大，能够容忍错误，能够处理模糊状况的架构，这与自然界的处理方式完全一致。Google 就像一台谕示机。阿兰·图灵曾说，除非我们允许机器犯错误，否则机器永远不会拥有真正的智能。确定性计算存在种种局限，而非确定性要素则是谕示机所必需的。我们要鼓励机器犯错误，宽容对待这种错误并使其从错误中学习。组成 Google 的原件是一系列确定性的机器；而作为人类，我们加入了 Google 的循环，在其中充当非确定性信号——正如谕示机的角色。
5. 如果有了数以百万计的八核乃至更多核的移动设备，我们能做些什么？不如考虑一下WebRTC，这个技术能够真正在浏览器中实现点对点。大家不妨看看 PeerJS 以及 SimpleWebRTC.js 。在我看来，我们似乎可以将昂贵的后端服务器抛在一边，认真探索一套利用移动设备合作所构成的可持续发展计算模型。
6. 来自 GitHub 的 Ted Hyman 做了一个分享： Scaling Happiness 。Hyman 主张完全舍弃管理人员。光靠文化与自由的特权还远远不够。要改变文化，我们必须先改变结构。这种结构也就是不要结构。文化总是自然产生。来自 67 个城市的 146 位成员共同为 GitHub 工作。如果缺少制定决策的机制，GitHub 上的很多优秀想法根本无法变成现实——因为大家彼此之间不能达成共识。这就是权衡的结果。团队是在兴趣的基础上自发成立起来的，换言之我们需要招聘正确的人才。技术创造秩序，内部工具则带来结构与处理惯例。我们无法随意指派某人去完成某项任务。要想彼此相容，我们就得允许他人以自己的方式使用资源库与工具。大家要学会接受失误。自我管理是无价之宝。没有任何成员在五年内离开团队。政策源自每个人的意见。也许在过程中有些好点子彻底消失了，但这是我们必须付出的代价。
7. TechOps Web 应用的预发布检查清单。这份清单罗列出了应用程序发布之前需要完成的各项任务。主要类别有：灾难预备、运行基本安全检查以及扩展性预备。 ukd1 在其 Hacker News 的讨论中评论到：‘设置一个缓存层（Memcached、Redis 或 Varish）’——如果这样就能扩展一切就太好啦，可惜现实是骨感的。扩展的准备工作应该包括：1. 测试我们何时需要筹备扩展；2. 实施监控，这样我们就能了解实施时间；3. 在接触数据及时间之前先从第 2 条中获取信息并制定规划；4. 实施；5. 测试第 4 条是否顺利进行；6. 发布；7. 重复整个流程。方法才是有意义的，“设置一个缓存层”不是一个方法。
8. 正如在 Disfluency（非流畅性）这篇文章中所提出的理论所说的，不容易理解的表达是一种警示，让我们意识到情况其实比预想的更复杂。在程序里面，这个理论也是通用的。
9. 数字系统中的可持续性。向上扩展，让城市更具有可持续行：将节约向上扩展为一套完整的“生态系统”，这样各建筑之间就能互相利用对方节约下来的资源；建筑物的能量活动不存在线性模式；各建筑物之间的互联性比建筑本身的年代、高度或者其它特性都更为重要；如果我们将建筑密度提高 50%，就能降低 20% 的能源使用量。
10. 为什么会出现复杂系统，这类系统在哪些情况下会失效？复杂系统从本质上讲非常危险，而任何复杂系统都针对故障进行了严密的防护工作。大型事故往往来自多个小型的故障，单点故障往往不足以拖垮一个复杂系统。复杂系统中包含多种潜在故障因素的混合体，并运行于降级模式之下。
11. 这条是个坏消息：供电中断引发的大问题：实验结果表明，15 套测试 SSD 设备中有 13 套在电源故障下发生惊人的损坏情况，包括位元信号错乱、写入错误、非串行化写入、元数据损坏以及总体设备故障等。
12. 大跃进：脱离了客户端 UI 的束缚，Basecamp Next 运行速度有了质的提升。文中深入探讨了一些高级网站加速技术：对每个我们曾经访问过的页面进行临时缓存处理，并在切换回该页面时进行内容更新，缓存容量依设置而定。大家可以在不同页面间共用一套缓存，也可以在不同用户间共用一套缓存，并使用无限分页发送较小的数据块。
13. Amir Salihefendic针对 Redis 进行了一番精彩陈述。它可以用于实现队列及其它常见编程任务。值得一提的是，利用 bitmapist 进行高级分析工作能帮你每月节约 2000 美元。
14. 花了几个礼拜来调整 JVM 标记？请阅读 JVM 性能优化第五章：Java 与扩展性是否属于一对矛盾？：正是 JVM 技术限制了企业级 Java 应用的扩展性。
15. O’Reilly 的新书，有关图形数据库。本书由 Ian Robinson、Jim Webber 以及 Emil Eifrém 共同撰写。看起来很棒的样子，而且这本书现在在审校阶段，是可以免费下载的：）
16. 利用集群模块来创建能够在一台设备上共享端口的网络流程，进而实现 Node.js 应用的扩展。我们可以通过 node-http-proxy 或者 nginx 来处理跨设备负载平衡工作。配置文件实例讲解非常清晰，能够帮助我们快速上手 Node.js。
17. Ooyala 能够为 Cassandra 针对大数据提供扩展性支持。用户可以利用它提高 Map/Reduce、Storm、恢复强化、机器学习以及指标测量的处理速度。
18. Braintree 的高可用性。 Braintree 是一套支付网关，因此 uptime 非常重要。所有故障被分为计划内与计划外两类。针对计划内故障的应对措施：维护窗口、迁移前后、滚动部署、针对高速 DDL 的 PostgreSQL，以及用 proxy later 暂停流量。针对计划外故障的应对措施：自建负载均衡器、LVS/IPVS、Pacemaker、BigBrother、LitmusPaper、在多 ISP 及数据中心间利用 BGP 进行流量路由、Pingdom 监控、连接、多网络连接、ISP 常见局部停机、使用处理器代理对 ISP 连接问题所涉及的代理与路由进行负载平衡、Mallory、系统恢复与重试、全局自动化。
19. 利用数据结构解决问题：数据结构能够用于封装实施细节并带来优美整洁的代码成果。封装是面向对象代码的首要推动力。
20. 2013 年 2 月 22 号 Windows Azure 存储停机细节回顾。教训：时刻保证安全证书的更新。这一点永远非常重要。另外， Azure 在性能测试中击败了 Amazon 云产品。
21. 循环仍在继续。Amazon 将 DynamoDB 的价格下调了 85% 。发布创新型产品。在实践中积累经验。通过规模化经济、硬件改进以及算法优化降低运营成本。