在現代軟體架構中，事件驅動架構和無伺服器技術已成為熱門趨勢。事件驅動架構強調以非同步方式處理事件，提高系統的彈性和可擴充套件性。無伺服器技術則簡化了基礎設施管理，讓開發者更專注於業務邏輯。然而，從傳統系統遷移到無伺服器架構並非易事，需要仔細規劃和執行。本文將探討事件驅動架構中的常見模式，並提供將傳統系統遷移到無伺服器架構的實踐策略。
伺服器無法安全性
Nicole Yip指出，伺服器無法架構可以使安全性更容易，因為環境是沙盒化的，減少了持續入侵點的能力。但是，當引入更複雜的使用案例時，例如網路和身份驗證，安全性專業知識的需求仍然相同。軟體工程師需要意識到他們在安全性方面的責任，並考慮容器執行程式碼所需的許可權和連線性。
文化和安全性
Nicole Yip分享了她對於如何在團隊和組織中培養安全性文化的見解。她強調，透明度、快速失敗和無罪原則是高績效工程文化的核心。此外，保持安全性在對話中，並提供足夠的支援給工程師以便他們能夠探索和學習安全性最佳實踐，是非常重要的。
安全性意識
Nicole Yip建議企業從企業層面開始，假設明天就會發生資安事件。企業應該檢查是否有良好的安全基礎，並知道如何反應和補救。預防和緩解措施是必要的，但永遠不能將風險降低到0%。企業應該建立基本的安全能力，例如偵測、回應和預防，並且應該讓平臺團隊建立安全的金色路徑，以便將所有內容路由到公司的SIEM系統中，並將優先順序警示表面化給團隊。
事件驅動架構中的模式實作
在事件驅動架構中，模式扮演著至關重要的角色。它們提供瞭解決常見問題和挑戰的方法，幫助開發人員更快、更有效地設計和實作系統。在本章中，我們將探討一些常見的事件驅動架構模式，包括編舞（Choreography）、管絃樂（Orchestration）和無_SERVER模式（Serverless Pattern）。
編舞（Choreography）模式
編舞模式是一種事件驅動架構模式，涉及多個服務之間的協調和溝通。這種模式通常用於需要多個服務之間進行複雜互動的系統中。編舞模式的優點包括：
- 低耦合度：服務之間的耦合度較低，從而提高了系統的可擴充套件性和可維護性。
- 高靈活性：編舞模式允許服務之間進行動態的協調和溝通，從而提高了系統的靈活性。
然而，編舞模式也有一些缺點，例如：
- 複雜性：編舞模式可能導致系統的複雜性增加，從而提高了開發和維護的難度。
- 效能：編舞模式可能導致系統的效能降低，因為服務之間的協調和溝通可能需要額外的時間和資源。
管絃樂（Orchestration）模式
管絃樂模式是一種事件驅動架構模式，涉及一個中央的協調器（Orchestrator）來管理和協調多個服務之間的互動。這種模式通常用於需要一個中央的控制點來管理和協調多個服務的系統中。管絃樂模式的優點包括：
- 高控制度：管絃樂模式允許中央的協調器對多個服務進行控制和協調，從而提高了系統的控制度和可靠性。
- 低複雜性：管絃樂模式可以降低系統的複雜性，因為中央的協調器可以簡化服務之間的互動和協調。
然而，管絃樂模式也有一些缺點，例如：
- 單點故障：管絃樂模式可能導致單點故障，因為中央的協調器如果失敗，則可能導致整個系統失敗。
- 效能瓶頸：管絃樂模式可能導致效能瓶頸，因為中央的協調器可能需要處理大量的請求和回應。
無_SERVER模式（Serverless Pattern）
無_SERVER模式是一種事件驅動架構模式，涉及使用無伺服器（Serverless）技術來實作系統。這種模式通常用於需要高可擴充套件性和低成本的系統中。無_SERVER模式的優點包括：
- 高可擴充套件性：無_SERVER模式允許系統自動擴充套件和收縮，從而提高了系統的可擴充套件性和可靠性。
- 低成本：無_SERVER模式可以降低系統的成本，因為無伺服器技術可以自動管理和最佳化資源。
然而，無_SERVER模式也有一些缺點，例如：
- 限制：無_SERVER模式可能有限制，因為無伺服器技術可能不支援所有的功能和特性。
- 複雜性：無_SERVER模式可能導致系統的複雜性增加，因為無伺服器技術可能需要額外的組態和管理。
內容解密
在上述內容中，我們探討了事件驅動架構中的三種常見模式：編舞、管絃樂和無_SERVER。每種模式都有其優點和缺點，開發人員需要根據具體需求選擇合適的模式。下面是每種模式的詳細解說：
- 編舞模式：編舞模式涉及多個服務之間的協調和溝通。這種模式通常用於需要多個服務之間進行複雜互動的系統中。編舞模式的優點包括低耦合度和高靈活性，但也可能導致系統的複雜性增加。
- 管絃樂模式：管絃樂模式涉及一個中央的協調器來管理和協調多個服務之間的互動。這種模式通常用於需要一個中央的控制點來管理和協調多個服務的系統中。管絃樂模式的優點包括高控制度和低複雜性，但也可能導致單點故障和效能瓶頸。
- 無_SERVER模式：無_SERVER模式涉及使用無伺服器技術來實作系統。這種模式通常用於需要高可擴充套件性和低成本的系統中。無_SERVER模式的優點包括高可擴充套件性和低成本，但也可能有限制和增加系統的複雜性。
圖表翻譯
下面是事件驅動架構中的三種常見模式的Mermaid圖表：
flowchart TD
A[編舞] --> B[管絃樂]
B --> C[無_SERVER]
C --> D[事件驅動架構]
D --> E[高可擴充套件性]
E --> F[低耦合度]
F --> G[高靈活性]
這個圖表展示了事件驅動架構中的三種常見模式之間的關係，以及每種模式的優點。
伺服器無法使用的資料處理流程
在一個運作正常的組織中，通常會有多個跨越不同領域、部門和團隊的資料流和資料處理流程。其中許多流程對於維持關鍵應用程式的運作至關重要。在將現有的傳統系統遷移到無伺服器架構時，需要一個周密規劃和協調的方法來轉移這些流程。
資料分享模式
圖 5-4 展示了一個常見的資料分享模式，其中多個傳統應用程式透過檔案傳輸協定從網路檔案夾中取得資料檔案。
圖表翻譯：
此圖示的是一個傳統的資料分享系統，資料檔案存放在網路檔案夾中，由應用程式在需要時透過檔案傳輸協定取得。
遷移目標架構
在開始遷移此類別系統之前，必須先建立一個遷移後的目標架構。圖 5-5 顯示了目標架構，其中包含了新實作的無伺服器微服務和既有的內部或外部應用程式。
圖表翻譯：
此圖示的是目標的無伺服器架構，其中包含了新實作的微服務和既有的應用程式。
資料流遷移
圖 5-6 顯示了新的資料流遷移過程，目的是逐漸減少傳統資料流進入不同網路檔案夾的數量，而是使用無伺服器架構中的 S3 產品資料儲存桶。根據傳統系統的能力，可能需要一個中間階段來完成遷移。
圖表翻譯：
此圖示的是資料流遷移的第一階段，目的是將新的產品資料流重新導向傳統品牌系統（假設它有 API 可以從 Lambda 函式接收資料）。
API 路由遷移
API 路由遷移策略與資料流遷移策略相似，涉及將現有的傳統應用程式的一部分功能替換為新的無伺服器版本，並逐漸將流量從舊端點轉移到新端點。在此過程中，同時執行舊有和新端點，以便觀察和改進新的服務，直到完全取代舊有的。
API 閘道和 BFF 模式
在遷移傳統單體應用程式到無伺服器架構時，需要一個層作為「交換板」來路由傳入請求到正確的後端端點。API 閘道和 BFF 模式是兩種常見的實作方式，可以提供一個外觀層來實作此功能。
圖表翻譯：
API 閘道可以作為外觀層，路由請求到舊有的和新的端點。BFF 模式則提供了一種管理路由到後端服務的方式，允許平行執行舊有和遷移後的應用程式。
儲存優先模式
儲存優先模式是一種新的模式，其主要概念是先儲存資料，然後再進行處理。在事件驅動架構中，當您處理請求時，需要確保不會丟失資料。使用儲存優先模式，您可以先將入站資料儲存到 SQS 佇列、Kinesis 流、S3 儲存桶或 DynamoDB 表中，然後再啟動計算部分。
圖表翻譯：
此圖示的是儲存優先模式的概念，強調先儲存資料，然後再進行處理，以確保不會丟失重要資料。
韌性架構：斷路器模式
斷路器模式是軟體工程中最重要和最廣泛採用的架構模式之一，在分散式服務環境中對於構建韌性和高用性的應用程式至關重要。斷路器模式的概念來自於電氣開關，可以手動或自動開啟電路，以保護電氣電路免受過載或中斷的影響。
圖表翻譯：
斷路器模式在無伺服器架構中尤其重要，因為它可以幫助保護應用程式免受網路問題、排程停機或意外中斷等問題的影響。
無伺服器架構的興起正推動著企業IT架構的變革。本文深入探討了無伺服器架構在安全性、文化建設、資料處理流程以及韌性設計等方面的關鍵議題。分析顯示，無伺服器架構雖具備諸多優勢，如高可擴充套件性和低成本，但在安全性管理、團隊文化建設以及傳統系統遷移等方面仍面臨挑戰。尤其在資料遷移過程中，需要仔細規劃目標架構和逐步遷移的策略，例如採用API閘道和BFF模式等。同時，儲存優先和斷路器模式等設計對於確保系統的可靠性和韌性至關重要。技術限制深析指出，軟體工程師的安全意識和專業知識仍然是確保無伺服器應用程式安全的重要因素。從技術演進預測來看，無伺服器技術將持續發展，更多成熟的工具和最佳實踐將不斷湧現，進一步降低應用門檻並拓展應用場景。玄貓認為，企業應積極探索無伺服器架構的潛力，同時注重安全性和文化建設，才能充分發揮其優勢，在競爭激烈的市場中保持領先地位。
