# 專題講稿
## 我自己的
### 目錄
- 以下是我們的目錄，接下來將依序介紹
### 動機
- 首先介紹我們製作此專題的動機，因為台灣即將在2025年邁入超高齡社會，代表每 5 人就有 1 人年滿65歲以上，但並非每位長輩都可以得到妥善的照顧，雖然目前很多單位都已經有在提供獨居長者的每日送餐服務，不過目前這些服務大多數仍採傳統的送餐模式，會有不易管理資料、無法得知即時狀況等缺點。因此我們希望能透過這次機會研發一套系統，期望能達到送餐服務的數位轉型，也使整個流程更易於掌控與管理，我們的目標是希望每位長者都能有尊嚴的享用每一餐。<br/>
此外，我們也在整個送餐過程中引入了計算碳排放的概念，希望能透過這些數據，在未來將整個備料、製餐和送餐流程中會產生的碳排放量清楚計算，為未來可能設立的減碳政策提前規劃。

### 六大核心功能
- 接下來，我們依序簡介系統的六大核心功能，後面會針對各個功能詳細介紹
1. 外送員的行進速度與停留時間之分析
2. 外送員送餐中遇緊急狀況之處理
3. 使用基因演算法最佳化送餐路線
4. 外送員記錄年長者每日健康狀況
5. 系統運用高可用叢集式架構架設及管理
6. 系統加上基於 ChatGPT 的問答式機器人

### 開發工具
- 我們的系統主要由 3 個子系統組成，分別是手機的 APP、地圖網頁以及管理網頁
- 這些是我們各個子系統會用到的服務，接下來我會介紹為甚麼以及如何使用他們

### 系統架構

- 在介紹會用到的服務之前，我先介紹在系統架構上我們設計的重點，主要有三點：
1. 實現 DevOps：所以我們採用微服務和容器化架構開發系統，以更好分配開發工作，以及自動化系統設定、整合及部屬的流程。加速產品開發生命週期，達成快速因應市場需求開發新功能、快速更新現有問題等效用
2. 高可用性：系統中所有服務皆需有高可用性，能夠應對單點失敗的問題。當叢集中有一節點發生問題，有可能是天災或被駭入導致節點 crash，系統能夠自動偵測，並且正確做到 failover，以確保整個系統不受影響能繼續運作
3. 負載平衡：為了應對實務上會有的同時大量流量的而導致服務品質下降的問題，比如說搶票系統會在一小段時間有大量流量而導致網頁無法在正常時間內載入，系統需要可以將流量分散於叢集中各個節點

- 接下來簡單介紹系統需要用到的服務：
1. APP：採用 Xamarin 開發，可以查看需送餐的客戶位址以及會定期回傳外送員的 GPS 以及送餐打卡狀況到 MQTT Server
2. MQTT：作為一個產出和訂閱的佇列，藉由 mqtt 封包的特性，降低手機頻繁回傳封包的成本，節省手機的網路流量以、電力消耗，也可以提升外送員在網路不好的區域成功傳送資料的機率
3. Kafka：也是作為一個產出和訂閱的佇列，但其高產出且有做緩存的特性可以解決 Web Server 直接對接 MQTT 所產生的兩個問題
1. 無法暫存資料：如果 Web Server 出現問題導致暫時無法接收 MQTT 的資料，這期間的資料就會丟失
2. 遺失封包：在進行壓力測試中，我們發現只要單一時間流量過大封包會有零星遺失的問題
5. Kafka Consumer：採用 Express.JS 開發，及時接收 Kafka 的資料並進行處理後再將資料送往 Socket.IO、管理網頁、MariaDB、redis、並且開放 API 讓地圖網頁存取歷史資料
4. MariaDB：為一個關聯式資料庫，將系統的功能規劃成 schema 後可以建立 table 以儲存資料
4. Redis：為一個非關聯式資料庫，利用其將資料儲存於記憶體所以可以快速存取的特性，作為 Cache 以加速系統存取資料的時間。若系統發現無法於 redis 中找到資料，會再去 MariaDB 存取，因為資料沒有存入磁碟會導致重開機時被清除。
6. 地圖網頁：採用 Angular.JS 和 Socket.IO 開發，除了顯示歷史資料（包含路線以及送達狀況）以外，Socket.IO 讓網頁可以查看及時外送員送餐的狀況
8. 管理網頁：採用 Express.JS 開發，可以管理外送員、送餐路線、客戶等資訊

- 為了將以上會用到的服務採用一開始提到的架構開發，
- 我們將 MairaDB 採用由 3 個節點組成的 MariaDB Galera Cluster 達成及時同步資料於多個節點的高可用性，再經由 haproxy 提供 load balance、 failover 以及監控節點狀況和流量的作用。
- 剩餘的服務打包成 container 再部屬於由 3 個節點組成的 docker swarm cluster
- 簡單介紹一下 docker swarm cluster
- 為 docker 原生提供的工具，通常由多個節點組成，可以將多個容器部屬和管理於多個節點。所以我們可以藉由使用此工具提供相較傳統的架構較不易有的以下幾個功能：
1. 自動處理容器間在不同節點但是在相同網路下的溝通，且可以在每個節點存取部屬於其他節點的容器的服務
2. 負載平衡：同個服務可以有多個容器部屬於不同節點，預設會採用 round-robin 的方式做負載平衡
3. 高可用性：當節點故障，會自動將部屬於其上的服務移至別的節點
4. 擴充性高：當系統的流量變大或變小，可以輕易地幫服務增減 replicas 的數量，可以維持服務的品質以及節省資源
5. 無痛更新：當系統要更新服務，但是系統可能是不能停機的重要服務（ex. google），docker swarm 會逐個替換掉舊版本的容器，以達成 zero downtime，讓使用者感覺是無痛更新
6. 操作簡單：相較於 kubernetes 需要理解更多元件的功能，docker swarm 基本上只要對 docker 有一點理解就容易上手，且基本的功能也都有提供

