酷!學園
精華區 => 酷!學園 精華區 => 主題作者是: FIEND 於 2012-08-26 10:04
-
###############################################
# 作 者 : FIEND
# Email : fiendcly@gmail.com
# Date : 2012/08/26
# 請盡量保留原文出處以供討論 , 謝謝大家.
###############################################
這幾年我比較少寫 PHP 了.
有陣子很迷它 , 但是因為工作關係 , 把較多的時間花在 網路封包和資料庫行為的分析工作上.
而且 因為年記較大了 所以也很難找到 寫程式的工作 多半都在做 工程師 的 "工頭"
對於這幾年 PHP 的變化 我來不及參與 .
在這裡收集這幾年對 PHP 的變化 , 寫篇 心得 過過小弟自己的乾隱 :
回顧您以往的職業生涯 , 您有好好的管理您寫的 CODE 嗎?
還是每次都寫到專案超級肥大了 , 才延伸出一大堆的 程式碼管理問題.
在這裡 小弟設計一個開發框架的架構 , 讓你的程式更簡潔 而且讓 你的程式 更有條有理的被應用.
當然這些架構教學我己經簡化很多 , 如果放入太多的設計 反而會得到反效果.
如果您是比較重口味的 PHP 設計者 , 先說聲報歉了 .
如果您常為了專案肥大難以管理你的程式 ,
這篇文章對您來說會是個值得參考的文章 , 至少它有著我十幾年的 專案開發經驗.
一. 常見的 PHP 應用的架構 :
(http://bbs.ecstart.com/php_tech/arc1.jpg)
在往下教學下去前 , 小弟先定義 一些 名詞 , 以方便大家接下去閱讀教學.
這一塊不用多介紹 , 我相信大家對 DB 的經驗獨道 , 我們直接跳過去.
這一塊 全部都是放一些 Access Logic 在裡頭 , 主要的工作是負責 跟 DB 還有 MEMCACHE 溝通 , 你可以使用現成的開發框架達成這一層的目地 , 也可以自己開發. 但是這些邏輯建議您都保留在這一層.
這一塊 主要是做為分散式架構的存取層 , 大家有沒有注意到一件事? 它是走 TCP 11211 PORT .
它可以用在什麼地方 ?
a. 讓你可以把從 DB 的資料撈到 快取一份到 MEMCACHE , 來減輕資料庫的工作負擔 , 這在大型而且流量很高的系統上 , 它辨演很重要的角色就是可以減輕 DB 的工作量.
* 我們這裡不多介紹 Memcahe 的使用及方式 , 您可以多參考 官方網站或其它網路上的教學.
b. 有一些不用儲存 用完就不要的資料 , 也可以利用 memcache 直接存取不用再交給 DB 去處理.
c. 注意一件事 :
在過去裡我的下屬們在使用它時常會犯一個錯就是爛用 Memcache ,
memcache 本身是 一個 TCP 的 服務 在單台 linux 伺服器下最多只能 使用 1024 個請求 , 當然你可以用 ulimit 提高它 , 但是請先了解它的本質 用對地方.
它本身並不能做為程式本身加快程式效能的工具 , 但是它是一個可以做到分散式的存取架構 , 並且可以減輕 DB 負擔的工具 , 的好用工具.
所以在使用它時要選對時機 , 千萬不要爛用.
- Access Layer : 這一層的工作主要是存取 資料層的邏輯 , 我將會 2. 會有更詳細的說明.
- Content Logic Layer : 這一層的工作主要是負責處理 存取層 從 資料層要來的資料的邏輯 , 我將會 3. 會有更詳細的說明.
- Presentation Layer : 這一層的工作意義重大 , 它主要是標準化 Presentation Logic 與 Content Logic Layer 溝通的標準, 讓你的 畫面邏輯不會愈來愈肥大及復雜 , 我將會 4. 會有更詳細的說明.
- Presentation Logic Layer : 這一層的工作 是做為 讓 你的畫面邏輯 可以採用標準化的 介面來 與伺服器溝通 , 如果 Presentation Layer 標準化了 , 你的 畫面邏輯的可重覆利用性就會更高及有彈性 , 我將會 5. 會有更詳細的說明.
- Client Layer : 這一層 就是我們平時便用的 瀏覽器, 雲端服務 等等的應用 , 相信大家非常了解這一層可以做到的事 , 所以我們就不多介紹 Client Layer 了.
二. 功能方塊介紹 :
序 :
到這裡我們必需要將圖裡的方塊切的更細讓大家理解 請耐心的看完下一張圖 :
(http://bbs.ecstart.com/php_tech/arc2.jpg)
1. Access Logic Layer :
Access Logic Layer 主要的工作是做為 與 DB 和 Content Logic 溝通的 區塊 , 在這裡小弟建議大家 在設計物件庫或函式庫前 , 先參考這個架構.
把所有跟 資料庫存取的 邏輯全部包裝在這個區塊下 , 例如大家在設計DB時最愛用 Factory 來做 DB 的 切換 , 同時把 這些邏輯全部整到這一層 讓您的程式更有層次更好管理.
看到這裡大家一定對 一些 使用 Factory 設計的 OOP DB 存取函式庫不漠生.
這時我要介紹大家一個名詞 , Object-relational_mapping :
http://en.wikipedia.org/wiki/Object-relational_mapping (http://en.wikipedia.org/wiki/Object-relational_mapping)
什麼地方有 ORM ? 就是大家常用的 .
CAKE PHP
ZEND FRAMEWORK.
Doctrine
Propel
CoughPHP
Symphony
當然...您也可以自己寫 , 重點是 , 要懂得怎麼有效率的去管理你的存取層的邏輯.
而一但定義了這一層 .
強烈建議 在接下來的 Content Logic Layer , Presentation Logic Layer 嚴格禁止其它邏輯層的邏輯跳過它來存取資料庫.
這麼做有什麼好處 ? :
1. 確保其它工作者不會寫出不良的DB存取邏輯造成你的系統不好維護
2. 你可以不用再擔心會有嚴重的存取層 BUG
3. 它在使用上變的更安全 , 不會讓你的資料庫 暴露在 Content & Presentation Logic Layer , 讓你的 DB 有一定程度的保障.
4. 如果你的 ORM TOOL 有提供管理器 , 你還可以把所有的 SQL 語法倒出來檢示有沒有什麼存取過重的語法.
5. 最重要的!! 你可以把 常用的存取層資料 跟 MEMCACHE 做有效的資源管理 , 讓你的 DB 的 資源更有效的被利用!!
補充說明 :
- Access MYSQL : 資料庫的新增改查邏輯全部放在這.
- Access Memcache : 與 MEMCACHE 存取的新增改查邏輯全部放在這.
- Access NOSQL : 現在最流行的 NOSQL , 你可以分別的去包裝你要的邏輯在這裡面.
- Other : 如果你有別的使用資料存取的邏輯 , 可以參造上述的方式 一一的去整理....
3. Content Logic Layer :
這一層有什麼東西?
1. 你們服務用的到的 商業邏輯 , 你可以把每個商業邏輯 用 OOP 設計 , 並且放在這一塊 , 以利日後的管理.
2. String Parser :
為什麼在這篇教學裡我會建議您設計這塊 ? 因為它必需滿足 Presentation Layer 要求的 幾個素求 :
1.一致性高, 2.可重覆利用性高 , 3.跨平台性高 ,4.雲端應用 , 所以大家不要關掉文章快點看到 3. 怎麼讓你的系統可以符合這四個素求.
3. Presentation Layer :
我為何在這篇教學裡 , 放入了這一層的應用?
(http://bbs.ecstart.com/php_tech/arc3.jpg)
這要回顧到 10年前 , 我入手了一本 Wrox 的 Professional PHP4 .
這本書我印象深刻 , 因為它一共有十一個作者在寫 : 當時看到它有一篇單元 "多層式架構開發" , 讓我對整個 WEB 架構開發的視野完全打開.
不過我得承認我以前很嘴賤 , 常說 SMARTY TEMPLATE 是玩具 .
PS : SMARTY TEMPLATE 採用 tpl php var 的方式來做 少了這一層 , 常會極端的用些言語說它不好.
你可以參考這二本書 , 會發現 這一層放入這個設計 會讓你未來工作變的輕鬆很多 .
http://www.amazon.com/Professional-PHP4-Programming-Deepak-Thomas/dp/1861006918 (http://www.amazon.com/Professional-PHP4-Programming-Deepak-Thomas/dp/1861006918)
http://www.amazon.com/Professional-PHP4-XML-Luis-Argerich/dp/1861007213/ref=sr_1_1?s=books&ie=UTF8&qid=1345942943&sr=1-1&keywords=PHP4+XML (http://www.amazon.com/Professional-PHP4-XML-Luis-Argerich/dp/1861007213/ref=sr_1_1?s=books&ie=UTF8&qid=1345942943&sr=1-1&keywords=PHP4+XML)
# 回到正題 -
這一層專門用來處理 Content Logic Layer 處理好的資料 , 利用 XML , JSON 等標準化的 介面語言 , 來規範你的 Content Logic Layer 按照你的 Convention (規範) 來吐出資料給 Presentation Logic Layer
a. 這樣做有什麼好處：
1. 一致性高 :
也因為這樣 , 你的 Presentation Layer 有著標準化的 格式 , 所以你在使用 AJAX , AS , PHP SDK 等...做畫面邏輯串接時 ,
你的畫面邏輯的程式將會變的一致性很高 , 因為都是參考同樣的格式 , 讓你的畫面邏輯的程式不會亂長.
工程師因為熟悉相同的介面格式 , 工作起來將會非常的輕鬆.
2. 可重覆利用性高 :
在你享受 Presentation Layer 有著標準化的格式 的好處時 , 你會發現, 你可以把 畫面邏輯也整理起來重覆利用 ,
這時你會發現你少寫好多好多的程式碼.
例如 : 換頁邏輯 , 表單的呈現 ...........等等等 , 只要另外塞 CSS 進來就好了 . 根本不用寫什麼程式.
3. 跨平台性高 :
啥咪? 還有. 是的!!! 大家記得 RSS 嗎? RSS就是利用了 Presentation Layer 這個特性 讓各種平台都可以串接 BLOG 的文章內容 , 讓你的系統有著強大的誇平台性整合能力.
4. 雲端應用 :
是的 即然跨平台性高了 , 也就是你完成這個專案的同時 , 你所有的系統內容的呈現可以丟給 任何雲端平台的整合!
b. 使用心得：
這個設計 , 會讓你的系統架構 非常靈活 , 靈活到什麼程度?
以往一組 新增/修改/刪除/換頁/搜尋 , 只要寫完一次 而且完整的從下到上每一層整合上來 .
我幾乎不用二次開發 , 直接套用 之前寫好的 content Logic , Presentation Logic 就可以完成一個專案 .
一天可以完工 三十幾組 新增/修改/刪除/換頁/搜尋 的串接 , 所以我當時消耗專案的速度比起一般沒有用這個設計技巧快上非常的多.
而大家心裡會有疑問 , 這不就是 以前 RUBY & CAKE PHP 的特性嗎? 是的!!就這個理念!
不過有差異 , 就是 CAKE PHP 在做 畫面邏輯時 , 它並不會真的把 這層切開 , 而是將 MVC 裡的 V 和 C 有效化的重覆利用 , 但是一但 要使用 雲端應用和誇平台時 ,
之前寫過的程式無法直接透過 Presentation Layer 拉出去給第三方平台做串接.
雖然省了 ORM 那一層的重覆開發 , 但是 Content Layer 和 Presentation Layer 還是要在手工調整的.
而一但一調整 , 就會產生 , DEBUG , 開發 , 穩定性 , 和你又多了一堆CODE 要維護的工作....
4. Presentation Logic Layer :
這一層講起來輕鬆多了 , 因為大家己經有了非常多的 AJAX , XSL , FACEBOOK SDK , IOS , ANDROID , FLASH AS 的串接經驗.
沒錯 , 這裡就是把之前辛苦定義並且做好的 Presentation Layer 吐出來的格式做應用 .
你可以透過~HTTP , SOCKET SERVER 等等.. 將你的 Presentation Layer 的 JSON , XML 吐出來 , 並且交給你的畫面邏輯程式去串接.
這麼一來你也輕鬆完成了一個 雲端的整合介面 , 讓你寫的 PHP 可以廣泛的使用在任何不同的平台上.
5. Unit Test & Stress Test & Integration Test :
在我開發每一層的 元件時 , 我都會要求工程師 , 做 單元測試(UNIT TEST) , 壓力測試 ( Stress Test ) , 整合測試 ( Integration Test )
a. 單元測試(UNIT TEST) : 你可以使用 PHPUNIT 或是自己寫 , 針對你的一個 函數的 進和出的測試 , 並且預先寫好 TEST CASE , 確保每一層的 函式庫都是非常穩定而且沒有問題的 , 來讓你管理程式的品質.
b. 壓力測試(Stess TEST) : 針對每一個函式庫的邏輯 , 在做 UNIT TEST 的同時 , 將 STRESS TEST 的 TEST CASE 餵進去 , 並且記錄每一個函式處理 TEST 所消耗的時間.
c. 整合測試(Integration Test) : 你可以寫一支程式 , 做 DAILY BUILD 每天去檢查 所有 程式設計師 COMMIT 到 SVN 的 程式碼是否有問題 , 確保每個函式之間整合 是正常的 , 降低 DEBUG 的工作量.
-
哇！經典啊！
受小弟一拜~O r z
-
哇！經典啊！
受小弟一拜~O r z
>_<" 知音難求~謝謝 捧場~~
-
應該要有"讚"按鈕啊~~
-
既然都有大大跳出來，那就特地來請教好了：
其實我最想知道的是：
在雲端架構裡，要怎麼作才能「增加主機就可以分擔流量及負擔」？
人多就多開幾台主機，沒人就關機。如何使用螞蟻 (多台超廉價電腦) 來搶過大象 (一台昂貴 Server) 以及 ET (不公開且稀有) 的工作？
===========
目前比較實用的應用就是 「雲監視器」
路口監視器嚴格來說是沒啥隱私權的，如果全省得監視器可以將資料收集到 「雲」 上
然後使用公開的格式儲存 (JPG, MP4)，那民眾就可以自由上網觀看
如此就沒有監視器壞掉沒人知道，以及調閱資料困難的問題
-
既然都有大大跳出來，那就特地來請教好了：
其實我最想知道的是：
在雲端架構裡，要怎麼作才能「增加主機就可以分擔流量及負擔」？
人多就多開幾台主機，沒人就關機。如何使用螞蟻 (多台超廉價電腦) 來搶過大象 (一台昂貴 Server) 以及 ET (不公開且稀有) 的工作？
===========
目前比較實用的應用就是 「雲監視器」
路口監視器嚴格來說是沒啥隱私權的，如果全省得監視器可以將資料收集到 「雲」 上
然後使用公開的格式儲存 (JPG, MP4)，那民眾就可以自由上網觀看
如此就沒有監視器壞掉沒人知道，以及調閱資料困難的問題
呵呵~ 又要花一些時間寫文章了 ......
你問的是比較偏 IT 架構的問題 , 這篇教學是 軟體架構 , 所以讓您看不出來怎麼解決您的問題.
一樣請先把圖看完 :
(http://bbs.ecstart.com/php_tech/arc4.jpg)
你問的是二個問題 :
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 .. 都有支援 , 這部份不多做介紹.
-
消化一下，感謝萬分 ...... 懶人福音 (另類懶人包)
============
所以有很多 N 個環節還是無法自己 DIY ，是嗎？
以 PHP 舉例是最好的啊，我也只會 PHP 啊 ^_^
不過如果不是 「全套」 以 PHP 說明其實我就沒啥興趣了，其他的語言我也看不懂啊 ....
監視器的部份就不用太著重了，那也只是一個舉例說明，我自己已經有亂寫一個版本出來試，不過想到沒分散結構後續就無法發展了。
-
消化一下，感謝萬分 ...... 懶人福音 (另類懶人包)
============
所以有很多 N 個環節還是無法自己 DIY ，是嗎？
以 PHP 舉例是最好的啊，我也只會 PHP 啊 ^_^
不過如果不是 「全套」 以 PHP 說明其實我就沒啥興趣了，其他的語言我也看不懂啊 ....
監視器的部份就不用太著重了，那也只是一個舉例說明，我自己已經有亂寫一個版本出來試，不過想到沒分散結構後續就無法發展了。
呵呵~~
我現在也都自己在 IDC 架設雲伺服器了.
大量使用 EXSI .
我都買 DL380Gen8 還沒插滿...可以開到 30台 LINUX ...
做起測試真的方便很多.
嘿嘿~~
########################
可以做啊 -
如果要的是 APPLICATION 層的分散式架構.
利用 PHP-FPM 就可以做到 多台 分散式的 一台 HTTP 對多台 PHP 的結構.
如果你要做 HTTP 的分散式 可以用HAPROXY 來做 不用錢.
如果你要做 存取層...
要看你的DB有沒有支援.
-
我最近在寫一個 跟 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 .
提供參考... 有遇到相同問題的 大大們 , 可以參考更新看看..... ^^
-
昨天又沒什麼睡~~終於完成這功能.
實測的結果 比 原生 PHP 的 可存取數高了 七倍而己~~~
可能是我加了 加密和壓縮的功能... 不然就是我~C 寫的太爛了~~
>_<" 有進步就好~~
-
您好, 可不可以請教一下
若依你的架構而言，像是權限控管部分應該要寫在那一層會是比較適合的呢?
另外，有時候web介面要顯示的資訊可能是資料庫原始資料經過計算或組合後的結果，像這一類的計算或組合到底屬於Access logic layer 還是content logic layer
抑或是presentation logic layer呢?