HBase系列課程slides之三~六

最近Takeshi真的是忙到蠟燭多頭燒，不太有時間把接下來的HBase系列課程slides做詳細的介紹；但又不想一直把已經做好的slides堆在自己的NB裡，所以今天心血來潮就直接把三到六的slides全部上架囉~

有興趣的朋友就先矇看唄，如果有任何問題想找takeshi討論，不論是直接在這留言給takeshi或是寄mail都ok囉~~

003 admin featuresandclients from Scott Miao

004 architecture andadvanceduse from Scott Miao

005 cluster monitoring from Scott Miao

006 performance tuningandclusteradmin from Scott Miao

HBase Region Server and Data Locality

很常聽到大家討論HDFS的data locality機制，那HBase呢？請看以下連結~
http://dumbointaiwan.blogspot.tw/2012/11/hbase-region-server-and-data-locality.html

HTablePool的多執行緒問題

Dumbo in TW是小弟在公司參與的group所維護的blog，往後小弟也會在這邊不定期update Dumbo in TW的更新ㄛ~

http://dumbointaiwan.blogspot.tw/2012/11/htablepool.html

Hbase系列課程slides之二

今天takeshi要跟大家分享的是HBase系列課程的第二個部分，這部分主要是在講解一般HBase的使用者，透過HBase client API (主要是用Java語言)，存取HBase時，有哪些功能可以使用，並且要注意哪些部分，slides如下；另外，課程大綱請參閱Part 1的文章ㄛ~

002 hbase clientapi from takeshi_miao

課程大綱如下~

• HBase Client API的基本使用方式

對於資料的CRUD (Create、Retrieve、Update和Delete)操作等，但是Hbase並不像一般RDB，以SQL語言為介面，可以有效隔離資料庫使用者和資料庫管理者角色區別 (當然也有一些極端的case，因為存取效率的考量，需要fine-tune SQL啦...)，也就是說資料庫的使用者，不太需要關心資料在RDB裡儲存方式，只管下SQL就對了；然而，因為HBase的設計是專門針對Big Data做操作，所以它所提供的API，可以做一定程度的調整；可以讓使用者決定撈取紀錄的部分資料 (partial record data)，或者是設定Cache和Batch等等，這些特殊設定或多或少都會影響的對於HBase資料操作的效率，takeshi強烈建議即使是HBase的單純使用者，對這些特殊設定也要多了解一些喔！！

• HBase Filter API

可以把它類比成SQL語法的WHERE子句 (也就是Projection)，HBase提供了各類型的Filter來讓使用者選取他/她所感興趣的資料，也提供了FilterList類別，來讓使用者組合各式各樣的Filter (包含使用者自訂的Filter)，來滿足使用者複雜查詢的需求ㄛ！但另外要注意的是，針對HBase不同元素的查詢，其實是會影響的HBase的查詢效率的喔！ (例如查詢rowkey的效率，會比查詢value的效率，要來的好很多！) 這個議題將在後續的課程討論，讓大家先有個印象唄！

• HBase Coprocessor

這算是HBase Client API相當進階的功能了，它類似於傳統RDB的Trigger和Stored procedure的功能，像是HBase的安全性功能，就是使用Coprocessor實作出來的喔！！

以上，takeshi今天就分享到這，供大家參考囉 ^^

Hbase系列課程slides之一

takeshi很就沒有發佈文章了，takeshi並不是消失了，而是前一陣子換了戰場，一下子有太多咚咚要學，實在是忙不過來ㄚ，其實還是擠得出時間啦，不過都拿去看電影了 XD

前日，遇到以前的同事，他們都在問我blog已經很久沒update了，讓takeshi覺得有一種欠教授作業，很久交不出來，準備被當掉的fuㄚ Orz；所以現在乘takeshi有fu的時候，趕緊擠一篇出來，要不等到下一次有fu，不知是民國幾年了 :p

takeshi最近因公事緣故，準備了HBase的課程教材，主要分為六大部分，依老規矩，先放個心智圖來搏版面 :p

HBase系列課程圖解

這張心智圖，是從右上至左上，採順時針方向來看ㄛ~

所以本篇文章的重點便是「HBase Introduction」囉~

服用警語：由於這些slides是takeshi為公司內部使用的，或許其中有一些名詞或連結，是對外無法使用的，因為takeshi懶得改還請客倌們見諒 Orz

001 hbase introduction from takeshi_miao

本slides主要在講的是...

