本文深入剖析了 .NET 開發者對生態系的復雜情感。一方面，他們依賴微軟提供的解決方案，認為這最為穩妥；另一方面，他們又對第三方工具抱有擔憂，在信任與恐懼之間掙紮。在 .NET 生態系中，各種觀點相互碰撞，有的開發者堅定地支持微軟的首選方案，而有的則強調多樣性和選擇的重要性。
然而，文章也揭示了單一選擇可能帶來的局限性，以及對第三方工具長期支持和生存能力的疑慮。這讓我們不禁思考，.NET 生態系的未來應如何發展？如何平衡微軟的貢獻與第三方創新之間的關系，以確保 .NET 能夠持續進步？這些問題值得我們深入探討。
近日，一則名為 「Epic: Eventing Framework in .NET 9」 的 ASP.NET GitHub 話題在開發者社群引起了軒然大波，背後主要原因是微軟在其 .NET 開源生態系中展現出的強勢插手態勢。對於這種現象，如果放在幾年前，我或許還會因此感到憤怒。但如今，這幾乎已經成了微軟的慣常做法 —— 對此，我也曾在我的文章中有過類似論述。無論我們怎樣表達憤怒，或是展現開源社群的精神，似乎都無法撼動微軟那座堅固的象牙塔。要想真正帶來改變，恐怕得從改變對 Azure 的投入開始。
如果你想在 .NET 生態系中作為開源計畫或工具開發者參與進來，那麽接受這樣的現實或許就是入場的代價。如果你覺得微軟涉足你的領域就意味著要放棄，或者這足以摧毀你的業務，那麽從一開始，或許你就缺乏足夠的創意、決心或熱情。
微軟聲稱他們開發這個框架主要是為了改進 Azure WebJobs，因此不會對 MassTransit、Wolverine、MediatR 等構成真正的威脅。但對此，我持懷疑態度。如果微軟並不打算讓第三方真正使用它，那又何必將其列為 ASP.NET 的重大工程，更何況 ASP.NET 還是生態系中最受歡迎的框架呢？
不過，真正讓我感興趣的並不是這個貼文上開源軟體生產者或微軟的反應，而是 .NET 開源軟體消費者的反應，這實在出乎我的意料。竟然有那麽多 .NET 開發人員歡呼這些流行的第三方框架被摧毀，仿佛擁有多個、維護良好的工具成了一種需要解決的麻煩。
究竟有哪些 .NET 開發者會要求 .NET 毀掉自己的生態系，甚至將 .NET 帶回昔日競爭力不足、智力貧瘠的時代呢？
.NET 開發者的兩種觀點
在那個貼文中，存在兩種截然不同的 .NET 開發者群體。
第一種認為供應商多樣化是件好事，他們傾向於擁有多種可行的軟體交付選項，這樣可以根據自己的需求進行選擇，從而保持生態系的健康和競爭力。而第二種觀點則相反，他們認為供應商多樣化並不是好事，主張應該有一個統一的標準來指導我們的工作，包括構建復雜的事件驅動架構等任務。他們認為，只要微軟支持這個單一標準，我們就不必擔心其他問題 —— 因為這個標準將比其他任何選擇擁有更完善的文件、更好的維護和更高的可操作性。他們建議圍繞這個標準整合生態系的其他部份。
需要明確的是，這兩種觀點並非同等有效、可以簡單 「同意或不同意」 的。第二種開發者群體所信奉的這種信念體系，實際上限制了他們的能力和技能，相比第一種開發者顯得更為不足。這種自我設限的信念，最終可能導致他們成為所謂的 「專家初學者」。
那些認為評估甚至只是擁有工具選項都是浪費時間的人，很可能並不具備構建高流量客戶面向的 SaaS 套用、工業物聯網、自動交易系統或其他比簡單數據表單更復雜計畫的能力。我之所以參與 .NET 開源軟體，完全是因為 我希望增加能夠利用 .NET 構建這些重要系統的開發者的數量 。
主張摧毀選項並不是我們應當參與的積極討論，因為「讓生態系變得更糟、更不具競爭力，以便我無需面對選擇」這種思維過於短視。尤其對於那些從未經歷過 .NET Core 之前的 .NET 生態系之弊端的開發者，或是那些「資深」開發者中未曾關註過在看似微不足道的應用程式中默默付出的人們，這一點尤為凸顯。
第一類：選項尋求者
競爭是積極的，擁有多種可行的選擇是有益的。微軟進入事件處理領域並不會淘汰現有的解決方案，用於構建訊息或事件驅動架構；實際上，這可能會增加首次嘗試構建它們的 .NET 開發者的數量——這是值得欣喜的！
微軟介入事件處理領域，若其影響導致開發者在構建軟體時不再充分考慮其他選擇，則可能產生「負面影響」。一個常見的例子是，越來越多的新手 .NET 開發者知道 Entity Framework 的工作原理，但不知道如何直接與 SQL 互動——既然 Code First EF「有效」，那他們為什麽還要去尋找其他選擇呢？
第一類選擇者關註的是選擇和自由——他們了解每個可能選項都涉及技術和風格上的權衡，並希望能夠獲得這些選項。選項的減少必然意味著更少的創造自由，可能無法獲得真正需要的工具（這在 .NET 的早期時期就經常發生）。
我經常被問到對 Microsoft Orleans 與 Akka.NET 的看法——我通常會回答我也很高興它們都存在，因為在 2013-2014 年，當我需要一個可行的 .NET actor 模型實作時，它們都還沒有出現。Orleans 和 Akka.NET 在使用 actor 構建軟體方面有不同的方法，我認為在這個領域有競爭是積極的。Orleans 的存在並沒有對 Akka.NET 的采用率造成任何傷害，因為 Orleans 和 Akka.NET 之間的這些差異對這兩個技術的使用者都非常重要。
選擇使我們在 .NET 生態系中的工作經驗對雇主和我們自己都更具經濟價值——因此，選擇是積極的。
第二類：恐懼者
我對一些 .NET 開發者在 https://github.com/dotnet/aspnetcore/issues/53219 上的評論感到驚訝，他們表現出對 .NET 開源計畫的恐懼，因此要求微軟提供官方解決方案來解決他們的問題。以下是一些例子：
「[OSS 工具] 的目的就是為了宣傳其建立者。」
「在這個討論中，我看到維護者抱怨這會扼殺他們的產品，而他們那擁有十年歷史卻只有 1k 顆星的計畫也難逃厄運。無論微軟是否介入，你們的采用率依然會很低。」
「你知道誰從未幫助過我嗎？是開發者。那麽多開發者如此敵對、保護主義、領土主義，又充滿防禦性，真是令人驚訝微軟竟然如此主動地擁抱開源，因為我們當中有太多人充滿敵意。」
「.NET 仍然需要很多創新，以及歷史上分離的產品線之間的統一。我想要的是一個統一的 .NET，社群中的分裂程度最小。當你可以擁有一個易於使用並在開箱即用時整合所有最佳實踐的庫時，就沒必要有 5 個基本做同樣事情的不同庫。合並是好事，應該被接受，因為它可以減少 .NET 社群中的分裂，為新的創新提供更多資源。」
「YouTube 效應催生了一代全新的開源計畫，這些計畫似乎只是為了追求精英地位而存在。一些開源計畫所有者如此自私，我真不明白他們為什麽要涉足這個領域。發現一些開源社群中最重要的人物也是最不友好的人物，讓我深感失望。」
「我一直擔心 MassTransit 等工具能否長期存在。」
還有諸如「我們的律師讓我們選擇技術棧」之類的借口，這簡直就是企業版的「狗子吃了我的作業」。
.NET 開發者常因公司合規要求，需詳細列出並證明每個第三方庫的引入情況。
對於微軟的庫，一般無需額外審查。然而，第三方庫則必須透過授權證清理，有時還需核查作者，以確保其不來自受限制的國家。
— Ted Anderson (@TedsTechTed) 2024 年 2 月 14 日
這一問題正是 .NET Foundation 旨在明確解決的第三方 .NET 開源計畫所面臨的挑戰之一。該基金會致力於確保所有納入其內的計畫都擁有清晰（無侵權）的智慧財產權和商業友好的開源授權證 —— 這兩個問題恰好是非工程利益相關者所關心的焦點。值得一提的是，我們的計畫 Akka.NET 正是 .NET Foundation 的成員之一。
Akka.NET 目前已被美國銀行、美國聯合航空公司、西門子、美國人力資源管理局、諾斯洛普・格魯曼、戴爾、高通等眾多公司套用於生產環境。我們已對其中部份公司進行了智慧財產權和授權證的審查，但僅限於此。即便在國防承包、司法系統、政府以及【財富】100 強等敏感領域，我也未曾見過法律部門強制規定必須使用特定庫作者的情況。開放原始碼的核心優勢在於其透明性，你可以清楚地了解所獲得的內容。如果你希望在技術供應鏈上做到極度警惕，你完全可以從自己的機器上複制原始碼，自行構建所需的元件。
實際上，只有軟體開發者自己才會提出如此嚴格的庫供應商規定，這也是這種說法在很大程度上站不住腳的原因：
然而，這些政策究竟是由誰制定的呢？答案是高級軟體開發人員！實際上，公司律師等人通常是追隨 IT/R&D 部門的領導，而非相反。
此外，將這種情況視為大公司中不可改變、固有的事實，實際上是開發人員學會了無助的一種表現。
— Aaron Stannard (@Aaronontheweb) 2024 年 2 月 14 日
我經常在我的部落格上探討 .NET 開源生態系。我們面臨的許多問題，例如開源永續性，都是軟體生態系中普遍存在的。然而，這些評論揭示了一個 .NET 生態系特有的問題：單一供應商主導下的單一文化，在這個案例中即微軟。
這些抱怨實際上反映了部份 .NET 使用者內心深處的深深憂慮：
主導因素：在面臨多個選項時，若微軟的選項不存在，他們可能會因技術選擇不當而受到指責。因此，遵循微軟制定的「標準」可以使他們免於承擔個人責任。
長期來看，他們擔心第三方計畫無法提供持久的支持，因此認為微軟的選項預設是「安全」的。
他們認為第三方技術的品質無法達到微軟在該領域的產品水平。
他們將第三方開源計畫的建立者視為精英主義者，並擔心會遭到虐待，而微軟則會對他們的需求做出迅速響應。
這些使用者正在放棄自己的批判性思維，盲目地信任微軟，這主要是因為流傳著「選擇微軟從未導致人被解雇」的說法。
在其他軟體生態系中，這種情況並不常見。如果一個 Java 開發人員因為害怕使用 Confluent 的工具而要求 Oracle 推出一個官方的 Kafka 替代品，那麽出於上述原因，他們可能會受到嘲笑。但在 .NET 領域，我們卻因為某些原因對此予以考慮，這是我們應該停止的行為。
這是情感推理導致的技術采納現象——人們選擇站在微軟這一邊，並非因為他們的工具最適合工作，而是因為它提供了最強大的責任追究防火墻。「選擇微軟從未導致人被解雇」這句話被過度解讀了。
最讓人感到悲哀的是，這些被提出的關於微軟「安全」的理由中，大部份甚至都不是真實的。
對於那些擔心開源工具永續性的使用者，他們可以問問那些在 2011 年 Silverlight 突然被取消時的使用者的感受。或者問問 WPF/UWP/MAUI 使用者，他們對微軟在 2024 年桌面 UI 領域的產品有多大的信心。
於我之前參照的評論特別關註 MassTransit 的永續性：MassTransit 自 2007 年開始開發，而 Windows Communication Foundation (WCF) 則始於 2006 年。那麽，在 2024 年，這兩個框架中哪一個仍在積極維護呢？
對於這種情緒，我不得不佩服其純粹的 「卡夫卡陷阱」 （ Kafkatrap ）能力：
盡管存在一些缺陷和糟糕的決策，但微軟對於那些感到被他人忽視或輕視的數百萬開發者來說，仍然是一個積極的因素。.NET SDK 是由一些世界頂尖的工程師開發的，其文件內容龐大且詳盡。微軟在釋出新版本時始終保持著連貫性和紀律性，並不斷創新。此外，他們的外交手段也非常出色。
盡管我認為微軟對產品品質的承諾是毋庸置疑的，但在這個生態系中，只有那些極度缺乏經驗的開發者才會相信，與擁有 10 萬名員工、市值 2 萬億美元的公司進行介面交流，會比與一個由 3 人組成的開源計畫進行介面交流更容易。微軟開發的任何計畫都有可能在經歷 1-2 次企業重組後就消失無蹤。想想那些可憐的 AppCenter 使用者的遭遇吧：
哇，微軟要關閉 AppCenter 了！
— Simon Cropp (@SimonCropp) 2024 年 3 月 15 日
在貼文中，有使用者高度贊揚了 ASP.NET 的速率限制功能，認為這體現了微軟無與倫比的天才，為 .NET 開發者提供了一種便捷的功能，這種功能對於許多所謂的「門外漢」來說可能是遙不可及的，這確實令人感到驚訝。
不過，考慮到「選擇困惑者」的觀點：「微軟預設提供的選項往往過早地讓大多數 .NET 使用者停止了尋找最佳選項的探索。」
然而，事實上，這位使用者所稱贊的 ASP.NET 速率限制 API 在大多數實際套用場景中，其「實用性」顯然是不夠的。
它們僅限於在行程內使用，因此，對於那些最重要的經濟上有用的速率限制套用（如按租戶計量收費）來說，這些功能根本無法使用。目前計劃在 .NET 9 中修復此問題連結。
它們的配置十分復雜，難以理解——實際上，執行一些基於流的編程（如 Rx、TPL Dataflow、Akka.Streams）會更為簡單。別問我是怎麽知道的，因為我整天都在處理這些工作。
它們對背壓不敏感——任意對 Web 應用程式進行速率限制是不明智的。我們應該僅在響應業務原因（如第 1 點所述）或因為共享資源（如資料庫）開始變得不可用，且選擇優先處理某些流量而非其他流量（這也是一項業務規則）時才應該這樣做。這需要一些背壓意識。目前，最接近支持此功能的 API 是令牌桶速率限制策略。
當你真正需要開始套用速率限制時，這個 API 在開箱即用的情況下，使得理解重要的副作用和流控制變得困難。我再強調一下，如果這是一個基於流的編程模型而不是基於配置的模型，那麽實作起來會更容易。根據我的應用程式要求，我可以簡單地開始緩沖、分批次處理、減弱請求或執行其他適當的操作。然而，在這種情況下，你只能拒絕一個請求，然後在事件處理常式中可能做一些其他工作。
ASP.NET 之所以推出這個速率限制功能，主要是因為「需要」這個功能，但它在考慮實際高流量應用程式需求時顯得捉襟見肘。那些一直在努力管理 ASP.NET 和其他 .NET 系統中高吞吐量流量的開發人員，比如那些在 https://github.com/ThrottlingTroll/ThrottlingTroll 中支持分布式按租戶限制速率的第三方解決方案，他們在設計這些功能時會更加完善。這是因為他們的業務依賴於這些功能，而不是因為微軟的產品經理將其納入了今年的目標和關鍵結果文件中。.NET 團隊做得不錯，但他們推出和做事情的動機不同，這一點在他們的優先級中得到了體現。
在庫/框架作者與使用者需求的「一致性」方面，第三方開源選項通常比微軟更貼近實際。許多這樣的計畫都是作者因為感受到真實業務需求而產生的，比如 Akka.NET 就是這樣誕生的。
如果微軟今年必須交付「雲原生」內容，明年又必須「與 Python 在極簡主義上競爭」，那並不一定符合當前框架使用者的真實需求。此外，由於 .NET 團隊需要支持的使用者、用例、版本和群體的數量和多樣性，他們必須提供滿足最低公共分母的體驗。這就是為什麽像 ASP.NET 的速率限制這樣的抽象概念，甚至是早期的
IDistributedCache
這樣的功能，在實際套用中並不常見的原因——對於嚴肅的客戶導向的生產用途來說，它們顯得相當笨拙。
因此，這位使用者在吹噓這個功能有多好的同時，也暴露了自己在速率限制方面缺乏實際經驗。這也印證了那些尋找更好選項的人的觀點，即只要微軟在該領域提供了某種解決方案，開發人員就會停止尋找最佳工具。這正是有人對微軟構建事件解決方案提出擔憂的原因所在。
戰略思考與行動
對於 .NET 的開源軟體，你或許無需過於關註。選擇微軟的官方解決方案同樣無可非議。然而，在選擇微軟的解決方案時，有兩種截然不同的動機：一是因為你確信它能滿足你的需求，而另一種僅僅是因為微軟推出了它。盡管這兩種決策過程最終可能導向相同的結論，但前者是基於理性的推理，後者則顯得較為牽強附會。
過度吹捧摧毀選項只會損及自己的長遠利益，因為這樣做會讓人才和優秀組織疏遠 .NET。下次你在/r/dotnet 上詢問「為何主流互聯網平台不采用 .NET？」時，請銘記，這正是因為在 .NET 的過去，構建這些平台的工具匱乏。
.NET 自跨平台以來一直在穩步發展。若你希望這種進步勢頭得以延續，就應當支持 .NET 生態系中選項的擴充套件，而非致力於淪陷它們。
作者簡介 ：
Aaron Stannard，Petabridge 公司的技術長兼創始人，致力於透過開發 Akka.NET、Phobos 等計畫，讓 .NET 開發人員更輕松地進行分布式編程。
原文連結 ： https://aaronstannard.com/dotnet-eventing-backslide/
