框架的設計

本論文所提出的框架如圖 11 所示，主要分成控制模組、呈現模組、事務 模組、SNS API 模組和其他幫助使用者簡化開發的函式庫。

Controller Model

Active Record

View

Database Helper & Library

Module

URL parsing Routing

Cache

Cache hit miss

hit miss

Browser / Client

Output Buffering

SNS Platform

SNS API

Batching Caching

API call

圖 11 框架的架構圖

首先由控制模組(Controller)接收來自使用者的請求，因應請求找出對應 的事務模組(Model)和呈現模組(View)回應。事務模組負責業務邏輯與資料

21

庫數據的調用，呈現模組負責畫面的輸出，兩者各司其職，互不干擾。並且 因應效能考量，在事務模組的調用提供了快取機制的加強，在呈現模組則加 入緩衝機制。最後在 SNS API 模組上，採用批次處理與快取機制來減少 API call 所需的網路通訊次數，以增進效能。

接下來，此小節會針對上述的各個模組進行詳盡地介紹，並闡述本框架 的快取機制。

3.3.1 控制模組(Controller)的設計

控制模組的設計是根據[4][13][19]所提出的 Page Controller 和 Front Controller 模式為基礎(Page Controller 和 Front Controller 模式請參見第二章 2.1.2 節)，針對社交網路服務平台所設計的一種介於兩者之間的混合模式，

稱之為 Hybrid Controller 模式。如圖 12 所示，Hybrid Controller 模式在處理 請求時，不像 Front Controller 模式般強制將所有請求都交由一個 Handler 集 中控管，而是類似 Page Controller 模式將請求交由對應的 Controller 執行。

在 Controller 內部運行的機制又類似於 Front Controller 模式，先將請求(URL) 進行解析，從中找出對應的行動對象並執行之。

行動對象(action)是指開發者依照應用程式或服務的業務邏輯，自行撰寫 的函式。在函式中，開發者可以調用相對應的事務模組來處理資料庫數據，

並決定由何者呈現模組負責畫面輸出。

22

Request from Browser

Controller Module

parse URL

choose action to run

execute action

(user-defined function) Model Module

View Module

Response to Browser

圖 12 Hybrid 模式的結構

不過在行動對象的歸屬上，Hybrid Controller 模式又與 Front Controller 模式有很大的不同。Front Controller 模式是將行動對象(或稱命令對象)與 Controller(在 Front Controller 模式稱 Handler)分離，中間透過一個抽象的介 面降低行動對象與 Controller 的耦合程度，增加彈性；Hybrid Controller 模式 則是將行動對象包含在 Controller 之中，如此便無 Front Controller 模式將行 動對象分離後造成執行的額外開銷。並且由於本框架是基於 Script Language 開發的，所以透過其動態執行的特性，因而無需透過行動對象的分離，即可 達到類似與 Front Controller 模式程度的彈性。

23

接著將 Hybrid Controller 模式與其他常見的 Controller 模式之差異比較 整理由表 3 所列。

表 3 Hybrid Controller 模式與其他模式的比較表

Page Controller Front Controller Hybrid Controller

實作難度 易 難 易

然而，今日許多呈現模組是基於樣板引擎(Template Engine)實現的。樣 板引擎透過解析其支援的特殊標籤(tag)，並將標籤替換成後台數據，因而達 到將程式邏輯與顯示畫面分離之效。而樣板引擎往往也支援一些程式語言的

24

特性，例如：流程控制語法（foreach、while、if else）、函數、模板內的數 學計算、正規表示式等等。這造成使用樣板引擎儼然在使用一個簡易的程式 語言，似乎只有減輕程式設計師的負擔，對美工或介面設計師而言，毫無助 益。

所以，本框架在設計呈現模組時不採用樣板引擎來實現。在內容渲染上 採用標準的 HTML 和 CSS，在調用後台資料上使用原生 Script Language 的 標籤來替換後台數據。透過這些標準標籤格式，讓美工或介面設計師可以利 用視覺開發工具，無需撰寫程式即可進行頁面設計。

3.3.3 事務模組(Model)的設計

事務模組的職責是負責處理業務邏輯與資料庫的數據操作。業務邏輯會 隨著企業組織的不同，有著不同的實現方式。因此根據上述事務模組的特性，

在設計上採用 Design Pattern 中的 Template 模式實現。框架本身只提供事務 模組的基本功能與雛形，實際的業務邏輯交由開發者自行實現。在處理資料 庫數據的部份，框架提供 SQL 的包覆類別與 ORM 方案。

