精華區 > 酷!學園 精華區

[教學]PHP 設計開發與雲端架構

<< < (2/3) > >>

FIEND:

--- 引述: hoyo 於 2012-08-27 16:21 ---既然都有大大跳出來,那就特地來請教好了:

其實我最想知道的是:

在雲端架構裡,要怎麼作才能「增加主機就可以分擔流量及負擔」?

人多就多開幾台主機,沒人就關機。如何使用螞蟻 (多台超廉價電腦) 來搶過大象 (一台昂貴 Server) 以及 ET (不公開且稀有) 的工作?

===========

目前比較實用的應用就是 「雲監視器」

路口監視器嚴格來說是沒啥隱私權的,如果全省得監視器可以將資料收集到 「雲」 上
然後使用公開的格式儲存 (JPG, MP4),那民眾就可以自由上網觀看
如此就沒有監視器壞掉沒人知道,以及調閱資料困難的問題

--- 引用結尾 ---

呵呵~ 又要花一些時間寫文章了 ......

你問的是比較偏 IT 架構的問題 , 這篇教學是 軟體架構 , 所以讓您看不出來怎麼解決您的問題.


一樣請先把圖看完 :




你問的是二個問題 :

1. 如何 將監視器的資訊收回雲並且每個人都可以同步看到內容 :

   這個問題做法很多種說 :

   A.可以使用 P2P 的方式 : 目前現成的套裝伺服器軟體有 ADOBE MEDIA SERVER , 錢軟的 MEDIA SERVER, 不用錢的 OpenRTMFP , 或民間有人做好的 元件直接拿來用 等等...

   B. 也可以使用 TCP SERVER 來發送和接收 : 自己寫一個 TCP 接收端 和 在 CLIENT 寫發送端 , 反正不是多對多 , 在 TCP 接口上 做一個 簡單的 SESSION 判斷及信任可以丟回來的封包 , 然後做 CLIENT 端做 封包壓縮及資料串流 , 然後存到伺服器內.

    PS :

    (有些 雲端服務有支援 GATWAY 和 ROUTER 的功能 , 像EXSI 就提供了 CISCO 的 SWITCH 模組) 如果你是使用雲端服務商而且有提供這些服務也可以參考 :

    另外您有提到 要查到 監視器有沒有活著 , 其實是有方法的 , 不用那麼辛苦每天有人盯.

    1. 你可以把 路監視器的封包 在流入你們機房的同時 , 用 PORT MIRROR 的方式 , 把 IP 和 PORT 用 ACL 給 放行進來 , 然後找套有 SNIFFER 功能的設備或是自己做軟體把它丟進來 來監控封包的狀況.

    2. 如果你的路口監視器上有支援 SNMP 你也可以透過~SNMP 抓到 它的狀態 , 不過要查一下 設備的手冊.

    3. 如果你的路口監視器上有支援 SYSLOG 你也可以透過~SYSLOG 抓到 它的狀態 , 不過要查一下 設備的手冊.

    4. 你們公司如果是用 CISCO 它有支援 NETFLOW , 如果是 FUT 它是支援 SFLOW , 用 NETFLOW 或 SFLOW 進來的封包數會比較小 比起你用 SNIFFER 監控封包 可以降低骨幹交換器的很多負載.
        但是相對的 NETFLOW 的封包是做抽樣 , SFLOW 的封包內容是做 平均值 , 反正你只是要看有沒有影音封包 , 所以用這二個格式會比較安全.

    5. 根據上述的方法 , 你收集到資料後 , 直接用 EVENT 把它丟給簡訊伺服器通知工程師.
   

2. 如何做到分散式架構存取 :


彈性的抽換機器 有 5 個層面 要探討 ,

1. TCP 的網路請求如何做到負載平衡 , 平均的分配 雲端的服務.
2. 由 TCP 來分配 HTTP 服務如何做到分散式架構 .
3. 應用程式 如何做到分散式架構.
4. 快取層如何做到分散式架構.
5. DB 如何做到分散式架構.


而你要的應該是 如何在這5層各別建置 Cluster 來 快速的加裝伺服器 , 以承載你一直增加的需求.

我以 PHP 為例 ..... 不然講不完.


1. 我們做一下架構的切割 :

由上往下 把每一層先定義出來 , 當然你也可以客制化 .

    第一層 : 負載平衡器
    第二層 : HTTP SERVER OR SOCKET SERVER.
    第三層 : PHP & PHP FPM OR Other Application Logic .
    第四層 : MEMCACHE or Other Cluster BUFFER System
    第五層 : 資料庫.


