作者 | Aaron Stannard

譯者 | Sambodhi

策劃 | 凌敏

本文深入剖析了 .NET 開(kāi)發(fā)者對(duì)生態(tài)系統(tǒng)的復(fù)雜情感。一方面，他們依賴微軟提供的解決方案，認(rèn)為這最為穩(wěn)妥；另一方面，他們又對(duì)第三方工具抱有擔(dān)憂，在信任與恐懼之間掙扎。在 .NET 生態(tài)系統(tǒng)中，各種觀點(diǎn)相互碰撞，有的開(kāi)發(fā)者堅(jiān)定地支持微軟的首選方案，而有的則強(qiáng)調(diào)多樣性和選擇的重要性。

然而，文章也揭示了單一選擇可能帶來(lái)的局限性，以及對(duì)第三方工具長(zhǎng)期支持和生存能力的疑慮。這讓我們不禁思考，.NET 生態(tài)系統(tǒng)的未來(lái)應(yīng)如何發(fā)展？如何平衡微軟的貢獻(xiàn)與第三方創(chuàng)新之間的關(guān)系，以確保 .NET 能夠持續(xù)進(jìn)步？這些問(wèn)題值得我們深入探討。

近日，一則名為 “Epic: Eventing Framework in .NET 9” 的 ASP.NET GitHub 話題在開(kāi)發(fā)者社區(qū)引起了軒然大波，背后主要原因是微軟在其 .NET 開(kāi)源生態(tài)系統(tǒng)中展現(xiàn)出的強(qiáng)勢(shì)插手態(tài)勢(shì)。對(duì)于這種現(xiàn)象，如果放在幾年前，我或許還會(huì)因此感到憤怒。但如今，這幾乎已經(jīng)成了微軟的慣常做法 —— 對(duì)此，我也曾在我的文章中有過(guò)類似論述。無(wú)論我們?cè)鯓颖磉_(dá)憤怒，或是展現(xiàn)開(kāi)源社區(qū)的精神，似乎都無(wú)法撼動(dòng)微軟那座堅(jiān)固的象牙塔。要想真正帶來(lái)改變，恐怕得從改變對(duì) Azure 的投入開(kāi)始。

如果你想在 .NET 生態(tài)系統(tǒng)中作為開(kāi)源項(xiàng)目或工具開(kāi)發(fā)者參與進(jìn)來(lái)，那么接受這樣的現(xiàn)實(shí)或許就是入場(chǎng)的代價(jià)。如果你覺(jué)得微軟涉足你的領(lǐng)域就意味著要放棄，或者這足以摧毀你的業(yè)務(wù)，那么從一開(kāi)始，或許你就缺乏足夠的創(chuàng)意、決心或熱情。

微軟聲稱他們開(kāi)發(fā)這個(gè)框架主要是為了改進(jìn) Azure WebJobs，因此不會(huì)對(duì) MassTransit、Wolverine、MediatR 等構(gòu)成真正的威脅。但對(duì)此，我持懷疑態(tài)度。如果微軟并不打算讓第三方真正使用它，那又何必將其列為 ASP.NET 的重大工程，更何況 ASP.NET 還是生態(tài)系統(tǒng)中最受歡迎的框架呢？

不過(guò)，真正讓我感興趣的并不是這個(gè)帖子上開(kāi)源軟件生產(chǎn)者或微軟的反應(yīng)，而是 .NET 開(kāi)源軟件消費(fèi)者的反應(yīng)，這實(shí)在出乎我的意料。竟然有那么多 .NET 開(kāi)發(fā)人員歡呼這些流行的第三方框架被摧毀，仿佛擁有多個(gè)、維護(hù)良好的工具成了一種需要解決的麻煩。

究竟有哪些 .NET 開(kāi)發(fā)者會(huì)要求 .NET 毀掉自己的生態(tài)系統(tǒng)，甚至將 .NET 帶回昔日競(jìng)爭(zhēng)力不足、智力貧瘠的時(shí)代呢？

.NET 開(kāi)發(fā)者的兩種觀點(diǎn)