SQL 的包覆類別(Wrapper Class)其目的是提供一個通用的資料庫存取介 面，支援不同廠商關聯式資料庫的 SQL 語法。開發者只需要使用這個通用介 面即可無視不同資料庫之間的差異，輕易達成無痛的轉換資料庫，降低轉換 成本。

ORM(Object Relational Mapping)的設計上，考量社交網路服務應用程 式有著開發時間急迫的特性 5，決定使用 Active Record 模式(ORM 各模式的 特點，請參見第二章 2.2 節)。Active Record 模式主要是透過分析資料表格 的 meta data，並將分析後的資訊建構成對應此表格的 ORM 物件，物件成員

25

的型別和資料要與資料庫欄位保持一致。透過這個與資料庫表格完全對應的 物件，取代傳統上使用 SQL 來操作資料庫的方式，其運作流程如圖 13 所示。

Cache 查詢資料表格的 meta data

分析 meta data

將資料表格的欄位與 ORM物件的成員配對

實際資料庫數據的操作

返回執行結果 透過ORM物件 進行資料庫操作

圖 13 Active Record 模式的運作流程

使用 Active Record 模式在分析和處理資料表格的 meta data 並對應成 ORM 物件的階段，明顯比傳統使用 SQL 來操作資料庫的方式多出很大的開 銷。因此，本論文基於資料庫表格的 schema 是不常變動的前提下，將此階 段的結果快取起來，以降低開銷，提昇效能。

26

3.3.4 SNS API 的設計

SNS API 設計目的是提高執行社交網路服務 API 的速度和改善其易用性。

在性能部分，社交網路服務應用程式的 API call 通常需要進行大量的網路通 訊動作，這使得其 API call 是個相對昂貴的操作。因此，為了解決頻繁的網 路呼叫所造成的性能損失，本框架透過批次處理與快取的機制，用以降低社 交網路服務 API 執行網路呼叫的頻率，提高執行的速度。

改善 API 易用性的部份，本框架包覆了原有的社交網路服務 API，用以 簡化原生 API 的複雜性。以 Facebook API 為例，當使用發送訊息(feed)API 時，開發者要配合 JavaScript 來定製一個訊息骨架才可以正確使用。這造成 開發者調用此 API 時，必須撰寫兩種程式語言，大大增加使用 API 難度。而 本框架的 SNS API 無需使用額外的程式語言，降低 API 的使用難度，進而 提昇開發效率。

3.3.5 快取機制的設計

本論文在快取機制的設計參考目前市面上流行且成熟的產品 Memcached 的機制，採用 Hash Table 作為快取的儲存結構。Hash Table 的優點在於查詢 速度很快，其平均查詢時間為 O(1)，因此非常適合作為快取機制使用。而雜 湊函式是決定 Hash Table 效能成敗的重要考量，因此根據[15]的比較，採用 以字串為 key 時，所產生 value 的分散程度與生成速度為考量時，DJBX33A 演算法有很好的表現。因此，採用此演算法作為本論文快取機制的雜湊函 式。

在碰撞處理上本論文採用鏈結法(chaining)因應，也就是當發生不同的輸

27

入字串卻產生相同雜湊值的情形時，將新加入的值使用額外的節點存放，用 以解決碰撞問題。此外為了增加快取機制的健壯性，本論文採用 LRU(Least Recently Used)演算法作為快取置換策略(cache replacement policy)。此演算 法是基於時間局部性(temporal locality)原則，也就是當一筆資料被使用後，

短時間內被使用的機率極高。因此基於此原則，當快取要進行置換時，移除 最近最少使用的內容可有效的增加快取命中的機率。表 4 為本論文在快取機 制設計所使用的技術一覽。

表 4 快取機制設計的整理表

考量項目 實作的演算法

資料結構 Hash Table

雜湊函式 DJBX33A

碰撞處理 Chaining

快取置換策略 LRU

在快取資料是否需要同步的議題上，本論文傾向「不強制要求所有的快 取資料皆需進行即時同步」。因為快取資料的同步，需要將可持久化儲存的 來源資料(在網路應用程式中，通常為資料庫數據)與快取資料保持一致。此 舉就會涉及到執行相對於緩慢的檔案 I/O 操作，影響快取的效能。

因此，本框架提供了兩種快取資料同步的方式：定時同步快取和即時同 步快取。定時同步快取機制適用於非即時性的資料，只有在超過使用者定義 的時間以後(時間單位為分鐘)，才進行資料同步動作。不然無論來源資料是 否發生變動都會直接傳回快取資料；而即時快取同步機制則適用於即時性的

28