想要服務寫的好，配置檔案不可少。如果是一個複雜的系統，甚至配置檔案都是需要進行動態調整的，做起來好像就不是那麼方便了，通常情況下，asp.net core中的IConfiguration只能用來讀取，沒有提供儲存功能，如果真的要操作一下，只能通過另外寫方法來寫入配置檔案。可能是這個玩意設計就是Immutable的吧，總之，很難受。 ## 前言 最近在做一個系統，區域網內工作基於C/S結構，一些配置專案需要從Server端傳送到Client端。於是我想的第一件事情，就是給Client一個配置檔案，通過Client中指定Server地址，發起通訊，並通過WebAPI，GRPC之類的東西獲得資料。 貌似挺完美的，然而，這個系統的Client端是可以有很多個的，一個個配置那不是很麻煩，萬一伺服器地址改了...不敢想。有沒有什麼方法可以讓Client自動發現Server，然後自動下載配置的？ ## 方案 當然可以自己搭建一個UDP廣播服務Server，然後Client端監聽廣播，收到廣播之後即可知道IP地址資訊，然後進行後續的資料傳輸操作。實現起來還是挺簡單的，可以參考這個[問答](https://stackoverflow.com/questions/22852781/how-to-do-network-discovery-using-udp-broadcast)。 但是我太懶了，我找了找有規範協議的，大概有這麼些： ### 1. WS-Discovery WS-Discovery(Web Services Dynamic Discovery,WSD)是一種區域網內的服務發現多播協議，WS-Discovery定義了兩種基本的實現服務發現機制的操作模式，即Ad-Hoc和Managed。 在Ad-Hoc模式下，客戶端在一定的網路範圍了以廣播的形式傳送探測（Probe）訊息以搜尋目標服務。在該探測訊息中，包含相應的搜尋條件。服務該條件的目標服務在接收到探測訊息之後將自身相關的資訊（包括地址）回覆給作為廣播訊息傳送源的客戶端。客戶端根據獲取到的服務資訊，選擇適合的服務進行呼叫。 在Managed模式下，一個維護所有可用目標服務的中心發現代理（Discovery Proxy）被建立起來，客戶端只需要將探測訊息傳送到該發現代理就可以得到相應的目標服務資訊。由於在Ad-Hoc模式下的廣播探測機制在Managed模式下被轉變成單播形式，帶來的好處就是極大地減輕了網路負載（Network Traffic）。 > 這個技術是OASIS標準協議，並且在WCF中有完整實現，對應可以搜尋`UdpDiscoveryEndpoint`就可以找到相關的資訊。 最開始就是想使用這個協議的，不過WCF已經被棄用了，.NET Core沒有對應的服務端支援，可惜。 ### 2. Consul/ZooKeeper 既然WCF要被淘汰了，後續的替代，微軟有一篇[文章](https://docs.microsoft.com/zh-cn/dotnet/architecture/grpc-for-wcf-developers/ws-protocols)提到了這兩個東西，基本上就是WS-Discovery的Managed方式，提供一個代理用於各種服務進行註冊，但是還是需要提前配置這些服務註冊伺服器的地址，達不到我的要求。 ### 3. MDNS MDNS就是Multicast DNS，在內網沒有DNS服務的時候，可以使用它來進行組播實現DNS。使用UDP協議的5353埠。基於這個協議比較著名的實現就是蘋果的Bonjour，也有一個非常有名的zeroconf也是差不多這個意思，mDNS也是一個標準（RFC6762）。 在前面兩個都用不了的情況下，只能用這個了。 ## 實現 首先安裝nuget包，這個包裡面包含有server/Client端。 ```ps install-package Makaretu.Dns.Multicast ``` 思路是這樣的，基於`ServiceDiscovery`釋出一個服務，並將額外的資訊釋出到然後監聽各種mDNS請求，客戶端通過服務名傳送查詢請求，並定位服務的地址資訊，然後傳送SRV，A和TXT查詢請求獲得服務全名，IP地址和額外配置資訊。這樣就獲得了在區域網內的服務資訊了。 > 客戶端接收的時候，使用了服務名稱作為篩選的依據。 服務釋出端 ```c# var sd = new ServiceDiscovery(); //釋出一個服務，服務名稱是有講究的，一般都是_開頭的，可以找一下相關資料 var p = new ServiceProfile("ipfs1", "_ipfs-discovery._udp", 5010); p.AddProperty("connstr", "Server"); //必須要設定這一項，否則不解析TXT記錄 sd.AnswersContainsAdditionalRecords = true; sd.Advertise(p); //sd.Announce(p); Console.ReadKey(); sd.Unadvertise(); ``` 服務呼叫端 ```c# static void Main(string[] args) { var mdns = new MulticastService(); var sd = new ServiceDiscovery(mdns); sd.ServiceInstanceDiscovered += (s, e) => { if (e.Message.Answers.All(w => !w.Name.ToString().Contains("ipfs1"))) return; Console.WriteLine($"service instance '{e.ServiceInstanceName}'"); // Ask for the service instance details. mdns.SendQuery(e.ServiceInstanceName, type: DnsType.SRV); }; mdns.AnswerReceived += (s, e) => { if (e.Message.Answers.All(w => !w.Name.ToString().Contains("ipfs1"))) return; // Is this an answer to a service instance details? var servers = e.Message.Answers.OfType(); foreach (var server in servers) { Console.WriteLine($"host '{server.Target}' for '{server.Name}'"); // Ask for the host IP addresses. mdns.SendQuery(server.Target, type: DnsType.A); //mdns.SendQuery(server.Target, type: DnsType.AAAA); } // Is this an answer to host addresses? var addresses = e.Message.Answers.OfType(); foreach (var address in addresses) { if (address.Address.AddressFamily== AddressFamily.InterNetwork) Console.WriteLine($"host '{address.Name}' at {address.Address}"); } // Get connectionstring from DNS TXT record. var txts = e.Message.Answers.OfType(); foreach (var txt in txts) { //“connstr=Server”，獲得對應connstr值 Console.WriteLine($"{txt.Strings.Single(w => w.Contains("connstr")).Split('=')[1]}"); //Console.WriteLine($"host '{address.Name}' at {address.Address}"); } }; try { mdns.Start(); sd.QueryServiceInstances("_ipfs-discovery._udp"); Console.ReadKey(); } finally { sd.Dispose(); mdns.Stop(); } } ``` 執行效果如下：  ## 總結 最好有一定的DNS的瞭解才會更深入理解這個過程。由於這個服務使用5353埠，我想著是不是在同一臺計算機上同時執行server和client會報錯誤來著。實際上可以正常執行，我本機上執行之後顯示了很多docker虛擬出來的網絡卡地址，如果是不同計算機的話，就只顯示同一網路的那個地址了，如果新增網段比較的話，就能變相獲得本機確實可用的網路地址了。 ## 參考資料 * [https://github.com/richardschneider/net-mdns](https://github.com/richardschneider/net-mdns) * [http://www.360doc.com/content/13/0426/11/3735408_281032366.shtml](http://www.360doc.com/content/13/0426/11/3735408_281032366.shtml) * [https://www.cnblogs.com/azhqiang/p/11024705.html](https://www.cnblogs.com/azhqiang/p/1102470