Twitter的案例分析

在逛網站的時候，發現一個已經熱門一陣子的話題，
那就是Twitter的系統效能和延展性。
底下只是一些個人的看法，畢竟我們都不是當事人，
很難深入了解問題出在那裡。
寫文章的目的，則是做為架構和分析時的參考。

在探討之前，先看幾篇文章。
(如果懶的看，只好將就一下我的總結。)

1. Mr.6 Twitter該不該開始對「超級使用者」收費、賺9.6億？
2. Twittering About Architecture
3. Twitter Current Positions
4. Scaling Twitter: Making Twitter 10000 Percent Faster

一開始是Mr.6提到某個Bloger提出Twitter應該對重度使用者收取費用，
因為重度使用者消秏很多資源。
被影射為重度使用者的另一名Blogger當然表達不同的意見。
於是問題便被帶出，Twitter的架構到是怎麼回事?
為什麼速度慢、常維修、又不太穩定?

問題點在於，沒有人知道Twitter真正的系統架構。
從上面第二個連結就可以知道，很多人提出可能的解決辦法供Twitter參考，
但Twitter表示，因環境不一樣，所以無法套用。
他們目前打算按照模組，一個一個重新改寫，
然後慢慢替換。
文末表示，如果你有興趣，歡迎加八他們，一起改善這個問題。

我很好奇的點到他們的微人網頁，也就是第三個連結。
從需求人才來推測，應用程式應該是Ruby on Rails，
那麼，資料庫就有很大的可能是MySQL。
至於要找會Java的人，是否為了用Java替換後端模組?
或者試試JRuby?這就不得而知。

接下來比較有趣的是第四個連結，有人就替Twitter猜測病情。
(該文是今年一月中撰寫)
有兩點特別讓我驚訝。
1.首席架構師(不知離職了沒，感覺壓力很大)
Blaine Cook表示

For us, it’s really about scaling horizontally – to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January.

(引用自上述第四個連結)

換個"比較快"的語言可以改善10% ~ 20%的效能，
改變架構可以改變10000%的效能。

那麼改變語言和架構呢?會不會有更好的效能?
什麼樣的架構改變，可以提高10000%的速度?

2.

1 MySQL Server (one big 8 core box) and 1 slave.
Slave is read only for statistics and reporting.

每秒讀取2400筆資料量的資料庫，只用一個MySQL Server。
這讓人很難了解，是太信任硬體，還是對自己的資料表設計太有自信?

Twitter真正的系統架構除非他們公佈，外界再怎麼推測也很難了解。
但是我們從這個案例可以學到一些事:
1.規劃架構時要想到後往可能的發展。
不論是硬體或軟體，多花一些時間，留一點空間，
比後來去修補或重寫而花費大量時間、人力，
還要應付客戶的抱怨、做公關，應該要好很多。

2. 該切開的就要分開。
和以往的應用程式不同的是，現在的Web Application開放很多API，
很多時候，存取API所需要的資源，比起訪問網站消秏的資源要來的多。
設計上能分開處理的最好別放在一起。

3. 資料庫的調校很重要。
這一點不用我解說大家也可以了解。
不過前提是在於應用程式的寫法和資料表的切割。
平常我們很少注意程式的效能(能跑又沒錯誤畫面就偷笑了)，
盡量參考Design Pattern囉。

或許有人會認為改用其它程式語言會是解決方案之一，至少我曾經這麼想過。
但Ruby on Rails既然是可行的方式，
或許Twitter選擇要排除萬難，成為第一大的ROR應用者，
也不是不可能的情況。
話說回來，整個應用程式也不一定單一語言撰寫，
程式語言的效能在這個案例似乎不是最重要的因素。