事件源架構的核心概念是將所有系統狀態變化以事件的形式記錄下來，並以此重建系統狀態。這使得系統具備高度的可追溯性和稽核能力，也能夠支援更精細的資料分析。在無伺服器環境中，事件源架構更能發揮其優勢，透過事件驅動的機制，實作微服務之間的鬆散耦合和彈性擴充套件。資料函式庫遷移方面，從傳統單體應用到雲原生架構，需要考慮重新託管、重新平臺化和重構等策略，並根據資料特性選擇合適的資料函式庫服務，例如關係型資料函式庫或 NoSQL 資料函式庫。非同步通訊和事件驅動架構的結合，可以提升系統的容錯性和可擴充套件性，避免緊密耦合帶來的級聯故障風險。
個人資料管理系統的應用
個人資料管理系統在各個領域都有廣泛的應用，例如：
- 企業：企業可以使用個人資料管理系統來管理員工、客戶和供應商的資料。
- 政府：政府可以使用個人資料管理系統來管理公民、企業和組織的資料。
- 教育：教育機構可以使用個人資料管理系統來管理學生、教師和員工的資料。
- 醫療：醫療機構可以使用個人資料管理系統來管理病人的資料。
內容解密：
以上內容對於個人資料管理系統進行了詳細的介紹，包括其核心部分、使用者介面、查詢功能和安全機制等。同時，也提到了個人資料管理系統的優點、應用領域和結論。以下是一個簡單的範例程式碼，示範如何使用Python實作一個基本的個人資料管理系統：
import pandas as pd
# 建立一個DataFrame來儲存個人資料
df = pd.DataFrame({
'ID': [100, 101, 102],
'Name': ['Joe', 'Biz', 'John'],
'Address': ['Edge Lane', 'Top Street', 'Fine Way'],
'DOB': ['1966/04/12', '1995/06/15', '1970/01/01']
})
# 定義一個函式來查詢個人資料
def query_data(df, name):
return df[df['Name'] == name]
# 查詢Joe的個人資料
print(query_data(df, 'Joe'))
圖表翻譯：
以下是一個Mermaid圖表，示範個人資料管理系統的基本架構：
flowchart TD
A[使用者介面] --> B[查詢功能]
B --> C[安全機制]
C --> D[資料函式庫]
D --> E[資料儲存]
E --> F[資料查詢]
F --> G[資料更新]
G --> H[資料刪除]
此圖表展示了個人資料管理系統的基本流程，從使用者介面到查詢功能、安全機制、資料函式庫、資料儲存、資料查詢、資料更新和資料刪除等。
事件來源的應用
事件來源（Event Sourcing）是一種軟體設計模式，最初的目的是重建實體的當前狀態。然而，現代的實作已經擴充套件到更多的用途，包括：
重建使用者會話活動
在分散式事件驅動系統中，許多應用程式會捕捉使用者互動的時間盒會話。會話通常從使用者登入應用程式開始，直到使用者登出或會話過期。事件來源在這裡非常有價值，因為它可以幫助使用者從他們離開的地方還原，或解決任何查詢或爭議，因為系統可以繪製每個使用者的旅程。
啟用稽核追蹤
在某些情況下，企業可能無法充分利用日誌來追蹤系統行為、客戶活動、財務資料流等詳細資訊。這是因為企業需要遵守資料隱私政策，防止敏感資料和個人可識別資訊（PII）被傳送到日誌中。使用事件來源，資料儲存在受保護的雲帳戶中，團隊可以建立工具從事件儲存中重建資料流。
執行資料分析以取得洞察
事件來源還可以用於執行資料分析，以便更深入地瞭解系統行為、使用者行為和業務流程。透過分析事件儲存中的資料，企業可以獲得有關其營運的寶貴洞察，從而做出更好的決策。
內容解密：
上述內容介紹了事件來源的三種主要應用：重建使用者會話活動、啟用稽核追蹤和執行資料分析。這些應用展示了事件來源的多功能性和強大功能，讓企業能夠更好地管理其資料和系統。
flowchart TD
A[事件來源] --> B[重建使用者會話活動]
A --> C[啟用稽核追蹤]
A --> D[執行資料分析]
B --> E[還原使用者會話]
C --> F[重建資料流]
D --> G[取得洞察]
圖表翻譯：
此圖表展示了事件來源的三種主要應用：重建使用者會話活動、啟用稽核追蹤和執行資料分析。每個應用都與事件來源相關聯，並展示了它們如何幫助企業管理其資料和系統。圖表還展示了每個應用的具體功能，例如還原使用者會話、重建資料流和取得洞察。
事件源與事件驅動架構
在現代數位化商業世界中，資料是驅動許多決策的關鍵因素。事件源（Event Sourcing）使得我們能夠在更細緻的層次上獲得更深入的洞察和分析。例如，在一個假期預訂系統中，事件儲存函式庫會收集來自多個微服務的所有業務事件，這些微服務協同工作以幫助顧客預訂假期。顧客通常會花費時間瀏覽多個目的地、優惠和可定製選項等，然後才完成預訂或在某些情況下放棄預訂。這些過程中發生的事件包含了可以用於識別熱門（和不熱門）目的地、套餐和優惠的線索。
事件源的概念
自從事件源的概念出現以來，由於雲端和管理服務的出現，捕捉和儲存的資料量以及可用的攝取機制和儲存選項都發生了巨大的變化。許多現代應用程式的資料模型都能夠儲存某段時間內的變化歷史，以便快速追蹤所有活動。
事件源的架構考量
在高層次上，事件源的概念很簡單，但其實作需要仔細的規劃。當分散式微服務共同執行業務功能時，您會面臨著處理不同類別和型別的數百個事件的挑戰。在這種情況下，您需要考慮以下問題：
- 如何確定哪些事件需要儲存到事件儲存函式庫中？
- 如何收集所有相關事件並將其放在同一個地方？
- 您是否應該為每個微服務、有界上下文、應用程式、域或企業維護一個單獨的事件儲存函式庫？
- 如何處理加密和敏感資料？
- 您應該在事件儲存函式庫中保留事件多久？
實作事件源
有幾種方法可以實作事件源：
- 專用微服務：您可以建立一個專門負責事件源的微服務，該微服務會管理規則以攝取所需的事件，執行必要的資料轉換，擁有一個或多個事件儲存函式庫，並管理資料保留和過渡策略等任務。
- 有界上下文級別的事件儲存函式庫：一個明確定義的有界上下文可以從擁有自己的事件儲存函式庫中受益，這對於稽核目的或重構導致應用程式或特定業務實體當前狀態的事件很有幫助。
- 應用程式級別的事件儲存函式庫：許多應用程式每天都會與多個分散式服務協調。例如，電子商務域具有多個子域和有界上下文，每個有界上下文都可以成功實作自己的事件源功能。
- 集中式事件源雲端帳戶：這是一種更先進的方法，涉及將所有事件流式傳輸到一個集中雲端帳戶中，以便進行安全稽核、合規性檢查和業務分析。
事件風暴
事件風暴是一種合作活動，可以幫助解決軟體工程中的經典問題，即平衡需求和實作。它是一種非技術性工作坊格式，將業務和技術人員聚集在一起討論、集思廣益、頭腦風暴和建模業務流程或分析問題域。事件風暴的兩個關鍵元素是域專家（貢獻者）和域事件（結果）。
事件風暴在無伺服器開發中的重要性
事件風暴是一種有效的合作和學習商業需求、識別域事件、塑造模型的方法，同時也能在考慮架構和解決方案設計之前進行。然而，根據域或產品的規模，事件風暴的結果可能是高層次的。在一個組織將其製造部門的IT營運轉型為無伺服器架構的例子中，事件風暴將會聚集多個域專家、商業利益相關者、企業和解決方案架構師、工程負責人和工程師、產品經理、UX設計師、QA工程師、測試專家等。經過幾天的合作後，您將會識別出各種商業流程、域事件、模型實體和多個有界上下文等。當您對整個域有了清晰的理解後，您就可以開始分配所有權——流對齊團隊——給有界上下文。
這些團隊隨後會深入到每個有界上下文中，以識別網頁應用程式、微服務、API、事件和架構構建塊等。雖然域級別事件風暴會議產生的文物形成了一個基礎，但無伺服器團隊需要更細緻的詳細資訊。因此，在無伺服器開發中，如果您採用兩階段的事件風暴將會很有幫助：
域級別事件風暴
根據Brandolini的說法，這是一個「大局觀」的事件風暴工作坊，旨在識別商業流程、域事件、命令、角色、集合體等。
開發級別事件風暴
這是一個更小規模的活動，涉及工程團隊、其商業利益相關者、產品經理和UX設計師。這與Brandolini所謂的「設計級別事件風暴」類別似。
在這裡，焦點放在有界上下文及其內部的開發上。團隊會識別內部流程、區域性事件和功能與責任的分離。這些成為微服務、其介面和事件互動作用的早期草圖。開發級別事件風暴的結果將會餵入解決方案設計過程（在第6章中將會解釋），當工程師開始思考無伺服器架構時。
讓我們考慮一個開發級別事件風暴的例子情況：
- 背景：圖2-3（在「域優先」第40頁中）展示了電子商務域的分解。一個域級別事件風暴工作坊已經識別了子域和有界上下文。一個流對齊團隊擁有使用者支付有界上下文。
- 使用案例：由於客戶需求和為了防止詐騙，利益相關者希望新增一個新功能，允許客戶透過電話呼叫客戶支援中心下單時，可以透過電子郵件傳送給他們的一個安全連結來進行支付，而不是在電話中提供信用卡號碼。
提出的新功能只需要電子商務團隊的一部分成員參與開發級別的事件風暴會議。這是一個小規模的活動，僅在有界上下文內進行，參與者較少。
摘要
您剛剛完成了本文中關於無伺服器開發的一個非常重要的章節。您在這裡學到的架構思想、最佳實踐和建議對於您是否作為獨立顧問或大型企業的一部分工作都是非常重要的。不論組織規模如何，您的目標是根據無伺服器的優點來架構解決方案。商業需求和問題域可能很複雜且難以理解，這在其他領域和生活中也是如此。您可以觀察並學習如何成功解決非軟體問題，並將這些原則應用於您的工作中。
無伺服器架構不需要是一個複雜而纏結的線網，遍佈您的整個組織。您的願景是架構單一用途、鬆散耦合、分散式和根據事件驅動的微服務作為易於構思、開發、營運、觀察和演化的獨立元件，位於組織的無伺服器技術生態系統中。
您將會帶著這些初始章節中的知識繼續閱讀本文的其餘部分。在第5章中，您將學習一些核心實作模式在無伺服器開發中。但是在那之前，下一章將深入探討軟體開發中的一個基本且關鍵話題：安全性。
專家訪談
Matt Lewis，IBM英國首席AWS架構師，AWS資料英雄 Matt是AWS資料英雄，並持有多個AWS認證。他在IBM英國擔任首席AWS架構師，負責發展AWS能力並確保客戶充分利用AWS服務以實作其成果並提供商業價值。之前，他曾在英國中央政府機構擔任首席架構師，在那裡他引入了無伺服器技術，成功處理每月數十億次請求。他創辦並營運AWS南威爾士使用者組，並是ServerlessDays Cardiff的組織者。
Q：Matt，您曾在公共和私營部門組織中工作過，設計高度關鍵系統。在這些組織之間，有技術和架構決策過程的根本轉變嗎？ 我不相信技術和架構決策過程之間存在根本轉變。相反，我認為差異與組織的底層文化相關，例如風險承受能力、雲營運模式以及工程產品團隊的自主權水平。
當這些組織遷移到雲端時，它們需要適應許多現有的流程。隨著它們沿著成熟度模型前進，它們採用新技術和快速架構決策的意願增加。這是因為DevSecOps等實踐以及透過服務控制策略等護欄強制執行控制，使變更可以以安全和受控的方式應用。
我相信我們將會看到更多組織在設計高度關鍵系統時採用無伺服器技術。英國國家網路安全中心指出，採用無伺服器元件使事情變得更容易，因為它將更多分享責任模型轉移到雲提供商身上。這意味著您可以專注於提供商業價值，而讓雲提供商管理重要功能，如補丁、擴充套件、高用性和還原力。
Q：當你在DVLA（駕駛員和車輛登記機構）工作時，我（Sheen）向一組開發人員和長官人發表了一場關於無伺服器優點和行業案例研究的演講。你如何看待這樣的會話對公共部門環境中的技術採用的影響？ 我非常相信社群和這類別會話的價值。我絕對鼓勵大家找到當地聚會群組並成為社群的一部分。一個人帶給組織的價值不僅僅是他們個人所知道的，而且還包括他們的網路。技術正在非常快速地演變，新的功能、服務、模式和最佳實踐層出不窮。一個人不可能跟上所有東西。此外，在組織內工作時，您可能只關注正在交付的內容範圍。
從公共部門的角度來看，提供的數字服務是我們作為公民所互動的服務。我們期望獲得與主要電子商務站點相同的使用者經驗。聽取私營和公共部門專家的意見並瞭解什麼有效以及如果重新開始會做什麼不同是非常重要的。這是我熱衷的事情，因為它會導致更高品質的服務以更低的成本點提供，並最終為納稅人提供更好的價值。
Q：作為AWS資料英雄，您具有使用AWS上的各種資料和儲存服務的經驗。在眾多DBaaS選項可用時，您會如何建議組織遷移其傳統單體應用程式，這些應用程式嚴重依賴於關聯式資料函式庫系統來處理結構化資料？ 在檢視遷移應用程式到公有雲時，我總是從“7 Rs”開始，這是一種行業方法，概述了七種最常見的遷移策略。對於遷移傳統單體應用程式，這些應用程式依賴於關聯式資料函式倉管理系統（RDBMS），最流行的三種策略是重新託管、重新平臺化和重構。
重新託管應用程式通常是最快的方式來遷移到雲端，但結果是總擁有成本最高。這通常是旅程中的第一步，以便在應用程式被最佳化以利用雲能力之前廢棄資料中心或內部伺服器。
重新平臺化應用程式允許您重塑它。主要機會包括遷移到開源或AWS雲原生資料函式庫引擎，並採用Amazon RDS或Amazon Aurora等受管理的資料函式庫服務。這樣，雲提供商負責像伺服器組態、補丁、自動備份和還原等行政任務，您可以利用連續監控、自我修復儲存和擴充套件等功能。您可以使用AWS Schema Conversion Tool（SCT）和Database Migration Service（DMS）工具來幫助遷移資料。
重構涉及重新架構應用程式，通常是在一段時間內分階段進行。行業正在向微服務轉變，涉及將傳統單體應用程式拆分為較小的微服務，這使得相關資料可以被拆分。當您拆分單體應用程式時，您可以檢視NoSQL替代方案，以滿足特定資料域的需求，這可能更合適並提供更多優勢。AWS提供了一系列專用資料函式庫，其中許多提供無伺服器版本。
亞馬遜自己已經將其消費者業務中的所有資料從Oracle遷移到各種AWS資料函式庫服務，包括Amazon DynamoDB、Amazon RDS、Amazon Aurora和Amazon Redshift。
Q：您在AWS re:Invent 2022期間聽到Werner提到了非同步性和根據事件驅動架構在其演講中的重要性。你為什麼認為這兩個是建構無伺服器應用程式的一些核心架構原則？ 如今提供的服務需要適應周圍環境的變化。使用同步請求/回應通訊建構的應用程式最終變得脆弱，並引入緊密耦合。某個元件中的問題，如錯誤率或延遲，可以導致級聯故障，而且引入新功能很困難。
非同步性和根據事件驅動架構是建構現代雲原生無伺服器應用程式的一些核心原則。其中關鍵的是解耦生產者和事件消費者。這為無伺服器應用程式帶來了許多好處，如：
graph LR
A[事件生產者] -->|傳送事件|> B[訊息佇列]
B -->|觸發|> C[微服務1]
C -->|處理|> D[資料函式庫]
D -->|儲存|> E[結果]
E -->|傳回|> F[微服務2]
F -->|觸發|> G[其他微服務]
圖表翻譯：
此圖示非同步性和根據事件驅動架構在無伺服器應用程式中的運作過程。事件生產者傳送事件到訊息佇列，觸發微服務1進行處理，微服務1再與資料函式庫互動儲存結果，最終傳回結果給微服務2，並觸發其他微服務繼續處理。這樣可以實作解耦生產者和消費者，提高系統的靈活性和可擴充套件性。
內容解密：
非同步性和根據事件驅動架構是無伺服器應用程式中的重要概念，它們使得系統可以更好地適應變化，並提高系統的可靠性和可擴充套件性。在實踐中，我們可以使用訊息佇列等技術來實作非同步通訊，並利用微服務架構來解耦系統中的各個元件，使得系統更容易維護和擴充套件。
個人資料管理系統、事件來源和無伺服器架構的應用都體現了資料在現代商業中的核心地位。分析這些技術的整合價值，我們發現它們共同解決了資料的取得、儲存、處理和分析等關鍵環節。個人資料管理系統著重於資料的組織和存取，事件來源則提供了更細粒度的資料追蹤和稽核能力，而無伺服器架構則為這些系統提供了彈性、可擴充套件且經濟高效的執行環境。然而，這些技術也面臨一些挑戰，例如資料隱私和安全、系統整合的複雜性以及技術團隊的技能缺口。對於重視資料價值的企業，建議採用分階段的整合策略，先從核心業務流程開始匯入，逐步擴充套件應用範圍，同時注重團隊的技術培訓和能力提升。展望未來，隨著資料驅動決策的重要性日益凸顯，預計這些技術的融合將更加緊密，形成一個更完整、更高效的資料管理和應用生態系統。玄貓認為，掌握這些技術的應用和整合，將成為企業在未來競爭中脫穎而出的關鍵。