從一個Web2.0時代的網站開始講起，由於Web2.0網站的資料，大多由使用者自身貢獻，所以當一個網站越紅的時候，它就越容易遇到儲存資料過量的問題！

儲存資料就用RDBㄚ！ 你問十個工程師，大概會有十一人會這樣回答你！那資源有限、任何RDB架構都用上了，最終仍是遇到資料存取速度太慢的問題，你該怎麼辦呢？

大資料時代來臨！！

noSQL及其分類~

主角登場！Apache HBase降臨！！

takeshi google到的一些實務上，使用noSQL架構

以上~~

軟體專案的素質之四 ─ 整體設計之 架構設計案例

之前的架構設計篇，給出了takeshi在設計系統架構時，一般會依循的原則；在此篇文章takeshi嘗試提出一個實際的案例，來回應之前的文章，讓各位朋友對系統架構設計有更深刻的認識！

假設我們作了一個線上書店的網站，因為需要符合客戶快速進入市場的需求，所以在一開始的系統架構設計是採取相當簡單且常見的Three-tier設計，以Tiers & Layers diagram來說，將會是以下內容

常見的Three-tiers架構設計，以Tiers & Layers diagram為例

以佈署圖(Deployment Diagram)來看的話，就可以更明確地看到整個系統的元件各自是放在哪個機器上

常見的Three-tiers架構設計，以佈署圖為例

takeshi通常是在系統架構不大的時候，採用tiers & layers diagram便收工了；但當系統所處的環境越來越複雜時，就會採用佈署圖來作描述，如此可以更明確地表達想法和增進團隊的溝通。

接著如果客戶的線上書店網站系統，希望提供iPhone和Android app的話，系統架構又要怎麼設計才好呢？takeshi的想法是採用Multi-tier架構設計，如下圖所示

常見的Multi-tiers架構設計，以佈署圖為例

以上的架構設計跟Three-tier設計的最大差別是，把線上網路書店系統拆分成五個部分，分別條列如下

1. On-line Bookstore services
集中統一處理系統的商業邏輯，並且對外提供不同的存取介面(EJB, Webservice等)供不同使用者介面呼叫

2. On-line Bookstore web
供瀏覽器存取的使用者介面(UI, User Interface)

3. iPhone On-line Bookstore app
供iPhone存取的UI

4. Android On-line Bookstore app
供Android Phone存取的UI

 5. mySQL-5.5.x
統一資料庫

takeshi認為Multi-tier架構設計的顯而易見的好處在於...

1. 集中商業邏輯統一處理
使用者使用不同的UI (Web、iPhone、Android等)，但背後系統的商業邏輯都是一致的；例如使用者選購書籍並下訂單，並不會因為使用UI的不同而有所不同(你並不會因為使用iPhone就可以不用挑選書籍，它不會聰明到幫你挑吧 XD)；所以集中商業邏輯統一處理可以讓商業邏輯不會到處發散，也不會到處重複；當然這跟系統設計師(SD, System Designer)的設計能力也有關係啦...

然而UI的頁面和流程會有所不同，這就是每個UI的系統元件要去處理的事囉！

2. 不同角色的系統元件關係在實體邏輯上切分清楚
如果套入tiers的觀念來看待On-line Bookstore web、iPhone On-line Bookstore app和Android On-line Bookstore app系統元件的話，不難發現它們都屬於presentation tier，而On-line Bookstore services則屬於Biz Logic tier和Data Integration tier；所以Multi-tier的架構設計，能夠在系統實體配置上突顯出系統中不同元件所扮演的不同角色；且在溝通介面設計良好的情況下，在更改其中一個系統元件的實作時，不會影響到其它元件；再者，不同的元件被佈署在不同的Server上，可以增加錯誤排除的效率(透過log和Server控管介面等)等

Multi-tier的另外一個更重要的好處，就是 可以透過水平式擴展(Horizontally Scalable，也就是叢集(cluster)啦)的方式，來增加系統的scalability、Availability等；舉以下一些例子

1. 線上書店在上線一陣子之後，發現同時線上使用者人數越來越多而導致系統效率變差，經查詢Web Server的控管介面後發現，Web Server準備的request pool已經被過多的同時上線使用者給占光，導致Web Server必須等待空的request instance來服務使用者的請求，導致整體系統回應時間變長，然而request pool已無法再調大(已達機器上限)；此時我們可以選擇新增一個機器來作為Web Server，這樣系統會有兩個Web Server組成的cluster來對外提供服務，這樣一來並能有效處理同時線上使用者人數越來越多的問題。

