Delivery System Design --- # 題目 請設計一個前後端架構的連鎖餐廳點餐外送系統， ● 使用者可在任何地方透過點餐系統點餐送單，上傳至點餐核心系統。 ● 核心系統收單後自動派送至距離使用者最近的餐廳據點備餐。 ● 備餐完成後透過待送餐點系統提供內部外送員外送資訊、取單確定外 送功能。 ● 開始外送時於外送系統顯示外送路徑與餐點資料 ● 使用者端同步顯示外送員外送進度 ● 資料於外送系統餐點送達後結束。 設計內容包含此系統整體架構、後端程式功能模組拆分，你認為會使用到 的所有類型Service、資料交換方式，並說明你的設計理由，可用任何型式 表示。 | 名稱 | 數量 | | ----- | -------- | | 蘋果 | 3 | | 雞蛋 | 12 | # 根據 C4 Model 梳理 System Context Diagram 1. 角色（Person） 主要角色 | 角色| 說明 | | ----- | -------- | | 使用者 | 一般顧客，透過前端系統（App/網頁）下單、查詢訂單、追蹤外送進度 | | 餐廳員工 | 負責備餐，接收訂單、確認備餐、通知外送員取單 | | 外送員 | 餐廳內部外送人員，負責取餐、配送、更新外送狀態 | | 系統管理員 | 後台管理，維護餐廳據點、菜單、帳號管理（可選，非主要流程） | 2. 系統（Software System） 主要系統 | 系統名稱 | 說明 | | ----- | -------- | | 使用者點餐系統 | 前端App/網頁，供顧客點餐、查詢、追蹤外送進度 | | 點餐核心系統 | 負責接收訂單、派送訂單、訂單流轉核心邏輯 | | 餐廳據點系統 | 各餐廳據點接收訂單、通知備餐完成、通知外送員 | | 外送管理系統 | 管理外送員、指派外送、追蹤外送進度、回報送達 | | 外送員App/系統 | 外送員端App/介面，查看外送任務、導航、更新狀態 | # 2.1 DevOps 的起源與定義 有關 DevOps 的起源 DevOps 的起源和發展歷程可追溯至 2007 年，當時比利時的一位 IT 顧問 Patrick Debois, 他興趣是從各角度研究 IT 組織。在參與為比利時政府的一個大型資料中心遷移的項目提供諮詢，主要負責這次遷移的測試與驗證工作。所以需要跟開發團隊與運維團隊一起協同工作。時常某一天要在開發團隊跟隨敏捷的節奏，過幾天又要以傳統瀑布的形式去逐步維護這些系統。\ 看到這兩個團隊的運作方式之間的顯著差異時，兩個團隊在不同的世界裡，但彼此又堅守著各自的利益，所以在這之間工作時到處都是衝突。這促使他開始尋求解決方案。 
<圖2-1> 過往組織內開發團隊和 IT 運維團隊之間隔閡與衝突。 2008 年 8 月 , 在多倫多的 Agile Conference 上，一位開發者 Andrew Shafer 提出一個名為 ” Agile Infrastructure” 的話題，這是DevOps的早期形式。當時只有 Debois 參加這話題。他倆在走廊裡，就私下的進行漫長的討論。也就是因為有這次對話，之後他倆就決定了在 Google Group 上建立了一個 Agile System Administration 的討論組繼續討論下去。然後兩人決定新開一個部落格來紀錄這些內容跟自己的經驗，於是乎一個名為 The Agile Admin 的部落格就此誕生。 2009 年 6 月，Debois 在比利時觀看了 O’Reilly Velocity’09 大會的直播。會中最引人注目的是 John Allspaw 和 Paul Hammond 的演講，主題為 “Flickr 如何實現每日 10 次以上部署：開發與運維協作”。這一方法在當時被視為創新和前衛。他們著重於開發和運維團隊之間的緊密合作，這是快速且可靠部署的關鍵。演講中，他們介紹了大量使用自動化工具和監控系統來支持高頻率部署，並提出了特徵標誌（feature flag）的概念，以便在執行環境中安全測試和部署。此外，他們強調應對故障的重要性，包括避免指責文化和加強團隊間溝通。他們指出，開發和運維團隊間的相互理解、尊重以及共享責任和目標對於支持這種敏捷和協作的工作方式至關重要。 此次演講後來成為許多與 DevOps 相關資料的引用來源。其核心觀點是以業務敏捷為中心，建立快速發佈服務的能力和文化。 在觀看了 Velocity’09 大會的直播後，Debois 深受啟發，相信還有其他人也有類似的想法。他隨即在 Twitter 上詢問如何能參加 Velocity 大會。有人回應他，為何不在比利時舉辦自己的類似會議？受此啟發，Debois 在比利時創辦了自己的研討會，邀請開發（Dev）和運維（Ops）人員共同探討協作方法及基礎設施管理，並重新思考團隊合作方式。最初，他想將會議命名為 DevOpsDays，因為會議持續兩天。但由於當時 Twitter 的字數限制為每條訊息 140 字，為了在每條推文中儘可能包含更多信息，他將標籤 devopsdays 縮短為 devops，意外地創造了 “DevOps” 這一詞彙。 
<圖2-2> 開發和運維團隊間應相互理解、尊重，緊密合作進而打造出合乎DevOps的文化。 2010 年，隨著第一屆 DevOpsDays 的成功舉辦，DevOps 這一概念開始被廣泛認可，逐漸成為 IT 部門合作的典範。在這一背景下，《The Agile Admin》部落格發表了一篇題為 “What is DevOps” 的文章，深入解釋了 DevOps 的含義。該文將 DevOps 定義為一種促進開發與運維合作的運動，並基於敏捷方法提出了一套完整的 DevOps 體系，涵蓋價值觀、原則、方法、實踐及相關工具。 DevOps的定義 What is DevOps 這篇文章就給了我們很好的方向來理解。 > DevOps 是一種實踐，涉及運營和開發工程師共同參與整個服務生命周期，從設計、開發到部署和運營支持。其特點在於運維人員使用與開發人員相同的技術進行系統工作，而開發人員則注重創建適應運營環境的優質程式和架構。 更深入點來看，其實圍繞他的討論含蓋了很多領域，所以它對不同人會有不同的意義︰ 1. 價值觀︰在敏捷宣言中得到了有效的捕捉，關注於持續地向客戶交付完整有價值的服務，來完成客戶的需求，而不僅僅是一個可執行的軟體。並重視團隊間的互動超過流程和工具，呼應了開發團隊與運維團隊的合作重要性。 2. 原則︰沒有統一標準，但常見的有CAMS，下一個小節會介紹。也有人覺得是IaC（Infrastructure as Code）或各種XX as Code。但Debois則覺得應該要將敏捷的原則擴展到系統和運營上，而不只是程式碼提交的層面上。 3. 方法︰借鑒敏捷運動的方法，如Scrum，看板等。甚至開發團隊比較常聽到的測試左移、左移可觀測性等策略。 4. 實踐︰眾所周知的包括CI（持續整合）和CD（持續佈署），甚至是可觀測性工程中常提到的對pipeline進行遙測管理，核對運行環境持續檢測和監控的方案。 5. 工具︰範圍廣泛，不同領域有不同選擇。工具本身不直接實現 DevOps，但有助於促進相關方法和實踐。 > DevOps常以8字環（或稱為無限循環符號）的形式出現表達，代表了 DevOps 的持續改進和迭代的理念。這個符號強調了開發（Dev）和運營（Ops）之間的緊密合作和無縫整合，以及這種合作如何在整個軟件交付過程中不斷循環和改進。 在 8 字環中，左半部分通常代表開發（Dev），包括規劃、程式碼設計、構建和測試；右半部分代表運營（Ops），包括部署、運行、監控和反饋。 
<圖2-3> DevOps的8字環，以及中各階段常見的工具類型。 文章中特別強調了 DevOps 的三個主要實踐領域： 1. 基礎設施自動化（Infrastructure Automation）：通過自動化提高效率和準確性。 2. 持續交付（Continuous Delivery）：快速且可靠地將軟件部署到營運環境。 3. 網站可靠性工程（Site Reliability Engineering）：不僅包括系統的運維、監控和編排，還涉及從一開始就設計出易於測試與操作的系統，本書的後半段重點會著重在此介紹。 這篇文章為 DevOps 的理解和實踐提供了清晰的框架，儘管人們對於 DevOps 的具體定義仍有不同見解，爭議在所難免。 隨著 DevOps 的普及，許多組織紛紛採納了 DevOps 的實踐方法。這一趨勢不僅改變了組織的工作方式，也對就業市場產生了顯著影響。根據 2018 年 LinkedIn 的統計，DevOps 工程師成為了招聘最多的職位之一。雖然 DevOps 定義上是一組能力和文化的實踐，但這一工作模式的迅速普及使得許多工程師開始將自己重新定位為 DevOps 工程師。這一現象反映出市場對 DevOps 專業人才的強烈需求，即使這個職稱並不總是代表著真正的 DevOps 實踐能力。
×
Sign in
Email
Password
Forgot password
or
Sign in via Google
Sign in via Facebook
Sign in via X(Twitter)
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Wallet (
)
Connect another wallet
Continue with a different method
New to HackMD?
Sign up
By signing in, you agree to our
terms of service
.