在那個(gè)帖子中，存在兩種截然不同的 .NET 開(kāi)發(fā)者群體。

第一種認(rèn)為供應(yīng)商多樣化是件好事，他們傾向于擁有多種可行的軟件交付選項(xiàng)，這樣可以根據(jù)自己的需求進(jìn)行選擇，從而保持生態(tài)系統(tǒng)的健康和競(jìng)爭(zhēng)力。而第二種觀點(diǎn)則相反，他們認(rèn)為供應(yīng)商多樣化并不是好事，主張應(yīng)該有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)來(lái)指導(dǎo)我們的工作，包括構(gòu)建復(fù)雜的事件驅(qū)動(dòng)架構(gòu)等任務(wù)。他們認(rèn)為，只要微軟支持這個(gè)單一標(biāo)準(zhǔn)，我們就不必?fù)?dān)心其他問(wèn)題 —— 因?yàn)檫@個(gè)標(biāo)準(zhǔn)將比其他任何選擇擁有更完善的文檔、更好的維護(hù)和更高的可操作性。他們建議圍繞這個(gè)標(biāo)準(zhǔn)整合生態(tài)系統(tǒng)的其他部分。

需要明確的是，這兩種觀點(diǎn)并非同等有效、可以簡(jiǎn)單 “同意或不同意” 的。第二種開(kāi)發(fā)者群體所信奉的這種信念體系，實(shí)際上限制了他們的能力和技能，相比第一種開(kāi)發(fā)者顯得更為不足。這種自我設(shè)限的信念，最終可能導(dǎo)致他們成為所謂的 “專家初學(xué)者”。

那些認(rèn)為評(píng)估甚至只是擁有工具選項(xiàng)都是浪費(fèi)時(shí)間的人，很可能并不具備構(gòu)建高流量客戶面向的 SaaS 應(yīng)用、工業(yè)物聯(lián)網(wǎng)、自動(dòng)交易系統(tǒng)或其他比簡(jiǎn)單數(shù)據(jù)表單更復(fù)雜項(xiàng)目的能力。我之所以參與 .NET 開(kāi)源軟件，完全是因?yàn)?/span>我希望增加能夠利用 .NET 構(gòu)建這些重要系統(tǒng)的開(kāi)發(fā)者的數(shù)量。

主張摧毀選項(xiàng)并不是我們應(yīng)當(dāng)參與的積極討論，因?yàn)椤白屔鷳B(tài)系統(tǒng)變得更糟、更不具競(jìng)爭(zhēng)力，以便我無(wú)需面對(duì)選擇”這種思維過(guò)于短視。尤其對(duì)于那些從未經(jīng)歷過(guò) .NET Core 之前的 .NET 生態(tài)系統(tǒng)之弊端的開(kāi)發(fā)者，或是那些“資深”開(kāi)發(fā)者中未曾關(guān)注過(guò)在看似微不足道的應(yīng)用程序中默默付出的人們，這一點(diǎn)尤為凸顯。

第一類：選項(xiàng)尋求者

競(jìng)爭(zhēng)是積極的，擁有多種可行的選擇是有益的。微軟進(jìn)入事件處理領(lǐng)域并不會(huì)淘汰現(xiàn)有的解決方案，用于構(gòu)建消息或事件驅(qū)動(dòng)架構(gòu)；實(shí)際上，這可能會(huì)增加首次嘗試構(gòu)建它們的 .NET 開(kāi)發(fā)者的數(shù)量——這是值得欣喜的！

微軟介入事件處理領(lǐng)域，若其影響導(dǎo)致開(kāi)發(fā)者在構(gòu)建軟件時(shí)不再充分考慮其他選擇，則可能產(chǎn)生“負(fù)面影響”。一個(gè)常見(jiàn)的例子是，越來(lái)越多的新手 .NET 開(kāi)發(fā)者知道 Entity Framework 的工作原理，但不知道如何直接與 SQL 交互——既然 Code First EF“有效”，那他們?yōu)槭裁催€要去尋找其他選擇呢？