2. 如上例，線上書店在上線一陣子之後，發現透過Web Server和Smart phone設備的同時線上使用者人數越來越多而導致系統效率變差，經查詢Application Server(AP Server)控管介面後，發現是AP Server運算資源不足，我們同樣地可以考慮再加上一台機器，作為新的AP Server，這樣系統會有兩個AP Server組成的cluster來對外提供服務，這樣一來並能有效處理同時線上使用者人數越來越多的問題。

3.當系統的Web Server或是AP Server突然crash時，cluster中的另一台Server仍可持續運作，雖然系統的效率會降低(直到修復為止)，但仍然可以持續提供服務，可以確保系統的availability。

傳統上為了要加強系統的非功能性需求的強度，通常是採取垂直式擴展(Vertical Scalable) ，也就是對一台機器狂加CPU和Memory，亦或是直接換一台更貴的機器來替代；至於要採用哪一種解決方案，需要從成本和技術能力上來作思考，水平式擴展方案的好處是可以使用相當便宜的機器，來組成一個cluster來提供服務；然而要達到前者所提供的運算能力，在垂直式擴展的方案來說，可能需要上百萬元等級的伺服器，才能達到同等級的運算能力。以技術能力來說，以Java平台來說，AP Server要組成cluster其實已經比以前要簡單很多，通常要注意的是AP Server的cluster設定、網路卡等級和路由器等級等；像上圖的AP Server是glassfish，是takeshi相當喜愛的AP Server，它是Oracle的opensource AP server，既免錢能力又強ㄛ(要作cluster也沒問題ㄛ)，強力推薦！

takeshi認為阻礙系統水平式擴展的最大問題，其實仍然是開發團隊對系統的設計和實作方式啦...

就以上takeshi的描述提出下圖

常見的Multi-tiers + clusters架構設計，以佈署圖為例

講到這裡，大家應該有發現到takeshi一直沒有提到Database的cluster應該要怎麼作處理？其實相對於上述提及的Web Server和AP Server的水平式擴展(Scale-out)，takeshi認為Database的Scale-out難度更是高很多；畢竟使用者需要自動化資訊系統，其主要用意也是希望可以更輕鬆的存取和操作資料，所以如何保持資料讀寫的一致性是非常重要的課題(會把資料弄壞的資訊系統，還會有人敢用嗎？)；然而要如何在維持資料讀寫的一致性和水平式擴展之間取得平衡點，就是個相當具有挑戰的議題囉！

雖然takeshi不是資料庫管理的專家 ，但仍然可以藉助google大神的力量跟大家作一些分享啦...以下簡述一般關聯式資料庫(RDB, Relational Database)如何採取水平式擴展的方法 (當然朋友們也可以直接採取垂直式擴展的方式啦)

1. 讀寫分離 (主從複製，Master/Slave)
使用多台RDB組成一cluster，一台為Master，其它台為Slave，Master Server負責寫入(write)操作，其它Slave Server負責讀取(read)操作；此概念是基於資料庫的使用，通常是讀取操作的比率比寫入操作要來得高 (例如，讀取線上書店產品的機率，比使用者下訂單要來的高；假如一樣高的話，書店老闆就賺到合不嚨嘴啦 XD)；概觀如下圖所示

RDB的水平式擴展方案，讀寫分離

2. 分庫 (Vertical Partitioning)
通常在讀寫分離也不符合需求的情況下，就要考慮分庫的作法了 (也就是被逼的啦...)；同樣也是舉線上書店的案例，通常線上書店在關聯式模型(Relational Model)的設計下，可能會有客戶資訊、交易資訊和產品類別與庫存等表格，假設今天線上書店的生意超級興隆，導致以上表格的資料量大到已經塞不下在一台Master Server裡了！所以系統維運團隊就不得不採取分庫的方法，來維持線上書店系統的正常運作了。

分庫的概念很簡單，其實就是把資料量大的表格分別拆到不同的DB Server中，以上述案例來說，就是把客戶資訊、交易資訊和產品分類與庫存資訊的表格，分別放置在不同的DB Server中；概觀如下圖所示

RDB的水平式擴展方案，分庫

 另一種方式是把讀寫分離和分庫兩個方法結合在一起，此方法適用於即使已使用分庫方法，但查詢(讀取)效率仍然低落的清況；例如以上案例，產品分類與庫存的表格儲存了相當大筆的資料，雖然可以把這些表格裝在一台DB Server裡，但查詢效率仍有待提升，所以可以只針對產品分類與庫存的表格作讀寫分離的作法；概觀如下圖所示，重點在右下台DB Server中

