[筆記]開發可拓展性網站原則
紀錄一下
XYZ分割
X軸：物理複製(類似clone)
例：將服務分配在多台主機上，利用load balance進行服務分配。
Y軸：根據不同事物分割：利用名詞與動詞配置不同資源(類似SOA)
例：收集客戶資料；動詞是「收集」，名詞是「客戶資料」，分配在不同的主機或裝置上。
Z軸：相近事物分割(資料庫表格或欄位分割)
例：假使資料庫有張表格寫入大於讀取很多，可以將讀寫分開在不同的主機上，或者儲存的資料很多，可以利用partition view方式，將資料存放在不同主機上而讀取方式相同。
原則
1. 客戶端的同步要看狀況，假如說按讚跟更新個人安全設定相比，按讚不用馬上同步到所有客戶端。
2. 防火牆的設定要恰當，不要為了資安而因噎廢食，對於商用網站來說，使用者的感受為第一優先。
3. 在應用程式及資料庫間建立一層緩存層，可以有效提高網站效能及使用者體驗。
4. 要分析存儲成本與資料效益，當儲存成本大於資料效益時，除非法律有明文規定要保留，否則可以考慮刪除。
5. 通過的Device越多，則可用性越低，假設網站有防火牆、Load Balance、Web server 、AP server 及DB server，每台機器的可用性為99%，則整體網站的可用性為 99% X 99% X 99% X 99% X 99% = 95%。
6. 一個遲到的回應，就是一個錯誤的回應：最壞的情況為使用者不斷發出請求，造成網站的TCP覆載全滿，不能再接受新的請求(Request)，可以利用泳道技術來分割錯誤發生點及處理機制。
7. 資料庫避免使用預存程序(Store procedure)來處理商業邏輯(BI)，原因如下：網站的效能瓶頸通常在資料庫，想要提升資料庫的效能，最好的方式就是將資料庫的行為單純化，資料庫只要處理資料的CRUD(Create、Read、Update、Delete)就好，不要處理複雜的商業邏輯；另一方面商業邏輯可以搭配物件導向的技術來增加可讀性及維護性，Store Procedure很難完成這點。
那些情況要使用非同步程式
| 使用情境 | 原因 |
| 外部或第三方的API | 1. 使用外部方法可能出現的問題太多。 2. 系統的健康和可用性避免與不能控制的系統連結。 |
| 長時間運作的程序 | 運作慢的程序是比停機更棘手的問題，系統會整個卡住，判斷條件如下： 1. 運作時間長。 2. 花費計算及I/O資源高。 |
| 容易出錯/頻繁修改的方法 | 1. 修改次數越多，程式有bug的可能性越大。 2. 不要把核心程式和需要頻繁修改的程式關聯在一起，容易造成故障增加。 |
| 時間約束 | 當兩個程序沒有時間約束，考慮使用發出請求後不用再管狀態的子程序。 |
MasLow(錘子定理)
如果你只有一把錘子，沒有其他工具，那麼你自然會把每個問題都看成釘子。
特色
• 解決問題時總是會選擇自己熟悉的工具。
• 採用相同的工具或者第三方產品得到一致的結果。
優點
• 可預測性。
• 一致性。
缺點
• 使用不適合或者不是最佳的工具或者解決方案來完成任務。
DID(Design Implement Deploy)
| 設計(Design) | 實現(Implement) | 部署(Deploy) | |
| 擴展目標 | 20倍到無限大 | 3~20倍 | 1.5~3倍 |
| 腦力成本 | 高 | 中 | 低到中 |
| 編程成本 | 低 | 高 | 中 |
| 資產成本 | 低 | 低到中 | 高或非常高 |
| 總成本 | 低/中 | 中 | 中 |
參考資料