第一類選擇者關(guān)注的是選擇和自由——他們了解每個(gè)可能選項(xiàng)都涉及技術(shù)和風(fēng)格上的權(quán)衡，并希望能夠獲得這些選項(xiàng)。選項(xiàng)的減少必然意味著更少的創(chuàng)造自由，可能無(wú)法獲得真正需要的工具（這在 .NET 的早期時(shí)期就經(jīng)常發(fā)生）。

我經(jīng)常被問(wèn)到對(duì) Microsoft Orleans 與 Akka.NET 的看法——我通常會(huì)回答我也很高興它們都存在，因?yàn)樵?2013-2014 年，當(dāng)我需要一個(gè)可行的 .NET actor 模型實(shí)現(xiàn)時(shí)，它們都還沒(méi)有出現(xiàn)。Orleans 和 Akka.NET 在使用 actor 構(gòu)建軟件方面有不同的方法，我認(rèn)為在這個(gè)領(lǐng)域有競(jìng)爭(zhēng)是積極的。Orleans 的存在并沒(méi)有對(duì) Akka.NET 的采用率造成任何傷害，因?yàn)?Orleans 和 Akka.NET 之間的這些差異對(duì)這兩個(gè)技術(shù)的用戶都非常重要。

選擇使我們?cè)?.NET 生態(tài)系統(tǒng)中的工作經(jīng)驗(yàn)對(duì)雇主和我們自己都更具經(jīng)濟(jì)價(jià)值——因此，選擇是積極的。

第二類：恐懼者

我對(duì)一些 .NET 開(kāi)發(fā)者在 https://github.com/dotnet/aspnetcore/issues/53219 上的評(píng)論感到驚訝，他們表現(xiàn)出對(duì) .NET 開(kāi)源項(xiàng)目的恐懼，因此要求微軟提供官方解決方案來(lái)解決他們的問(wèn)題。以下是一些例子：

• “[OSS 工具] 的目的就是為了宣傳其創(chuàng)建者?！?/span>
• “在這個(gè)討論中，我看到維護(hù)者抱怨這會(huì)扼殺他們的產(chǎn)品，而他們那擁有十年歷史卻只有 1k 顆星的項(xiàng)目也難逃厄運(yùn)。無(wú)論微軟是否介入，你們的采用率依然會(huì)很低?！?/span>
• “你知道誰(shuí)從未幫助過(guò)我嗎？是開(kāi)發(fā)者。那么多開(kāi)發(fā)者如此敵對(duì)、保護(hù)主義、領(lǐng)土主義，又充滿防御性，真是令人驚訝微軟竟然如此主動(dòng)地?fù)肀ч_(kāi)源，因?yàn)槲覀儺?dāng)中有太多人充滿敵意。”
• “.NET 仍然需要很多創(chuàng)新，以及歷史上分離的產(chǎn)品線之間的統(tǒng)一。我想要的是一個(gè)統(tǒng)一的 .NET，社區(qū)中的分裂程度最小。當(dāng)你可以擁有一個(gè)易于使用并在開(kāi)箱即用時(shí)集成所有最佳實(shí)踐的庫(kù)時(shí)，就沒(méi)必要有 5 個(gè)基本做同樣事情的不同庫(kù)。合并是好事，應(yīng)該被接受，因?yàn)樗梢詼p少 .NET 社區(qū)中的分裂，為新的創(chuàng)新提供更多資源?！?/span>
• “YouTube 效應(yīng)催生了一代全新的開(kāi)源項(xiàng)目，這些項(xiàng)目似乎只是為了追求精英地位而存在。一些開(kāi)源項(xiàng)目所有者如此自私，我真不明白他們?yōu)槭裁匆孀氵@個(gè)領(lǐng)域。發(fā)現(xiàn)一些開(kāi)源社區(qū)中最重要的人物也是最不友好的人物，讓我深感失望?！?/span>
• “我一直擔(dān)心 MassTransit 等工具能否長(zhǎng)期存在?！?/span>

