終於到了第三十天！回想一個月前，突然腦子抽到，想說今年是不是來報名個 IT 鐵人賽，可以試著把近期轉戰系統架構師的個人學習心得做個總結，然後查了一下，發現自己完全沒有準備的時間，壓線報名，之後把自己當成鴨子趕了上架去火烤。這個月每天除了上班，就是在準備文章，六日基本也都在規劃文章內容。期間家人還不斷生病，真的是一度想要棄坑，還好有放幾天颱風假讓我挺了下來，也謝謝另一半的大力支持。無論如何，最後一關了！今天我們來做一點反思。
一路實作下來，Microservices 的開發成本真的很高，明明一個 MVC 專案就可以更輕易的做到這 To-do List 的應用服務，搞得這麼複雜做什麼？也或許有人心中會有疑問，自己負責的專案通常都不大，用戶也不多，又或者沒有那麼多資源可以把專案拆成微服務，那我還要需要學這東西嗎？
其實，學習微服務架構的概念和原則，對於 Monolith 也有很大的幫助。想像一下，當你設計單體應用時，如果能夠運用微服務的思維，你就能夠創造出一個更加靈活、可擴展的系統結構。
通過學習微服務，你會更注重模組化設計，讓系統的各個部分職責明確、邊界清晰。這樣一來，即使是在單體應用中，你也能輕鬆地識別和管理不同的功能模組。而且，當系統需要擴展時，你已經有了清晰的藍圖，知道該如何將某些功能拆分出去，變成獨立的服務。
最重要的是，當你的系統真的需要升級或重構時，你會發現這個過程變得相對輕鬆。因為你的系統架構已經考慮到了未來的變化，各個部分之間的耦合度較低，你可以更容易地進行局部修改或整體重構。
所以，即使你現在不打算使用微服務架構，學習這些概念仍然能幫助你在開發 Monolith 時做出更明智的設計決策，為未來的發展留下更多可能性。
身為一個軟體工程師，刷個 LeetCode 都可以有 N 項解法，在系統設計與開發中，解法更是百百種。如果有看到這裡想要更上一層樓的讀者，可以試著去回答或者實作下面幾個問題。
在 Day 06 - DDD Tactical Design：物件設計到資料庫格式 最後也有問過同一問題，在做 Aggregates 設計時，Aggregate 是允許被別的 Aggregates 聚合的，如果我們將 Todo Item 變成 Todo List Aggregate 中的一個 Entity，那我們這個系統會變成怎麼樣？
我這個專案完全沒有做 Error Handling，這裡的 Error 包括了 Response 和 Compensation 機制，而在這樣的微服務架構內，你知道幾種處理 Error 的方式？你會怎麼樣做？而這做法是否符合 DDD 和 Clean Architecture 的精神？
今天如果我想要紀錄所有 Todo List 內所有 Todo Item 發生的所有紀錄，並且可以讓使用者輕易的讀取歷史資料甚至回朔模擬，那你會怎麼設計系統與紀錄這些歷史事件？
我們在開發系統的時候，常常會使用 CQRS（Command Query Responsibility Segregation） Pattern 來使我們分離關注點，既然我們專案內都使用了 MediatR 了，你會如何在現有架構中實施 CQRS？另外可以想想這個 GraphQL 算不算 CQRS 的一種體現方式？
就像我在 Day 01 - 前言與大綱 一開始的規畫一樣，完結並不是真正的完結，完結之後才是開發微服務的大魔王。
想想看，以前我們用單體架構做個 To-do List，一個 MVC 專案加上一個資料庫就搞定了。現在呢？我們的 Docker 容器裡跑了整整十個應用，而這還只是個簡單的 To-do 系統而已。在真實世界的複雜系統中，同時運行上百個不同的服務簡直是家常便飯。而當你面對上百個不同的服務群集的時候，你該如何管理？可以想像，部署和維護這樣的系統有多麼重要和具有挑戰性了吧！
所以，讓我們跳出開發的框框，從不同角度來看看微服務：
我們需要學習如何運用 CI/CD 工具來自動化部署流程。這些工具能幫我們自動進行測試、打包應用、推送到容器倉庫，甚至自動部署到不同的環境中。這樣一來，我們就能更快速、更可靠地將新功能推送給用戶。
感興趣可以學學：GitLab CI/CD、Jenkins、Azure DevOps、GitHub、CircleCI、Argo CD
Kubernetes 可以說是容器編排的王者。我們得了解如何使用它來管理和擴展我們的微服務集群。甚麼藍綠部屬、金絲雀部屬、各種探針、有狀態與無狀態等等，從基本的部署到複雜的滾動更新，從資源管理到服務發現，這些知識都能幫助我們更好地駕馭微服務。
感興趣可以學學：Kubernetes、Docker、Helm、Rancher、Lens
在微服務的世界裡，監控和維護變得更加重要。我們需要學會如何收集和分析分散在各處的日誌和指標。這些工具能幫我們快速發現問題，分析系統性能，在出現異常時及時做出反應。
感興趣可以學學：Health Check、OpenTelemetry、Prometheus、Grafana、ELK(Elasticsearch, Logstash, Kibana)、Zabbix
在微服務架構中，資料管理變得更加複雜。我們需要考慮如何選擇合適的資料庫，如何在分散式系統中保證資料一致性，如何處理大規模資料，以及如何優化資料訪問性能。正確的資料管理策略能大大提升系統的效能和可靠性。
感興趣可以學學：CAP、PACELC、Kafka、Cassandra、Elasticsearch、NoSQL
最後，我們需要有人來把這所有的拼圖拼在一起。這就是平台工程的魅力所在。平台工程師的工作是為開發團隊提供一個無縫的開發和運維體驗，讓整個組織能夠更高效、更創新地工作。
感興趣可以學學：Terraform、Ansible
以上講的天花亂墜的一堆 Terms，許多我也都一知半解，有些我甚至也沒實際操作過，但若有一天需要用到的時候，至少你會知道這項技術的目的是為了改善甚麼。
經過這三十天的旅程，我們從微服務的基礎概念出發，探索了領域驅動設計、Clean Architecture，並實際動手搭建了一個簡單但完整的微服務系統。希望這過程有使你們體會到了實際應用中可能遇到的挑戰和解決方案。
然而，正如上述所言，這僅僅是微服務世界的冰山一角。真正的微服務架構涉及更多複雜的技術和概念，從部署、運行、維護到資料管理和系統整合，每一個環節都是一個值得深入探討的領域。
作為開發者，我們應該保持開放和學習的心態。技術世界日新月異，今天的最佳實踐可能明天就會過時。但是，核心的設計原則和思考方式卻是不變的。無論是構建單體應用還是微服務系統，清晰的架構、模組化的設計、鬆耦合的組件都是我們應該追求的目標。（或許未來電腦超級強大、AI 寫 Code 沒架構卻超穩定，那我們的目標就得改一改，但在那之前，學這些應該還是有些用處啦！）
最後，希望這個系列能為你打開微服務的大門，激發你對系統架構的興趣和思考。要記住，沒有一種架構是萬能的，關鍵是要根據實際需求選擇最適合的解決方案。
這三十天來的所有的 Code、文章、draw.io 素材、截圖，我都整理在我的 GitHub 上，有喜歡的話可以按個 Star 支持一下！
感謝各位一路相伴，祝願大家在軟體開發的道路上越走越遠，越走越精彩！
iThome鐵人賽
看影片追技術