Sean Hull是一名工作于纽约的技术咨询顾问，同时也是Oracle & Open Source一书的作者。最近，他在自己的博客上发布了一篇文章，指出5种“罪过”会对可扩展性产生致命影响。他在2011年发布过一篇文章，其中也提到5种罪。加起来，正好是影响可扩展性的“十宗罪”。接下来我们一一列举，看看到底是哪十宗罪。

　　第一宗：磁盘I/O慢，使用RAID5，使用多租户EBS磁盘是所有服务器的基础，也是服务器性能性能的基础。虽然主内存变得越来越大，很多都可以作为缓存使用，但是服务器仍然需要不时从磁盘上读取数据，从内存清出数据。所以磁盘对于性能和可扩展性非常重要。

　　Raid 5有什么问题？

　　Raid 5是为了用更少磁盘提供更多的空间。常常用于磁盘插槽比较少的服务器，或者就是因为运维人员不知道它对性能的影响有大。在数据库服务器上用会特别不好。

　　所有的写操作都会影响性能。更大的问题在于：如果你失去了一块磁盘，虽然RAID原则上还在线，但是会巨慢无比，就跟掉线了一样。重建需要耗费N多小时。更糟糕的是：在重建过程中，可能会有另外一块磁盘也失效。要是你刚订购磁盘要好几天才能到，那该怎么办？

　　解决方案是采用RAID 10。每两个磁盘做镜像，然后对它们做Stripe操作。即使只有四个硬盘插槽，这么做也值得。读写性能都很好，并且有保护。

　　多租户的问题是尼玛怎么回事？

　　在云上，可以共享服务器、网络和磁盘，就像共享某间公寓一样。Amazon的EBS（Elastic Block Storage，弹性块存储）是对这个比喻的扩展，为你提供存储网络令人欣喜的灵活性。但是你的瓶颈就是：与其他租户争抢同一个存储网络。

　　Amazon提供的默认服务器存在这个问题，不过AWS解决了这个严重的问题，用一个不太为人熟知但是超级有用的特性——Provisioned IOPS。用它你可以锁定可靠的磁盘I/O。

　　第二宗：用数据库处理队列MySQL在很多地方都做得很好，但是在处理应用程序排队方面却并不理想。你的数据库中是不是有类似JOBS这样的表，其中有一个状态列，包括“queued”、“working”、“completed”这样的值。如果是，你可能把数据库来处理应用中的队列工作了。这样使用MySQL不好，因为会出现锁的问题，还有查找下一个任务时的搜索和扫描任务也会遇到麻烦。

　　建议使用RabbitMQ或者Amazon的SQS方案，因为这些外部服务更容易扩展。

　　第三宗：用数据库进行全文搜索Oracle提供全文搜索支持，为什么MySQL却不能用呢？MySQL确实有这项功能，但是在很多版本中，只能配合老的MyISAM存储引擎使用。最好采用Apache Solr等经过验证的搜索解决方案，它专门用作搜索，有非常好的库，开发者可以使用多种现代web语言进行开发，并且非常容易扩展。只要在网络中增加服务器，或者做整体分布即可。

　　对于前沿技术感兴趣的同学，MySQL 5.6中提供了Innodb的崩溃安全和事务存储引擎。既便如此，还是建议使用外部解决方案，如Solr，或者Sphinx及MySQL Sphinx SE插件解决。

　　第四宗：每个层次的缓存不够缓存，缓存，及更多的缓存。在web服务器和数据库之间可以使用memcache或者其他对象缓存机制。所有这些小结果集将会主流在内存中，等待未来需要它们的web页面。

　　也要考虑使用varnish这样的页面缓存，它位于web服务器之前，不妨将其看成一个迷你web服务器，处理很简单的页面，但是速度非常快。就像在堵塞的道路上开摩托车，让你的web服务器加速以完成更复杂的工作。

　　浏览器缓存也非常重要，但是你无法控制用户的浏览器，也许你可以？当然不是直接控制，但是你可以指导他们缓存哪些东西。还要使用合适的过期报头。让你的管理员配置Apache来支持这一点。

　　第五宗：太多技术欠债技术欠债总有一天要还的。这是什么？探索新的点子，你会搭建一个原型。当这个原型已经部署给客户使用之后，要修改就变得更困难，因为某些问题可能有些东西还得掩盖起来。一个团队离开，另外的人接手这个应用，问题变得更复杂。随时间推移，你的技术债务不断积累，团队会花更多时间去维护老的代码以及修复bug，开发新功能的时间会越来越少。在某个时候就有必要重写代码了。

　　第六宗：对象关系映射器ORM很受开发人员的欢迎，但是对于性能专家来说却不是这样。为什么会这样？原因主要是由于这两类人看待web应用视角不同。一种是功能开发，以满足业务需求作为考察的结果。性能和可扩展性在这种情况下往往位于较低优先级。ORM能让开发者更有效率，通过后端的数据存储将SQL的交互难度抽象出来，让开发者将注意力集中在功能的开发上。

　　从性能角度出发，看到的是另外的场景。如果用ORM实现SQL查询，数据库将无法优化复杂的查询。而且ORM不允许对查询的简单调整，拖慢调优过程。

　　第七宗：同步、串行、耦合或锁定进程在web应用里，锁相当于现实世界中的交通信号灯。如果将交通灯换成环形交通枢纽可以显著提升流量。因为如果你去一个交通流量很小的地方，没有人会在交通灯下做无用的等待。更重要的是：如果有车流量很大，环形枢纽可以让车辆保持流动。如果需要锁，最好使用InnoDB数据表，因为它们能提供粒度更细的行级锁定，而不是MyISAM的表级锁定。

　　要避免出现等待其它节点消息而无法执行程序的半同步复制。在高事务并发的web应用中，成千上万的并发会话会导致这种等待的增加。

　　避免任何类型的两阶段提交机制。多阶段提交提供了一个串行入口，让多个节点投票决定数据应该是什么样子，但是它们是扩展性的毒药。最好使用采取最终一致性算法的技术。

　　第八宗：只有一份数据库拷贝如果没有复制机制，那么你的数据库就只有一份。所有的web服务器只能使用唯一的后端数据存储，它就会成为漏斗或瓶颈。

　　第九宗：没有定量衡量标准没有衡量标准是可扩展性的一剂毒药，因为你无法以可视化方式看见系统中发生了什么。没有可视化的线索，业务部门、开发者和执行团队很难对扩展性方面的问题达成一致。如果团队认识不到这一点，要让大家理解：这些简单的工具可以提供基础设施的分析。

　　第十宗：缺乏功能标志应用程序如果缺乏功能标志，会很难实现优雅升级。如果你的网站流量猛增，而你不能施展魔法来扩展和提升流量，有内建的功能标志，运维团队就可以在不让网站宕机的前提下，降低服务器负载。你也得以有更多时间来扩展web服务器或是数据库，甚至是改进你的应用，允许同时读写多个数据库。

　　不提供这些开关，扩展性和可用性就受到了很大限制。

　　以上就是Sean Hull提出的：影响可扩展性的“十宗罪”。各位InfoQ的读者，以上这“十宗罪”，你在处理扩展性的过程中遇到过吗？你觉得还有哪些“罪”？又是怎么解决这些罪过的？欢迎在留言中说明。