轉：影響可擴展性的十宗罪

from:http://www.infoq.com/cn/news/2013/06/10-sins-for-scalability?utm_source=infoq&utm_medium=popular_links_homepage

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的讀者，以上這「十宗罪」，你在處理擴展性的過程當中遇到過嗎？你以爲還有哪些「罪」？又是怎麼解決這些罪過的？歡迎在留言中說明。