EZTABLE IDEAS 是 EZTABLE 成員揮灑熱情和大家分享專業及創意的網誌。 EZTABLE 讓消費者 24 小時都可以在網路訂位全台灣最優質的餐廳,同時提供餐廳經營者 e 化的訂位管理系統 (雲端、iPad、智慧型手機)

【Workshop】知名網站架構分析

八月 05 2014 Published by under Engineering, 創業故事, 經營兩三事

【Workshop@140801】

Topic: 知名網站架構分析
Speaker: Penny Yi

 

 

 3-IMG_1355

大家好,我是Penny,先不免俗地介紹我自己,

2000年開始工作
2004年到2012年都在上海某交友網站工作
2012回到台灣

加入EZT前在搞什麼:Lead Mobile Team + Build API Service (v3)
個人感興趣領域:
Python、Performance Tuning、Lua、Go、LBS、Restful Service、Infrastructure

 

 

今天要分享的是某大交友網站 ,創辦人和EZTABLE一樣是4個有為青年

1-IPART 

04年加入,他們架構就是這個PHP4+MYSQL+ APACHE2直接做
05稱為侏儸紀,正式進入中國,用的東西更多了
08年 公司最茁壯的一年,加上了一些衛星服務
12年 正準備回台時,市場服務又更進一步成熟

 
 
 
 2-IMG_1353
 

中國之旅

網路南北大不同(北網通~南電信~)

網路南北大不同

在中國大陸,很多技術論壇裡的第一個問題是問:你們家機房放哪裡? 是網通還是電信?
如果你了解、講得出來「北網通,南電信」,代表專業,你真的有在大陸混過!

在中國大陸,北網通、南電信,兩方互看對方不爽,導致兩邊的機房不合。
假設你公司的機房放在網通的機房,而用戶透過電信的機房去連,這時用戶的速度大約跟"撥接"差不多。

 

所以那些你叫得出名字的大家公司都是自建機房,
像是阿里巴巴非常聰明接了兩條線進來,再自己的機房裡做交換,自己把這兩方的gap修補起來。
而騰訊比較囂張,對電信表示我的機房比你好,把你的server放在我的機房。
(這家公司大到的程度,已經反客為主了)

 

因為網通、電信很奇怪 ,兩個地方彼此沒有連接,是各自為陣,
所以他們透過另外一個節點,再繞到對方那。
這個節點上有學術網路、還有一個叫「鐵通」。

PS.鐵通的網路是跟著鐵路所佈,網路是跟著鐵軌走的,
所以火車走過去時網路會變慢,交通比較頻繁時很糟糕,常會收到客訴 😛

 

 

CDN服務

Screen-Shot-2012-07-10-at-10.00.31-AM1

因為網通和電信間的關係,中國的CDN彭勃發展,
擁有比較大的CDN可能在全中國都有機房,可以佈署到全中國,使各地的網路品質維持在同個水準。

 

 

CDN服務可達到的優點

  • 加速網頁瀏覽效能:已將緩存資料放在最近的機房中,不需重新向伺服器讀取。
  • 有效分流(頻寬):所有用戶都不再向同一個伺服器讀取資料,大幅降低集中流量。
  • 網站穩定度:網站流量分散網站的穩定度大幅提高。
  • 安全性增加:因網站透過CDN分散出去,駭客較難直接攻擊網站本體。

補充:
「常在打別人,意味著常被打」
駭客表示,打他們成本很高,他們機台分散在全中國,這將會影響駭客的策略: 到底要打哪一台?
駭客的軟實力是技術,硬實力是到底操做多少台PC ,
駭客想的是,打哪個節點效率最高,可是你很難猜,而且每打一次你的漏機又會少掉一堆。
因為server被攻擊後,就把你的IP封鎖掉,
這樣你手上的機子馬上瞬間 6000大軍→600→60,
因此會讓心懷不軌的駭客放棄對你的攻擊,
否則下次軍備競賽時,你的硬實力輸人家!

 

 

 4-IMG_1358

 2005年踏上中國土地,我很無助,我把台灣這塊系統搬到大陸去,結果一天就被打趴了,
在台灣了不起user 500~600,而在這一個禮拜我們經營的user到1000,再過一個禮拜達到6000! 

我發現以台灣的架構過去,擋不住那麼多人進來;之後,針對能最快解決的方法 ,我們打算從DB下手。

 

BTW我回到台灣的母校跟教資料庫的老師說,我進到中國這個領土,做到第5正規化,可是..毀了..
因為我Join太多blalba一堆,結果無法讓DB 的loading降下來,
老師: 你最後怎麼解決?
我: 最後我把第五正規化變成第一正規化,就解決問題了。

 

 

 資料庫優化

  • 減少PHP連線數

透過PHP連DB,如果你的連線數一直維持在一個非常高的連線量,
那DB跟本完全動不了,前面user也不會快,整個網站卡死。

  • 拆分Database,拆分Table

因此我們策略是 既然一個instance沒有辦法負荷那麼多,
那就拆DB,拆掉後有些東西不好拆,那拆table。 

  • CPU升級/SSD硬碟

再者,速度慢有無更好的提升方式──花錢! 只要是錢可以解決的就不是難事。
解Slow Log解了兩天,換了SSD後兩秒鐘搞定,效率提升很跨張。

  • Slow Log優化,和遷移更多的Query到Backup Database

當Data有再做Backup時沒事,而平常沒事做時花錢很討厭,
在高峰時也做些事,然尖峰時間的每台DB的loading 100%、CPU 100%

分享一個概念: 
阿里巴巴有一次在論壇裡分享,他們有幾萬台機台 ,而每一台KPI CPU 98%,代表幾乎是以100%在跑,
他認為100%在跑不見得是壞事,只要確認一件事──CPU跑到100%不會掛掉!
他總是在追求CPU 100%然後不會掛掉的神的境界!

  • API 化 – 以方便針對性擴容,共享

(EZTABLE在這方面做的很徹底。)

  • 靜態網頁CDN Caching

user連到一個網頁,整篇看完後他可能連我們的DB都不用連到,
只要不去改裡面的內容、照片,將會永遠存在上面。

但後來發現這個方案有點弱,不動很方便,但只要有改到內容便會變得很麻煩;
更動後,要把靜態網頁回收重製,

但因為CDN太多,觸發到各地的時間不一,所以可能更改完後,
CDN目前只觸發到北京,北京的資訊新的,而河南還未觸發,資訊是舊的。

  • 盡可能使用緩存(Redis/Memcache)

最後用記憶體的方式,前者EZ用狠多,兩者很有趣優缺點可以是互補

 

 

之後的workshop會再繼續介紹一些還沒提到的內容。

 

 

 

 


 

如果您喜歡這篇文章可以點擊「讚」&「分享」
並歡迎訂閱EZTABLE IDEAS!  😀 

如果你是學習力強,而且經驗值高的人才,
歡迎一起加入我們 EZTABLE!! 

EZTABLE at Linkedin-Senior Mobile Software Engineer


Related Posts Plugin for WordPress, Blogger...

No responses yet

發表迴響