想要服務寫的好，配置文件不可少。如果是一個復雜的系統，甚至配置文件都是需要進行動態調整的，做起來好像就不是那么方便了，通常情況下，asp.net core中的IConfiguration只能用來讀取，沒有提供保存功能，如果真的要操作一下，只能通過另外寫方法來寫入配置文件。可能是這個玩意設計就是Immutable的吧，總之，很難受。
前言
最近在做一個系統，局域網內工作基於C/S結構，一些配置項目需要從Server端發送到Client端。於是我想的第一件事情，就是給Client一個配置文件，通過Client中指定Server地址，發起通訊，並通過WebAPI，GRPC之類的東西獲得數據。
貌似挺完美的，然而，這個系統的Client端是可以有很多個的，一個個配置那不是很麻煩，萬一服務器地址改了...不敢想。有沒有什么方法可以讓Client自動發現Server，然后自動下載配置的？
方案
當然可以自己搭建一個UDP廣播服務Server，然后Client端監聽廣播，收到廣播之后即可知道IP地址信息，然后進行后續的數據傳輸操作。實現起來還是挺簡單的，可以參考這個問答。
但是我太懶了，我找了找有規范協議的，大概有這么些：
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要被淘汰了，后續的替代，微軟有一篇文章提到了這兩個東西，基本上就是WS-Discovery的Managed方式，提供一個代理用於各種服務進行注冊，但是還是需要提前配置這些服務注冊服務器的地址，達不到我的要求。
3. MDNS
MDNS就是Multicast DNS，在內網沒有DNS服務的時候，可以使用它來進行組播實現DNS。使用UDP協議的5353端口。基於這個協議比較著名的實現就是蘋果的Bonjour，也有一個非常有名的zeroconf也是差不多這個意思，mDNS也是一個標准（RFC6762）。
在前面兩個都用不了的情況下，只能用這個了。
實現
首先安裝nuget包，這個包里面包含有server/Client端。
install-package Makaretu.Dns.Multicast
思路是這樣的，基於ServiceDiscovery發布一個服務，並將額外的信息發布到然后監聽各種mDNS請求，客戶端通過服務名發送查詢請求，並定位服務的地址信息，然后發送SRV，A和TXT查詢請求獲得服務全名，IP地址和額外配置信息。這樣就獲得了在局域網內的服務信息了。
客戶端接收的時候，使用了服務名稱作為篩選的依據。
服務發布端
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();
服務調用端
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<SRVRecord>();
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<AddressRecord>();
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<TXTRecord>();
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虛擬出來的網卡地址，如果是不同計算機的話，就只顯示同一網絡的那個地址了，如果添加網段比較的話，就能變相獲得本機確實可用的網絡地址了。