點選上方藍色“Go語言中文網”關注我們，領全套Go資料，每天學習 Go 語言
Micro In Action
本文作者：Che Dan
原文連結：https://medium.com/@dche423/micro-in-action-6-service-discovery-cn-c13c3e3829d
本文是Micro系列文章的第六篇。我們将從最基本的話題開始，逐漸轉到進階特性。
今天來談談Micro中的服務發現。
本系列的第一篇文章曾提到，Micro以插件的形式支援多種服務發現系統。預設情況下，服務發現基于多點傳播DNS(mDNS)機制， 無需任何配置，非常便于在開發環境中使用。
但是在生産環境中， 我們需要可靠性更高的産品。高可靠的注冊中心有很多， 例如 etcd/consul /zookeeper/eureka 等等。針對這些産品， Micro都提供了相應的插件，它甚至提供了Kubernetes插件， 以便把Kubernetes用作注冊中心。
在所有這些産品中， etcd是目前最主流的。它也是Micro官方推薦并内置支援的方案。是以若想在Micro 中使用etcd，與mDNS一樣，無需任何插件即可使用。
連接配接etcd
下面我們将嘗試在示例項目中使用etcd。
etcd本身的安裝與配置不是本文的重點(可以etcd官網找到更多相關資訊)，我們假設你已經擁有一個三節點的etcd叢集， 位址分别是
- etcd1.foo.com:2379
- etcd2.foo.com:2379
- etcd3.foo.com:2379
由于Micro内置支援etcd，我們無需對hello-srv項目的源碼作任何修改，隻需在項目啟動時指定兩個參數：
- registry，指定注冊中心類型，這裡我們指定為**etcd。**環境變量$MICRO_REGISTRY 作用與此參數相同。
- registry_address，指定注冊中心位址，多個位址用逗号分隔。環境變量$MICRO_REGISTRY_ADDRESS 作用與此參數相同。
指定參數并運作程式的結果如下：
注意其中的 Registry [etcd] 字樣， 這說明此刻已經與etcd叢集連接配接成功！
同樣道理， 保持伺服器運作的情況下， 運作本系列的第三篇文章中建立的用戶端項目， 即可完成對服務的調用。
注：除了指令行參數，我們也可以通過環境變量來控制注冊中心的選擇，以上面的程式為例，也可以用如下方式運作：
可見，在Micro中使用etcd是非常簡單的。如果沒有特殊理由， 推薦使用etcd作為注冊中心。
另外，由于
micro
指令行工具與其它Micro項目采用相同架構， 是以micro指令行工具也可以用同樣的方式指定注冊中心。例如：
不過這僅限于内置的etcd和mdns， 如果想使用其它插件， 則需要重新編譯
micro
，這顯然不是一個好方法。Micro 似乎也支援運作時加載插件，如果這是可行的， 那将是比較理想的方式，與此相關的細節會在後續文章中單獨探讨
連接配接consul
雖然Micro推薦使用etcd，但并不限制你作其它選擇。下面我們用執行個體說明Micro中consul的使用方法。
假設已經三節點的consul叢集，其位址分别為
- consul1.foo.com:8300
- consul2.foo.com:8300
- consul3.foo.com:8300
指定相關參數，運作hello-srv：
**服務并沒有順利啟動，**隻列印一些參數提示資訊。
這展現了Micro指令行處理的一個弊端：當不能正确處理傳入參數時 ， 架構不能清晰地回報錯誤所在。這對于新手開發者非常不友好(曾經浪費了我不少時間)。
在本例中， 錯誤的原因是需要在源碼中引入consul插件。
前面文章中提到， 每個項目中都有一個名為 plugin.go 的空檔案， 這是Micro約定用來導入插件的地方。為解決上述問題， 我們修改此檔案：
當然， 同時需要修改go.mod檔案：
注意其中 v1.5.1 非常重要。因為這是與micro v1.18.0 相比對的插件版本。若不指定， 會引來其它錯誤。
修改源碼後再運作：
至此， 我們的程式已經成功連接配接了consul叢集。看起來也非常簡單。
不過你可能會有疑惑， 為什麼registry參數的值是consul，而不是cnsl 或其它什麼？到哪裡能找到插件的名字呢？
這又回到了Micro一直以來作得不好的地方：文檔不足。要解答上述疑惑隻有一個辦法：看源碼 。
不過我在這裡會給你一些線索和規律， 希望可以提高找答案的速度。以consul插件為例， 相關的關鍵源碼在 github.com/micro/go-plugins/registry/consul/consule.go裡 ：
一般情況下， 每一個插件源碼中都會有一個與插件同名的源檔案。這算是插件的主檔案。在這個主檔案中的
init
函數是插件“注冊”的地方。這裡可以看到插件的名字。在本例中，就是 consul。 其它插件也基本遵循這個約定。
上述兩個示例充分展現了Micro插件架構的優越性。無論是使用内置支援的etcd還是consul， 我們幾乎無需修改代碼。 架構把不同産品的差異和複雜度完全隔離在了業務開發之外。由于對業務代碼沒有侵入， 使得我們可以友善地內建和切換不同注冊中心。
當然Micro的插件優勢不僅展現在這裡， 我們在後續的文章将看到更多示例。
總結
Micro幾乎支援市面上所有注冊中心産品，本文以etcd和consul為例進行了具體說明。
雖然有少量細節不盡如人意， 但總體上Micro在服務發現方面的功能是完備和優雅的。
由于有統一的理念貫穿整個Micro生态，使得我們可以用一緻的方式操作官方提供的指令行工具和自己開發的項目。
如果你曾經“手工”處理過分布式系統的服務發現問題， 對比之下你會為Micro化繁為簡的能力點贊。
推薦閱讀
- Micro In Action(五)：Message Broker
喜歡本文的朋友，歡迎關注“Go語言中文網”：
Go語言中文網啟用微信學習交流群，歡迎加微信：274768166，投稿亦歡迎