新版Bing 搜尋後臺的.NET 技術棧

微軟在今天在Redmond 線下舉辦媒體一場活動，釋出了新版的微軟必應，在桌面上推出了測試版，行動版也即將推出。微軟執行長納德拉稱Al-powered搜尋為公司自雲15年以來最大的事情。

2023年1月初，微軟已經在討論將OpenAI的技術納入Word、PowerPoint、Outlook和其他應用程式，這樣使用者就可以用簡單的提示自動生成文字，2023年1月下旬，微軟宣佈即將會把ChatGPT加入Azure雲服務。新版微軟必應+Chatgpt的測試版會推出，在面對谷歌剛剛宣佈釋出Bard聊天機器人的時刻，這場釋出會就更容易引人注目。

微軟的大量雲服務，包括必應搜尋，他們的技術棧都是.NET , 都是用2014宣佈開源的跨平臺的 .NET ,必應早在2018年就從.NET Framework升級到.NET Core 2.1，具體參見 https://devblogs.microsoft.com/dotnet/bing-com-runs-on-net-core-2-1/。.NET Core為Bing 帶來了的顯著效能改進。

下面將彙總一下微軟的開發部落格——這些部落格均涉及微軟將產品和服務遷移到.NET 6的成果。部落格按時間由近及遠排序。

《Microsoft Teams’ Infrastructure and Azure Communication Services’ Journey to .NET 6》: https://devblogs.microsoft.com/dotnet/microsoft-teams-infrastructure-and-azure-communication-services-journey-to-dotnet-6/

遷移到 .NET Core 是由多種因素驅動的：

成本降低：Azure 計算成本平均節省 29%。
效能提升：效能提升30-50%，包括P99 CPU利用率和P99服務時延。
服務和網路現代化：存取框架中的最新功能，例如輕量級應用程式記憶體佔用，支援Linux上的容器，更好的例外處理，從而在惡劣的條件下獲得更好的可靠性以及最新的安全修復。
提高工程滿意度和生產力

《Microsoft Commerce’s .NET 6 Migration Journey》：https://devblogs.microsoft.com/dotnet/microsoft-commerce-dotnet-6-migration-journey/

一個特別重要的例子是，一個服務從 .NET Framework 遷移到 .NET Core 3.1，同時儘可能多地保留其他相同內容（儘管此更改也包括對 .NET Core 的依賴項更新，以及在遷移其程式碼時所做的小改進）。下圖顯示了服務延遲提高了約 78%，並且在最初部署後（使用相同的負載、環境和硬體執行）顯著提高了穩定性！

隨著我們更復雜的服務遷移到 Kubernetes 中，我們的遷移需要的不僅僅是 .NET：

從Windows 到Linux
.NET 框架到 .NET Core（3.1，在某些情況下為 5.0，現在是 6.0）
平臺轉向容器和Kubernetes（遠離虛擬機器器）
更換構建和釋出系統，以利用最新的安全性和合規性改進並支援容器化應用程式。
隨著我們在遷移時利用平臺和 .NET 中的增強和改進，以及我們的合作伙伴對依賴項執行了相同的操作，還有更多功能。雖然這些好處並不完全歸功於我們的 .NET Core 遷移，但它們是通過遷移實現的，我們非常感謝 .NET 團隊在遷移過程中提供的所有幫助和支援！

《Microsoft Teams Assignments Service’s Journey to .NET 6》：https://devblogs.microsoft.com/dotnet/microsoft-teams-assignments-service-dotnet-6-journey/

在遷移後，我們確實看到了一些 CPU 和延遲的改進，但最一致的改進是記憶體消耗（程序\專用位元組）的減少。隨著我們繼續調整我們的程式碼庫，我們對此遷移解鎖的更有針對性的優化感到非常興奮！例如，我們可以利用它來減少更多程式碼路徑中的分配，因為大多數 BCL API 現在都支援它作為的替代方法。此外，我們現在可以存取 .NET 6 （https://docs.microsoft.com/en-us/dotnet/core/runtime-config/）中的大量新設定選項，並期待調整和調整執行時以更好地適應我們的所有工作負載。

