的寫法，大學生計算機第一課就教了。但踏上工作崗位進入像百度這樣的大企業不該繼續寫這麼幼稚的javascript loading方式啊，這個request不需要用synchronization JavaScript保證加載順序的……</p><p>給大家科普一下：</p><p>1. 一個synchronization JavaScript加載（<script src = “…”>），其裡面請求的JS加載多少時間，就會block整個瀏覽器多少時間，block的意思是網頁根本不動，滾動條都沒法動。</p><p>2. JS如果屬於跨國被牆的域名，就會出現經典的“白屏”效果。可以很簡單地嘗試一個實驗：寫一個hello world網頁，上面放一個來自於Google或Facebook的Javascript，例如<script src = “http://www.google.com/xxx.js”>，然後自己打開看看是否要很久都是白屏。</p><p>國外有些網站不知道這一經典陷阱，在國內打開時，發現各種加載慢或基本打不開，很多就是這個原因。</p><p>所以，<strong>IT之家和阿里雲，你們貌似都</strong><strong>被</strong><strong>百度躺槍了……</strong></p><p>解法很簡單，就三行code，用Bing搜索一下non-blocking Javascript，不用我寫了，一看就明白。</p><p><strong>Cache</strong><strong>（緩存）</strong><strong>& CDN</strong></p><p>IT之家有很多圖片，但在重複加載時候，還是需要浪費請求去詢問一下server要不要加載，返回304（已經cache緩存了）。細看一下每個圖片的http header，基本都是設了超短的近乎無效的expiration header</p><p><img class="lazy" src="//p2.ttnews.xyz/loading.gif" data-original="http://p1.pstatp.com/large/101f0004d2f9fcd20caa" img_width="1487" img_height="470" style="height:470px" alt="性能架構師看IT之家的性能問題及解法" inline="0"></p><p><img class="lazy" src="//p2.ttnews.xyz/loading.gif" data-original="http://p1.pstatp.com/large/10650001d2c5089c337c" img_width="677" img_height="166" alt="性能架構師看IT之家的性能問題及解法" inline="0"></p><p>來來回回幾十個無意義的請求其實是會block住後面重要資源的加載，會讓網頁看起來一卡一卡有些慢。解法是設一個長一點的expiration header就可以了。</p><p>再談一下CDN，很多人以為CDN cache一下圖片CSS JS等靜態資源就差不多了，其實不知<strong>CDN</strong><strong>可以cache幾乎任何東西，即使是一個</strong><strong>動態</strong><strong>資源請求，對於CDN來說也就是一</strong><strong>個</strong><strong>文件，照樣可以cache。</strong></p><p>以筆者之前的經歷，MSN.com這個全球Top 3的門戶網站，每日PV都是好幾億的，相比IT之家流量要大幾百倍，而且是全球訪問都保持PLT在1秒左右，在IT界幾乎屬於mission impossible（申明一下真不是做廣告）。我們對其中一個流量超大的板塊做performance tuning，將很多原先認為不能cache的動態資源|請求，都設了cache header放在CDN上面，就是timeout時間設短一點，例如1-15分鐘（根據業務需求情況而定），甚至包括base頁面即主請求main request（不可思議吧）。</p><p>結果是幾乎沒有什麼request被傳輸到web server，基本全部被CDN以“靜態資源cache”擋在門外，對於CDN簡直是九牛一毛，web server的CPU輕鬆地我們都以為沒開機呢，都在一位數左右，<strong>最終將</strong><strong>76臺服務器</strong><strong>縮減到僅剩</strong><strong>4臺</strong><strong>，而且</strong><strong>4臺</strong><strong>根本CPU都在個位數，用</strong><strong>4臺</strong><strong>的原因僅僅是用來做容災……</strong></p><p>這是為什麼呢？很簡單，靜態資源（static request）如圖片、CSS、JS對於web server的CPU消耗非常少，但是<strong>動態請求（</strong><strong>dynamic r</strong><strong>e</strong><strong>quest</strong><strong>）</strong><strong>就要</strong><strong>走遍</strong><strong>web server的</strong><strong>全鏈路，對於資源消耗非常高，通常體現在CPU</strong><strong>。</strong><strong>然後</strong><strong>不單</strong><strong>是IIS連接池，</strong><strong>就連</strong><strong>很多要查詢數據庫的request都繼續</strong><strong>被</strong><strong>送往SQL Server數據庫（</strong><strong>即使</strong><strong>得到的response data是跟之前請求一模一樣的）</strong><strong>，</strong><strong>然後，然後SQL Server就跟著一起CPU high了</strong><strong>。</strong></p><p>所以其實很多情況下，<strong>像</strong><strong>IT之家這種門戶網站，</strong><strong>單條</strong><strong>內容更新頻率其實並不高，可以說</strong><strong>90</strong><strong>%以上的內容都是可以被cache的，評論部分拆開請求就好了</strong><strong>。</strong>在web + db的兩層架構之間，也可以加一層cache，例如memcache或Redis或其它cache實現，這層麼稍微花點錢。</p><p>其實，cost wise（價格方面），放CDN上面來cache大部分內容，要便宜很多很多，後臺可以表示“輕鬆無壓力”。</p><p><strong>高可用</strong><strong>&</strong><strong>彈性</strong><strong>擴展</strong></p><p>接著上文繼續說，如果省錢確實可以用一臺虛擬機放web server。不過如果虛機掛了那就是真的掛了，<strong>業務掛了是最不划算的事情</strong><strong>，</strong><strong>一般至少</strong><strong>2臺</strong><strong>虛機，在雲上跨不同Availability Zone（</strong><strong>可用區</strong><strong>）</strong><strong>以</strong><strong>防止一個可用區（</strong><strong>通常</strong><strong>為一個物理機房）</strong><strong>down</strong><strong>掉。</strong></p><p>其次，因為你要放2個以上web server互為主備，這時候就<strong>不推薦把SQL Server數據庫都放在web server一起</strong>了（創業時可以這麼幹，成熟了就業務為先了）。數據庫是核心資產，肯定要做主備，最好跨AZ甚至跨region，分開來放。試想911時候那架飛機，不單撞走了上千條人命，也撞走了好多公司，因為當時有不少人都是把數據庫放辦公室裡的，以為樓永遠不倒……然後，大家都放雲上去了。</p><p>但是，<strong>NB的雲服務商例如AWS和Azure，從來就會跟你說如果你</strong><strong>自己</strong><strong>不做備份，只用單實例，</strong><strong>如果</strong><strong>機器掛了他們不會對你的數據</strong><strong>可靠性</strong><strong>負責。</strong>因為如AWS般成熟的IT企業，其VP <strong>Werner Vogels都說過</strong><strong>Everything Fails</strong>。<strong>業務</strong><strong>可用性</strong><strong>是</strong><strong>要</strong><strong>靠</strong><strong>業主自己的架構去保障</strong><strong>（例如</strong><strong>備份、高可用</strong><strong>），而不是物業</strong><strong>去保障。</strong>難道你家客廳電視機壞了看不了世界盃還要去罵物業麼？誰讓你不在臥室也放個電視機咧（主備）？或者用筆記本看（高可用）？</p><p>關於高可用的架構，網上文章很多，我就不再贅述了。</p><p>然後，我要跟大家講一個淺顯易懂的道理：<strong>虛擬機 不等於 彈性計算</strong>。</p><p>雲計算的初衷是讓大家享受<strong>彈性</strong>計算，重點在“<strong>彈性</strong>”（<strong>Elastic</strong>）。很多人把這兩個字給忘了，結果變成只有計算了，計算就變成只有虛擬機了。如果是這樣，每個有Windows 7以上的人，因為可以安裝HyperV來做虛擬機，就都有云計算啦！</p><p>彈性的根本，是用來解決你流量的高峰低谷時候用的資源擴容和縮容，即可以給你水平擴展（注意：此時要把數據庫剝離開來別放web server一起哦）。<strong>AWS</strong><strong>、</strong><strong>Azure、阿里雲都給你提供了Scaling Service，</strong><strong>例如</strong><strong>在阿里雲叫Elastic Scaling Service</strong><strong>（ESS），</strong><strong>配置一下</strong><strong>規則</strong><strong>例如CPU到多少就擴容幾臺web server</strong>，挺簡單的，事情不用想太複雜，成熟雲服務商早都考慮好這點了，也是最最基本的服務。否則按照傳統思維，難道真的都要升級配置，變成以前那種機器不行就加內存、換更貴的CPU，走上用小型機、大型機這種老路？那還要雲計算幹嘛。</p><p><strong>總結</strong></p><p>最後點個題，綜上所述，這次“事件”從技術角度來看是個不大的問題，測試也發現實際上之前存在的卡慢現象在換了基礎雲之後依舊存在。這就尷尬了。要做好網站的優化是門長期功夫，靠堆硬件（指服務商的提供的性能）是不可取的，靠服務商來服務也是不夠的。當然，對於藉機PR的做法也不認同。（個人性格，不喜勿噴）</p><p>建議IT之家：（1）把Web和Database部署分離 （2）用ESS這種來擴容縮容 （3）做一下高可用。可能只需要1周時間。</p></div>
閱讀更多 IT科技范 的文章
