# System Design
## 議題討論
### 何謂 System Design？系統設計的流程與步驟為何？

**System design** 是指設計一個系統的**架構、部件、介面**的流程，目的是要達成系統使用者的需求。

系統設計生命週期（development life cycle）
- 一、需求分析與開發計畫：透過實際考察、資料分析等方式，找到可能的需求以及限制。
- 二、定義需求：詳細定義所有需求，並得到所有相關人員同意（開發者、消費者、股東等等），通常會制定 Software Requirement Specification（SRS）。
- 定義每秒需求、儲存容量、需要哪些功能
- 三、架構設計：這個階段需要考慮需求以及系統的複雜度（performance、availability、scalibility 等等），決定外來不同的部件間如何整合
- 前端、後端、DB
- 演算法、table怎麼設計、API規格
- 四、系統開發：透過已撰寫好的文件進行需求的實作
- 五、系統測試與整合：單元測試以及整合各個部件，確保系統能夠正確提供服務，架構的性能也在此時被測試
- 六、部屬和系統維護：系統部屬後，後續的更新以及維護

架構設計：
- 辨識複雜度：思考並定義此系統在延展性、可用性以及效能上的需求，了解架構需要著重於哪個部分
- 設計備選方案
- 評估和選擇方案
- 詳細方案設計（實作）

### 什麼是 High Performance、High Availability、Scalability？

- **高可用性（High Availability）**：取決於**正常運行時間（uptime）** 長度以及**功能反應時間**，一些機構像是醫院、金融等負擔不起過長的等待時間就需要高可用性的系統。
- **可靠性（Reliability）**：當系統可以正確的提供所有的功能和服務（features & services），那麼系統便是 **Reliable**。可靠的系統需要一定程度的[**故障容許度（fault tolerance）**](https://zh.m.wikipedia.org/zh-hant/%E6%95%85%E9%9A%9C%E5%AE%B9%E8%A8%B1%E5%BA%A6)，讓系統不會因為某些功能的故障導致系統故障。
- **高效能（High Performance）**：系統在特定工作量下的效能，是 scalability 以及 availability 的綜合指標。
- Response Time
- Throughput
- Resource utilization
- Workload
- **延展性（Scalability）**：指系統的流量負載量（work load），透過調整系統負載流量的方式去適應高流量的情境，流量可能是：
- 系統指令（request）
- 資料庫指令
- Cache hit/miss
- 當前活躍使用者

### 如何提升系統的 Performance？
https://ithelp.ithome.com.tw/articles/10081534
### 何謂資料庫讀寫分離？
* 使用原因：因為多數場景都是讀多寫少，為了減緩讀檔壓力
* 主要架構：主從式設計
* 寫入：先寫入主DB，再由主DB寫入從DB
* 讀檔：基本由從DB負責

https://codingnote.cc/zh-tw/p/276299/

### Cache 如何提升系統效能？該放在系統哪個位置？

減少資料庫操作；前端
提升複雜計算速度；後端

### 如何提升系統的 High Availability？


https://www.filecloud.com/blog/an-introduction-to-high-availability-architecture/

### 何謂 CAP 理論？該如何選擇？
* Constitency - 一致性
* Availability - 可用性
* Partition Tolerance - 分區容錯性
##### CAP Theorem
* CAP不可能同時滿足三點，於是分為三種情況
* CA - 基本上是單一主機運行
* CP - 確保所有主機資料一致，否則回傳錯誤
* AP - 基本不報錯，但不保證資料是最新

https://ithelp.ithome.com.tw/articles/10216500

### Database 的 Replication 有哪些模式？
* **Master Slave Replication 主從式**
* https://www.manageengine.com/device-control/data-replication.html
### 如何提升系統的 Scalability？
- 程序執行方式
- 非同步程序：讓回應速度慢的程序已非同步的方式執行，確保其他功能的的流量可以先被解決
- 程序排程（queue）
- 硬體加速
- 分散式系統（w/ load balancer）
- Cache 複雜計算時所需要的資料
- 資料庫操作限制
- Cache 機制
- Idexing 搜尋

### 何謂微服務與分層架構？
* **分層架構**中的一個重點在於**當某一層進行更改時，通常不應該影響到非相關依賴層** ，而分幾層可以按場景靈活應用(n-tier architecture)，例如：很多公司會根據組織結構（前端工程師、後端工程師、DBA）做分層。
* **微服務**是一種軟體開發的方法，將**應用拆解為最小單位的獨立元件**。以臉書為例，可以拆解成動態牆、影片、個人檔案、照片等，而這些功能的程式碼再由不同團隊更新、部署、維運。
#### 分層架構
* 大部分的分層架構會分成這四層：
1. **表示層 (Presentation Layer）**：處理所有用戶界面和瀏覽器通信邏輯。
3. **業務層 (Business Layer)**：處理軟體本身特定的業務邏輯。
4. **持久層 (Persistence Layer)**：注於資料的儲取活動。
5. **資料訪問層 (Data Access Layer)**：外部資料來源 (通常獨立於應用程式)。
* 為什麼要分層？分層的好處？
* **易於理解與開發**：程式邏輯很線性，資料流不是從上到下就是從下往上
* **關注點分離（Separation of concerns, SoC）**：該層只處理與該層相關的邏輯，可以有效分割功能，讓開發、測試與維護變得更簡單。
* **可測試性**：分層獨立更容易模擬單元測試。
* 參考資料
* [軟體架構：分層架構模式 (Layered Architecture)](https://medium.com/%E7%A8%8B%E5%BC%8F%E6%84%9B%E5%A5%BD%E8%80%85/%E8%BB%9F%E9%AB%94%E6%9E%B6%E6%A7%8B-%E5%88%86%E5%B1%A4%E6%9E%B6%E6%A7%8B%E6%A8%A1%E5%BC%8F-layered-architecture-a959da09d1c6)
* [從分層架構到微服務架構（二）之分層架構](https://www.readfog.com/a/1632288208805007360)
#### 微服務
* 基本特點
* 每個服務運行在自己的process中
* 使用輕量級協議(RESTful APIf、gRPC)做通訊(Lightweight Mechanism)
* 透過自動化部屬來完成獨立部屬
* 按照業務能力(Business Capability)來區分規劃各服務範圍
* 各服務可以使用不同的語言來開發, 也可以使用不同的資料儲存媒介
* 參考資料
* [菜鳥漫步雲端 #3: 什麼是微服務(Microservices)](https://medium.com/@yijyun10100926/%E8%8F%9C%E9%B3%A5%E6%BC%AB%E6%AD%A5%E9%9B%B2%E7%AB%AF-3-%E4%BB%80%E9%BA%BC%E6%98%AF%E5%BE%AE%E6%9C%8D%E5%8B%99-microservices-51d8b873d252)
* [微服務瞎談(2) 服務與架構的演化](https://ithelp.ithome.com.tw/articles/10234821)
## 案例研究
### Design Rate Limiter
### Design ID Generator
## 實作
### 1. Stylish DB放到RDS
### 2. AWS Auto Scaling + Artillery + Rate Limiter
### 3. 實作 ID Generator