1. 負載平衡器 :

     如果你的第二層服務是 HTTP 或其它的 SOCKET 服務端口 , 你可以使用硬體式的負載平衡器 或軟體式的 , 如果公司沒有錢 推薦使用這套 :

     http://haproxy.1wt.eu/   ( 它支援的不只是 HTTP 的格式 其它 SOCKET 格式它也支援 封包的 HA . )

     不過要小心 , 它是軟式的 , 也就是說它會受限於 作業系統 TCP/IP 的處理速度 , 我實測過每秒最多可以消化 2萬筆左右的封包 ,

     當然你也可以用 NAT 下 ACL 來做到相同的事 , 但是不要忘了 它有支援 延遲 及 平均分配封包量 , 所以才叫負載平衡 .

     如果你們公司的 服務封包請求量非常高....接近十萬筆 , 不買設備不行了!! 我有點久沒碰 負載平衡器 了 記憶中有些牌子可以處理到十萬筆.

     軟式的跟走 晶片運算的 相對的一分錢一分貨.....

     有錢的當然要買 , 不過一台至少都要台幣~100~150 萬... ( 像 F5 就要 100~150 萬大元 , 拿到更低價的別跳出來...我一定會找你要低價的>_<"  )

     以 HTTP SERVER 為例 :

     你可以分流你的 HTTP 伺服器 來達到 HTTP 伺服器 每一台要用多少個 REQUEST , 來分配你的 HTTP 伺服器群, 這樣就可以做到 用不到就關掉那台~HTTP , 用的到就開那些 HTTP 的需求了.

     ( 記得 把 ULIMIT 開大 , TCP 的 SESSION 數 要視你要分配多少封包進和出. )

2. HTTP SERVER OR SOCKET SERVER :

    這一層 , 如果你的用戶 是需要登入連線後 , 做 非常快速的資料交流 , 我建議自己寫  不要用 NGINX 或 APACHE , 
    ( 如果使用長連結 , 每秒可以消化的連線數 可以達到 一萬八千多筆(這數字是我自己寫的SERVER的效能供參考而己) , 而短連線 則差異非常大 , 因為 要BIND 和 LISTEN , 詳細的可以去研究 TCP SOCKET 的原理 )
    不過如果沒有能力自己寫 , 就真的只好用 NGINX 或 APACHE 了 .

    你要的是影音串流的服務 , 我強烈建議你們買 STREAM SERVER 的軟體 或 找找免費的 把它放在這一層做服務 , 最好是做長連結的溝通.

    JPG 沒什麼壓縮和切割封包的空間 , 所以放在~HTTP 就可以了.

    如果說有什麼好推薦的  , 我覺得 ADOBE 的 MEDIA SERVER 或 FREE 的 https://github.com/OpenRTMFP/Cumulus/wiki/_pages 是不錯的選擇.

3. PHP & PHP-FPM , APPLICATION 這塊大部份現在都採用 FAST-CGI 的方式 , PHP-FPM 和 FAST-CGI 其實格式是互通的 , 我之前無聊就寫了個 PHP-FPM 的溝通接口 , 用 fastchi.h 串接.

    這有什麼好處?  PHP-FPM 也可以取代 第二層 的應用直接對外 , 做分散式架構 , 等於你可以用一台 HTTP 或 SOCKET SERVER 將 PHP 的 APPLICATION SERVER 切成很多等份.
   
    一樣可以做到 APPLICATION SERVER 的分散式架構.

4. MEMCACHE 的 CLUSTER :

    為什麼連 MEMCACHE 都要做分散式架構?

    因為 MEMCACHE 是走 TCP 連線 , 而且每次的請求都是短連結.

    FB 現在的做法是 做 MEMCACHE 的分散式架構 , 會有一個 長連線的 連線 , 然後再把 請求 分配到 下面的 SERVER , 來達到 超高流量的 分散式架構.

   目前有廠商在做 , 我忘了網站在那了 , 要錢喔!! , 這裡有能力的也可以自己寫 , 其實很簡單.

   只要建一個長連線的 MASTER SERVER , 然後架 N 台 CLUSTER SERVER , 讓它去跟其它的 MEMCACHE SERVER 溝通 , 並且背後有個機制會不停的去 SYNC 所有 MC 的內容.

   如果你們公司銀子夠多 , 其實可以去買一些市面上 專門在做 CLUSTER 的 BUFFER SERVER .



5. 資料庫的分散式架構 :

    目前 MYSQL , OL , MSQL .. 都有支援 , 這部份不多做介紹.



   


hoyo:
消化一下,感謝萬分 ......  懶人福音 (另類懶人包)

============

所以有很多 N 個環節還是無法自己 DIY ,是嗎?

以 PHP 舉例是最好的啊,我也只會 PHP 啊 ^_^

不過如果不是 「全套」 以 PHP 說明其實我就沒啥興趣了,其他的語言我也看不懂啊 ....

監視器的部份就不用太著重了,那也只是一個舉例說明,我自己已經有亂寫一個版本出來試,不過想到沒分散結構後續就無法發展了。

FIEND:

--- 引述: hoyo 於 2012-08-27 18:17 ---消化一下,感謝萬分 ......  懶人福音 (另類懶人包)

============

所以有很多 N 個環節還是無法自己 DIY ,是嗎?

以 PHP 舉例是最好的啊,我也只會 PHP 啊 ^_^

不過如果不是 「全套」 以 PHP 說明其實我就沒啥興趣了,其他的語言我也看不懂啊 ....

監視器的部份就不用太著重了,那也只是一個舉例說明,我自己已經有亂寫一個版本出來試,不過想到沒分散結構後續就無法發展了。

--- 引用結尾 ---

呵呵~~

我現在也都自己在 IDC 架設雲伺服器了.

大量使用 EXSI .

我都買 DL380Gen8 還沒插滿...可以開到 30台 LINUX ...

做起測試真的方便很多.

嘿嘿~~

########################

可以做啊 -

如果要的是 APPLICATION 層的分散式架構.

利用 PHP-FPM 就可以做到 多台 分散式的 一台 HTTP 對多台 PHP 的結構.

如果你要做 HTTP 的分散式 可以用HAPROXY 來做 不用錢.

如果你要做 存取層...

要看你的DB有沒有支援.

FIEND:
我最近在寫一個 跟 MEMCACHE 有點類似的 SERVER 系統.
跟 MC 不同的地方是 , 我是做長連結的服務.

1.  CLIENT  USER 要先建立一個連線請求 , 我會要求它輸入帳號密碼 , 並且通過認證我才會準許它繼續跟我的伺服器使用長連結溝通 .
2.  SERVER 端 會把 CLIENT 端的請求全部 放到我做好的 記憶體容器(在C++裡是 VECTOR , MAP 等...)
3.  SERVER 和 CLIENT 溝通的介面全部都用 壓縮過的 JSON 內容 溝通 . ( 壓縮會損失一些效能 但是可以省很多 網路費. )
4.  溝通的內容會記錄在 SERVER 端.
5.  會跟 PHP 還有 DB 還有 DATA 做存取 並且快取在我這一層.
6.  會主動廣撥 通知所有連線上來的使用者 目前其它用戶的狀況.
7.  CLIENT 端的串接元件必需支援 SOCKET 連線. (FLASH AS , IOS , ANDROID 等等... 都可以用.)


這是 上面講的 架構的再運用 , 我把 CLIENT 和 SERVER 間的溝通 , 變成互動式的.

直接取代掉 MC 解決 ,  原本 MC 的 TCP 連線限制.  ( MC 短連結限制受限於 伺服器本身的作業系統 ,  沒錢買 MC CLUSTER 的免錢做法 )

SERVER 端也不再是單一請求等待回應再處理的方式而己 , 大量的解決了很多的溝通成本及不必要的溝通次數 , 相對的也省了很多網路頻寬和降低伺服器的處理次數.

製作成本大楖二星期 , 功能很少 只是做 一些 TCP 封包的處理和呼叫.

因為只要拿現成的一些 C++ 元件庫套一套就好了 , 以我的薪水計算....很滑算不到十萬

這樣做會遠比用 NGINX + PHP + MC 快上十倍喔.....

測試 :

NGINX + PHP + MC (都接起來 進去到出來) =>  每秒可以消化1600 個 REQUEST. ( 卡在 NGINX 串 PHP-FPM 再往下串 MC 再流上來 , 浪費了很多效能和時間 )

這個架構 => 每秒最快 可以消化 18000 個 REQUEST .



提供參考... 有遇到相同問題的 大大們 , 可以參考更新看看..... ^^

FIEND:
昨天又沒什麼睡~~終於完成這功能.

實測的結果 比 原生 PHP 的 可存取數高了 七倍而己~~~

可能是我加了 加密和壓縮的功能... 不然就是我~C 寫的太爛了~~

>_<"  有進步就好~~

導覽

[0] 文章列表

[#] 下頁

[*] 上頁

前往完整版本