還有諸如“我們的律師讓我們選擇技術(shù)棧”之類的借口，這簡(jiǎn)直就是企業(yè)版的“狗子吃了我的作業(yè)”。

.NET 開(kāi)發(fā)者常因公司合規(guī)要求，需詳細(xì)列出并證明每個(gè)第三方庫(kù)的引入情況。

對(duì)于微軟的庫(kù)，一般無(wú)需額外審查。然而，第三方庫(kù)則必須通過(guò)許可證清理，有時(shí)還需核查作者，以確保其不來(lái)自受限制的國(guó)家。

— Ted Anderson (@TedsTechTed) 2024 年 2 月 14 日

這一問(wèn)題正是 .NET Foundation 旨在明確解決的第三方 .NET 開(kāi)源項(xiàng)目所面臨的挑戰(zhàn)之一。該基金會(huì)致力于確保所有納入其內(nèi)的項(xiàng)目都擁有清晰（無(wú)侵權(quán)）的知識(shí)產(chǎn)權(quán)和商業(yè)友好的開(kāi)源許可證 —— 這兩個(gè)問(wèn)題恰好是非工程利益相關(guān)者所關(guān)心的焦點(diǎn)。值得一提的是，我們的項(xiàng)目 Akka.NET 正是 .NET Foundation 的成員之一。

Akka.NET 目前已被美國(guó)銀行、美國(guó)聯(lián)合航空公司、西門子、美國(guó)人力資源管理局、諾斯洛普?格魯曼、戴爾、高通等眾多公司應(yīng)用于生產(chǎn)環(huán)境。我們已對(duì)其中部分公司進(jìn)行了知識(shí)產(chǎn)權(quán)和許可證的審查，但僅限于此。即便在國(guó)防承包、司法系統(tǒng)、政府以及《財(cái)富》100 強(qiáng)等敏感領(lǐng)域，我也未曾見(jiàn)過(guò)法律部門強(qiáng)制規(guī)定必須使用特定庫(kù)作者的情況。開(kāi)放源代碼的核心優(yōu)勢(shì)在于其透明性，你可以清楚地了解所獲得的內(nèi)容。如果你希望在技術(shù)供應(yīng)鏈上做到極度警惕，你完全可以從自己的機(jī)器上克隆源代碼，自行構(gòu)建所需的組件。

實(shí)際上，只有軟件開(kāi)發(fā)者自己才會(huì)提出如此嚴(yán)格的庫(kù)供應(yīng)商規(guī)定，這也是這種說(shuō)法在很大程度上站不住腳的原因：

然而，這些政策究竟是由誰(shuí)制定的呢？答案是高級(jí)軟件開(kāi)發(fā)人員！實(shí)際上，公司律師等人通常是追隨 IT/R&D 部門的領(lǐng)導(dǎo)，而非相反。

此外，將這種情況視為大公司中不可改變、固有的事實(shí)，實(shí)際上是開(kāi)發(fā)人員學(xué)會(huì)了無(wú)助的一種表現(xiàn)。

— Aaron Stannard (@Aaronontheweb) 2024 年 2 月 14 日

我經(jīng)常在我的博客上探討 .NET 開(kāi)源生態(tài)系統(tǒng)。我們面臨的許多問(wèn)題，例如開(kāi)源可持續(xù)性，都是軟件生態(tài)系統(tǒng)中普遍存在的。然而，這些評(píng)論揭示了一個(gè) .NET 生態(tài)系統(tǒng)特有的問(wèn)題：?jiǎn)我还?yīng)商主導(dǎo)下的單一文化，在這個(gè)案例中即微軟。

這些抱怨實(shí)際上反映了部分 .NET 用戶內(nèi)心深處的深深憂慮：

