精華區 > 酷!學園 精華區

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

(1/3) > >>

FIEND:
###############################################
# 作       者 : FIEND
# Email       : fiendcly@gmail.com
# Date        : 2012/08/26
# 請盡量保留原文出處以供討論 , 謝謝大家.
###############################################

這幾年我比較少寫 PHP 了.

有陣子很迷它 , 但是因為工作關係 , 把較多的時間花在 網路封包和資料庫行為的分析工作上.

而且 因為年記較大了 所以也很難找到 寫程式的工作 多半都在做 工程師 的 "工頭"


對於這幾年 PHP 的變化 我來不及參與 .

在這裡收集這幾年對 PHP 的變化 , 寫篇 心得 過過小弟自己的乾隱 :

回顧您以往的職業生涯 , 您有好好的管理您寫的 CODE 嗎?

還是每次都寫到專案超級肥大了 , 才延伸出一大堆的 程式碼管理問題.


在這裡 小弟設計一個開發框架的架構 , 讓你的程式更簡潔 而且讓 你的程式 更有條有理的被應用.

當然這些架構教學我己經簡化很多 , 如果放入太多的設計 反而會得到反效果.

如果您是比較重口味的 PHP 設計者 , 先說聲報歉了 .

如果您常為了專案肥大難以管理你的程式 ,

這篇文章對您來說會是個值得參考的文章 , 至少它有著我十幾年的 專案開發經驗.



一. 常見的 PHP 應用的架構 :



在往下教學下去前 , 小弟先定義 一些 名詞 , 以方便大家接下去閱讀教學.


[*] DB                :
                                這一塊不用多介紹 , 我相信大家對 DB 的經驗獨道 , 我們直接跳過去.

   [*] Access Layer :
                                這一塊 全部都是放一些 Access Logic 在裡頭 , 主要的工作是負責 跟 DB 還有 MEMCACHE 溝通 , 你可以使用現成的開發框架達成這一層的目地 , 也可以自己開發. 但是這些邏輯建議您都保留在這一層.
   [*] 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 了.


[/list]


二. 功能方塊介紹 :

序 :
 
到這裡我們必需要將圖裡的方塊切的更細讓大家理解 請耐心的看完下一張圖  :






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

什麼地方有 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                     :  如果你有別的使用資料存取的邏輯 , 可以參造上述的方式 一一的去整理....
[/list]



3. Content Logic  Layer :

             這一層有什麼東西?

             1. 你們服務用的到的 商業邏輯 , 你可以把每個商業邏輯 用 OOP 設計 , 並且放在這一塊 , 以利日後的管理.

             2. String Parser  :

                                為什麼在這篇教學裡我會建議您設計這塊 ?  因為它必需滿足 Presentation Layer 要求的 幾個素求 :

                                          1.一致性高, 2.可重覆利用性高 , 3.跨平台性高 ,4.雲端應用 , 所以大家不要關掉文章快點看到 3. 怎麼讓你的系統可以符合這四個素求.




3. Presentation  Layer :



                  我為何在這篇教學裡 , 放入了這一層的應用?



                  這要回顧到 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-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 的工作量.

netman:
哇！經典啊！

受小弟一拜~O r z

FIEND:

--- 引述: netman 於 2012-08-26 20:36 ---哇！經典啊！

受小弟一拜~O r z

--- 引用結尾 ---

>_<" 知音難求~謝謝 捧場~~

micmic3:
應該要有"讚"按鈕啊~~

hoyo:
既然都有大大跳出來，那就特地來請教好了：

其實我最想知道的是：

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

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

===========

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

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

導覽

[0] 文章列表

[#] 下頁