RDB的水平式擴展方案，分庫 + 讀寫分離

 3. 分庫 + 分表 (Horizontal Partitioning/Database sharding)
 通常在使用了分庫作法也還是不符合需求的情況下，就要考慮分庫分表的作法了 (走到這個地步的話，takeshi真的要恭喜，表示這間公司真的賺很大ㄚ...Orz)；同樣如上案例，假使作了分庫之後，產品分類與庫存表格的資料量仍然大到一台DB Server無法承受，此時就需要作分表了。

概念上同樣也很簡單，就是把原來的一張表格，拆分成多張表格啦；概觀如下圖所示，重點是在DB Server4中的表格，是從DB Server3的表格中拆分出來的

RDB的水平式擴展方案，分庫+分表

以上的RDB水平式擴展的方案，還是屬於較概念上的描述，實際上還是要看各家DB產品的支援和解決方案為主啦；但不可否認的是，從一個架構遷移到另一個架構，都是相當耗費時間和人力的大工程，也需要有相當經驗的DBA來協助，此遷移才能順利完成；此外，RDB這段落是takeshi從網路上的文章所整理下來，所以應該跟實務上的作法仍有一些差距，這就看看有沒有熱心的網友提供建議囉 XD

近年來相當火紅的noSQL DB，也是為了要解決上述等等問題而產生的；據takeshi的了解，hadoop的目的是在提供資訊系統一個可以無限水平擴展分散式檔案系統；HBase則是基於Hadoop，可以無限水平擴展分散式資料庫；另外還有Memcached這類的分散式memory database，用來緩存系統常用的資訊，以進而增加系統的反應時間；總而言之，noSQL DB的產品可是不勝枚舉ㄚ...對超大規模資訊系統架構設計有興趣的朋友，也可以參考High Scalability這個網站，takeshi有時候也會上去晃晃說

這篇文章到這裡也夠長了，takeshi之後有機會再說說noSQL的感想唄~

軟體專案的素質之三 ─ 整體設計之 架構設計篇

這次takeshi要談的是架構設計，在正式開始討論之前，takeshi要先幫大家refresh一下記憶，之前takeshi討論系統設計的文章，引用了kenming的文章，如下圖...

{程序員邀稿} 以架構為中心的主要設計產出(1)，Kenming's鮮思維

 takeshi也講解過對於 需求、結構和實作觀點的看法，takeshi再舉一個關於"舞台劇"的例子：需求觀點就好比是一齣劇的劇本，而結構觀點就好比是這齣劇的演員，實作觀點就好比是舞台的選擇；我們從導演或編劇(客戶窗口或領域專家)手上拿到劇本(需求收集)，然後挑選適合的演員(系統分析)，請演員依據劇本作排練(系統設計，takeshi是使用Domain-Driven Design)，然後就預期觀眾人數(系統正式上線人數)來決定正式演出的舞台(架構設計)；也就是說，舞台劇的預期觀眾人數較少，就使用較簡單的舞台，而預期觀眾人數較多，就使用較大較豪華的舞台

關於劇本的內容和演員的演技，就是藉由不斷的排演(Iteration)來跟導演或編劇作確認與調整；而平常大家都是在排練室作排練來磨練演技(Unit Test, Integrated Test)，偶而在正式舞台上作排練來確認最終表演的成果(System Test)，必要時也請一些觀眾來參與排練演出(User Acceptance Test)；經由不斷的排練，最終是一個博得滿堂彩的演出(成功的專案，客戶滿意、高品質的系統)！

所以說系統的架構設計就是在探討該如何挑選適合的舞台！
那該如何挑選呢？ takeshi在這裡分享自己在作系統架構設計時的思考框架

Tiers (欲開發之應用系統的概念分層)
首先，先從欲開發之應用系統(SuD，System under Development)之概念上的分層架構著手，以下這張圖對於JavaEE的developer來說，應該不陌生

SuD的tiers，本blog整理

以下簡單介紹每個Tiers所負責的工作
Client Tier
指SuD使用者的環境，可能是PC、Browser、Smart Phone等...

Presentation Tier
指SuD的使用者介面，現行應用系統大多是圖形化使用者介面(Graphical User Interface)

