“Sean Hull是一名技术咨询顾问，同时也是《Oracle & Open Source》一书的作者。他在自己的博客上发布了一篇文章，指出10种“罪过”会对可扩展性产生致命影响。接下来我们一一列举，看看到底是哪十宗罪。   1. 磁盘I/O慢，使用RAID5、多租户EBS磁盘是所有服务器的基础，也是服务器性能的基础。虽然主内存变得越来越大，很多都可以作为缓存使用，但是服务器仍然需要不时从磁盘上读取数据，从内存清出数据。所以磁盘对于性能和可扩展性非常重要。


Raid 5有什么问题？


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


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


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


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


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


不过AWS解决了这个严重的问题，用一个不太为人熟知但是超级有用的特性——Provisioned IOPS。用它你可以锁定可靠的磁盘I/O。
   2. 用数据库处理队列MySQL在很多地方都做得很好，但是在处理应用程序排队方面却并不理想。你的数据库中是不是有类似JOBS这样的表，其中有一个状态列，包括“queued”、“working”、“completed”这样的值？如果是，你可能把数据库用来处理应用中的队列工作了。这样使用MySQL很不好，因为会出现锁的问题，还有查找下一个任务时的搜索和扫描任务也会遇到麻烦。


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


对于前沿技术感兴趣的同学，MySQL 5.6中提供了Innodb的崩溃安全和事务存储引擎。既便如此，还是建议使用外部解决方案，如Solr，或者Sphinx及MySQL Sphinx SE插件解决。
   4. 每个层次的缓存都不够缓存，缓存，及更多的缓存，重要的事情说三遍。在web服务器和数据库之间可以使用memcache或者其他对象缓存机制。所有这些小结果集将会主流在内存中，等待未来需要它们的web页面。


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


浏览器缓存也非常重要，但是你无法控制用户的浏览器，也许你可以？当然不是直接控制，但是你可以指导他们缓存哪些东西。还要使用合适的过期报头。让你的管理员配置Apache来支持这一点。
   5. 太多技术欠债出来混总有一天要还的。技术债是什么？探索新的点子，你会搭建一个原型。当这个原型已经部署给客户使用之后，要修改就变得更困难，因为某些问题可能有些东西还得掩盖起来。


一个团队离开，另外的人接手这个应用，问题变得更复杂。随时间推移，你的技术债务不断积累，团队会花更多时间去维护老的代码以及修复bug，开发新功能的时间会越来越少。在某个时候就有必要重写代码了。
   6. 对象关系映射器ORM很受开发人员的欢迎，但对性能专家来说却不是这样。为什么？原因主要是由于这两类人看待web应用的视角不同。


一种是功能开发，以满足业务需求作为考察的结果。性能和可扩展性在这种情况下往往位于较低优先级。ORM能让开发者更有效率，通过后端的数据存储将SQL的交互难度抽象出来，让开发者将注意力集中在功能的开发上。


从性能角度出发，看到的是另外的场景。如果用ORM实现SQL查询，数据库将无法优化复杂的查询。而且ORM不允许对查询的简单调整，拖慢调优过程。
   7. 同步、串行、耦合或锁定进程在web应用里，锁相当于现实世界中的交通信号灯。如果将交通灯换成环形交通枢纽可以显著提升流量。因为如果你去一个交通流量很小的地方，没有人会在交通灯下做无用的等待。更重要的是：如果有车流量很大，环形枢纽可以让车辆保持流动。


如果需要锁，最好使用InnoDB数据表，因为它们能提供粒度更细的行级锁定，而不是MyISAM的表级锁定。


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


避免任何类型的两阶段提交机制。多阶段提交提供了一个串行入口，让多个节点投票决定数据应该是什么样子，但是它们是扩展性的毒药。最好使用采取最终一致性算法的技术。
   8. 只有一份数据库拷贝如果没有复制机制，那么你的数据库就只有一份。所有的web服务器只能使用唯一的后端数据存储，它就会成为漏斗或瓶颈。
   9. 没有定量衡量标准没有衡量标准是可扩展性的一剂毒药，因为你无法以可视化方式看见系统中发生了什么。没有可视化的线索，业务部门、开发者和执行团队很难对扩展性方面的问题达成一致。如果团队认识不到这一点，要让大家理解：这些简单的工具可以提供基础设施的分析。
   10. 缺乏功能标志应用程序如果缺乏功能标志，会很难实现优雅升级。如果你的网站流量猛增，而你无法施展魔法来扩展和提升流量。


如果有内建的功能标志，运维团队就可以在不让网站宕机的前提下，降低服务器负载。你也得以有更多时间来扩展web服务器或是数据库，甚至是改进应用，允许同时读写多个数据库。


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


以上这十宗罪，你在处理扩展性的过程中遇到过吗？你觉得还有哪些坑？又是怎么解决的？欢迎留言告诉我们。


回复数字浏览风向标热门文章1. 50PB海量数据排序，谷歌是这么做的

2. 程序员掺和产品设计，是瞎胡闹还是有必要？

3. NoSQL类型知多少

4. 代码审查最佳实践

5. NoSQL中的分布式、容错事务

6. 如何成为出色的软件工匠

7. 持续集成已死？

8. 微服务，让开发过程更简单还是更复杂？

微信公众号技术风向标，关注IT趋势，承载前沿、深入、有温度的内容。感兴趣的读者可以搜索ID：jishuqushi，或者长按下方二维码加关注。

