结合服务器、数据库等环节设计，途必科技小优再续讲在开发测试环节如何运用编码、缓存等技术来完成生成效率和运行效率。

编码

流程

大部分程序员都是远程工作，自己选择编码地点

编译非常快

然后运行少量的测试

一旦编译成功，代码即转移至开发交付准备服务器

通过功能开关隐藏新功能

在相同硬件上作为其他站点测试运行

然后转移至 Meta.stackoverflow 测试，每天有上千个程序员在使用，一个很好的测试环境

如果通过则上线，在更广大的社区进行测试

大量使用静态类和方法，为了更简单及更好的性能

编码过程非常简单，因为复杂的部分被打包到库里，这些库被开源和维护。.Net 项目数量很低，因为使用了社区共享的部分代码。

开发者同时使用 2 到 3 个显示器，多个屏幕可以显著提高生产效率。

缓存

缓存一切

5 个等级的缓存

1 级是网络级缓存，缓存在浏览器、CDN 以及代理服务器中。

2 级由 .Net 框架 HttpRuntime.Cache 完成，在每台服务器的内存中。

3 级 Redis，分布式内存键值存储，在多个支撑同一个站点的服务器上共享缓存项。

4 级 SQL Server Cache，整个数据库，所有数据都被放到内存中。

5 级 SSD。通常只在 SQL Server 预热后才生效。

举个例子，每个帮助页面都进行了缓存，访问一个页面的代码非常简单：

使用了静态的方法和类。从 OOP 角度来看确实很糟，但是非常快并有利于简洁编码。

缓存由 Redis 和 Dapper 支撑，一个微型 ORM

为了解决垃圾收集问题，模板中 1 个类只使用 1 个副本，被建立和保存在缓存中。监测一切，包括 GC 操。据统计显示，间接层增加 GC 压力达到了某个程度时会显著的降低性能。

CDN Hit 。鉴于查询字符串基于文件内容进行哈希，只在有新建立时才会被再次取出。每天 3000 万到 5000 万 Hit，带宽大约为 300GB 到 600GB。

CDN 不是用来应对 CPU 或I/O负载，而是帮助用户更快的获得答案

部署

每天 5 次部署，不去建立过大的应用。主要因为

可以直接的监视性能

尽可能小化建立，可以工作才是重点

产品建立后再通过强大的脚本拷贝到各个网页层，每个服务器的步骤是：

通过 POST 通知 HAProxy 下架某台服务器

延迟 IIS 结束现有请求（大约 5 秒）

停止网站（通过同一个 PSSession 结束所有下游）

Robocopy 文件

开启网站

通过另一个 POST 做 HAProxy Re-enable

几乎所有部署都是通过 puppet 或 DSC，升级通常只是大幅度调整 RAID 阵列并通过 PXE boot 安装，这样做非常快速。

协作

团队

SRE （System Reliability Engineering）：5 人

Core Dev（Q&A site）6-7 人

Core Dev Mobile：6 人

Careers 团队专门负责 SO Careers 产品开发：7 人

Devops 和开发者结合的非常紧密

团队间变化很大

大部分员工远程工作

办公室主要用于销售，Denver 和 London 除外

一切平等，些许偏向纽约工作者，因为面对面有助于工作交流，但是在线工作影响也并不大

对比可以在同一个办公室办公，他们更偏向热爱产品及有才华的工程师，他们可以很好的衡量利弊

许多人因为家庭而选择远程工作，纽约是不错，但是生活并不宽松

办公室设立在曼哈顿，那是个人才的诞生地。数据中心不能太偏，因为经常会涉及升级

打造一个强大团队，偏爱极客。早期的微软就聚集了大量极客，因此他们征服了整个世界

Stack Overflow 社区也是个招聘的地点，他们在那寻找热爱编码、乐于助人及热爱交流的人才。

编制预算

预算是项目的基础。钱只花在为新项目建立基础设施上，如此低利用率的 web server 还是 3 年前数据中心建立时购入。

测试

快速迭代和遗弃

许多测试都是发布队伍完成的。开发拥有一个同样的 SQL 服务器，并且运行在相同的 Web 层，因此性能测试并不会糟糕。

非常少的测试。Stack Overflow 并没有进行太多的单元测试，因为他们使用了大量的静态代码，还有一个非常活跃的社区。