• 主導(dǎo)因素：在面臨多個(gè)選項(xiàng)時(shí)，若微軟的選項(xiàng)不存在，他們可能會(huì)因技術(shù)選擇不當(dāng)而受到指責(zé)。因此，遵循微軟制定的“標(biāo)準(zhǔn)”可以使他們免于承擔(dān)個(gè)人責(zé)任。
• 長(zhǎng)期來(lái)看，他們擔(dān)心第三方項(xiàng)目無(wú)法提供持久的支持，因此認(rèn)為微軟的選項(xiàng)默認(rèn)是“安全”的。
• 他們認(rèn)為第三方技術(shù)的質(zhì)量無(wú)法達(dá)到微軟在該領(lǐng)域的產(chǎn)品水平。
• 他們將第三方開(kāi)源項(xiàng)目的創(chuàng)建者視為精英主義者，并擔(dān)心會(huì)遭到虐待，而微軟則會(huì)對(duì)他們的需求做出迅速響應(yīng)。

這些用戶正在放棄自己的批判性思維，盲目地信任微軟，這主要是因?yàn)榱鱾髦斑x擇微軟從未導(dǎo)致人被解雇”的說(shuō)法。

在其他軟件生態(tài)系統(tǒng)中，這種情況并不常見(jiàn)。如果一個(gè) Java 開(kāi)發(fā)人員因?yàn)楹ε率褂?Confluent 的工具而要求 Oracle 推出一個(gè)官方的 Kafka 替代品，那么出于上述原因，他們可能會(huì)受到嘲笑。但在 .NET 領(lǐng)域，我們卻因?yàn)槟承┰驅(qū)Υ擞枰钥紤]，這是我們應(yīng)該停止的行為。

這是情感推理導(dǎo)致的技術(shù)采納現(xiàn)象——人們選擇站在微軟這一邊，并非因?yàn)樗麄兊墓ぞ咦钸m合工作，而是因?yàn)樗峁┝俗顝?qiáng)大的責(zé)任追究防火墻?！斑x擇微軟從未導(dǎo)致人被解雇”這句話被過(guò)度解讀了。

最讓人感到悲哀的是，這些被提出的關(guān)于微軟“安全”的理由中，大部分甚至都不是真實(shí)的。

對(duì)于那些擔(dān)心開(kāi)源工具持久性的用戶，他們可以問(wèn)問(wèn)那些在 2011 年 Silverlight 突然被取消時(shí)的用戶的感受?；蛘邌?wèn)問(wèn) WPF/UWP/MAUI 用戶，他們對(duì)微軟在 2024 年桌面 UI 領(lǐng)域的產(chǎn)品有多大的信心。

于我之前引用的評(píng)論特別關(guān)注 MassTransit 的持久性：MassTransit 自 2007 年開(kāi)始開(kāi)發(fā)，而 Windows Communication Foundation (WCF) 則始于 2006 年。那么，在 2024 年，這兩個(gè)框架中哪一個(gè)仍在積極維護(hù)呢？

對(duì)于這種情緒，我不得不佩服其純粹的 “卡夫卡陷阱” （Kafkatrap）能力：

盡管存在一些缺陷和糟糕的決策，但微軟對(duì)于那些感到被他人忽視或輕視的數(shù)百萬(wàn)開(kāi)發(fā)者來(lái)說(shuō)，仍然是一個(gè)積極的因素。.NET SDK 是由一些世界頂尖的工程師開(kāi)發(fā)的，其文檔內(nèi)容龐大且詳盡。微軟在發(fā)布新版本時(shí)始終保持著連貫性和紀(jì)律性，并不斷創(chuàng)新。此外，他們的外交手段也非常出色。

盡管我認(rèn)為微軟對(duì)產(chǎn)品質(zhì)量的承諾是毋庸置疑的，但在這個(gè)生態(tài)系統(tǒng)中，只有那些極度缺乏經(jīng)驗(yàn)的開(kāi)發(fā)者才會(huì)相信，與擁有 10 萬(wàn)名員工、市值 2 萬(wàn)億美元的公司進(jìn)行接口交流，會(huì)比與一個(gè)由 3 人組成的開(kāi)源項(xiàng)目進(jìn)行接口交流更容易。微軟開(kāi)發(fā)的任何項(xiàng)目都有可能在經(jīng)歷 1-2 次企業(yè)重組后就消失無(wú)蹤。想想那些可憐的 AppCenter 用戶的遭遇吧：

