Istio技術與實踐01： 原始碼解析之Pilot多雲平臺服務發現機制
服務模型
首先，Istio作為一個（微）服務治理的平臺，和其他的微服務模型一樣也提供了Service，ServiceInstance這樣抽象服務模型。如Service的定義中所表達的，一個服務有一個全域名，可以有一個或多個偵聽埠。
type Service struct {
// Hostname of the service, e.g. "catalog.mystore.com"
Hostname Hostname `json:"hostname"`
Address string `json:"address,omitempty"`
Addresses map[string]string `json:"addresses,omitempty"`
// Ports is the set of network ports where the service is listening for connections
Ports PortList `json:"ports,omitempty"`
ExternalName Hostname `json:"external"`
...
}
當然這裡的Service不只是mesh裡定義的service，還可以是通過serviceEntry接入的外部服務。
每個port的定義在這裡：
type Port struct {
Name string `json:"name,omitempty"`
Port int `json:"port"`
Protocol Protocol `json:"protocol,omitempty"`
}
除了port號外，還有 一個name和protocol。可以看到支援如下幾個Protocol
const (
ProtocolGRPC Protocol = "GRPC"
ProtocolHTTPS Protocol = "HTTPS"
ProtocolHTTP2 Protocol = "HTTP2"
ProtocolHTTP Protocol = "HTTP"
ProtocolTCP Protocol = "TCP"
ProtocolUDP Protocol = "UDP"
ProtocolMongo Protocol = "Mongo"
ProtocolRedis Protocol = "Redis"
ProtocolUnsupported Protocol = "UnsupportedProtocol"
)
而每個服務例項ServiceInstance的定義如下
type ServiceInstance struct {
Endpoint NetworkEndpoint `json:"endpoint,omitempty"`
Service *Service `json:"service,omitempty"`
Labels Labels `json:"labels,omitempty"`
AvailabilityZone string `json:"az,omitempty"`
ServiceAccount string `json:"serviceaccount,omitempty"`
}
熟悉SpringCloud的朋友對比下SpringCloud中對應interface，可以看到主要欄位基本完全一樣。
public interface ServiceInstance {
String getServiceId();
String getHost();
int getPort();
boolean isSecure();
URI getUri();
Map<String, String> getMetadata();
}
以上的服務定義的程式碼分析，結合官方spec可以非常清楚的定義了服務發現的資料模型。但是，Istio本身沒有提供服務發現註冊和服務發現的能力，翻遍程式碼目錄也找不到一個儲存服務登錄檔的服務。Discovery部分的文檔是這樣來描述的：
對於服務註冊，Istio認為已經存在一個服務登錄檔來維護應用程式的服務例項(Pod、VM)，包括服務例項會自動註冊這個服務登錄檔上；不健康的例項從目錄中刪除。而服務發現的功能是Pilot提供了通用的服務發現介面，供資料面呼叫動態更新例項。
即Istio本身不提供服務發現能力，而是提供了一種adapter的機制來適配各種不同的平臺。
多平臺支援的Adpater機制
具體講，Istio的服務發現在Pilot中完成，通過以下框圖可以看到，Pilot提供了一種平臺Adapter，可以對接多種不同的平臺獲取服務註冊資訊，並轉換成Istio通用的抽象模型。
從pilot的程式碼目錄也可以清楚看到，至少支援consul、k8s、eureka、cloudfoundry等平臺。
服務發現的主要行為定義
服務發現的幾重要方法方法和前面看到的Service的抽象模型一起定義在中。，可以認為是Istio服務發現的幾個主要行為。
// ServiceDiscovery enumerates Istio service instances.
type ServiceDiscovery interface {
// 服務列表
Services() ([]*Service, error)
// 根據域名的得到服務
GetService(hostname Hostname) (*Service, error)
// 被InstancesByPort代替
Instances(hostname Hostname, ports []string, labels LabelsCollection) ([]*ServiceInstance, error)
//根據埠和標籤檢索服務例項，最重要的以方法。
InstancesByPort(hostname Hostname, servicePort int, labels LabelsCollection) ([]*ServiceInstance, error)
//根據proxy查詢服務例項，如果是sidecar和pod裝在一起，則返回該服務例項，如果只是裝了sidecar，類似gateway，則返回空
GetProxyServiceInstances(*Proxy) ([]*ServiceInstance, error)
ManagementPorts(addr string) PortList
}
下面選擇其中最簡單也可能是大家最熟悉的Eureka的實現來看下這個adapter機制的工作過程
主要流程分析
1. 服務發現服務入口
Pilot有三個獨立的服務分別是agent，discovery和sidecar-injector。分別提供sidecar的管理，服務發現和策略管理，sidecar自動注入的功能。Discovery的入口都是pilot的pilot-discovery。
在service初始化時候，初始化ServiceController 和 DiscoveryService。
if err := s.initServiceControllers(&args); err != nil {
return nil, err
}
if err := s.initDiscoveryService(&args); err != nil {
return nil, err
}
前者是構造一個controller來構造服務發現數據，後者是提供一個DiscoveryService，釋出服務發現數據，後面的分析可以看到這個DiscoveryService向Envoy提供的服務發現數據正是來自Controller構造的資料。我們分開來看。
2. Controller對接不同平臺維護服務發現數據
首先看Controller。在initServiceControllers根據不同的registry型別構造不同的conteroller實現。如對於Eureka的註冊型別，構造了一個Eurkea的controller。
case serviceregistry.EurekaRegistry:
eurekaClient := eureka.NewClient(args.Service.Eureka.ServerURL)
serviceControllers.AddRegistry(
aggregate.Registry{
Name: serviceregistry.ServiceRegistry(r),
ClusterID: string(serviceregistry.EurekaRegistry),
Controller: eureka.NewController(eurekaClient, args.Service.Eureka.Interval),
ServiceDiscovery: eureka.NewServiceDiscovery(eurekaClient),
ServiceAccounts: eureka.NewServiceAccounts(),
})
可以看到controller裡包裝了Eureka的client作為控制代碼，不難猜到服務發現的邏輯正式這個client連Eureka的名字服務的server獲取到。
func NewController(client Client, interval time.Duration) model.Controller {
return &controller{
interval: interval,
serviceHandlers: make([]serviceHandler, 0),
instanceHandlers: make([]instanceHandler, 0),
client: client,
}
}
可以看到就是使用EurekaClient去連EurekaServer去獲取服務發現數據，然後轉換成Istio通用的Service和ServiceInstance的資料結構。分別要轉換convertServices convertServiceInstances,convertPorts,convertProtocol等。
// InstancesByPort implements a service catalog operation
func (sd *serviceDiscovery) InstancesByPort(hostname model.Hostname, port int,
tagsList model.LabelsCollection) ([]*model.ServiceInstance, error) {
apps, err := sd.client.Applications()
services := convertServices(apps, map[model.Hostname]bool{hostname: true})
out := make([]*model.ServiceInstance, 0)
for _, instance := range convertServiceInstances(services, apps) {
out = append(out, instance)
}
return out, nil
}
Eureka client或服務發現數據看一眼，其實就是通過Rest方式訪問/eureka/v2/apps連Eureka叢集來獲取服務例項的列表。
func (c *client) Applications() ([]*application, error) {
req, err := http.NewRequest("GET", c.url+appsPath, nil)
req.Header.Set("Accept", "application/json")
resp, err := c.client.Do(req)
data, err := ioutil.ReadAll(resp.Body)
var apps getApplications
if err = json.Unmarshal(data, &apps); err != nil {
return nil, err
}
return apps.Applications.Applications, nil
}
Application是本地對Instinstance物件的包裝。
type application struct {
Name string `json:"name"`
Instances []*instance `json:"instance"`
}
又看到了eureka熟悉的的定義。當年有個同志提到一個方案是往metadata這個map裡塞租戶資訊，在eureka上做多租。
type instance struct { // nolint: maligned
Hostname string `json:"hostName"`
IPAddress string `json:"ipAddr"`
Status string `json:"status"`
Port port `json:"port"`
SecurePort port `json:"securePort"`
Metadata metadata `json:"metadata,omitempty"`
}
以上我們就看完了服務發現數據生成的過程。對接名字服務的服務發現介面，獲取資料，轉換成Istio抽象模型中定義的標準格式。下面看下這些服務發現數據怎麼提供出去被Envoy使用的。
3. DiscoveryService 釋出服務發現數據
在pilot server初始化的時候，除了前面初始化了一個controller外，還有一個重要的initDiscoveryService初始化Discoveryservice
environment := model.Environment{
Mesh: s.mesh,
IstioConfigStore: model.MakeIstioStore(s.configController),
ServiceDiscovery: s.ServiceController,
..
}
…
s.EnvoyXdsServer = envoyv2.NewDiscoveryServer(environment, v1alpha3.NewConfigGenerator(registry.NewPlugins()))
s.EnvoyXdsServer.Register(s.GRPCServer)
..
即構造gRPC server提供了對外的服務發現介面。DiscoveryServer定義如下
//Pilot支援Evnoy V2的xds的API
type DiscoveryServer struct {
// env is the model environment.
env model.Environment
ConfigGenerator *v1alpha3.ConfigGeneratorImpl
modelMutex sync.RWMutex
services []*model.Service
virtualServices []*networking.VirtualService
virtualServiceConfigs []model.Config
}
即提供了這個grpc的服務發現Server，sidecar通過這個server獲取服務發現的資料，而server使用到的各個服務發現的功能通過Environment中的ServiceDiscovery控制代碼來完成.從前面environment的構造可以看到這個ServiceDiscovery正是上一個init構造的controller。
// Environment provides an aggregate environmental API for Pilot
type Environment struct {
// Discovery interface for listing services and instances.
ServiceDiscovery
這樣幾個功能元件的互動會是這個樣子:
1. Controller使用EurekaClient來獲取服務列表，提供轉換後的標準的服務發現介面和資料結構；
2. Discoveryserver基於Controller上維護的服務發現數據，釋出成gRPC協議的服務供Envoy使用。
非常不幸的是，碼完這篇文字碼完的時候，收到社群裡merge了這個PR ：因為Eureka v2.0 ，Istio服務發現裡。即1.0版本後再也看不到Istio對Eureka的支援了。這裡描述的例子真的就成為一個例子了。
總結
我們以官方文件上這張經典的圖來端到端的串下整個服務發現的邏輯：
1. Pilot中定義了Istio通用的服務發現模型，即開始分析到的幾個資料結構；
2. Pilot使用adapter方式對接不同的(雲平臺的)的服務目錄，提取服務註冊資訊；
3. Pilot使用將2中服務註冊資訊轉換成1中定義的自定義的資料結構。
4. Pilot提供標準的服務發現介面供資料面呼叫。
5. 資料面獲取服務服務發現數據，並基於這些資料更新sidecar後端的LB例項列表，進而根據相應的負載均衡策略將請求轉發到對應的目標例項上。