《OneService Journey to .NET 6》：https://devblogs.microsoft.com/dotnet/one-service-journey-to-dotnet-6/

在兩年多的時間裡，我們將大量 .NET Framework 4.7.2 應用、庫和測試專案轉換為 .NET 6，驗證了功能和效能等效性（或更好），現在幾乎完全在生產中的 .NET 6 上執行。該專案取得了重大成功，有助於降低運營成本並改善開發人員體驗。

突出：

基礎設施成本降低 29%。
遷移服務的 CPU 平均提高 30%。
主 API 的 P95 延遲提高了 8-27%。
減少了技術債務，現在可以輕鬆地升級到年度 .NET 版本。
更快樂、更高效的團隊。

《Exchange Online Journey to .NET Core》：https://devblogs.microsoft.com/dotnet/exchange-online-journey-to-net-core/

出於三個原因，我們之所以有動力遷移到 .NET Core。首先，我們非常需要提高效能和成本效益。任何基於雲的供應商都知道，每一次低效率都會花費真金白銀。第二，知道 .NET Framework 不再積極開發，我們希望遷移到一個為未來開闢道路的現代框架。第三，可能更重要的是它很酷，有光澤和新鮮。

《The Azure Cosmos DB Journey to .NET 6》：https://devblogs.microsoft.com/dotnet/the-azure-cosmos-db-journey-to-net-6/

Azure Cosmos DB's API閘道器是一種低延遲的 Azure 服務。它以多種方式利用 .NET 來實現其效能和延遲要求。多年來，每次 .NET 升級都產生了許多好處，既包括新的 API，這些 API 提供了更好的方法來管理效能，並改進了框架中的現有 API 和執行時行為。我們正在積極與 .NET 團隊合作，採用 .NET 7，並期待在即將釋出的 .NET 版本中推出更多影響深遠的效能功能。

《Microsoft Graph’s Journey to .NET 6》：https://devblogs.microsoft.com/dotnet/microsoft-graph-dotnet-6-journey/

四年前，該服務在 IIS 上執行，在 .NET Framework 4.6.2 上 ASP.NET。目前，該服務在 HTTP 上執行.sys.NET 6 上 ASP.NET 核心，在 .NET Core 3.1 和 .NET 5 上暫時停止。每次升級時，我們都觀察到 CPU 利用率有所提高，尤其是在 .NET Core 3.1 和最近的 .NET 6 中。

從 .NET 框架到 .NET Core 3.1，我們觀察到在相同的流量下 CPU 減少了 30%。
從 .NET Core 3.1 到 .NET 5，我們沒有觀察到要報告的有意義的差異。
從 .NET 5 到 .NET 6，我們觀察到在相同的流量下，CPU 又減少了 10%。

CPU 利用率的大幅降低轉化為更好的延遲、吞吐量和有意義的計算容量成本節約，從而有效地幫助我們實現目標。

《Azure Active Directory’s gateway is on .NET 6.0!》：https://devblogs.microsoft.com/dotnet/azure-active-directorys-gateway-is-on-net-6-0/

Azure 活動目錄的閘道器服務是一個反向代理，用於處理構成 Azure 活動目錄（Azure AD）的數百個服務。如果使用了 office.com、outlook.com、portal.azure.com 或 xbox.live.com 等服務，則表示你已使用 Azure AD 的閘道器。閘道器提供 TLS 終止、自動故障轉移/重試、異地鄰近路由、限制和向 Azure AD 中的服務分段等功能。該閘道器存在於全球 54 個 Azure 資料中心，每天為大約 1850 億個請求提供服務。直到最近，Azure AD 的閘道器還在 .NET 5.0 上執行。截至 2021 年 9 月，它已在 .NET 6.0 上執行。

這些部落格都在強烈凸顯著.NET的進步：

更低的CPU消耗
更低的記憶體佔用
更低的響應延遲
更高的吞吐量
更完善的腳手架
更強大的測試和監控工具
……

之後類似的部落格還會發布在：Developer Stories - .NET Blog (microsoft.com) ：https://devblogs.microsoft.com/dotnet/category/developer-stories/ , 有興趣的讀者可以加入收藏夾持續關注。