其他服务注册表的集成

依然是参考该文章，里面给出了三种不同的集成方式。

上图中分别用红、绿、三种颜色标识了这三种不同的集成方式。

该文章的处理建议是走红色路线，实现一个自定义的Adapter。不选择其他路线的原因：

1. 绿色路线ApiServer的性能会是一个瓶颈。
2. 蓝色路线因为galley已经废弃了，不建议启用。

我们在调研的过程中，测试过直接通过k8s的ApiServer操作，无论是对POD还是对ServiceEntry，性能都是一个问题。红色路线需要改动istio的源码，也没有采用。而蓝色路线，看了最新的代码，实际上nacos社区已经支持MCP Over XDS协议，反而是成为我们采用的方案。

实现方案分析

MCP方案代码分析

具体实现方式，在istio启动时，把外部nacos的地址作为configSources传入，schema协议头为xds://。

关键配置信息如下：

apiVersion: v1

data:
  mesh: |-
    accessLogFile: /dev/stdout
    configSources:
        - address: xds://192.168.x.xx:18848
        - address: k8s://localhost/

configController初始化

关键代码分析如下

// initConfigController creates the config controller in the pilotConfig.
func (s *Server) initConfigController(args *PilotArgs) error {
	s.initStatusController(args, features.EnableStatus)
	meshConfig := s.environment.Mesh()
	if len(meshConfig.ConfigSources) > 0 {
		// Using MCP for config.
		if err := s.initConfigSources(args); err != nil {
			return err
		}
	}

//下文省略

如果有配置configSources，则以configSources为准。注意：为了istio能正常服务，k8s依然需要作为配置传入。

xds://处理

//上文省略
case XDS:
			xdsMCP, err := adsc.New(srcAddress.Host, &adsc.Config{
				Namespace: args.Namespace,
				Workload:  args.PodName,
				Revision:  args.Revision,
				Meta: model.NodeMetadata{
					Generator: "api",
					// To reduce transported data if upstream server supports. Especially for custom servers.
					IstioRevision: args.Revision,
				}.ToStruct(),
				InitialDiscoveryRequests: adsc.ConfigInitialRequests(),
			})
			if err != nil {
				return fmt.Errorf("failed to dial XDS %s %v", configSource.Address, err)
			}
			store := memory.Make(collections.Pilot)
			// TODO: enable namespace filter for memory controller
			configController := memory.NewController(store)
			configController.RegisterHasSyncedHandler(xdsMCP.HasSynced)
			xdsMCP.Store = configController
			err = xdsMCP.Run()
			if err != nil {
				return fmt.Errorf("MCP: failed running %v", err)
			}
			s.ConfigStores = append(s.ConfigStores, configController)
			log.Warn("Started XDS config ", s.ConfigStores)

//下文省略

xdsMCP流程

总结一下，xdsMCP里面会建立一个grpc链接，拉取配置信息，外部服务作为ServiceEntry下发。

1. 初始化
2. 根据协议创建grpc连接后，client端发送一个init请求(InitialDiscoveryRequests)，表示自己要监听哪些资源, 外部服务作为ServiceEntry
3. 随后等待对端返回，并分发处理，即go a.handleRecv()

核心代码如下

func (a *ADSC) Run() error {
    var err error
    a.client = discovery.NewAggregatedDiscoveryServiceClient(a.conn)
    a.stream, err = a.client.StreamAggregatedResources(context.Background())
    if err != nil {
       return err
    }
    a.sendNodeMeta = true
    a.InitialLoad = 0
    // Send the initial requests
    for _, r := range a.cfg.InitialDiscoveryRequests {
       if r.TypeUrl == v3.ClusterType {
          a.watchTime = time.Now()
       }
       _ = a.Send(r)
    }
    // by default, we assume 1 goroutine decrements the waitgroup (go a.handleRecv()).
    // for synchronizing when the goroutine finishes reading from the gRPC stream.

    a.RecvWg.Add(1)

    go a.handleRecv()
    return nil
}

configController处理

1. initConfigSources除了xdsMCP.Run()之外，还创建了一个configController，实际是一个内存副本。

   //上文省略
   store := memory.Make(collections.Pilot)
   			// TODO: enable namespace filter for memory controller
   			configController := memory.NewController(store)
   			configController.RegisterHasSyncedHandler(xdsMCP.HasSynced)
   			xdsMCP.Store = configController
   			err = xdsMCP.Run()
   			if err != nil {
   				return fmt.Errorf("MCP: failed running %v", err)
   			}
   			s.ConfigStores = append(s.ConfigStores, configController)
   			log.Warn("Started XDS config ", s.ConfigStores)
   //下文省略
   

2. 这就意味着handleMCP都会触发更新内存中的configStore。RUN的时候除了更新store列表，还起了一个monitor在监听事件。

func (c *Controller) Run(stop <-chan struct{}) {
    c.started.Store(true)
    c.monitor.Run(stop)
}
//事件包括以下几种：
const (
    // EventAdd is sent when an object is added
    EventAdd Event = iota

    // EventUpdate is sent when an object is modified
    // Captures the modified object
    EventUpdate

    // EventDelete is sent when an object is deleted
    // Captures the object at the last known state
    EventDelete
)

结合前面所说的handleMCP对ConfigStore进行增删改之后，会触发monitor相关的事件，从而分发到各handler处理。

总结

MCP方案同步的部分总体流程如下。

 

后续这些配置变更，会经过istio下发到各个数据面，本文不再展开。验证方法可以查看istio控制面日志确认。