㈠ 為什麼需要資料庫審計產品
從安華金和一次直播里了解到，資料庫審計產品可以協助完成安全合規建設，因為《網路安全法》國家實行網路安全等級保護制度。網路運營者應當按照網路安全等級保護制度的要求，履行下列安全保護義務，保障網路免受干擾、破壞或者未經授權的訪問，防止網路數據泄露或者被竊取、篡改：
（一）制定內部安全管理制度和操作規程，確定網路安全負責人，落實網路安全保護責任；
（二）採取防範計算機病毒和網路攻擊、網路侵入等危害網路安全行為的技術措施；
（三）採取監測、記錄網路運行狀態、網路安全事件的技術措施，並按照規定留存相關的網路日誌不少於六個月；
（四）採取數據分類、重要數據備份和加密等措施；
（五）法律、行政法規規定的其他義務。
而安華金和資料庫審計產品確保網路日誌保留6個月以上；
實時監測訪問資料庫行為：全面實時監測訪問資料庫行為並做記錄，並提供實時風險告警，可以減少或者避免數據泄露事件的發生；
事件溯源：幫助用戶快速定位異常點和異常行為，如果真的發生數據泄露事件，至少可以溯源，知道這次事件的源頭，了解原因，採取進一步防護措施；
性能評估：實時對資料庫運行狀態監控，可以實時了解資料庫狀況。
安華金和資料庫審計產品是基於資料庫通訊協議分析和SQL解析技術進行的，在精準度上在國內是領先的。
㈡ 事件存儲是什麼意思
事件存儲：存儲所有聚合根裡面發生過的事件。 1.事件存儲中可以做並發的處理，比如Command 重復，領域事件的重復 2.領域事件的重復通過聚合根Id+版本號判斷，可以在資料庫中建立聯合唯一索引，在存儲事件時檢測重復，記錄重復的事件，根據業務做處理 3.這里要保證存儲事件與發布領域事件的一致性 如何保證存儲事件與發布領域事件的一致性 先存儲事件然後在發布領域事件，如果發生異常，就一直重試，一直到成功為止，也可以做一定的處理，比如重試到一定的次數，就通知，進行人工處理 我選擇了CAP + Policy + Dapper 事件溯源：在事件存儲中記錄導致狀態變化的一系列領域事件。通過持久化記錄改變狀態的事件，通過重新播放獲得狀態改變的歷史。 事件回放可以返回系統到任何狀態 聚合快照：聚合的生命周期各有長短，有的聚合裡面有大量的事件，事件越多載入事件以及重建聚合的執行效率就會越來越低，快照裡面存儲的是聚合 1.定時存儲整個聚合根：使用定時器每隔一段時間就存儲聚合到快照表中 2.定量存儲整個聚合根：根據事件存儲中的數量來存儲聚合到快照表中事件溯源的實現方式 1.首先我們需要實現聚合In Memory， 2.在CommandHandler中訂閱 Command命令， 創建聚合時 ，在內存中維護一個數據字典，key為：聚合根的Id，value為：聚合 修改，刪除，聚合時，根據聚合根的Id，查詢出聚合 如果內存中聚合不存在時：根據聚合根的Id 從聚合快照表中查詢出聚合，然後根據聚合快照存儲的時間，聚合根Id，查詢事件存儲中的所有事件，然後回放事件，得到聚合最終的狀態。
㈢ 為什麼說資料庫審計是是資料庫安全行業的核心產品
推薦你與安華金和溝通下，我先簡單說下我的想法，資料庫審計產品是目前安全產品較為成熟的產品，適用於政府、金融、能源、醫療、教育、企業、運營商等行業，應用場景也非常多，符合安全合規要求，安全合規是資料庫審計的重要應用場景，也是目前很多用戶選擇資料庫審計產品的重要原因。《網路安全法》第二十一條中，明確要求：「採取監測、記錄網路運行狀態、網路安全事件的技術措施，並留存網路日誌不少於六個月」。另在等保2.0等國家規定中對於數據審計也有明確的要求。目前市面上大多資料庫審計產品一般都可以滿足國家法律法規和行業政策的要求。
實時掌握資料庫運行狀況，也有一些資料庫審計產品可以提供實時的資料庫運行狀態監控：例如針對資料庫訪問流量、並發吞吐量、解析語句量、語句歸類模板量、SQL語句的響應速度進行專項的界面分析；可針對失敗SQL語句、語句量執行最多、語句訪問最慢的語句進行發現和排列，提供專業的性能診斷分析，幫助用戶了解資料庫的運行狀況並及時優化資料庫性能。
及時發現各類數據操作違規事件或攻擊事件，這是資料庫審計產品的一個重要應用場景：提供資料庫風險告警能力，產品可以基於靈活的策略配置設置風險規則，對於外部發起的資料庫漏洞攻擊、惡意的SQL注入行為、非法的業務登錄、高危的SQL操作和批量的數據下載，提供實時的風險告警。告警方式一般包括企業微信、簡訊、郵件、SNMP、Syslog等。
數據違規事件溯源，這是資料庫審計產品的一個基本應用場景：基於精確資料庫協議分析、完全SQL解析、參數化匹配等技術，對資料庫訪問行為進行周期性對比，幫助用戶快速定位異常點和異常行為，通過提供全量的資料庫行為記錄、全局檢索能力，可以深度關聯並展示會話和語句詳情，根據訪問來源實現資料庫的關聯查詢和關聯分析，使資料庫的訪問行為有效定位到具體業務工作人員，幫助用戶追溯風險來源。所以說審計產品是數據安全必不可少的一款溯源產品。安華金和資料庫審計產品，是一款基於資料庫通訊協議分析和SQL解析技術的產品，網路也查得到的。
㈣ 什麼是事件溯源
一個對象從創建開始到消亡會經歷很多事件，以前我們是在每次對象參與完一個業務動作後把對象的最新狀態持久化保存到資料庫中，也就是說我們的資料庫中的數據是反映了對象的當前最新的狀態。而事件溯源則相反，不是保存對象的最新狀態，而是保存這個對象所經歷的每個事件，所有的由對象產生的事件會按照時間先後順序有序的存放在資料庫中。可以看出，事件溯源的這種做法是更符合事實觀的，因為它完整的描述了對象的整個生命周期過程中所經歷的所有事件。
㈤ 使用資料庫安全審計設備的好處有哪些
安華金和資料庫審計系統能給用戶帶來的好處有如下幾點：
1、協助用戶完成安全合規建設，安華金和資料庫審計系統通過全面行為審計、數據操作監控、風險事件告警、行為分析建模、審計記錄留存、專項合規報表等功能特性，協助用戶完成安全合規建設
2、協助用戶實時感知風險、了解安全狀況，安華金和資料庫審計系統通過對登錄異常、操作異常、數據異動異常、漏洞攻擊、SQL注入等監測，以及事中異常行為告警，第一時間協助用戶實時感知風險、了解安全狀況，及時止損，使損失降到最低。
3、為數據泄漏追溯、分析、定責提供支撐，安華金和資料庫審計系統通過會話回放、行為軌跡圖等檢索查詢能力能夠有效進行事件追溯；通過登錄行為分析、訪問行為分析、數據使用等行為分析，有效對所有資料庫操作訪問行文進行統計分析；對訪問源身份、應用身份的識別，形成完整證據鏈條有效進行責任認定，從而為數據泄漏追溯、分析、定責提供支撐。
4、幫助企業及時發現生產過程數據異動，減少損失，安華金和資料庫審計系統通過配置敏感數據訪問規則來定義數據使用規范；通過實時監控告警，使用戶第一時間發現異常使用行為；通過事件多角度關聯分析，分析異常產生過程，來定位數據使用問題，使用戶及時處置高危操作風險，減少損失。
5、幫助用戶輔助進行性能分析評估，優化業務系統
6、安華金和資料庫審計系統具有失敗SQL分析能力，能夠真實呈現資料庫對失敗SQL應答信息，便於分析語句正確性及合理性；具有SQL耗時統計能力，能夠記錄SQL執行時長及結果集返回時長，輔助定位性能問題，找出需要優化的語句；具有TOP SQL分析能夠能力，提供最多執行次數語句統計及執行耗時最長SQL統計，便於快速定位問題，從而幫助用戶輔助進行性能分析評估，優化業務系統。
㈥ 為什麼 MySQL 使用多線程，而 Oracle 和 PostgreSQL 使用多進程
.NET平台很棒。真的很棒。直到它不再那麼棒。我為什麼不再用.NET？簡單來說，它限制了我們選擇的能力(對我來說很重要)，轉移了我們的注意力，使得我們向內認知它的安全性，替代了幫助我們認知外面廣闊世界的所有可能性。[系好安全帶：這個文章的長度幾乎成了一本書…]優點首先讓我開始說說.NET做得對的許多事吧，盡管這其中的大多數並不來自.NET本身，但卻是由.NET社區而來。C#C#令人驚嘆。我認為它是一個令人驚嘆的編程語言。從強大的C語言背景而來，我徹底地喜歡其語法，流和這門語言的所帶來的感覺。當然有我可能改變的事，但總體來說它是一門扎實的語言。並且基於開發人員使用的編程語言如此巨額的百分比和Windows操作系統的優越性，它是一門眾所周知的語言。ReSharper我也很喜歡Resharper。在JetBrains工作的開發者們都是奇跡般的人。如果沒有ReSharper和一些相關的工具，我可能並不會如此喜歡C#。BDDandMSpec我也很喜歡簡稱為機器規格(mspec)的BDD風格的框架。它是一個令人驚嘆的測試框架，真正支持在測試中使用正確的語言測試本身。在使用mspec之前，我的測試真是一團糟並且很礙我的事。另外，當我們創建GoConvey—基於Golang的BDD測試框架的時候，Mspec對於我的組織來說是一個巨大的靈感和激勵。多語言運行時我認為多語言的CLR(公共語言運行時)的觀念真得使得JVM的世界思考著。我不知道任何非Java的JVM語言在CLR之前，但隨著「公共語言運行時」的到來，我的理解是這使得使用JVM的人們向前進並且最終創造了如Scala和Clojure這樣偉大的JVM編程語言。如果我錯了請糾正我。再者，CLR使得Sun公司的人們坐下來並關注它，因為Java有一點陳舊並且隨著Java8的到來，僅僅現在才在多個方面追趕著。競爭是一件非常好的事。NuGet另一個顯著的例子是NuGet。這個包在Windows中作為一個整體特別是在Windows的開發中，它的管理軼事是糟透的。NuGet解決了很多問題，他們也通過從Python和Ruby借用了很多東西去做了很多正確的事。有改進的餘地嗎？當然。但比起其他一些選擇在這兒或那兒的包升級來說，我還沒有感到使用NuGet有這許多痛楚。Mono對於Mono的開發者們，我不能不說太棒了。他們所創造的太驚奇了。沒有任何官方支持和不顧潛在的懸在他們頭上的法律問題，他們向前推進並創造了一個居然能替代官方運行時的實現。我已經有一些運行在產品中應用程序，在Mono下運行了幾乎一年而沒有任何問題。它的產品准備好了嗎？這可能取決於你的應用程序(見下文「Mono」)。CQRS和事件溯源可以認為，關於.NET最好事之一是，它是CQRS的誕生地並有相關的技術：事件溯源。就算這樣，CQRS+ES本身並沒有什麼很新的東西。正如GregYoung將會告訴你的，這是由一堆40年歷史原料為我們重新打包並更名的。對於大型代碼庫我有些非常嚴重的問題，當我5年前使用CQRS+ES的時候，它完全釋放了我的域。CQRS+ES現在是命名模式的並且其成長是顯而易見的。這可能是因為.NET已經能夠和其他的開發平台交互共享的原因。除了這個之外，大多數的創新是從外部來的。缺點優點先放在一邊，讓我們看看什麼出錯了和我為什麼不再用.NET框架。關於我最近開發平台的遷移，最能激勵我的事是我可以利用許多最好的部分而丟下不好的部分(如下文所說)。Windows正如前文所述，當面對基於網路的伺服器軟體時，Windows並不是一個好的選手。在我看來，Windows的另一個真正的大問題是傳統的Windows開發者是通常僅僅擅長於Windows，當他們離開安樂窩之後就會很快迷失，這對於Linux開發者來說卻不是問題。計算遠不止是Windows。開發者僅僅能操作單一的操作系統的一個問題是它不可避免得導致Windows的激增。換句話說，Windows生了Windows。沒法打破這個循環。另一方面，*NIX的開發者通常熟悉多操作系統(Linux，Unix，OSX，Windows等等)，一個操作系統的內部工作原理，不同的分布(基於Debian和基於Fedora)，窗口管理器，桌面管理器，文件系統，包管理，編譯，重新編譯，重新打包，命令行「fu」等等。我的一個心病是文件系統。NTFS並不是系統唯一的文件系統，對於任何給予的任務它幾乎都不是最好的選擇。ZFS，BTRFS，ReiserFs，ext*等等，有一些很酷的特性。我也很喜歡為了各種高速/透明的磁碟操作，能從BASH創建迴路設備或者創建RAM設備。這在Windows中不會發生—如果沒有第三方軟體的話。在AWS雲服務中，啟動一個Windows機器要花掉足足10多分鍾。我大約15-20秒就能啟動一個簡單的Linux機器。當涉及到雲計算規模，它能夠迅速擴展是很重要的，因為當擴展很重要時，10-15分鍾就像是永恆的。VisualStudio在我這另一根刺，當屬VisualStudio。我需要一個大大超出預期的IDE去做任何開發，這個想法困擾著我。它只是如Windows一樣龐大的資源豬。我有一個內核i73770K3.5GHZ的台式機，以16GB的內存和最大4512GB的固態硬碟去編譯。它差不多刷爆了Windows體驗指數，但Windows+VS仍然很慢。(是的，ReSharper使得它更慢了，但是ReSharper對這來說是值得的。)現在我在MacBookPro上開發，它比起我的強大的台式機來說只有更少的CPU馬力，但運行明顯更快，在一個短小的學習曲線之後，UX（用戶體驗）變得無限美好了。事實上，我甚至不再用滑鼠了—我的雙手一直在鍵盤或觸控板上，我可以用手勢操作我的電腦並讓它回應—不像在Windows。關於VS很酷的一個事是調試器。它的查看和使用，令人難以置信得方便。每隔一段時間會在監視窗口報告錯誤的值，導致花費時間去調試。同時，這也是很大的負面，因為CLR默認的，多線程的世界使得我一開始就需要一個調試器。沒有調試器是一個解脫的體驗，因為它迫使你以另一種方式編程。VS同樣也有創建「csproj」和「sln」文件的壞毛病。我恨這些。當然，C#必須知道編譯什麼和何時編譯。我理解這點。在Golang中，引用在代碼中使用了很重要的語句。如果它不是.NET中用到的工程文件，我可能使用簡單的文本編輯器編碼C#，並且對這門語言更流暢。使用gitrebase操作時，這些文件也有導致合並沖突。別讓我開始說換行符的差異。我不能相信直到今天我們還在處理這樣的事。如果VS解決方案文件以Linux行結束符結束，通過雙擊它並不能載入該解決方案，因為VS解決方案文件分析器讀不出它來。源代碼管理幸運的是，我早就跳出了微軟陣營的源代碼管理(版本控制系統VSS)。我早在2000年初，在VSS無數次丟失了我的提交之後，就使用了Subversion(譯者註：Subversion是開源的版本控制系統)。之後git(譯者註：git是開源的版本控制系統，內容管理系統等)出現了，我又迷上了它。不幸的是，沒有Windows的介面—對我來說是典型的遭遇。最終有人創建了一個介面，我就用了那個並且沒有回頭。Git是一把非常鋒利的刀，但當你正確運用它的時候，它是一個強大而高效的工具。我曾經在一個小工程中用過TFS(譯者註：TeamFoundationServer，工作流協作引擎)，它是一個怪物—和所有來自Redmond(譯者註：美國微軟總部)的產品一樣。它感染了我的項目文件並且污染了我的源代碼目錄。真可惡。不，還是謝謝你。給了我任意一天用命令行git…或者可能是SourceTree，如果你需要從GUI得到一點關愛。Mono是的，這是第二次提及Mono。正如Mono本身如此驚艷一樣。在.NET的世界，它仍然二等公民。無論什麼時候我嘗試在Mono上運行任何重要的東西，我通常都在和漏洞作斗爭。幸運的是，對下載代碼，查找問題，發送請求和在Linux上編譯代碼我沒有感到不舒服。但是這件事我都記不清做了多少遍了。是的，CLR是個巨大的怪物，並且對一個非官方的應用在不同的操作系統都有相同的行為，簡直是個類似於分開紅海的奇跡。但事實是，我不得不花費如此多的時間來填補漏洞以使我的代碼能夠正確運行，實在是很難為其辯護。Mono的特定區域也慢。也許它不是在慢在過載，但對我來說Web伺服器是關鍵所在。並且它非常慢，最後，慢到了最底下—即使是微不足道的東西。我想好消息是它只能從這兒得到更好的。我也應該提及Mono的開發者可能忘了Linux，比起我可能知道的還多，所以我不能太挑剔。IIS也許IIS在嘗試著為太多的應用程序做太多的事情。它從作為一個web伺服器變為像J2EE應用程序容器一樣的應用程序宿主。它也站在慢速這一邊。我猜如果我需要更高的性能，我應該編寫我自己的web伺服器，但我真的很想只關注我應用程序的代碼。可能利用Windows事件伺服器將是好的，但nginx(譯者註：一個高性能的HTTP和反向代理伺服器，也是一個IMAP/POP3/SMTP代理伺服器)和其他伺服器只是不喜歡在Windows中生產。虛擬的以JVM為基礎的實現，例如Netty(譯者註：JBOSS提供的一個java開源框架)，很容易處理每秒650K+/的請求量。IIS在運行一個簡單的CLR應用程序「Hello,World!」，處理大約每秒50K的請求量時就會壅塞。(有趣的題外話，參考基準開發者通過TCP套接字創建了一個簡單的C#的web伺服器，它能處理大約每秒120K的請求量。)狹隘的心理前些年有個運動叫做ALT.NET。該運動是全部是關於尋找我們自身之外的更廣闊的開發社區以作為一個整體，並匯聚不同的部分。有趣的是，那是StructureMap、Autofac、NuGet、ASP.NETMVC和許多其它工具的靈感來源。在傳統的.NET的圈子裡，這個運動受到了很多的不屑和鄙視。我把這看作是，作為一個整體的社區普遍的狹隘心理和怠惰的一個極大的例證。(的確，它們中的一些可能會消失，進而以包括Redis，MongoBD還有其它的不同的技術而出現。)有這么多很棒的方案在那裡。假定微軟已註定是唯一正確之路的想法是荒謬的。如果是這樣的話，我們就都還在使用VisualStudio的設計工具去拖放按鈕和鏈接元素到一個WebForm的界面上，我們會設定了該按鈕並且依賴ViewState以幫助我們與可怕的HTTP所帶來的恐懼隔開。我從我的一個部署的代碼庫中最後一個WebForm中擺脫的那一天，是個光榮的值得慶賀的日子。誰又曾想過「網路控制」是個好主意？很顯然我考慮過因為我喝了Kool-Aid(譯者註：卡夫公司出品的飲料，這里意指明知是註定的或有危險的仍然去做,有負面涵義)並且完全接受它。它狠咬了我。見過2MB的ViewState嗎？[註：當我寫這篇文章的時候，原來的標題，「為什麼我不再用.NET」，意味著整個.NET生態系統。標題感覺有點短於是我更新為「為什麼我不再用.NET框架」。我想.NET作為一個生態系統，包括了所有的工具，工程，平台，組織還有很多開發者。這就是為什麼有些更廣泛的.NET社區的元素在我的這篇文章中受到抨擊原因。]性能殺手C，Java和C#中典型的多線程範例都強烈推薦使用鎖和互斥。對於鎖來說有個隱藏的開銷：它們慢得難以忍受。使用Disruptor(JVM中的無鎖的環形緩存[譯者註：實際上就是擁有一個序號指向下一個可用元素的數組])，你可以很容易得每秒處理20M以上的事件。在.NET中使用規定的「最佳實踐」等任何超過每秒十幾次的傳輸，都被認為是體面又好的性能表現，在這一點上來說你僅僅需要更大/更好/的硬體設備。事實上，我見過第三方客戶端庫(Rabbit，Couch，Mongo等等)中鎖語句遍布整個代碼。即使在我的代碼中沒有任何的並發，默認的和首選的方法都用了鎖。無鎖的、事件驅動的方法允許你大幅降低硬體和資金支出。大部分應用程序可以輕易地運行在兩台機器上，第二台機器僅僅在冗餘和失效備援時是必須的，以防因為硬體相關的問題導致第一台機器不可用的時候起作用。這個問題的另一個方面是調用網路和磁碟子系統的傳統方式：同步，阻塞代碼。如果你需要多個並發的HTTP請求，你需要的線程。大多數人不知道的是，為維持線程多出的1-2MB和上下文切換線程的需求，使得CPU內核消耗所有的時間顛簸在上下文切換上而不是做真正的工作。所以現在我們得到了在一個應用程序中數百或數千的線程，佔用了RAM，並造成CPU停滯不前。還有個更好的方式。Netty/NIO(JVM)，Erlang，Node，Gevent(Python)和Go都支持使用事件驅動的子系統操作(選擇/epoll[譯者註：Linux內核中的一種可擴展IO事件處理機制]/kqueue[譯者註：FreeBSD的可擴展的事件通知介面])。這就意味著當等待數據包被tx/rx跨網路的時候，CPU可以自由地去做其它，重要的工作。因為JVM的成熟，Netty可以認為是做這項工作最快的，但我喜歡Go用Goroutines操作這個的方式—它簡單，優雅，很容易推理，沒有像義大利面條一樣的回調。SQLServer作為一名.NET開發者，當你開始一個新的工程時，有一些事是你通常會去做的：創建一個新的solution將其部署到TeamFoundationServer(譯者註：Microsoft應用程序生命周期管理(ALM)解決方案的核心協作平台)IIS中建立相應的網站入口創建一個新的SQLServer資料庫在solution中關聯EntityFramework(通常是2010年之後創建的工程)開始設計你的資料庫和ActiveRecord實體在大多數情況下這不是編寫代碼的正確方式。當然它可能在某些情況下有效，但是作為一個「默認的架構」它並不是你想要的。為什麼在我們甚至還沒理解問題領域之前已經做了任何技術上的選擇？這簡直是本末倒置了。微軟的生態系統鼓勵每個人使用SQLServer。在VisualStudio中和SQLService進行交互或者使用SQLManagementStudio(和它的前身，SQL查詢分析器)是如此令人難以置信的容易。這種以資料庫為中心的重點，是欽定的或唯一正確的方式的一部分。它使你更加迷戀微軟。廠商鎖定始終對廠商來說是好的。為什麼我們要如此開發？為什麼我們不地考慮應用程序的行為而不是它如何存儲的？現在我所有的項目都使用基於JSON的鍵/值存儲。有了這種功能，我可以選擇任何我想要的存儲引擎，包括SQLServer，Oracle，PostgreSQL，MySQL，Cassandra,CouchDB,CouchBase,Dynamo,SimpleDB,S3,Riak,BerkeleyDB,Firebird,Hypertable,RavenDB,Redis,TokyoCabinet/Tyrant,AzureBlobs，文件系統中的明文JSON文件等等等等。突然之間，我們能夠開始根據其優點而不是僅僅對其熟悉來選擇存儲引擎了。題外話：在AWSRDS的雲上運行過SQLServer嗎？別這么做。當然它會工作，但是一些例如復制這樣最簡單的事是不存在的。文章充斥著對SQLServer不能在AWSRDS上工作的引用。結論也許我在軟體開發中學到的兩件最重要的教訓是：邊界和封裝的重要性(以多種形式)付出代價以得到正確的模型和抽象許多年前我恨「模型」這個詞。每個人都會把它到處扔，它是一個如此過載的術語，很難理解它的含義和它為什麼這么重要。就這點來說，我僅僅會說模型是對你想要封裝的現實的一個有限的表示。也許最簡單的例子就是地球儀的墨卡托投影了。這很確切得說明了一件事：導航。如果你在其他的事情上使用它，它並不毫無價值。如果你不專注於付出代價去使模型正確，去封裝商業現實，那麼沒有任何技術能夠拯救你。我對.NET最大的抱怨是，「唯一正確的方式」引導你遠離理想的模型並把你推向關注實現細節和技術缺陷的方向。這樣的關注導致技術實施滲血並且感染模型，最終導致它腐爛變質，因為它不能適應不斷變化的商業需求。當這發生的時候，開發者掙扎著並蹬踢著，如同吸毒者一樣，他們從一個新技術轉向另一個，以期望下一個強大的技術能夠治癒他們的病痛。技術本身並不是靈丹妙葯，相反地，它是關於取捨和選擇。只有正確地理解了商業行為並把它們封裝進結構良好的，易於理解的模型中，以幫助保持技術堆棧在屬於它的地方—作為一個實現細節。這就是我為什麼不再用.NET框架，因為它不斷地重申自己(的主張)，不斷地想要比它的本身的：一個實現細節。