哇，微軟要關(guān)閉 AppCenter 了！

— Simon Cropp (@SimonCropp) 2024 年 3 月 15 日

在帖子中，有用戶高度贊揚(yáng)了 ASP.NET 的速率限制功能，認(rèn)為這體現(xiàn)了微軟無(wú)與倫比的天才，為 .NET 開(kāi)發(fā)者提供了一種便捷的功能，這種功能對(duì)于許多所謂的“門外漢”來(lái)說(shuō)可能是遙不可及的，這確實(shí)令人感到驚訝。

不過(guò)，考慮到“選擇困惑者”的觀點(diǎn)：“微軟默認(rèn)提供的選項(xiàng)往往過(guò)早地讓大多數(shù) .NET 用戶停止了尋找最佳選項(xiàng)的探索?！?/span>

然而，事實(shí)上，這位用戶所稱贊的 ASP.NET 速率限制 API 在大多數(shù)實(shí)際應(yīng)用場(chǎng)景中，其“實(shí)用性”顯然是不夠的。

1. 它們僅限于在進(jìn)程內(nèi)使用，因此，對(duì)于那些最重要的經(jīng)濟(jì)上有用的速率限制應(yīng)用（如按租戶計(jì)量收費(fèi)）來(lái)說(shuō)，這些功能根本無(wú)法使用。目前計(jì)劃在 .NET 9 中修復(fù)此問(wèn)題鏈接。
2. 它們的配置十分復(fù)雜，難以理解——實(shí)際上，執(zhí)行一些基于流的編程（如 Rx、TPL Dataflow、Akka.Streams）會(huì)更為簡(jiǎn)單。別問(wèn)我是怎么知道的，因?yàn)槲艺於荚谔幚磉@些工作。
3. 它們對(duì)背壓不敏感——任意對(duì) Web 應(yīng)用程序進(jìn)行速率限制是不明智的。我們應(yīng)該僅在響應(yīng)業(yè)務(wù)原因（如第 1 點(diǎn)所述）或因?yàn)楣蚕碣Y源（如數(shù)據(jù)庫(kù)）開(kāi)始變得不可用，且選擇優(yōu)先處理某些流量而非其他流量（這也是一項(xiàng)業(yè)務(wù)規(guī)則）時(shí)才應(yīng)該這樣做。這需要一些背壓意識(shí)。目前，最接近支持此功能的 API 是令牌桶速率限制策略。
4. 當(dāng)你真正需要開(kāi)始應(yīng)用速率限制時(shí)，這個(gè) API 在開(kāi)箱即用的情況下，使得理解重要的副作用和流控制變得困難。我再?gòu)?qiáng)調(diào)一下，如果這是一個(gè)基于流的編程模型而不是基于配置的模型，那么實(shí)現(xiàn)起來(lái)會(huì)更容易。根據(jù)我的應(yīng)用程序要求，我可以簡(jiǎn)單地開(kāi)始緩沖、分批處理、減弱請(qǐng)求或執(zhí)行其他適當(dāng)?shù)牟僮?。然而，在這種情況下，你只能拒絕一個(gè)請(qǐng)求，然后在事件處理程序中可能做一些其他工作。

ASP.NET 之所以推出這個(gè)速率限制功能，主要是因?yàn)椤靶枰边@個(gè)功能，但它在考慮實(shí)際高流量應(yīng)用程序需求時(shí)顯得捉襟見(jiàn)肘。那些一直在努力管理 ASP.NET 和其他 .NET 系統(tǒng)中高吞吐量流量的開(kāi)發(fā)人員，比如那些在 https://github.com/ThrottlingTroll/ThrottlingTroll 中支持分布式按租戶限制速率的第三方解決方案，他們?cè)谠O(shè)計(jì)這些功能時(shí)會(huì)更加完善。這是因?yàn)樗麄兊臉I(yè)務(wù)依賴于這些功能，而不是因?yàn)槲④浀漠a(chǎn)品經(jīng)理將其納入了今年的目標(biāo)和關(guān)鍵結(jié)果文檔中。.NET 團(tuán)隊(duì)做得不錯(cuò)，但他們推出和做事情的動(dòng)機(jī)不同，這一點(diǎn)在他們的優(yōu)先級(jí)中得到了體現(xiàn)。