“Sean Hull是一名技术咨询顾问，同时也是《Oracle & Open Source》一书的作者。他在自己的博客上发布了一篇文章，指出10种“罪过”会对可扩展性产生致命影响。接下来我们一一列举，看看到底是哪十宗罪。   1. 磁盘I/O慢，使用RAID5、多租户EBS磁盘是所有服务器的基础，也是服务器性能的基础。虽然主内存变得越来越大，很多都可以作为缓存使用，但是服务器仍然需要不时从磁盘上读取数据，从内存清出数据。所以磁盘对于性能和可扩展性非常重要。


Raid 5有什么问题？


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


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


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


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


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


不过AWS解决了这个严重的问题，用一个不太为人熟知但是超级有用的特性——Provisioned IOPS。用它你可以锁定可靠的磁盘I/O。
   2. 用数据库处理队列MySQL在很多地方都做得很好，但是在处理应用程序排队方面却并不理想。你的数据库中是不是有类似JOBS这样的表，其中有一个状态列，包括“queued”、“working”、“completed”这样的值？如果是，你可能把数据库用来处理应用中的队列工作了。这样使用MySQL很不好，因为会出现锁的问题，还有查找下一个任务时的搜索和扫描任务也会遇到麻烦。


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


对于前沿技术感兴趣的同学，MySQL 5.6中提供了Innodb的崩溃安全和事务存储引擎。既便如此，还是建议使用外部解决方案，如Solr，或者Sphinx及MySQL Sphinx SE插件解决。
   4. 每个层次的缓存都不够缓存，缓存，及更多的缓存，重要的事情说三遍。在web服务器和数据库之间可以使用memcache或者其他对象缓存机制。所有这些小结果集将会主流在内存中，等待未来需要它们的web页面。


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


浏览器缓存也非常重要，但是你无法控制用户的浏览器，也许你可以？当然不是直接控制，但是你可以指导他们缓存哪些东西。还要使用合适的过期报头。让你的管理员配置Apache来支持这一点。
   5. 太多技术欠债出来混总有一天要还的。技术债是什么？探索新的点子，你会搭建一个原型。当这个原型已经部署给客户使用之后，要修改就变得更困难，因为某些问题可能有些东西还得掩盖起来。


一个团队离开，另外的人接手这个应用，问题变得更复杂。随时间推移，你的技术债务不断积累，团队会花更多时间去维护老的代码以及修复bug，开发新功能的时间会越来越少。在某个时候就有必要重写代码了。
   6. 对象关系映射器ORM很受开发人员的欢迎，但对性能专家来说却不是这样。为什么？原因主要是由于这两类人看待web应用的视角不同。


一种是功能开发，以满足业务需求作为考察的结果。性能和可扩展性在这种情况下往往位于较低优先级。ORM能让开发者更有效率，通过后端的数据存储将SQL的交互难度抽象出来，让开发者将注意力集中在功能的开发上。


从性能角度出发，看到的是另外的场景。如果用ORM实现SQL查询，数据库将无法优化复杂的查询。而且ORM不允许对查询的简单调整，拖慢调优过程。
   7. 同步、串行、耦合或锁定进程在web应用里，锁相当于现实世界中的交通信号灯。如果将交通灯换成环形交通枢纽可以显著提升流量。因为如果你去一个交通流量很小的地方，没有人会在交通灯下做无用的等待。更重要的是：如果有车流量很大，环形枢纽可以让车辆保持流动。


如果需要锁，最好使用InnoDB数据表，因为它们能提供粒度更细的行级锁定，而不是MyISAM的表级锁定。


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


避免任何类型的两阶段提交机制。多阶段提交提供了一个串行入口，让多个节点投票决定数据应该是什么样子，但是它们是扩展性的毒药。最好使用采取最终一致性算法的技术。
   8. 只有一份数据库拷贝如果没有复制机制，那么你的数据库就只有一份。所有的web服务器只能使用唯一的后端数据存储，它就会成为漏斗或瓶颈。
   9. 没有定量衡量标准没有衡量标准是可扩展性的一剂毒药，因为你无法以可视化方式看见系统中发生了什么。没有可视化的线索，业务部门、开发者和执行团队很难对扩展性方面的问题达成一致。如果团队认识不到这一点，要让大家理解：这些简单的工具可以提供基础设施的分析。
   10. 缺乏功能标志应用程序如果缺乏功能标志，会很难实现优雅升级。如果你的网站流量猛增，而你无法施展魔法来扩展和提升流量。


如果有内建的功能标志，运维团队就可以在不让网站宕机的前提下，降低服务器负载。你也得以有更多时间来扩展web服务器或是数据库，甚至是改进应用，允许同时读写多个数据库。


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


以上这十宗罪，你在处理扩展性的过程中遇到过吗？你觉得还有哪些坑？又是怎么解决的？欢迎留言告诉我们。


回复数字浏览风向标热门文章1. 50PB海量数据排序，谷歌是这么做的

2. 程序员掺和产品设计，是瞎胡闹还是有必要？

3. NoSQL类型知多少

4. 代码审查最佳实践

5. NoSQL中的分布式、容错事务

6. 如何成为出色的软件工匠

7. 持续集成已死？

8. 微服务，让开发过程更简单还是更复杂？

微信公众号技术风向标，关注IT趋势，承载前沿、深入、有温度的内容。感兴趣的读者可以搜索ID：jishuqushi，或者长按下方二维码加关注。