- 

- 最後為系統架構做一個總結：我們透過以上設計，讓系統可以快速更新版本且穩定的運行。
- 接下來給下一位同學負責講解詳細系統功能

## 十二分鐘
- 功能介紹
- 我們專題製作了一個送餐平台，由 APP、地圖網頁、管理網頁系統、ChatBot 組成
- 因為長輩越多，所以開發此系統增加管理效率
- APP
- 裝在外送員的 APP，可以顯示及時位置、送餐狀況
- 地圖網頁
- 顯示外送員的及時位置、送餐狀況
- ChatBot 詢問菜色
- 管理網頁
- 管理外送員及客戶的資料、利用基因演算法規劃路線等
- ChatBot 系統功能導覽
- 架構介紹
- 我們採用 DevOps 的方式開發系統以加快產品開發週期。並且系統所有服務皆採用高可用、負載平衡、高擴充性的架構，分別利用以下架構
- HAProxy + MariaDB Galera Cluster
- Docker Swarm Cluster

## 問題
### 技術 (猛哥回答)
- 使用 load balancing 的甚麼機制 & 原因
- 機制 : round robin
- 原因 : 每台主機性能相近，因此用 round robin 平均分散流量
### ChatGPT
- 回答錯誤的資訊 (幻象)？
- 透過調整 prompt 來提升回答的準確性
- 隱私問題？
- 透過調整 prompt 讓 chatgpt 不會回答敏感資訊
- 或是用謝承瑾提的方法 (我忘了)
> FIXME
### App
- 網路不好或完全沒網路怎麼回報簽到簽退紀錄？
- 暫存在手機，網路通順或有網路再傳。
- 摔車嚴重時可能無法手動按確認送出？
- 有考量過一段時間沒回應會自動送出，但發現可能在行駛時誤判而送餐員無法及時取消，造成誤報。這部分可以再優化偵測準確性，或是設計出更完善的自動通報流程。
- 誤觸警報系統怎麼處理？
- 社工會以電話通知，確認送餐員是否真的有出狀況
- 三軸加速器細節？
- 目前是以 x、y、z 三軸數字測試最適合的組合
- 可以再持續優化偵測碰撞的準確度
### 演算法
- 基因(路線最佳化)演算法問題？
- 路線不順路
- 這屬於方向性的問題。可以用兩個點的角度來計算方向性，以角度太大作為評分標準之一
- 解釋演算法細節
- 過程參考這裡 https://hackmd.io/9Os2l76XTem9u9eUx_ZmBA?view
- 權重重點
- 目前重點放在 **路線案主數** 與 **路線總距離** 最重
- 碳排放如何計算？
- 參考政府開放資料平台的機車碳排係數資料，機車在不同時速會對應不同的碳排放量，依此來計算。
- 停留時間分析演算法怎麼定？
- 怠速 28 km/h
- 參考弗傳慈心基金會的送餐員平均行駛速度 (36 km/h)，扣掉 1.5 個標準差為 28 km/h
- 那為甚麼是 1.5 個標準差？
- 代表要與平均速度有相當大的落差才會分析被為怠速
- 超速 50 km/h
- 參考台灣大多道路限速為 50 km/h，再考量適宜送餐的行駛速度，總結出 50 km/h 這個標準。
- 回報時間過長
- 參考弗傳慈心基金會的送餐員平均的給餐時間約為 1 分半，所以增加 1.5 個標準差為 2 分鐘當作標準
- 那為甚麼是 1.5 個標準差？
- 代表要與平均給餐時間有相當大的落差才會被分析為回報時間過長
### 管理
- 商業價值？
- 個人
- 市面上較少功能完整的數位送餐平台 (例如追蹤送餐員送餐進度、自動化簽到、安排路線流程...)，加上弗傳慈心基金會的送餐服務確實有此需求，代表有潛在商機。
- 快速部署的特性能讓我們能夠快速複製多個服務給多個機構
- 商家
- 原本須用紙本記錄、不能得知即時資訊，透過數位化可以解決前述問題
- 為甚麼不用其他送餐平台？
- 服務目的不同，送餐平台是營利導向，慈善機構送餐平台是為了照顧到每位獨居長輩
- 同時這些送餐平台也沒有如此完整的功能，例如追蹤送餐員行經軌跡、停留時間分析，或是紀錄案主的健康狀況等。
### 未來展望
- 如何智能化管理模式？
- 目前只有將送餐管理工作自動化，可以將其他工作比如備料、制餐流程中的管理工作也自動化
### 遇到困難
- 遇到甚麼困難？
- 系統設計
- 一開始須完整列出功能，並切分好各個子系統需要做哪些功能、將需求化為資料庫的 schema、溝通好 API 要如何存取
- Docker Swarm
- VMWare port conflict with Docker Swarm ingress
### 奇怪的問題
- 地圖網頁顯示案主家會不會有個資問題？
- 有做模糊化，不會在地圖顯示完全精準的座標位置
- mqtt 訊息加密問題？
- mqtt 可以開啟加密功能，但會損失效能高的好處，經考量後我們決定以效能為優先。
- 為什麼要匯出報表，幹嘛不直接在網頁上看？
- 方便上繳資料給政府單位