雲端原生之路 - 重構
雲端原生 (Cloud Native) 已經成為應用程式開發的大勢所趨。為了充分發揮雲端的優勢，我們需要對傳統的應用程式進行重構，使其能夠更好地適應雲端環境。
本文將專注探討將應用程式上雲端所需要的重構 (Restructure)，包括微服務化、容器化、自動化部署、無狀態設計等。透過這些策略，我們可以將應用程式轉變為雲端原生應用程式，更好地適應雲端環境，提高開發效率和應用程式的可靠性。
為什麼要上雲端？
在現在競爭激烈的時代想要在市場上脫穎而出，就需要有靈活、方便擴展的基礎設施來支持業務的創新跟成長。
而雲端可以帶來以下幾個優勢：
- 省錢：雲端服務提供了按需付費的模式，可以根據實際使用量來付費，避免了資源浪費。
- 彈性：可以根據業務需求自動調整運算資源,在尖峰時期也能穩穩應對大流量，在低流量時也能節省成本。
- 高可用性：雲端服務商在多個地區都有機房,就算有地方出問題,也能快速切換,保證服務不中斷。
- 加速開發：雲端服務商提供了許多服務和開發工具,如資料庫、訊息隊列、機器學習等,可以讓開發者專注於業務邏輯加速開發,不用花時間在基礎設施上。
- 安全可靠：雲端服務商投入大量資源來確保平台的安全性,提供各種安全服務和最佳做法,讓公司的服務和資料更有保障。
雲端以現代的角度來看，已經不只是個技術議題，而是一個業務戰略。如果可以充分利用雲端的優勢，在變化快速的市場中佔得先機,用創新和敏捷的力量來讓公司更具競爭力。
微服務化
微服務化是重構應用程式的第一步。它將龐大、複雜的單體應用拆分為多個小型、獨立的微服務，每個微服務專注於特定的業務功能。這樣的拆分使得開發團隊可以更加敏捷地開發、測試和部署每個微服務，而不會影響整個應用程式。
在這個過程中，我們需要考慮微服務之間的通訊方式。常用的通訊方式包括 REST API、gRPC、Message queue 等。
在此同時，我們也需要注意微服務之間的資料一致性問題，這可以使用分散式事務、事件驅動架構等方式來解決。
舉一個例子，一個電商平台原本是一個單體應用，包含了使用者管理、商品管理、訂單管理、支付等所有功能。透過微服務化，我們可以將其拆分為使用者服務、商品服務、訂單服務、支付服務等獨立的微服務。每個團隊負責一個微服務，可以選擇最適合的技術堆疊和開發方式，大大提高了開發效率和應用程式的可維護性。
關於各種架構更詳細的內容，可以參考這篇文章。
雲端架構設計的四種範式 - 單體、微服務、巨石與無服務。
容器化
容器化是實現應用程式可移植性和一致性部署的關鍵。透過將應用程式及其相依套件打包成一個標準化的容器映像檔，我們可以確保應用程式在任何環境(dev、staging、product)中都能夠以相同的方式執行。這不僅簡化了應用程式的部署流程，也降低了環境差異引起的問題。
我們更可以透過建立私有的容器倉庫，以便於管理和部署容器映像檔。在此同時，我們也可以透過容器倉庫來實現容器映像檔的安全控制和監控。
常見的容器倉庫包括 Harbor、Docker Hub、Google Container Registry 等。
其中，Harbor 是一個開源的企業級容器倉庫，提供了安全、可靠的容器映像檔儲存和管理功能，支持 RBAC、漏洞掃描、安全控制等功能。
自動化部署
在雲端原生時代，應用程式的發佈頻率越來越高，手動的部署方式已經無法滿足需求。自動化部署透過構建 CI/CD 流程，將應用程式的構建、測試、部署等環節自動化，實現應用程式的快速、頻繁和可靠的交付。
除了可以降低了人為錯誤的風險、提高部署的效率，也可以確保產出跟我們看到的程式碼一致。
常用的 CI/CD 工具包括 Jenkins、GitLab CI、Azure DevOps、GitHub Actions 等。我們可以使用這些工具來驅動從程式碼的提交、構建、測試到自動化的部署，大大提高了應用程式的交付效率和品質。
常用的部署工具則有 Terraform、Ansible 等。這些工具可以幫助我們自動化地部署應用程式到雲端環境，實現應用程式的快速、可靠的部署。
無狀態設計
雲端環境下，應用程式需要能夠快速、彈性地擴展，以應對不斷變化的流量需求。無狀態設計是實現這一目標的關鍵。無狀態的應用程式將工作階段狀態等資訊儲存在外部服務(如Redis、MongoDB)中，本身不保存任何狀態。這使得應用程式的每個執行個體都是獨立、等價的，可以隨時新增或移除，從而實現水平擴展。
例如：在設計無狀態的應用程式時，我們可以使用 JWT(JSON Web Token)來實現無狀態的使用者認證。JWT 將使用者的身份資訊加密後存儲在 Token 中，應用程式可以根據 Token 來識別使用者，而不需要在伺服器端儲存工作階段狀態。
又或者我們也可以使用 Redis 等快取服務來儲存一些需要共享的臨時狀態，如購物車資訊等。讓所有 pod 都可以共享這些狀態，實現使用者工作階段的無縫銜接。
又或者如果只是單純的服務，也可以單純引入 AWS Lambda or Azure Function 來實現無狀態的設計。
分散式資料儲存
雲端原生應用程式面臨著海量資料和高併發的挑戰，傳統的關聯式資料庫已經無法滿足這樣的需求。分散式資料儲存(如NoSQL資料庫、物件儲存)透過分散式的架構設計，實現了資料的水平擴展和高可用，成為應對這一挑戰的利器。
常見的分散式資料庫包括 MongoDB、Cassandra、Couchbase 等。這些資料庫支援分片(Sharding)、複製集(Replica Set)等機制，可以實現資料的分散儲存、高可用和故障轉移。
在選擇資料庫時，我們也需要根據應用程式的需求，如資料模型、查詢模式、擴展性需求等，來選擇最適合的資料庫。
監控與警報
對於監控部分，我們可以使用 Prometheus 和 Grafana 的組合。
Prometheus 是一個開源的監控系統，它可以收集應用程式 exporter 所發佈的監控指標，並提供了強大的查詢語言和警示機制。
Grafana 則是一個開源的可視化平台，可以將 Prometheus 收集的監控資料以豐富的圖表和儀表板的形式展示出來。
在應用程式中，我們可以使用各種 exporter 來抓取應用程式的各種監控指標，例如：包括請求數、錯誤率、延遲等。
然後，我們再部署 Prometheus 伺服器來抓取這些指標。
在 Grafana 上，我們可以透過建立以 Prometheus 為資料來源的儀表板，實時展示應用程式的運行狀態。
在警報方面，我們可以透過 alertmanager 來設定警報規則，當應用程式出現問題時，監控系統可以自動發送警報通知，幫助我們及時發現和處理問題。
同時，我們也可以使用 Prometheus 的服務發現機制，自動發現和監控動態變化的微服務，無需手動配置監控目標。
日誌分析
對於日誌部分，我們可以選擇使用 Kibana 或 Azure Data Explorer。
Kibana 是 Elastic Stack 的一部分，可以用來搜尋、分析和視覺化日誌資料。
Azure Data Explorer 則是 Azure 上的一個快速且高度可擴展的資料探索服務，也可以用於日誌分析。
在應用程式中，我們可以使用像 Log4j、Winston 等日誌程式庫來生成結構化的日誌資料。
然後，我們可以使用 Fluentd 或 Logstash 等工具來收集這些日誌，並將其傳送到 Kibana 或 Azure Data Explorer。在 Kibana 或 Data Explorer 中，我們可以使用豐富的查詢語言來搜尋和分析日誌，並建立視覺化的儀表板。
在設計日誌系統時，我們需要考慮日誌的格式和內容。一個好的日誌應該包含足夠的上下文資訊，如時間戳、請求 ID、使用者 ID 等，以便於故障排查和分析。同時，我們也可以使用 JSON 等結構化的格式來記錄日誌，方便日誌的解析和檢索。
除了基本的日誌分析之外，我們還可以使用異常檢測技術來自動發現日誌中的異常模式。這可以幫助我們及時發現潛在的問題，如系統錯誤、性能瓶頸等，提高系統的可靠性和穩定性。
安全規範
在雲端時代，應用程式的安全規範顯得尤為重要。我們需要在整個應用程式的生命週期中，從設計、開發、部署到運維的各個環節，都要考慮安全規範的要求。只有構建安全可信的雲端原生應用，才能贏得使用者和監管機構的信任。
首先，我們需要對應用程式進行安全的程式碼分析和測試，識別和修復潛在的安全漏洞。同時，也要使用容器倉庫對容器鏡像進行安全掃描，確保沒有已知的安全風險。在 CI/CD 流程中，我們可以引入自動化的安全測試和檢查，在應用程式部署前就發現和解決安全問題。
其次，我們需要對應用程式的資料進行適當的保護。這包括資料的加密(靜態加密和傳輸中加密)、存取控制、備份與恢復等。對於敏感資料，我們可以使用 Azure Key Vault、AWS KMS 等雲端服務來管理密鑰和憑證，提高資料的安全性。
再者，我們需要對應用程式的存取進行嚴格的身份驗證和授權。這可以透過 OAuth2、OpenID Connect 等標準協定來實現。同時，也要對 API 的存取進行適當的控制和監控，防止未經授權的存取和濫用。
最後，我們需要持續監控應用程式的安全狀態，及時發現和回應安全事件。這需要建立完善的日誌收集和分析系統，以及安全事件的警報和處理流程。同時，也要定期進行安全審核和滲透測試，主動發現和修復安全問題。
我們還需要遵循相關的標準和法規，如 GDPR、PCI DSS 等。這需要我們在應用程式的設計和開發過程中，就要考慮這些標準和法規的要求，並通過適當的技術和管理措施來確保安全性。
結論
將應用程式遷移到雲端是一個複雜的過程,需要對應用程式進行全面的重構和優化。微服務化、容器化、自動化部署、無狀態設計等策略可以幫助我們構建更加適應雲端環境的應用程式。同時,我們還需要關注應用程式的監控、日誌、安全等方面,以確保應用程式在雲端環境中的穩定運行。
然而,應用程式的雲端化不僅僅是一個技術問題,更是一個組織變革和文化轉型的過程。我們需要重新審視組織的架構和流程,打破傳統的部門邊界,建立跨職能的團隊。我們還需要培養團隊的 DevOps 文化和精神,鼓勵協作、自動化和持續改進。
同時,我們也需要關注團隊的技能轉型和人才培養。雲端原生應用程式的開發和運維需要一系列新的技能和知識,如容器技術、Kubernetes、微服務架構等。我們需要通過培訓、實踐和知識共享,幫助團隊成員快速掌握這些新技能。
最後,我們還需要與業務方保持緊密的溝通和協作。雲端化不僅僅是 infra 部門的事情,更需要業務方的理解和支持。我們需要與業務方一起制定雲端化的目標和路線圖,並通過敏捷的開發和交付方式,快速響應業務需求的變化。
應用程式的雲端化是一個長期的過程,需要組織上下的共同努力和持續投入。只有建立起適應雲端環境的應用程式架構、流程和文化,我們才能真正實現雲端的價值,加速業務創新和發展。