在庫(kù)/框架作者與用戶需求的“一致性”方面，第三方開(kāi)源選項(xiàng)通常比微軟更貼近實(shí)際。許多這樣的項(xiàng)目都是作者因?yàn)楦惺艿秸鎸?shí)業(yè)務(wù)需求而產(chǎn)生的，比如 Akka.NET 就是這樣誕生的。

如果微軟今年必須交付“云原生”內(nèi)容，明年又必須“與 Python 在極簡(jiǎn)主義上競(jìng)爭(zhēng)”，那并不一定符合當(dāng)前框架用戶的真實(shí)需求。此外，由于 .NET 團(tuán)隊(duì)需要支持的用戶、用例、版本和群體的數(shù)量和多樣性，他們必須提供滿足最低公共分母的體驗(yàn)。這就是為什么像 ASP.NET 的速率限制這樣的抽象概念，甚至是早期的IDistributedCache這樣的功能，在實(shí)際應(yīng)用中并不常見(jiàn)的原因——對(duì)于嚴(yán)肅的客戶導(dǎo)向的生產(chǎn)用途來(lái)說(shuō)，它們顯得相當(dāng)笨拙。

因此，這位用戶在吹噓這個(gè)功能有多好的同時(shí)，也暴露了自己在速率限制方面缺乏實(shí)際經(jīng)驗(yàn)。這也印證了那些尋找更好選項(xiàng)的人的觀點(diǎn)，即只要微軟在該領(lǐng)域提供了某種解決方案，開(kāi)發(fā)人員就會(huì)停止尋找最佳工具。這正是有人對(duì)微軟構(gòu)建事件解決方案提出擔(dān)憂的原因所在。

戰(zhàn)略思考與行動(dòng)

對(duì)于 .NET 的開(kāi)源軟件，你或許無(wú)需過(guò)于關(guān)注。選擇微軟的官方解決方案同樣無(wú)可非議。然而，在選擇微軟的解決方案時(shí)，有兩種截然不同的動(dòng)機(jī)：一是因?yàn)槟愦_信它能滿足你的需求，而另一種僅僅是因?yàn)槲④浲瞥隽怂?。盡管這兩種決策過(guò)程最終可能導(dǎo)向相同的結(jié)論，但前者是基于理性的推理，后者則顯得較為牽強(qiáng)附會(huì)。

過(guò)度吹捧摧毀選項(xiàng)只會(huì)損及自己的長(zhǎng)遠(yuǎn)利益，因?yàn)檫@樣做會(huì)讓人才和優(yōu)秀組織疏遠(yuǎn) .NET。下次你在/r/dotnet 上詢問(wèn)“為何主流互聯(lián)網(wǎng)平臺(tái)不采用 .NET？”時(shí)，請(qǐng)銘記，這正是因?yàn)樵?.NET 的過(guò)去，構(gòu)建這些平臺(tái)的工具匱乏。

.NET 自跨平臺(tái)以來(lái)一直在穩(wěn)步發(fā)展。若你希望這種進(jìn)步勢(shì)頭得以延續(xù)，就應(yīng)當(dāng)支持 .NET 生態(tài)系統(tǒng)中選項(xiàng)的擴(kuò)展，而非致力于毀滅它們。

作者簡(jiǎn)介：

Aaron Stannard，Petabridge 公司的首席技術(shù)官兼創(chuàng)始人，致力于通過(guò)開(kāi)發(fā) Akka.NET、Phobos 等項(xiàng)目，讓 .NET 開(kāi)發(fā)人員更輕松地進(jìn)行分布式編程。

原文鏈接:

開(kāi)發(fā)者陣營(yíng)分化，.NET 開(kāi)源生態(tài)系統(tǒng)如何走向未來(lái)？_軟件工程_Aaron Stannard_InfoQ精選文章