基础设施改变。鉴于所有东西都有双份，所以每个旧配置都有备份，并使用了一个快速故障恢复机制。比如，keepalived 可以在负载均衡器中快速回退。

对比定期维护，他们更愿意依赖冗余系统。SQL 备份用一个专门的服务器进行测试，只为了可以重存储。计划做每两个月一次的全数据中心故障恢复，或者使用完全只读的第二数据中心。

每次新功能发布都做单元测试、集成测试盒 UI 测试，这就意味着可以预知输入的产品功能测试后就会推送到孵化网站，即 meta.stackexchange（原 meta.stackoverflow）。

监视/日志

当下正在考虑使用 http://logstash.net/做日志管理，目前使用了一个专门的服务将 syslog UDP 传输到 SQL 数据库中。网页中为计时添加 header，这样就可以通过 HAProxy 来捕获并且融合到 syslog 传输中。

Opserver 和 Realog 用于显示测量结果。Realog 是一个日志展示系统，由 Kyle Brandt 和 Matt Jibson 使用 Go 建立。

日志通过 HAProxy 负载均衡器借助 syslog 完成，而不是 IIS，因为其功能比 IIS 更丰富。

关于云

还是老生常谈，硬件永远比开发者和有效率的代码便宜。基于木桶效应，速度肯定受限于某个短板，现有的云服务基本上都存在容量和性能限制。

如果从开始就使用云来建设 SO 说不定也会达到现在的水准。但毫无疑问的是，如果达到同样的性能，使用云的成本将远远高于自建数据中心。

性能至上

StackOverflow 是个重度的性能控，主页加载的时间永远控制在 50 毫秒内，当下的响应时间是 28 毫秒。

程序员热衷于降低页面加载时间以及提高用户体验。

每个独立的网络提交都予以计时和记录，这种计量可以弄清楚提升性能需要修改的地方。

如此低资源利用率的主要原因就是高效的代码。web server 的 CPU 平均利用率在5% 到 15% 之间，内存使用为 15.5 GB，网络传输在 20 Mb/s到 40 Mb/s。SQL 服务器的 CPU 使用率在5% 到 10% 之间，内存使用是 365GB，网络传输为 100 Mb/s到 200 Mb/s。这可以带来 3 个好处：给升级留下很大的空间；在严重错误发生时可以保持服务可用；在需要时可以快速回档。

学到的知识

1. 为什么使用 MS 产品的同时还使用 Redis？什么好用用什么，不要做无必要的系统之争，比如 C# 在 Windows 机器上运行好，我们使用 IIS；Redis 在*nix 机器上可以得到充分发挥，我们使用*nix。

2. Overkill 即策略。平常的利用率并不能代表什么，当某些特定的事情发生时，比如备份、重建等完全可以将资源使用拉满。

3. 坚固的 SSD。所有数据库都建立在 SSD 之上，这样可以获得 0 延时。

4. 了解你的读写负载。

5. 高效的代码意味着更少的主机。只有新项目上线时才会因为特殊需求增加硬件，通常情况下是添加内存，但在此之外，高效的代码就意味着 0 硬件添加。所以经常只讨论两个问题：为存储增加新的 SSD；为新项目增加硬件。

6. 不要害怕定制化。SO 在 Tag 上使用复杂查询，因此专门开发了所需的 Tag Engine。

7. 只做必须做的事情。之所以不需要测试是因为有一个活跃的社区支撑，比如，开发者不用担心出现“Square Wheel”效应，如果开发者可以制作一个更更轻量级的组件，那就替代吧。

8. 注重硬件知识，比如 IL。一些代码使用 IL 而不是C#。聚焦 SQL 查询计划。使用 web server 的内存转储究竟做了些什么。探索，比如为什么一个 split 会产生 2GB 的垃圾。

9. 切勿官僚作风。总有一些新的工具是你需要的，比如，一个编辑器，新版本的 Visual Studio，降低提升过程中的一切阻力。

10. 垃圾回收驱动编程。SO 在减少垃圾回收成本上做了很多努力，跳过类似 TDD 的实践，避免抽象层，使用静态方法。虽然极端，但是确实打造出非常高效的代码。

11. 高效代码的价值远远超出你想象，它可以让硬件跑的更快，降低资源使用，切记让代码更容易被程序员理解。

责任编辑：途必技术部

版权所有：http://www.uweb.net.cn (优网科技) 转载请注明出处