近年來，計算領域的各種趨勢已經浮出水面：大資料、容器、無伺服器應用程式、微服務和事件驅動架構(eda)。相比單體應用，事件驅動架構讓企業可以更快建立更易於管理的可伸縮解決方案，所以越來越受歡迎。
越來越多的企業正在意識到，隨著系統必須處理的資料呈指數級增長，傳統的rdbms無法處理這麼大的資料量，資訊的處理需要長時間執行的基於批處理的etl來提取業務洞察力。批處理操作用於資料倉儲當然沒有什麼問題，但是實時洞察力的需求對於實現企業想要的結果至關重要。
n層架構示例
在20世紀中期，n層架構大行其道。企業大多會構建由rdbms支援的單體應用**庫，所有crud都是針對rdbms執行的。但應用程式越來越複雜，它們的依賴關係圖譜實際上是不可能理解的。又或者，拼湊了那麼多點對點的整合，從而建立了乙個脆弱的解決方案。沒有人會責怪軟體工程師，畢竟，物件導向程式設計(object-oriented programming，oop)鼓勵**重用，而在當時，確實只需要服務x來與服務y對話即可。這很糟糕。
很多企業正開始從單體架構遷移到微服務架構。業務邏輯及相關服務與事件處理器的分離降低了架構的複雜性。服務可以單獨開發和部署，不必知道其他服務的存在。微服務架構需要從系統的角度來促進服務間通訊。在我看來，為此進行一些初始投資是值得的。
本質上，事件驅動架構促成了去中心化的平台。服務甚至不必駐留在同乙個系統或資料中心，也不必由同乙個組織所擁有。如果校車系統需要額外的巴士，例如，由於校外活動在不同的學區舉行，校車系統可以要求乙個或多個系統提供額外的巴士，以應付額外的負荷。這種靈活性允許系統按需擴充套件和收縮。
對於eda來說，吞吐量和延遲是兩個重要的效能指標。延遲越大，吞吐量就越低。有兩個選項可以持續提高系統的效能：通過優化**或配置來減少延遲，或者通過新增額外的資源來提高吞吐量。
在度量效能時，我建議您的團隊為平台中的每個服務定義服務水平目標(service level objects，slo)和服務水平指示器(service level indicator，sli)。我們採用了這種方法，它不僅允許我們監視和評估我們在生產環境中的成功之處，而且它為我們在發布新特性之前分析基準和效能測試結果提供了乙個指南。
我從構建可伸縮平台中學到的最重要的一件事，那就是每毫秒都很重要。1ms的延遲在低資料量的情況下也許無關緊要，但在處理百萬條訊息時，每條訊息增加1ms的延遲，處理時間就增加了15分鐘，如果是10億條訊息的話，處理時間就會增加277個小時。
每毫秒都很重要。在10億條訊息中增加1毫秒的處理時間將使處理時間增加277個小時。
以下是根據我的經驗提出的一些建議：
「當你拿著乙個錘子,所有問題看起來都像釘子。」
本質上，事件驅動架構並不是適用所有應用程式的正確模式。恰恰相反，這種模式本身就帶來了複雜性。
不要成為錘子綜合症的受害者。
如果你本來只需要一把螺絲刀時，edas很可能是解決你問題的錘子。在決定這是否是正確的解決方案時，要考慮開發和維護的成本。
在考慮解決方案所需的複雜性以及是否值得進行投資時，請確定已經了解如何處理以下問題：
1、服務抽象的正確級別是什麼？
2、您的事件訊息是schema還是schema-less的？
譯註：
在sql環境下，schema就是資料庫物件的集合，所謂的資料庫物件也就是常說的表，索引，檢視，儲存過程等。
簡單來說，在schemaless資料的基本單位被命名為單元（cell）。它是不可變的，一旦寫入，便無法被覆蓋。（在特殊情況下，我們可以刪除舊記錄）；單元可以被行鍵（row key）、列名（column name）和引用鍵（ref key）來引用；單元內容通過編寫引用鍵更高的新版來執行更新，但行鍵和列名保持不變。schemaless不對其中儲存的資料執行任何操作，故而命名schemaless。
3、您的系統如何處理由壞的或有衝突的資料以及服務或佇列的降級所造成的故障？
4、如何處理鄰域雜訊問題?
譯註：
雲是乙個多租戶環境，這意味著乙個單一的體系結構承載了多個客戶的應用程式和資料。當應用程式或虛擬機器使用大多數可用資源並給共享基礎設施上的其他人造成網路效能問題時，就會產生鄰域雜訊問題。
5、您將如何除錯和理解系統中的事件流？
6、如何處理非冪等事件？
譯註：
乙個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。
7、您的系統將如何處理迴圈預防和檢測？
8、您的系統將如何處理分布式事務的回滾？
總而言之，edas是：
在下列情況下考慮使用eda：
原文發布時間為：2018-11-20
bootstrap 柵格系統 理解與總結
最近需要寫乙個既適應pc端 又適應手機端 最重要的是還要支援手機橫屏 所以用到了布局神器 bootstrap 柵格系統 先放效果圖 pc端 然後 我的需要適應pc 手機 以及橫屏，所以類名這裡是這樣寫的 響應式網格系統隨著螢幕或視口 viewport 尺寸的增加，系統會自動分為最多12列。row 解...
linux作業系統理解 IPC
ipc指程序間通訊方式，注意不是執行緒間，執行緒之間同步只有訊號量和互斥量 1.管道pipe shell的管道就是這個原理 程序管道 popen pclose函式 1.2命名管道fifo，是一種特殊的檔案，在檔案系統中以檔案的形式存在 2.訊號量 備註 學習多程序的同步與互斥，和多線的同步與互斥時，...
作業系統 理解訊號量
訊號量是一種常用的併發機制。基本原理 兩個或多個程序可以通過簡單的訊號合作，可以強迫乙個程序在某個位置停止，直到它接收到乙個特定的訊號。任何複雜的合作都可以通過適當的訊號結構得到滿足。為了發訊號，需要使用到乙個訊號量的特殊變數。要通過訊號量s傳送訊號，程序必須執行semsignal s v操作 要通...