Business Tier
指SuD商業邏輯運行的地方，Domain Model也是在這裡運行

Integration Tier
指SuD對其他外部系統互動之邏輯所運行的地方

Resource Tier
指外部系統，可能是其他上下游系統，亦或是資料儲存媒體(資料庫、檔案)等

最左邊的Client Tier是對SuD使用者提供服務，使用者觸發某個事件(例如click button)，此事件會產生請求，往右邊 Tier傳送，一層接著一層，直到SuD把請求處理完；接著再往左邊 Tier回傳，又一層接著一層，傳回到SuD使用者看到回應，接著使用者再對SuD繼續執行下一個步驟，因此又觸發新的事件，SuD再接著處理；此一連串步驟不斷執行，直到使用者把他/她的目的達到為止

舉個例子，使用者使用瀏覽器(Client Tier)在線上書店網站(Presentation Tier)購物，已在購物車中挑選好想要購買的書籍， 接著點選「結帳」連結，觸發使用者介面事件，事件產生請求(request)，並傳送到SuD的Business Tier；SuD商業邏輯要幫使用者產生訂單，會跟Integration Tier請求使用者資訊(地址、電話等)、書籍價格、運費資訊等，接著Integration Tier會跟資料庫(Resource Tier)請求相關資料，再回傳給Business Tier；Business Tier把這些相關資料包裝起來，再一起送到Presentation Tier，在線上書店網站呈現出填寫訂單頁面；等待著使用者填寫訂單，並觸發下一個事件；上述類似流程會不斷執行，一直到使用者把他/她的訂單完成(達到目的)為止

如上所述，把一個SuD拆解成多個Tier，其主要原因如下

降低複雜度
這是人類處理複雜問題的一般處理手法；把一個龐大的複雜問題，照一定的邏輯和相關性作分解和歸類，拆成一個個小型問題，再來針對這些小型問題來想解決方案，問題複雜度會因此降低很多，也就是要分而治之 (divide and conquer)


鬆散耦合和提高內聚力(Loosely-coupled & Highly-cohesive)
這是物件導向設計原則都會提醒的概念，我們在作系統設計時，類別之間要相依於介面而不是實作，和每個類別所負責的操作是否適當，如此才能提高類別之間的彈性和盡量縮小因需求變動而產生的設計變動範圍；然而在設計SuD之間的Tier的相依性時，也是同樣的道理；每一 Tier都會提供介面來對下一個 Tier提供服務；例如當SuD的Resource Tier對外部系統的呼叫，其外部系統的介面從原本的JDBC呼叫，換成了Web Service技術，我們只要抽換此Resource Tier的相關實作即可，SuD的其他Tier皆不會受影響


實務經驗分享
就takeshi在實務上的經驗，其實在業界待過一陣子的developer，大多都知道這個東東，但對為啥要這麼作卻不甚了解，所以到後來的概念分層，變成了單純地只是在命名空間(在Java是指package)上的區別，然而實作之間的相依性卻藕斷絲連，舉一些例子如下...

1. Data Integration Tier使用了DAO pattern(Data Access Object)，但卻在Business Tier組裝SQL語法，當作DAO物件方法的參數；試問假如遇到了takeshi剛舉出的例子(從JDBC換成Web Service)時，那是不是連同Business Tier也受到影響了呢？

2. 同樣也是DAO的例子，takeshi也看過直接從DAO方法回傳ResultSet物件出來的...

3. 還有一種是比較不明顯的例子，就是在DAO中直接用SQL組成SuD UI的資料需求，然後直接往前端Tier回傳，而Business Tier單純只是為了要接收request、呼叫DAO，接著把資料往前回傳；就takeshi的觀察，主要會有以下問題衍生...

3.1 SQL語法會異常複雜，並且類似語法會散佈在整個DAO都是(或是散佈在資料庫端)，一旦使用者介面有修改需求，必須要搜尋整個DAO tier，確保相關修改資料的SQL語法都有調整到

3.2 一旦SQL語法查詢無法滿足UI需求時，就會在Business Tier作資料組裝的工作，通常此類型的資料組裝邏輯，可讀性相當低；原本複雜的SQL + 到處散佈在DAO Tier + Business Tier的資料組裝的可讀性低，大大地增加系統維護的複雜度！


Layers (平台服務的分層)
接下來takeshi要分享的是各階層平台要提供哪些服務來支持SuD的需求；要聚焦的是SuD的每個Tier，在每一個Layer需要哪些服務，是一種二維的概念，如下圖所示

