本篇將主要介紹go chassis的重要功能，生態對接
註冊中心
在Eureka宣佈停止維護之前，其實已經能夠看到平臺發現會代替客戶端註冊成為主流的執行模式這樣的趨勢，類似Kubernetes這樣的平臺在部署後會幫你自動維護生命週期，而不再是類似Eureka這樣的需要微服務使用開發框架自行註冊，並不斷維護微服務心跳。Go chassis將過去的Registry介面拆分，重新設計為2個元件Registrator與ServiceDiscovery
ServiceDiscovery為必選元件，當離開平臺時可以通過啟用Registrator來或者自注冊和上報心跳的能力（目前僅支援ServiceComb service center）
服務發現積極擁抱了不同生態對接了Istio0.8 和kubernetes。
而在這之上維護了統一的快取模型，以使路由管理能夠通用於不同的註冊中心。
這樣設計無論是容器平臺還是VM等基礎設施都可以適應，加強了go chassis的通用性。
路由管理
Go chassis抽象了router管理介面，可以對接不同生態系統，將這些配置轉換為統一的標準路由定義模型
目前有2個實現：
- 對於非istio環境，可以使用攜程開源的apollo進行路由管理，學習go chassis的配置語法即可
- 支援Istio控制面，如果你已經有Istio了，那麼你可以用原生的Istio流量管理來管理go chassis的路由定義。
過程如下：
1. 請求具有特徵，其中最重要的就是Service Name，即要訪問的服務，根據請求特徵進入路由定義進行匹配，得到他訪問的具體服務是什麼樣的，服務具有怎麼樣的metadata。
2. 根據Service Name即metadata確定一批服務例項
3. 傳到負載均衡進行例項選取
比如
•系統中穩定執行著A服務，版本是1.0，最近新上線了1.1版本，你希望只讓一部分使用者進行體驗，那麼你可以定義Header帶有device-os=android就將95%流量轉移版本為1.0的例項中，5%轉移到1.1版本。
•請求者的後設資料中帶有env=production，那麼要將路由到後設資料中帶有env=production的例項中
基於後設資料的路由管理十分靈活。
多協議支援
在執行態go chassis將協議轉為統一的模型Invocation來處理協議，以此讓所欲接入的協議都能複用負載均衡，路由，限流，分散式追蹤等能力。在網路傳輸時在轉會標準協議請求發出。
配置中心
go chassis使用了go-archaius作為開發庫，可以支援本地檔案及遠端配置中心中的配置管理。
以此來實現配置（熔斷，限流，負載均衡，容錯）變更0當機時間。可以通過Apollo前臺來進行配置下發。https://go-chassis.readthedocs.io/en/latest/user-guides/apollo-chassis.html
同時archaius的API也完全面向開發者，允許業務程式碼使用進行配置管理。
分散式配置管理是個比較大的話題，關於go archaius我將在另一篇章中介紹。
總結
本章節剖析了go chassis內部元件設計的細節，在下一篇章中，將分享效能調優的一些知識
go chassis專案地址：https://github.com/go-chassis/go-chassis
go archaius專案地址： https://github.com/go-chassis/go-archaius