Tiers & Layers Diagram，本blog整裡

有在追蹤takeshi部落格的朋友，相信對這張圖有點眼熟，這是Java MVC  sample#2的Tiers & Layers Diagram，takeshi借用這張圖來對每個Layer所代表的意義作個簡單介紹

Application Layer
描述SuD的軟體元件；參考上圖，從Client tier到Data Integration tier就是Sample Project #2和Resource tier的DB Schema

Virtual Platform
描述SuD所相依之平台所提供的介面 ；參考上圖，在Client tier是基於html v4.0，而在Presentation tier則是AS v3、MXML和PureMVC-AS3-2.0.4，之後以此類推...

Upper Platform
描述SuD所相依之平台本身；參考上圖，在Client tier是基於任何廠牌的瀏覽器(Any browser)和Adobe Flash Player v10的版本

Lower Platform
描述SuD所相依的作業系統(OS，Operating System)；參考上圖，Client tier是可以是任何OS，而SuD也是任何OS；另外要注意的是，Client tier和Presentation ~ Resources tier是拆分為兩個儲存格，其實是代表在不同的電腦上運作的意思

Hardware Platform
描述SuD所相依的電腦規格；參考上圖，不論是Client tier或是Presentation ~ Resources tier都可以是任何電腦

takeshi在實務上會使用tiers & layers diagram或是UML的佈署圖來記錄以上資訊


Service-Level Requirements/Quality Of Service (QoS)
在這一節，takeshi要分享的系統架構設計最大的主角，也就是系統的非功能性需求，簡單介紹如下...

Performance
描述客戶期望SuD對於需求的反應時間；例如，當使用者在線上書店下訂單時，對訂單的處理必須要在三秒內完成，並把結果呈現給使用者知道！

Scalability
描述SuD對於需求的吞吐量，也就是在同一時間單位可同時處理多少需求，同時又能滿足Performance需求；例如，客戶希望SuD有每秒鐘可以同時處理一千位使用者的需求，又能滿足三秒鐘內回覆給使用者知道的能力！

Reliability
描述SuD對於交易處理的完整性與一致性；例如，客戶當然對於SuD保存客戶資料和交易資料相當重視；另外一方面，對於SuD所產生出來的log檔案，其數量可能是最多的，但客戶可能對其儲存的完整性與一致性的要求，相對就沒這麼高；所以對於兩者資料的儲存方式有機會可以採取不同的作法

Availability
描述SuD可以一直提供服務的程度；像是Amozon的EC2服務，保證可以在訂閱之後的365天內，提供99.95%的Availability，換句話說，每年大概約有四個小時，服務會有無法提供的可能性

Security
描述SuD提供的安全性機制；通常客戶會要求SuD，對於使用者敏感資料操作必須要提供SSL連線方式；另外也可能會要求儲存在資料庫的使用者密碼，應該要使用演算法加密，防止可以存取資料庫的相關人員盜竊

實務經驗分享
takeshi在實務上的經驗是，通常系統分析師(System Analyst，SA)在跟客戶窗口搜集需求時，往往都聚焦在功能性需求，而對非功能性需求都比較少關注；當系統進入使用者接受度測試(User Acceptance Test)時，非功能性需求的瓶頸才被關注，然而在此階段才去解決此問題，時間往往都已經不夠用；並且改善非功能性需求的問題，動到系統設計的可能性是高的；通常會演變成開發團隊要卯起來加班，最後就算SuD如期上線，但背後的系統設計可能已經受到影響，對往後的維護工作造成影響

所以對於非功能性需求的部分，應當及早釐清，並在系統開發的過程中，就要盡量做到非功能性的系統測試(System Test)；以Java平台而言，takeshi建議可考慮使用類似像Apache JMeter等軟體，來作非功能性測試


SunTone Methodology
以上takeshi介紹的從三個思考框架來看待系統架構，其實可以使用三維的方塊(cube)來表達，如下圖所示

SunTone Cube

上圖的x軸就是指Tiers，y軸就是Layers，而z軸就是QoS；其實這是昇陽提出來的系統架構設計方法，叫做「SunTone Methodology」，有興趣的朋友可以參考這裡，或者是可以去上OO-226的課程，takeshi在這門課程學到不少東東說~


takeshi在選擇和設計系統架構時，就是依據此cube來作思考的，對takeshi相當有幫助，希望也對看到此篇文章的朋友們也有幫助囉 ^^