MOSN – MOSN 博客

Blog: MOSN 源码解析 - 启动流程（v0.4.0）

Wed, 26 Feb 2020 00:00:00 +0000

本文的目的是分析 MOSN 的启动流程。基于 mosn 版本 v0.4.0，commit 为: dc35c8fc95435a47e6393db1c79dd9f60f7eb898

MOSN 简介

MOSN 是一款使用 Go 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议，模块化，智能化，安全的代理能力。

MOSN 在基于 Kubernetes 的 service mesh 中通常扮演数据平面的角色，它作为 sidecar 注入到集群的 Pod 中，接管在 Pod 之间的网络连接。

MOSN 启动流程

我们先找到程序的入口，很多 go 的项目都将程序入口写在 cmd 文件夹中，然后具体的实现写在 pkg 中。MOSN 项目也正好如此。在 cmd/mosn/main/mosn.go 中有我们要的 main 函数，提供了 start, stop 和 reload 命令。其中 stop 和 reload 还未做实现。

//commands
app.Commands = []cli.Command{
	cmdStart,
	cmdStop,
	cmdReload,
}

在 cmd/mosn/main/control.go 中，有　mosn start 执行的代码部分。mosn start 当前有5个参数：

config, c: 提供配置文件的路径，默认值是 configs/mosn_config.json
service-cluster, s: xdsclient 的初始化参数：服务集群名称，这里的集群是 MOSN 连接到的一组逻辑上相似的上游主机
service-node, n: xdsclient 的初始化参数：服务集群中的节点
service-meta, sm: xdsclient 的初始化参数：元数据
feature-gates, f: feature-gates 是 MOSN 的特性开关，当前有三个特性： XdsMtlsEnable, PayLoadLimitEnable 和 MultiTenantMode。

最终可以在 pkg/mosn/starter.go 中找到启动方法：

// Start mosn project
// step1. NewMosn
// step2. Start Mosn
func Start(c *v2.MOSNConfig) {
	//log.StartLogger.Infof("[mosn] [start] start by config : %+v", c)
	Mosn := NewMosn(c)
	Mosn.Start()
	Mosn.wg.Wait()
}

启动方法很简单，Mosn := NewMosn(c) 实例化了一个 Mosn 实例。Mosn.Start() 开始运行。下面主要就 NewMosn(c) 和 Start() 方法做分析。

MOSN 的初始化

在进入到具体初始化之前，我们先看 MOSN 的结构：

type Mosn struct {
	servers        []server.Server
	clustermanager types.ClusterManager
	routerManager  types.RouterManager
	config         *v2.MOSNConfig
	adminServer    admin.Server
	xdsClient      *xds.Client
	wg             sync.WaitGroup
	// for smooth upgrade. reconfigure
	inheritListeners []net.Listener
	reconfigure      net.Conn
}

servers 是一个数组，server.Server 是接口类型。但是目前的代码逻辑中只会有一个 server。

clustermanager 顾名思义就是集群管理器。 types.ClusterManager 也是接口类型。这里的 cluster 指得是 MOSN 连接到的一组逻辑上相似的上游主机。MOSN 通过服务发现来发现集群中的成员，并通过主动运行状况检查来确定集群成员的健康状况。MOSN 如何将请求路由到集群成员由负载均衡策略确定。

routerManager 是路由管理器，MOSN 根据路由规则来对请求进行代理。

adminServer 是一个服务，可以通过 http 请求获取 MOSN 的配置、状态等等

xdsClient 是 xds 协议的客户端。关于 xds, Envoy 通过查询文件或管理服务器来动态发现资源。概括地讲，对应的发现服务及其相应的 API 被称作 xDS。mosn 也使用 xDS，这样就可以兼容 istio。

inheritListeners 和 reconfigure 都是为了实现 MOSN 的平滑升级和重启。

这里我们也要注意到 inheritListeners 和 reconfigure 参数，MOSN 在启动时分为两种情况：

普通启动流程：这种情况下是 MOSN 作为 sidecar 第一次在 Pod 中启动，不需要考虑长连接转移等情况。
热升级/重启流程：在 MOSN 已经作为 sidecar 运行的情况下，如果此时要做 MOSN 的升级/重启，则必须要考虑当前 MOSN 上已有的长连接，如果直接断开连接重启，肯定会对业务有影响。所以 MOSN 在升级/重启时，会进行比较复杂的长连接转移的工作。

在了解以上内容的前提下，现在我们开始具体分析。

NewMosn函数在63行左右，一上来就开始初始化各种配置。比如日志，进程id路径，unix socket 路径，trace的开关（SOFATracer）以及日志插件等等。这里的代码比较简单，就不具体分析每个方法了。

initializeDefaultPath(configmanager.GetConfigPath())
initializePidFile(c.Pid)
initializeTracing(c.Tracing)
initializePlugin(c.Plugin.LogBase)

下面大概在 70 行左右，主要开始做listener的转移。

注意：为了贴出来的代码可以简单，我删除了一些错误处理和日志的语句。并在代码中添加了注释帮助理解

//get inherit fds
inheritListeners, reconfigure, err := server.GetInheritListeners()
if reconfigure != nil {
	// set Mosn Active_Reconfiguring
	store.SetMosnState(store.Active_Reconfiguring)
	// parse MOSNConfig again
	c = configmanager.Load(configmanager.GetConfigPath())
} else {
	// start init services
	if err := store.StartService(nil); err != nil {
		log.StartLogger.Fatalf("[mosn] [NewMosn] start service failed: %v,  exit", err)
	}
}

这段代码的第一行调用了 GetInheritListeners() 来获取要继承过来的监听器。 reconfigure 这个返回值是新旧 MOSN 在 listen.sock 上的连接，如果为空代表了 MOSN 为普通启动，反之为热升级/重启。下面开始分析 GetInheritListeners()。在 GetInheritListeners() 中调用了 isReconfigure() 方法。

func isReconfigure() bool {
	var unixConn net.Conn
	var err error
	unixConn, err = net.DialTimeout("unix", types.ReconfigureDomainSocket, 1*time.Second)
	defer unixConn.Close()

	uc := unixConn.(*net.UnixConn)
	buf := make([]byte, 1)
	n, _ := uc.Read(buf)
	if n != 1 {
		return false
	}
	return true
}

这里通过连接 unix socket reconfig.sock，判断能否读取到数据。旧 MOSN 会监听 reconfig.sock，在有连接进来时发送数据。

l, err := net.Listen("unix", types.ReconfigureDomainSocket)
defer l.Close()
ul := l.(*net.UnixListener)
for {
	uc, err := ul.AcceptUnix()
	_, err = uc.Write([]byte{0})
	uc.Close()
	reconfigure(false)
}

如果能读到，说明已经有一个旧的 MOSN 启动并监听了 reconfig.sock，那么本次启动就是热升级/重启了。同时向 reconfig.sock 发起连接，会使得旧的 MOSN 尝试向 listen.sock 发送要转移的 listener 数组。这个逻辑在上面的 reconfigure(false) 方法中调用 sendInheritListeners() 实现。为了保证旧的 MOSN 可以连上新的 MOSN，这里还重试了10次，并且每次等待1s。也就是说，新 MOSN 在接下来 10s 内可以监听 listen.sock 即可。

// retry 10 time
for i := 0; i < 10; i++ {
	unixConn, err = net.DialTimeout("unix", types.TransferListenDomainSocket, 1*time.Second)
	if err == nil {
		break
	}
	time.Sleep(1 * time.Second)
}

同时，该连接在旧 MOSN 中保持10分钟后，或者读到了代表要退出的数据，旧 MOSN 就会自动退出。如果是确定了是升级或重启，那么 GetInheritListeners() 还会继续执行以下的代码：

// unlink 系统调用比较特殊。关于它的描述中有一点：如果这个文件是一个 unix socket，它会被移除，但是打开它的进程可以继续使用它。也就是说新旧 mosn 都会在这个地址监听。
syscall.Unlink(types.TransferListenDomainSocket)

// 监听
l, err := net.Listen("unix", types.TransferListenDomainSocket)
defer l.Close()

ul := l.(*net.UnixListener)
ul.SetDeadline(time.Now().Add(time.Second * 10))
uc, err := ul.AcceptUnix()

buf := make([]byte, 1)
oob := make([]byte, 1024)
_, oobn, _, _, err := uc.ReadMsgUnix(buf, oob)

scms, err := unix.ParseSocketControlMessage(oob[0:oobn])

if len(scms) != 1 {
	log.StartLogger.Errorf("[server] expected 1 SocketControlMessage; got scms = %#v", scms)
	return nil, nil, err
}

// 解析从另一个进程传来的socket控制消息：打开的文件描述符的整型数组
gotFds, err := unix.ParseUnixRights(&scms[0])

listeners := make([]net.Listener, len(gotFds))

// 这个循环中将文件描述符转换成了listener
for i := 0; i < len(gotFds); i++ {
	fd := uintptr(gotFds[i])
	file := os.NewFile(fd, "")

	defer file.Close()

	fileListener, err := net.FileListener(file)

	if listener, ok := fileListener.(*net.TCPListener); ok {
		listeners[i] = listener
	} else {
		return nil, nil, errors.New("not a tcp listener")
	}
}

return listeners, uc, nil

上面的代码中新的 MOSN 监听了 listen.sock，这样就能获取到旧 MOSN 的所有 listener。当然，如果本次启动是普通启动，那么获取的 inheritListeners 就是 nil。然后根据本次启动是普通启动还是热升级/重启：

如果是普通启动，则直接调用 StartService。需要注意在后面的执行流程中，还会再一次调用 StartService。
如果是热升级/重启，设置当前状态为 Active_Reconfiguring，然后重新加载配置文件，注意在此时并没有调用 StartService。

因为后面还会有StartService的调用，因此 StartService 的逻辑在后面分析，以便理解在不同地方调用的逻辑。

88 行的 initializeMetrics(c.Metrics) 初始化了监控指标，使用了 go-metrics。这里不做分析。

90 行开始是 Mosn 实例的初始化。它传入了上面的 inheritListeners 和 reconfigure 变量。

m := &Mosn{
	config:           c,
	wg:               sync.WaitGroup{},
	inheritListeners: inheritListeners,
	reconfigure:      reconfigure,
}

123 行开始是 clustermanager 的初始化，它会根据是否是 Xds 模式来选择不同的初始化方式。如果是 Xds, 则先用空配置初始化，集群信息会在之后通过 Xds 来获取，否则的话就用配置文件来初始化。

//cluster manager filter
cmf := &clusterManagerFilter{}

// parse cluster all in one
clusters, clusterMap := configmanager.ParseClusterConfig(c.ClusterManager.Clusters)
// create cluster manager
if mode == v2.Xds {
	m.clustermanager = cluster.NewClusterManagerSingleton(nil, nil)
} else {
	m.clustermanager = cluster.NewClusterManagerSingleton(clusters, clusterMap)
}

136 行是路由管理器的初始化

// initialize the routerManager
m.routerManager = router.NewRouterManager()

138 行开始就是对配置中的 servers 进行解析，我们可以根据上面的一处判断得知，当前 MOSN 只会有一个 server，这里的 for 循环应该是为了之后功能扩展准备的。

srvNum := len(c.Servers)
if srvNum == 0 {
	log.StartLogger.Fatalf("[mosn] [NewMosn] no server found")
} else if srvNum > 1 {
	log.StartLogger.Fatalf("[mosn] [NewMosn] multiple server not supported yet, got %d", srvNum)
}

for 循环的代码，具体执行的逻辑我用注释写在了代码上。

for _, serverConfig := range c.Servers {
	//1. server config prepare
	//server config
	c := configmanager.ParseServerConfig(&serverConfig)

	// new server config
	sc := server.NewConfig(c)

	// init default log
	server.InitDefaultLogger(sc)

	var srv server.Server
	if mode == v2.Xds {
	    // xds 模式下，server 的配置是在上面创建的
		srv = server.NewServer(sc, cmf, m.clustermanager)
	} else {
	    // 这里的server配置是从文件中读取的， 可以看 configs 下配置文件来帮助理解
		//initialize server instance
		srv = server.NewServer(sc, cmf, m.clustermanager)

		//add listener
		if serverConfig.Listeners == nil || len(serverConfig.Listeners) == 0 {
			log.StartLogger.Fatalf("[mosn] [NewMosn] no listener found")
		}

		for idx, _ := range serverConfig.Listeners {
			// parse ListenerConfig， 这里面会解析 listeners 的配置，并且和 inheritListeners 中的 listener 比对，如果是同一个连接(端口号相同，ip配置相同)，就继承过来
			lc := configmanager.ParseListenerConfig(&serverConfig.Listeners[idx], inheritListeners)

			// parse routers from connection_manager filter and add it the routerManager
			if routerConfig := configmanager.ParseRouterConfiguration(&lc.FilterChains[0]); routerConfig.RouterConfigName != "" {
				m.routerManager.AddOrUpdateRouters(routerConfig)
			}

			var nfcf []api.NetworkFilterChainFactory
			var sfcf []api.StreamFilterChainFactory

			// Note: as we use fasthttp and net/http2.0, the IO we created in mosn should be disabled
			// network filters
			if !lc.UseOriginalDst {
				// network and stream filters
				nfcf = configmanager.GetNetworkFilters(&lc.FilterChains[0])
				sfcf = configmanager.GetStreamFilters(lc.StreamFilters)
			}

			_, err := srv.AddListener(lc, nfcf, sfcf)
			if err != nil {
				log.StartLogger.Fatalf("[mosn] [NewMosn] AddListener error:%s", err.Error())
			}
		}
	}
	m.servers = append(m.servers, srv)
}

上面就是 MOSN 初始化的分析。主要做了下列的工作：

初始化配置文件路径，日志，进程id路径，unix socket 路径，trace的开关（SOFATracer）以及日志插件。
通过 server.GetInheritListeners() 来判断启动模式（普通启动或热升级/重启），并在热升级/重启的情况下继承旧 MOSN 的监听器文件描述符。
如果是热升级/重启，则设置 Mosn 状态为 Active_Reconfiguring;如果是普通启动，则直接调用 StartService()，关于 StartService 会在之后分析。
初始化指标服务。
根据是否是 Xds 模式初始化配置。
- xds 模式下，使用 nil 来初始化 clustermanager, 非 Xds 模式下(也就是File, Mix模式) ，从配置文件中初始化 clustermanager
- xds 模式下，使用默认配置来实例化 routerManager, 非 Xds 模式下，初始化 routerManager，并从配置文件中读取路由配置更新
- xds 模式下，使用默认配置来实例化 server，非 Xds 模式下，还要从配置文件中读取 listener 并添加。

这里也用时序图来展示热升级/重启的初始化流程:

如果是普通启动，则6,7,8,9,10,11,12是没有的，并且在第5步后会调用StartService。为了便于对比，这里仍然用时序图来展示：

MOSN 的启动

MOSN 启动逻辑实现在 Mosn 的 Start() 方法中，代码如下

func (m *Mosn) Start() {
	m.wg.Add(1)
	// Start XDS if configured
	m.xdsClient = &xds.Client{}
	utils.GoWithRecover(func() {
		m.xdsClient.Start(m.config)
	}, nil)
	// start mosn feature
	featuregate.StartInit()
	// TODO: remove it
	//parse service registry info
	configmanager.ParseServiceRegistry(m.config.ServiceRegistry)

	// beforestart starts transfer connection and non-proxy listeners
	m.beforeStart()

	// start mosn server
	for _, srv := range m.servers {
		utils.GoWithRecover(func() {
			srv.Start()
		}, nil)
	}
}

我们从代码中可以知道，Start() 方法主要做了以下的工作：

启动 xdsClient, xdsClient 负责从 pilot 周期地拉取 listeners/clusters/clusterloadassignment 配置。这个特性使得用户可以通过 crd 来动态的改变 service mesh 中的策略。
开始执行所有注册在 featuregate中 feature 的初始化函数。在 pkg/featuregate/mosn_features.go 文件中的 init() 方法中，可以看到 XdsMtlsEnable、PayLoadLimitEnabl e 和 MultiTenantMode 的注册。
解析服务注册信息
MOSN 启动前的准备工作。详细解析见下面的小章节 2.2.1
正式启动 MOSN 的服务。详细解析见下面的小章节 2.2.2

beforeStart(): MOSN 启动前的最后一步

beforeStart 中主要做了以下的几个工作：

构造 adminServer，将 admin server 加入到全局的 services 中
根据 MOSN 的状态是否是 Active_Reconfiguring
- 如果是热升级/重启，调用 store.StartService(m.inheritListeners)，继承 listener 直接启动。通知旧 MOSN 退出，并从旧 MOSN 中转移长连接。
- 如果是普通启动，store.StartService(nil) 会先监听 listener在启动。
关闭遗留的 listener，也就是在第 2 步中没有使用的 lisenter
开启 dump config
监听 reconfig.sock，这样就可以接收下一次的平滑升级或重启

这里我们先思考一下 store.StartService 的调用逻辑，因为在前文提到，初始化 MOSN 的时候，如果是普通启动，则会调用一次 store.StartService。而热升级/重启则不会调用。而后面无论何种情况都会调用store.StartService，是否多此一举呢？通过注释可以发现，前面是 start init services，后面是 start other services，同时 service 的结构如下：

type service struct {
	start bool
	*http.Server
	name string
	init func()
	exit func()
}

这里想表达的逻辑应该是，如果是普通启动，那么有一些具有 init 变量的服务需要提前启动。在 StartService 中也可以验证这个想法：

if s.init != nil {
	s.init()
}

但是在整个项目中我只找到了三处 service，没有符合条件的。这里可能是为了之后的功能扩展使用的。三处 service 如下所示：

store.AddService(s, “pprof”, nil, nil)
store.AddService(srv, “Mosn Admin Server”, nil, nil)
store.AddService(srv, “prometheus”, nil, nil)

因为普通启动时只有store.StartService(nil)，因此我们这里接着分析在热升级/重启时的长连接转移逻辑。在初始化 MOSN 部分，新的 MOSN 实例已经继承过来 listener 了，为了实现平滑的升级或重启，还需要把旧 MOSN 上的连接也转移过来。在 2.1 小章节中说到，GetInheritListeners() 方法通过监听 listen.sock，继承了旧 MOSN 中的 listener。在这里我们通过继承过来的 listener 在新 MOSN 中启动服务。

// start other services
if err := store.StartService(m.inheritListeners); err != nil {
	log.StartLogger.Fatalf("[mosn] [NewMosn] start service failed: %v,  exit", err)
}

同时新 MOSN 实例拥有了一个叫做 reconfigure（不要被名字误导了，它是新旧 MOSN 在 listen.sock 上的连接）的连接。该连接会在旧 MOSN 中保持10分钟或者读到了代表要退出的数据。在 beforeStart 中，就是使用了 reconfigure 来在新 MOSN 即将启动之际，通知旧的 MOSN 退出。可以看 pkg/mosn/starter.go 的 202 行左右。下面一小段代码中，向 reconfigure 连接写入了一个 0 来通知旧 Mosn 退出。

// notify old mosn to transfer connection
if _, err := m.reconfigure.Write([]byte{0}); err != nil {
	log.StartLogger.Fatalf("[mosn] [NewMosn] graceful failed, exit")
}

m.reconfigure.Close()

旧的 MOSN 在读到上面的 0 后，会执行以下逻辑

停止服务，也就是关闭数据平面
等待3s，这是为了新的 MOSN 启动
停止 accept，这时候就不会有新的连接到旧的 MOSN 上了
等待已有连接完成逻辑。默认是 30s
退出

代码在 pkg/server/reconfigure.go 的 87 行左右：

// Wait new mosn parse configuration
notify.SetReadDeadline(time.Now().Add(10 * time.Minute))
n, err = notify.Read(buf[:])
if n != 1 {
	log.DefaultLogger.Alertf(types.ErrorKeyReconfigure, "new mosn start failed")
	return
}

// stop other services
store.StopService()

// Wait for new mosn start
time.Sleep(3 * time.Second)

// Stop accepting requests
StopAccept()

// Wait for all connections to be finished
WaitConnectionsDone(GracefulTimeout)

log.DefaultLogger.Infof("[server] [reconfigure] process %d gracefully shutdown", os.Getpid())

keeper.ExecuteShutdownCallbacks("")

// Stop the old server, all the connections have been closed and the new one is running
os.Exit(0)

这个时候，我们再回来看长连接的转移。新 MOSN 在通知之后，会立即启动 TransferServer，也就是转移长连接的服务。

// transfer old mosn connections
utils.GoWithRecover(func() {
	network.TransferServer(m.servers[0].Handler())
}, nil)

旧 MOSN 会通过 conn.sock 来发送长连接的文件描述符给新 MOSN。具体调用的方法是pkg/network/transfer.go中的transferRead 和 transferWrite 方法。关于长连接转移的细节非常复杂，MOSN 官网上提供了详细的文档，很值得学习：MOSN 平滑升级原理解析

下面我们用时序图来展示一下长连接的转移过程：

Start(): MOSN 正式启动

经过上面复杂的启动过程，MOSN 正式启动就很简单了。

for _, srv := range m.servers {
	utils.GoWithRecover(func() {
		srv.Start()
	}, nil)
}

对于当前来说，只有一个 server，这个 server 是在 NewMosn 中初始化的。

server := &server{
	serverName: config.ServerName,
	stopChan:   make(chan struct{}),
	handler:    NewHandler(cmFilter, clMng),
}

Start 方法如下：

func (srv *server) Start() {
	// TODO: handle main thread panic @wugou

	srv.handler.StartListeners(nil)

	for {
		select {
		case <-srv.stopChan:
			return
		}
	}
}

基本术语参考

下面基本术语的解释来自于这篇文章：Envoy 中的基本术语

Host：能够进行网络通信的实体（在手机或服务器等上的应用程序）。在 Envoy 中主机是指逻辑网络应用程序。只要每台主机都可以独立寻址，一块物理硬件上就运行多个主机。
Downstream：下游（downstream）主机连接到 Envoy，发送请求并或获得响应。
Upstream：上游（upstream）主机获取来自 Envoy 的链接请求和响应。
Cluster: 集群（cluster）是 Envoy 连接到的一组逻辑上相似的上游主机。Envoy 通过服务发现发现集群中的成员。Envoy 可以通过主动运行状况检查来确定集群成员的健康状况。Envoy 如何将请求路由到集群成员由负载均衡策略确定。
Mesh：一组互相协调以提供一致网络拓扑的主机。Envoy mesh 是指一组 Envoy 代理，它们构成了由多种不同服务和应用程序平台组成的分布式系统的消息传递基础。
运行时配置：与 Envoy 一起部署的带外实时配置系统。可以在无需重启 Envoy 或更改 Envoy 主配置的情况下，通过更改设置来影响操作。
Listener: 监听器（listener）是可以由下游客户端连接的命名网络位置（例如，端口、unix域套接字等）。Envoy 公开一个或多个下游主机连接的侦听器。一般是每台主机运行一个 Envoy，使用单进程运行，但是每个进程中可以启动任意数量的 Listener（监听器），目前只监听 TCP，每个监听器都独立配置一定数量的（L3/L4）网络过滤器。Listenter 也可以通过 Listener Discovery Service（LDS）动态获取。
Listener filter：Listener 使用 listener filter（监听器过滤器）来操作链接的元数据。它的作用是在不更改 Envoy 的核心功能的情况下添加更多的集成功能。Listener filter 的 API 相对简单，因为这些过滤器最终是在新接受的套接字上运行。在链中可以互相衔接以支持更复杂的场景，例如调用速率限制。Envoy 已经包含了多个监听器过滤器。
Http Route Table：HTTP 的路由规则，例如请求的域名，Path 符合什么规则，转发给哪个 Cluster。
Health checking：健康检查会与SDS服务发现配合使用。但是，即使使用其他服务发现方式，也有相应需要进行主动健康检查的情况。详见 health checking。

参考资料

Blog: 以一次 RPC 请求为例探索 MOSN的工作流程

Mon, 11 Mar 2024 00:00:00 +0000

1. 前言

MOSN（Modular Open Smart Network）是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并经过双11大促几十万容器的生产级验证。 MOSN 为服务提供多协议、模块化、智能化、安全的代理能力，融合了大量云原生通用组件，同时也可以集成 Envoy 作为网络库，具备高性能、易扩展的特点。MOSN 可以和 Istio 集成构建 Service Mesh，也可以作为独立的四、七层负载均衡，API Gateway、云原生 Ingress 等使用。

MOSN 作为数据面，整体 NET/IO、Protocol、Stream、Proxy 四个层次组成，其中

NET/IO 用于底层的字节流传输
Protocol 用于协议的 decode/encode
Stream 用于封装请求和响应，在一个 conn 上做连接复用
Proxy 做 downstream 和 upstream 之间 stream 的转发

那么 MOSN 是如何工作的呢？下图展示的是使用 Sidecar 方式部署运行 MOSN 的示意图，您可以在配置文件中设置 MOSN 的上游和下游协议，协议可以在 HTTP、HTTP2.0、以及SOFA RPC 等中选择。以上内容来自官网 https://mosn.io/

2. RPC 场景下 MOSN 的工作机制

RPC 场景下 MOSN 的工作机制示意图如下

我们简单理解一下上面这张图的意义：

Server 端 MOSN 会将自身 ingress 的协议端口写入到注册中心
Client 端 MOSN 会从注册中心订阅地址列表，第一次订阅也会返回全量地址列表，端口号是 Server 端 ingress 绑定的端口号
注册中心会实时推送地址列表变更到 Client 端（全量）
Client 端发起rpc 调用时，请求会被 SDK 打到本地 Client 端 MOSN 的 egress 端口上
Client 端 MOSN 将 RPC 请求通过网络转发，将流量通过负载均衡转发到某一台 Server 端 MOSN 的 ingress 端口处理
最终到了 Server 端 ingress listener，会转发给本地 Server 应用
最终会根据原来的 TCP 链路返回

3. 全局视野下的 MOSN 工作流程

为了方便大家理解，我将以上时序图内容进行拆分，我们一一攻破。

3.1 建立连接

MOSN 在启动期间，会暴露本地 egress 端口接收 Client 的请求。MOSN 会开启 2 个协程，分别死循环去对 TCP 进行读取和写处理。MOSN 会通过读协程获取到请求字节流，进入 MOSN 的协议层处理。

// 代码路径 mosn.io/mosn/pkg/network/connection.go
func (c *connection) Start(lctx context.Context) {
	// udp downstream connection do not use read/write loop
	if c.network == "udp" && c.rawConnection.RemoteAddr() == nil {
		return
	}
	c.startOnce.Do(func() {
    // UseNetpollMode = false
		if UseNetpollMode {
			c.attachEventLoop(lctx)
		} else {
      // 启动读/写循环
			c.startRWLoop(lctx)
		}
	})
}

func (c *connection) startRWLoop(lctx context.Context) {
  // 标记读循环已经启动
	c.internalLoopStarted = true

	utils.GoWithRecover(func() {
    // 开始读操作
		c.startReadLoop()
	}, func(r interface{}) {
		c.Close(api.NoFlush, api.LocalClose)
	})
  // 省略。。。
}

3.2 Protocol 处理

Protocol 作为多协议引擎层，对数据包进行检测，并使用对应协议做 decode/encode 处理。MOSN 会循环解码，一旦收到完整的报文就会创建与其关联的 xstream，用于保持 tcp 连接用于后续响应。

// 代码路径 mosn.io/mosn/pkg/stream/xprotocol/conn.go
func (sc *streamConn) Dispatch(buf types.IoBuffer) {
	// decode frames
	for {
		// 协议 decode，比如 dubbo、bolt 协议等
		frame, err := sc.protocol.Decode(streamCtx, buf)

		if frame != nil {
      // 创建和请求 frame 关联的 xstream，用于保持 tcp 连接用于后续响应
			sc.handleFrame(streamCtx, xframe)
		}
	}
}

func (sc *streamConn) handleFrame(ctx context.Context, frame api.XFrame) {
	switch frame.GetStreamType() {
	case api.Request:
    // 创建和请求 frame 关联的 xstream，用于保持 tcp 连接用于后续响应，之后进入 proxy 层
		sc.handleRequest(ctx, frame, false)
	}
}

func (sc *streamConn) handleRequest(ctx context.Context, frame api.XFrame, oneway bool) {
	// 创建和请求 frame 关联的 xstream
	serverStream := sc.newServerStream(ctx, frame)
  // 进入 proxy 层并创建 downstream
	serverStream.receiver = sc.serverCallbacks.NewStreamDetect(serverStream.ctx, sender, span)
	serverStream.receiver.OnReceive(serverStream.ctx, frame.GetHeader(), frame.GetData(), nil)
}

3.3 Proxy 层处理

proxy 层负责 filter 请求/响应链、路由匹配、负载均衡最终将请求转发到集群的某台机器上。

3.3.1 downStream 部分

// 代码路径 mosn.io/mosn/pkg/proxy/downstream.go
func (s *downStream) OnReceive(ctx context.Context, headers types.HeaderMap, data types.IoBuffer, trailers types.HeaderMap) {
	s.downstreamReqHeaders = headers
  // filter 请求/响应链、路由匹配、负载均衡
  phase = s.receive(s.context, id, phase)
}

func (s *downStream) receive(ctx context.Context, id uint32, phase types.Phase) types.Phase {
	for i := 0; i <= int(types.End-types.InitPhase); i++ {
		s.phase = phase

		switch phase {

		// downstream filter 相关逻辑
		case types.DownFilter:
			s.printPhaseInfo(phase, id)
			s.tracks.StartTrack(track.StreamFilterBeforeRoute)

			s.streamFilterChain.RunReceiverFilter(s.context, api.BeforeRoute,
				s.downstreamReqHeaders, s.downstreamReqDataBuf, s.downstreamReqTrailers, s.receiverFilterStatusHandler)
			s.tracks.EndTrack(track.StreamFilterBeforeRoute)

			if p, err := s.processError(id); err != nil {
				return p
			}
			phase++

		// route 相关逻辑
		case types.MatchRoute:
			s.printPhaseInfo(phase, id)

			s.tracks.StartTrack(track.MatchRoute)
			s.matchRoute()
			s.tracks.EndTrack(track.MatchRoute)

			if p, err := s.processError(id); err != nil {
				return p
			}
			phase++
			
		// 在集群中选择一个机器、包含cluster和loadblance
		case types.ChooseHost:
			s.printPhaseInfo(phase, id)

			s.tracks.StartTrack(track.LoadBalanceChooseHost)
      // 这里很重要，在选中一个机器之后，这里upstreamRequest对象有两个作用
      // 1. 这里通过持有downstream保持着对客户端app的tcp引用，用来接收请求
      // 2. 转发服务端tcp引用，转发客户端app请求以及响应服务端response时的通知
			s.chooseHost(s.downstreamReqDataBuf == nil && s.downstreamReqTrailers == nil)
			s.tracks.EndTrack(track.LoadBalanceChooseHost)

			if p, err := s.processError(id); err != nil {
				return p
			}
			phase++
		}
	}
}

3.3.2 upStream 部分

至此已经选中一台服务端的机器，开始准备转发。

// 代码路径 mosn.io/mosn/pkg/proxy/upstream.go
func (r *upstreamRequest) appendHeaders(endStream bool) {

	if r.downStream.oneway {
		_, streamSender, failReason = r.connPool.NewStream(r.downStream.context, nil)
	} else {
    // 会使用 ChooseHost 中选中的机器 host 创建 sender，xstream 是客户端的流对象
		_, streamSender, failReason = r.connPool.NewStream(r.downStream.context, r)
	}
}

接下来会到达 conn.go 的 handleFrame 的 handleResponse 方法，此时 handleResponse 方法继续调用 downStream 的 receiveData 方法接收数据。

//代码路径 mosn.io/mosn/pkg/stream/xprotocol/conn.go
func (sc *streamConn) handleFrame(ctx context.Context, frame api.XFrame) {
	switch frame.GetStreamType() {
	case api.Response:
    // 调用 downStream 的 receiveData 方法接收数据
    // 因为 mosn 在转发之前修改了请求id，因此会重新 encode 请求
		sc.handleResponse(ctx, frame)
	}
}

一旦准备好转发就会通过 upstreamRequest 选择的下游主机直接发送 write 请求，请求的协程此时会被阻塞。

// 代码路径 mosn.io/mosn/pkg/stream/xprotocol/stream.go
func (s *xStream) endStream() {
	defer func() {
		if s.direction == stream.ServerStream {
			s.DestroyStream()
		}
	}()

	if log.Proxy.GetLogLevel() >= log.DEBUG {
		log.Proxy.Debugf(s.ctx, "[stream] [xprotocol] connection %d endStream, direction = %d, requestId = %v", s.sc.netConn.ID(), s.direction, s.id)
	}

	if s.frame != nil {
		// replace requestID
		s.frame.SetRequestId(s.id)
    // 因为 mosn 在转发之前修改了请求 id，因此会重新 encode 请求
		buf, err := s.sc.protocol.Encode(s.ctx, s.frame)
		if err != nil {
			log.Proxy.Errorf(s.ctx, "[stream] [xprotocol] encode error:%s, requestId = %v", err.Error(), s.id)
			s.ResetStream(types.StreamLocalReset)
			return
		}

		tracks := track.TrackBufferByContext(s.ctx).Tracks

		tracks.StartTrack(track.NetworkDataWrite)
    // 一旦准备好转发就会通过upstreamRequest选择的下游主机直接发送 write 请求，请求的协程此时会被阻塞
		err = s.sc.netConn.Write(buf)
		tracks.EndTrack(track.NetworkDataWrite)
		}
	}
}

3.4 准备将响应写回客户端

接下来客户端 xstream 将通过读协程接收响应的字节流，proxy.go 的 OnData 方法作为 proxy 层的数据接收点。

// 代码位置 mosn.io/mosn/pkg/proxy/proxy.go
func (p *proxy) OnData(buf buffer.IoBuffer) api.FilterStatus {
  // 这里会做两件事
  // 1. 调用 protocol 层进行decode
  // 2. 完成后通知upstreamRequest对象，唤醒downstream阻塞的协程
	p.serverStreamConn.Dispatch(buf)

	return api.Stop
}

// 代码位置 mosn.io/mosn/pkg/proxy/upstream.go
func (r *upstreamRequest) OnReceive(ctx context.Context, headers types.HeaderMap, data types.IoBuffer, trailers types.HeaderMap) {
  // 结束当前stream
	r.endStream()

  // 唤醒
	r.downStream.sendNotify()
}

downstream 被唤醒处理收到的响应，重新替换回正确的请求ID，并调用 protocol 层重新编码成字节流写回客户端，最后销毁请求相关的资源，流程执行完毕。

// 比如我的 demo 是 dubbo 协议
func encodeFrame(ctx context.Context, frame *Frame) (types.IoBuffer, error) {

	// 1. fast-path, use existed raw data
	if frame.rawData != nil {
		// 1.1 replace requestId
		binary.BigEndian.PutUint64(frame.rawData[IdIdx:], frame.Id)

		// hack: increase the buffer count to avoid premature recycle
		frame.data.Count(1)
		return frame.data, nil
	}

	// alloc encode buffer
	frameLen := int(HeaderLen + frame.DataLen)
	buf := buffer.GetIoBuffer(frameLen)
	// encode header
	buf.WriteByte(frame.Magic[0])
	buf.WriteByte(frame.Magic[1])
	buf.WriteByte(frame.Flag)
	buf.WriteByte(frame.Status)
	buf.WriteUint64(frame.Id)
	buf.WriteUint32(frame.DataLen)
	// encode payload
	buf.Write(frame.payload)
	return buf, nil
}

4. 总结

本文以工作中非常常见的一个思路为出发点，详细描述了 MOSN 内部网络转发的详细流程，可以帮助小伙伴加深对 MOSN 的理解。MOSN 是一款非常优秀的开源产品， MOSN 支持多种网络协议（如HTTP/2, gRPC, Dubbo等）并且能够很容易地增加对新协议的支持；MOSN 提供了丰富的流量治理功能，例如限流、熔断、重试、负载均衡等；MOSN 在性能方面进行了大量优化，比如内存零拷贝、自适应缓冲区、连接池、协程池等，这些都有助于提升其在高并发环境下的表现。除此之外 MOSN 在连接管理方面，MOSN 设计了多协议连接池；在内存管理方面，MOSN 在 sync.Pool 之上封装了一层资源对的注册管理模块，可以方便的扩展各种类型的对象进行复用和管理。总的来说，MOSN 的设计体现了可扩展性、高性能、安全性、以及对现代云环境的适应性等多方面的考虑。对于开发者来说，深入研究MOSN的代码和架构，无疑可以学到很多关于高性能网络编程和云原生技术的知识。

MOSN 官网：https://mosn.io/
MOSN Github：https://github.com/mosn/mosn

Blog: MOSN 源码解析 - 启动流程

Sun, 17 Dec 2023 00:00:00 +0000

本文基于 MOSN V1.6.0版本的源码基础上进行整理。该版本对比之前 V0.4.0 版本启动逻辑有比较大的变化。其中比较明显的差异是该版本新增了 StageManager 结构，该结构对 MOSN 的生命周期进行封装并加以维护，使得 MOSN 从启动到停止过程中每个逻辑更易于维护和扩展。

MOSN 启动入口

MOSN 利用 cli 组件（github.com/urfave/cli）来实现命令行的控制。启动之后默认执行 cmdStart 命令，之后就进入下面的启动逻辑。

在 control.go 文件中 cmdStart.Action 方法是整个 MOSN 启动的入口方法。首先调用 NewMosn() 这个方法只是返回了一个空的 Mosn 对象，该对象代表着 Mosn 应用，该对象定义如下：

type Mosn struct {
	isFromUpgrade  bool // hot upgrade from old MOSN
	Upgrade        UpgradeData
	Clustermanager types.ClusterManager
	RouterManager  types.RouterManager
	Config         *v2.MOSNConfig
	// internal data
	servers   []server.Server
	xdsClient *istio.ADSClient
}

场景管理器

下面的逻辑中创建了一个叫 StageManager（场景管理器）的对象，这个对象是用来管理 MOSN 的生命周期，后面的逻辑都是围绕着这个对象来编码的，定义如下：

// stagemanagr/stage_manager.go
// StageManager is used to controls service life stages.
type StageManager struct {
	lock                    sync.Mutex
	state                   State
	exitCode                int
	stopAction              StopAction
	data                    Data  //保存了app不同生命周期阶段所使用的数据
	app                     Application // Application interface app其实就是MOSN
	wg                      sync.WaitGroup
    //以下是不同生命周期对应的处理函数 -- start
	paramsStages            []func(*cli.Context)  //参数准备阶段
	initStages              []func(*v2.MOSNConfig) //初始化场景
	preStartStages          []func(Application)  //启动之前
	startupStages           []func(Application)  //启动
	afterStartStages        []func(Application)  //启动之后
	beforeStopStages        []func(StopAction, Application) error //停止之前
	gracefulStopStages      []func(Application) error  //优雅停止
	afterStopStages         []func(Application) //停止之后处理
    //生命周期阶段 --- end  
	onStateChangedCallbacks []func(State)
	upgradeHandler          func() error // old server: send listener/config/old connections to new server
	newServerC              chan bool
}

// Data contains objects used in stages
type Data struct {
	// ctx contains the start parameters
	ctx *cli.Context
	// config path represents the config file path,
	// will create basic config from it and if auto config dump is set,
	// new config data will write into this path
	configPath string
	// basic config, created after parameters parsed stage
	config *v2.MOSNConfig
}

上面代码增加了注释，可以看到 stageManager 的生命周期包含参数准备、初始化、启动之前处理、启动、启动之后处理、停止之前处理、优雅停止、停止之后处理等几个阶段。每个阶段对应的是一个函数的数组，也就是说每个阶段的处理可以有多个处理函数。

这里可以好好的看一下 stage_manager.go 的源码，里面定义了11种场景的状态和2种额外的场景（stage_manager.go 原文件头部有大块的注释里把场景的含义描述的比较清楚），那么当状态发生变化的时候，就会调用上文提到的场景管理器维护的回调函数。

Application

同时还定义了一个 Application 的接口，是对一个应用进行抽象，其中之前说的 Mosn 对象就是 Application 的一个实现。 Application 被 stageManager 所管理，Application 本身定义了生命周期（ application 不同的生命周期，会触发 stage 场景的切换），周期包括：初始化，启动，停止。那么 stageManager 根据这些周期的变化，同时回调切换场景的函数。

阶段小结

到这里先不着急往下看启动逻辑，我们先总结一下目前掌握的内容及背后的设计思路，这样后面梳理逻辑会变得很轻松。
如上图所示，Application 应用（其实就是 Mosn 本身）包含若干方法：初始化、启动、停止。这些方法调用后让应用进入不同的生命周期，同时场景管理器（StageManager）维护的场景状态也对应发生改变，应用生命周期与场景二者是有关联关系的。

那么先不看源码只凭借猜测，到底是应用的生命周期发生变化后触发场景改变状态；还是先触发场景改变状态进而触发应用改变生命周期呢？我的猜测是这样，因为上文提到场景管理器（StageManager）用来管理应用的生命周期，StageManager 结构体中也包含 Application 对象。那么很大的可能是先由场景管理来触发状态改变，再触发应用对应的方法来改变生命周期。

其实因为场景的状态有11个粒度要比应用的生命周期粒度更细，从这点上来看也只可能场景状态（细粒度）切换同时调用应用的方法切换生命周期（粗粒度），而反之行不通（粗粒度的一方无法识别什么时候调用细粒度一方）。

既然我猜测是 StageManager 场景来控制切换，那么肯定有对应的方法提供场景切换。这个时候我们再来看代码，发现确实存在这样的方法来证明我的猜测。下面是切换场景的方法：

详细分析

场景管理器的启动

我们继续看一下 stage_manager.go 的 Run() 方法，可以清楚的看到场景管理器的启动逻辑，就是调用了不同子阶段，每个阶段都会有切换状态的逻辑，在方法的最后逻辑可以看到，启动之后设置场景状态为 Running。

// Run until the application is started
func (stm *StageManager) Run() {
	// 1: parser params
	stm.runParamsParsedStage()
	// 2: init
	stm.runInitStage()
	// 3: pre start
	stm.runPreStartStage()
	// 4: run
	stm.runStartStage()
	// 5: after start
	stm.runAfterStartStage()

	stm.SetState(Running)
}

可以看到这个 Run() 方法执行了参数解析、初始化、启动前处理、启动、启动后处理等方法。我猜测每个方法一定是执行前文说的每个阶段对应的回调函数数组。找其中一个方法看一下逻辑，果然如我猜测一样。

func (stm *StageManager) runParamsParsedStage() {
	st := time.Now()
    //设置场景状态
	stm.SetState(ParamsParsed) 
    //果然和猜测一样，遍历回调函数的数组并调用
	for _, f := range stm.paramsStages {
		f(stm.data.ctx)
	}
	// after all registered stages are completed
	stm.data.config = configmanager.Load(stm.data.configPath)

	log.StartLogger.Infof("parameters parsed stage cost: %v", time.Since(st))
}

可以说 Run() 方法作用就是场景管理器 stageManager 来启动应用 Application，那这个 Run() 方法在什么地方被调用呢？梳理一下代码，调用链路是：control.go cmdStart.Action(就是前面提到的程序启动的入口)->stm.RunAll()->stm.Run()。这样从上文提到 MOSN 命令行启动到这个 Run() 方法就串起来了。

其中还有一个比较重要的方法是 stm.RunAll() ，该方法是场景管理器中完整的场景都会执行一遍： Run 是启动，之后 WaitFinish 就等待 server 停止，最后是 Stop 场景。每个过程都会调用若干场景切换。

// run all stages
func (stm *StageManager) RunAll() {
	// start to work
	stm.Run()
	// wait server finished
	stm.WaitFinish()
	// stop working
	stm.Stop()
}

启动逻辑详解

好了现在我们回到最开始的 control.go cmdStart.Action 逻辑。

159         Action: func(c *cli.Context) error {
	            // 创建Application
160             app := mosn.NewMosn()
                // 创建stagemanager场景管理器
161             stm := stagemanager.InitStageManager(c, c.String("config"), app)
162             // if needs featuregate init in parameter stage or init stage
163             // append a new stage and called featuregate.ExecuteInitFunc(keys...)
164             // parameter parsed registered
165             stm.AppendParamsParsedStage(ExtensionsRegister)
166             stm.AppendParamsParsedStage(DefaultParamsParsed)
167             // initial registered
168             stm.AppendInitStage(func(cfg *v2.MOSNConfig) {
169                 drainTime := c.Int("drain-time-s")
170                 server.SetDrainTime(time.Duration(drainTime) * time.Second)
171                 // istio parameters
172                 serviceCluster := c.String("service-cluster")
173                 serviceNode := c.String("service-node")
174                 serviceType := c.String("service-type")
175                 serviceMeta := c.StringSlice("service-meta")
176                 metaLabels := c.StringSlice("service-lables")
177                 clusterDomain := c.String("cluster-domain")
178                 podName := c.String("pod-name")
179                 podNamespace := c.String("pod-namespace")
180                 podIp := c.String("pod-ip")
181
182                 if serviceNode != "" {
183                     istio1106.InitXdsInfo(cfg, serviceCluster, serviceNode, serviceMeta, metaLabels)
184                 } else {
185                     if istio1106.IsApplicationNodeType(serviceType) {
186                         sn := podName + "." + podNamespace
187                         serviceNode = serviceType + "~" + podIp + "~" + sn + "~" + clusterDomain
188                         istio1106.InitXdsInfo(cfg, serviceCluster, serviceNode, serviceMeta, metaLabels)
189                     } else {
190                         log.StartLogger.Infof("[mosn] [start] xds service type is not router/sidecar, use config only")
191                         istio1106.InitXdsInfo(cfg, "", "", nil, nil)
192                     }
193                 }
194             })
195             stm.AppendInitStage(mosn.DefaultInitStage)
196             stm.AppendInitStage(func(_ *v2.MOSNConfig) {
197                 // set version and go version
198                 metrics.SetVersion(Version)
199                 metrics.SetGoVersion(runtime.Version())
200                 admin.SetVersion(Version)
201             })
202             stm.AppendInitStage(holmes.Register)
203             // pre-startup
204             stm.AppendPreStartStage(mosn.DefaultPreStartStage) // called finally stage by default
205             // startup
206             stm.AppendStartStage(mosn.DefaultStartStage)
207             // after-stop
208             stm.AppendAfterStopStage(holmes.Stop)
209             // execute all stages
                //执行所有场景
210             stm.RunAll()
211             return nil
212  },

（line160）创建应用 mosn.NewMosn ,
（line161）创建场景管理器 stagemanager.InitStageManager(c, c.String(“config”), app)
（line210）启动场景管理器 stm.RunAll() ，触发执行启动、等待停止、停止。
而中间（第165行到第208行）的一堆逻辑其实就是在设置 StageManager（场景管理器），为每个状态设置了对应的回调函数，后面启动过程中调用场景切换的时候其实就是调用这里设置的回调函数。

ParamsParsed 阶段

(stm *StageManager) AppendParamsParsedStage(f func(*cli.Context))

这个阶段是整个生命周期的第一个阶段，如果需要有需要通过命令行参数来初始化的工作，可以在这个阶段完成。这个阶段注册了两个函数 ExtensionsRegister 和 DefaultParamsParsed 这两个函数作用如下：

ExtensionsRegister ：主要用来初始化一些扩展的组件。这块我理解 MOSN 在落地的时候会根据具体场景来接入一些特定的组件。这些组件如果需要初始化，可以在这个方法里初始化。为什么要在这个函数里初始化呢？一个是函数的参数是 cli.Context 命令行的封装，可以方便获取命令行参数来初始化组件，另外这个函数执行也是整个生命周期最开始执行，如果需要 MOSN 启动首先初始化的组件可以在这里来实现。而 v1.6.0 版本里该函数主要用来初始化一些链路追踪的配置，以及网络协议编解码的设置。这里就不展开分析了。
DefaultParamsParsed ：这里就是 MOSN 默认的在命令解析阶段进行初始化的内容一般不用修改。目前作用是用来设置日志级别及从命令行里解析各种开关。

InitStage阶段

(stm *StageManager) AppendInitStage(f func(*v2.MOSNConfig)) *StageManager

这个是第二个阶段，这个阶段也是用来初始化，只不过初始化的来源是通过 MOSN 的配置文件。

（line168-194）这部分主要是从 Config 配置文件中获取运行环境的相关元数据，用这些数据来初始化 xds 客户端。xds 客户端使用xds协议与控制面组件进行交互。（ xds 是 Istio 标准的协议）
（line195）调用了 MOSN 的默认初始化，这部分逻辑非常的多。里面又细分很多步骤。这里我对每个方法都加上了注释，见下面代码段。

func DefaultInitStage(c *v2.MOSNConfig) {
	InitDefaultPath(c) //初始化mosn需要的相关运行时的目录,比如：日志，存储mosn进程ID的文件等
	InitDebugServe(c)   //启动mosn的debug信息查看服务，可以查看pprof信息
	InitializePidFile(c)  //初始化mosn pid持久化的文件
	InitializeTracing(c)   //初始化mosn 链路追踪的组件，根据配置文件中链路相关的配置。在之前的分析ParamParsed阶段会维护一些mosn支持的链路追踪的驱动列表，然后在这个阶段里会选择一个具体的组件作为链路追踪的实现。
	InitializePlugin(c) //这个阶段是初始化一下插件，不过看了实现其实就是初始化log配置
	InitializeWasm(c) //初始化web assembly 环境
	InitializeThirdPartCodec(c)  //初始化第三方的编解码的配置，这块我也不太理解，需要后面继续研究一下。个人感觉是加载动态代码，目前支持wasm和goPlugin
}

（line196-201）这部分比较简单，AppendInitStage 这部分就是初始化 metrics 初始化统计的组件
接下来（line202）stm.AppendInitStage(holmes.Register) 这句初始化一个蚂蚁开源的可观测性组件 holmes。参考：holmes

PreStartStage阶段

func (stm *StageManager) AppendPreStartStage(f func(Application)) *StageManager

这个阶段逻辑并不复杂，主要是启动 xds 客户端。

// Default Pre-start Stage wrappers
func DefaultPreStartStage(mosn stagemanager.Application) {
	m := mosn.(*Mosn)

	// start xds client
	_ = m.StartXdsClient()
	featuregate.FinallyInitFunc()  //初始化配置中指定的Feature
	m.HandleExtendConfig()  //将配置中扩展配置信息转换成对象
}

StartStage阶段

func (stm *StageManager) AppendStartStage(f func(Application)) *StageManager

（line206） stm.AppendStartStage(mosn.DefaultStartStage) 这个阶段启动了 MOSN 的管理服务，通过配置文件进行启动。

// Default Start Stage wrappers
func DefaultStartStage(mosn stagemanager.Application) {
	m := mosn.(*Mosn)
	// register admin server
	// admin server should register after all prepares action ready
	srv := admin.Server{}
	srv.Start(m.Config)
}

AfterStopStage阶段

func (stm *StageManager) AppendAfterStopStage(f func(Application)) *StageManager

（line208） stm.AppendAfterStopStage(holmes.Stop) 这个阶段是在 MOSN 服务关闭后调用，这里就直接调用 holmes.Stop 关闭 holmes 组件。

Blog: MoE 系列[七] - Envoy Go 扩展之沙箱安全

Sun, 07 May 2023 00:00:00 +0000

前两篇介绍了内存安全和并发安全，今天来到了安全性的最后一篇，沙箱安全，也是相对来说，最简单的一篇。

沙箱安全

所谓的沙箱安全，是为了保护 Envoy，这个宿主程序的安全，也就是说，扩展的 Go 代码运行在一个沙箱环境中，即使 Go 代码跑飞了，也不会把 Envoy 搞挂。

具体到一个场景，也就是当我们使用 Golang 来扩展 Envoy 的时候，不用担心自己的 Go 代码写的不好，而把整个 Envoy 进程搞挂了。

那么目前 Envoy Go 扩展的沙箱安全做到了什么程度呢？

简单来说，目前只做到了比较浅层次的沙箱安全，不过，也是实用性比较高的一层。

严格来说，Envoy Go 扩展加载的是可执行的机器指令，是直接交给 cpu 来运行的，并不像 Wasm 或者 Lua 一样由虚拟机来解释执行，所以，理论上来说，也没办法做到绝对的沙箱安全。

实现机制

目前实现的沙箱安全机制，依赖的是 Go runtime 的 recover 机制。

具体来说，Go 扩展底层框架会自动的，或者（代码里显示启动的协程）依赖人工显示的，通过 defer 注入我们的恢复机制，所以，当 Go 代码发生了奔溃的时候，则会执行我们注入的恢复策略，此时的处理策略是，使用 500 错误码结束当前请求，而不会影响其他请求的执行。

但是这里有一个不太完美的点，有一些异常是 recover 也不能恢复的，比如这几个：

Concurrent map writes
Out of memory
Stack memory exhaustion
Attempting to launch a nil function as a goroutine
All goroutines are asleep - deadlock

好在这几个异常，都是不太容易出现的，唯一一个值得担心的是 Concurrent map writes，不熟悉 Go 的话，还是比较容易踩这个坑的。

所以，在写 Go 扩展的时候，我们建议还是小心一些，写得不好的话，还是有可能会把 Envoy 搞挂的。

当然，这个也不是一个很高的要求，毕竟这是 Gopher 写 Go 代码的很常见的基本要求。

好在大多常见的异常，都是可以 recover 恢复的，这也就是为什么现在的机制，还是比较有实用性。

未来

那么，对于 recover 恢复不了的，也是有解决的思路：

比如 recover 恢复不了 Concurrent map writes，是因为 runtime 认为 map 已经被写坏了，不可逆了。

那如果我们放弃整个 runtime，重新加载 so 来重建 runtime 呢？那影响面也会小很多，至少 Envoy 还是安全的，不过实现起来还是比较的麻烦。

眼下比较浅的安全机制，也足够解决大多数的问题了，嗯。

Blog: mosn基于延迟负载均衡算法 -- 走得更快，期待走得更稳

Fri, 05 May 2023 00:00:00 +0000

前言

这篇文章主要是介绍mosn在v1.5.0中新引入的基于延迟的负载均衡算法（#2253）。首先会对分布式系统中延迟出现的原因进行剖析，之后介绍mosn都通过哪些方法来降低延迟，最后构建来与生产环境性能分布相近的测试用例来对算法进行验证。

在开始聊基于延迟的负载均衡算法之前，先介绍下什么是负载均衡

什么是负载均衡

Wikipedia中 Load Balancing (Computing) 词条是这样介绍负载均衡的：

负载均衡是将一组任务分配到一组资源（计算单元）上的过程，目的是使它们的整体处理更有效率。负载均衡可以优化响应时间，避免负载不均匀导致一些计算节点过载而其他计算节点处于空闲状态

负载均衡在大型分布式系统中是关键的组成部分。负载均衡解决了分布式系统中最重要的两个问题：可伸缩性（scalability）和韧性（resilience）。

可伸缩性：应用程序部署在多个相同的副本中。当计算资源不足时可以通过部署额外的副本来增加计算资源，而当计算资源大量冗余时可以通过减少副本来节省成本。通过负载均衡可以将请求负载分布到不同的副本中。
韧性：分布式系统的故障是部分的。应用程序通过冗余副本的方式，保证在部分组件故障时仍能正常地提供服务。负载均衡通过感知节点的故障，调整流量的分配，将流量更多的分配到那些能够正常提供服务的节点上。

走得更快

负载均衡使得现代软件系统具备了可扩展性和韧性。但在分布式系统中还存在不容忽视的问题：延迟。

延迟来自哪里

现代软件系统通常是多层级结构大型分布式系统，即使是只服务单个终端用户的请求，它背后也有可能经过了上百次的数据访问，这种情况在微服务架构中更是尤为普遍。

微服务架构（引用自Microservices Pattern）

单台性能稳定的服务器中延迟通常由以下几个方面造成：

计算任务本身的复杂度
内容的传输过程中的延迟
请求排队等待的延迟
后台任务活动所导的资源竞争

这些服务器之间的延迟将会叠加，任何显著的延迟增加都会影响终端用户的体验。此外，任何来自单个节点的延迟峰值也会直接影响到终端用户体验。最后，越来越多地使用公有云部署应用程序，进一步加剧了响应时间的不可预测性，因为在这些环境中存在共享资源（CPU、内存和IO）的争用，应用程序机几乎不可避免地遇到性能影响，并且这种影响是随时发生的。

如何减少延迟

有研究表明，在大型互联网应用中，延迟往往具有长尾特点，P999比中位数高出几个数量级。如果在应用架构的每层都能够减少这些尾部延迟，那么对终端用户整体的尾部延迟将会显著降低。

在服务网格中，所有接收和发送的流量都会经过边车代理，通过边车代理可以轻松地控制网格的流量，而无需对服务进行任何修改。如果边车代理在对应用层流量进行转发时，总是通过负载均衡时选择响应时间较短的服务器，那么将会显著降低对终端用户的尾部延迟。

基于此，我们准备开始为mosn引入基于延迟的负载均衡算法，并进行适当调整来保证能够在大多数使用场景下显著减少延迟。

性能问题是局部的

前面提到了，每个节点的性能受到多种因素的影响，这些影响因素是动态的，难以准确预测每个节点的性能，因此我们无法精确地选择最好的节点，但是可以避免较差的节点。

在云环境中，服务器的性能常常是难以预测的，但是我们可以通过对大量的数据进行分析，发现服务器性能的分布大多数情况下是符合正态分布的。因此，尽管有一部分的服务器在性能方面表现比较差，它们的数量通常都是少数的（3sigma），而绝大部分服务器节点的表现是正常的。

除了服务器之间的差异，还存在由基础设施导致的动态延迟，这种延迟可能是由于网络拥塞、故障或不断增长的流量所导致。这种延迟通常具有持续性和局部性。持续性则表示延迟会长时间存在，不会在短时间内消失；而局部性指的是延迟往往只出现在某些特定服务器上，而不会在全局发生。

PeakEWMA

面对这些问题，我们使用PeakEWMA（Peak Exponentially Weighted Moving Average）计算响应时间指标，并根据这个指标来对节点进行负载均衡。

EWMA是一种动态权重调整算法，各数值的加权影响力随时间而指数式衰退，越近期的数据加权影响力越重，但较旧的数据也给予一定的加权值。

它以相对较高的权重考虑了最近响应时间的影响，因此更具有针对性和时效性。加权的程度以常数 𝛼 决定， 𝛼 数值介于 0 至 1，它用来控制数据加权影响力衰退的速率。

作为一种统计学指标，EWMA的计算过程不需要大量的采样点以及时间窗口的设定，有效地避免了计算资源的浪费，更适合在mosn这样的边车代理中使用。

由于响应时间是历史指标，当服务器出现性能问题导致长时间未返回时，负载均衡算法会错误地认为这台服务器仍是最优的，而不断地向其发送请求而导致长尾延迟增高。我们使用活跃连接数作为实时变化的指标对响应时间进行加权，表示等待所有活跃的连接都返回所需要的最大时间。

P2C（Power of Two Choice）

在大规模集群中，如果使用遍历所有服务器选择最好的服务器的方法，虽然可以找到最轻负载的服务器来处理请求，但这种方法通常需要大量的计算资源和时间，因此无法处理大规模的请求。因此，我们使用P2C（Power of Two Choice）来选择最优节点。相比之下，P2C算法可以在常数时间内选择两个服务器进行比较，并选择其中负载更轻的服务器来处理请求。P2C基于概率分配，即不直接基于权重分配，而是根据每个服务器优于其他服务器的概率值来决定请求的分配。

此外，在多个负载均衡器的情况下，不同负载均衡器可能会有不同的节点视图，这可能导致某些负载均衡器选择的最优节点总是最差的节点。这是因为负载均衡器选择最优节点时基于自己的视图信息，而节点视图随着时间的变化可能会发生变化，因此不同的负载均衡器选择的最优节点也可能不同。P2C算法通过对随机选择的两个节点进行比较，可以使节点间的负载均衡更加均匀，即使节点视图发生变化，也能提供稳定的负载均衡效果。

在mosn的v1.5.0版本中，只有节点权重相同时会使用P2C，当权重不同时会使用EDF进行加权选择。后续会提供可配置的选项。

模拟流量验证

我们构建了与生产环境性能分布相近的测试用例来对算法进行验证。

首先我们使用正态分布生成了10台服务器的基准性能，其中数学期望为50ms，标准差为10ms。接下来，我们将这些基准性能作为数学期望，并以标准差为5ms的正态分布随机生成了请求延迟，以模拟真实世界的情况。此外，我们还在其中一台服务器注入了概率为0.1的故障，故障发生时会产生1000ms的延迟，以测试系统的容错性。

为了模拟请求倾斜时请求排队等待的延迟，我们限制了每台服务器的最大并发数为8，当同时处理的最大请求数超过了最大并发数时，将会排队等待。这样能够更加真实地模拟出系统的运行情况。

最后，我们使用了Round Robin、Least Request和PeakEWMA三种算法，分别以16并发同时发送请求，得到的P99如下

Round Robin算法虽然平衡，但是始终会选择到注入了故障的服务器，导致P99始终在1000ms上下波动；Least Request算法虽然避开了故障服务器，但是其P99值依然表现出较大的波动。

与此相比，PeakEWMA算法在保持稳定的同时，P99值始终低于Round Robin和Least Request算法。这恰当地体现了mosn在性能优化方面的成功，mosn确实做到了走得更快。

期待走得更稳

虽然mosn在服务网格中解决了让应用跑得更快的问题，但是分布式系统中的故障却时刻存在。我们期望通过mosn的负载均衡算法，可以让我们的服务走得更稳。

快速失败的挑战

根据经验，故障时的响应时间往往远远小于正常值，比如网络分区导致的连接超时，而没有实际处理请求。我们称这种错误时响应时间远远小于正常值的情况为快速失败。

在服务器出现快速失败时，从负载均衡的角度看，就会错误地认为该服务器是最优的选择。尽管可以通过断路器来避免向该服务器发送长期请求，但断路器本身也是一种快速失败，错误的视图依然会传播。此外，断路器的阈值设置也存在挑战。此外，断路器需要足够的错误样本才能触发，而我们期望尽可能避免错误的发生。

因此，我们在后续版本中将会对负载均衡算法进行调整，让负载均衡算法能够感知错误的发生，并在触发断路器前就避免将请求转发到故障的服务器中。

Blog: MoE 系列[六] - Envoy Go 扩展之并发安全

Sun, 16 Apr 2023 00:00:00 +0000

前一篇介绍了 Envoy Go 扩展的内存安全，相对来说，还是比较好理解的，主要是 Envoy C++ 和 Go GC 都有自己一套的内存对象的生命周期管理。

这篇聊的并发安全，则是专注在并发场景下的内存安全，相对来说会复杂一些。

并发的原因

首先，为什么会有并发呢？

本质上因为 Go 有自己的抢占式的协程调度，这是 Go 比较重的部分，也是与 Lua 这类嵌入式语言区别很大的点。

细节的话，这里就不展开了，感兴趣的可以看这篇 cgo 实现机制 - 从 c 调用 go

这里简单交代一下的，因为 c 调用 go，入口的 Go 函数的运行环境是，Goroutine 运行在 Envoy worker 线程上，但是这个时候，如果发生了网络调用这种可能导致 Goroutine 挂起的，则会导致 Envoy worker 线程被挂起。

所以，解决思路就是像 Go 扩展的异步模式中的示例一样，新起一个 Goroutine，它会运行在普通的 go 线程上。

那么此时，对于同一个请求，则会同时有 Envoy worker 线程和 Go 线程，两个线程并发在处理这个请求，这个就是并发的来源。

但是，我们并不希望用户操心这些细节，而是在底层提供并发安全的 API，把复杂度留在 Envoy Go 扩展的底层实现里。

并发安全的实现

接下来，我们就针对 Goroutine 运行在普通的 Go 线程上，这个并发场景，来聊一聊如何实现并发安全的。

对于 Goroutine 运行在 Envoy 线程上，因为并不存在并发冲突，这里不做介绍。

我们先聊一个简单的，比如在 Go 里面通过 header.Set 写一个请求头。

核心思路是，是通过 dispatcher.post，将写操作当做一个事件派发给 Envoy worker 线程来执行，这样就避免了并发冲突。

读 header 则要复杂不少，因为写不需要返回值，可以异步执行，读就不行了，必须得到返回值。

为此，我们根据 Envoy 流式的处理套路，设计了一个类似于所有权的机制。

Envoy 的流式处理，可以看这篇搞懂 http filter 状态码

简单来说，我们可以这么理解，当进入 decodeHeaders 的时候，header 所有权就交给 Envoy Go 的 c++ 侧了，然后，当通过 cgo 进入 Go 之后，我们会通过一个简单的状态机，标记所有权在 Go 了。

通过这套设计/约定，就可以安全的读取 header 了，本质上，还是属于规避并发冲突。

为什么不通过锁来解决呢？因为 Envoy 并没有对于 header 的锁机制，c++ 侧完全不会有并发冲突。

读写 data 操作

有了这套所有权机制，data 操作就要简单很多了。

因为 header 只有一份，并发冲突域很大，需要考虑 Go 代码与 c++ 侧的其他 filter 的竞争。

data 则是流式处理，我们在 c++ 侧设计了两个 buffer 对象，一个用于接受 filter manager 的流式数据，一个用于缓存交给 Go 侧的数据。

这样的话，交给 Go 来处理的数据，Go 代码拥有完整的所有权，不需要考虑 Go 代码与 C++ 侧其他 filter 的竞争，可以安全的读写，也没有并发冲突。

请求生命周期

另外一个很大的并发冲突，则关乎请求的生命周期，比如 Envoy 随时都有可能提前销毁请求，此时 Goroutine 还在 go thread 上继续执行，并且随时可能读写请求数据。

处理的思路是：

并没有有效的办法，能够立即 kill goroutine，所以，我们允许 goroutine 可能在请求被销毁之后继续执行
但是，goroutine 如果读写请求数据，goroutine 会被终止，panic + recover（recover 细节我们下一篇会介绍）。

那么，我们要做的就是，所有的 API 都检查当前操作的请求是否合法，这里有两个关键：

每请求有一个内存对象，这个对象只会由 Go 来销毁，并不会在请求结束时，被 Envoy 销毁，但是这个内存对象中保存了一个 weakPtr，可以获取 C++ filter 的状态。

通过这个机制，Go 可以安全的获取 C++ 侧的 filter，判断请求是否还在。
同时，我们还会在 onDestroy，也就是 C++ filter 被销毁的 hook 点；以及 Go thread 读写请求数据，这两个位置都加锁处理，以解决这两个之间的并发冲突。

最后

对于并发冲突，其实最简单的就是，通过加锁来竞争所有权，但是 Envoy 在这块的底层设计并没有锁，因为它根本不需要锁。

所以，基于 Envoy 的处理模型，我们设计了一套类似所有权的机制，来避免并发冲突。

所有权的概念也受到了 Rust 的启发，只是两者工作的层次不一样，Rust 是更底层的语言层面，可以作用于语言层面，我们这里则是更上层的概念，特定于 Envoy 的处理模型，也只能作用于这一个小场景。

但是某种程度上，解决的问题，以及其中部分思想是一样的。

Blog: MoE 系列 [五] - Envoy Go 扩展之内存安全

Sun, 09 Apr 2023 00:00:00 +0000

前面几篇介绍了 Envoy Go 扩展的基本用法，接下来几篇将介绍实现机制和原理。

Envoy 是 C++ 实现的，那 Envoy Go 扩展，本质上就相当于把 Go 语言嵌入 C++里了。

在 Go 圈里，将 Go 当做嵌入式语言来用的，貌似并不太多见，这里面细节还是比较多的。比如：

Envoy 有一套自己的内存管理机制，而 Go 又是一门自带 GC 的语言
Envoy 是基于 libevent 封装的事件驱动，而 Go 又是包含了抢占式的协程调度

为了降低用户开发时的心智负担，我们提供了三种的安全保障。有了这三层保障，用户写 Go 来扩展 Envoy 的时候，就可以像平常写 Go 代码一样简单，而不必关心这些底层细节。

三种安全

内存安全

用户通过 API 获取到的内存对象，可以当做普通的 Go 对象来使用

比如，通过 headers.Get 得到的字符串，在请求结束之后还可以使用，而不用担心请求已经在 Envoy 侧结束了，导致这个字符串被提前释放了
并发安全

当启用协程的时候，我们的 Go 代码将会运行在另外的 Go 线程上，而不是在当前的 Envoy worker 线程上，此时对于同一个请求，则存在 Envoy worker 线程和 Go 线程的并发

但是，用户并不需要关心这个细节，我们提供的 API 都是并发安全的，用户可以不感知并发的存在
沙箱安全

这一条是针对宿主 Envoy 的保障，因为我们并不希望某一个 Go 扩展的异常，把整个 Envoy 进程搞奔溃了。

目前我们提供的是，Go runtime 可以 recover 的有限沙箱安全，这通常也足够了。

更深度的，runtime 也 recover 不了的，比如 map 并发访问，则只能将 Go so 重载，重建整个 Go runtime 了，这个后续也可以加上。

内存安全实现机制

要提供安全的内存机制，最简单的办法，也是（几乎）唯一的办法，就是复制。但是，什么时候复制，怎么复制，还是有一些讲究的。这里权衡的目标是降低复制的开销，提升性能。

这里讲的内存安全，还不涉及并发时的内存安全，只是 Envoy（C++）和 Go 这两个语言/运行时之间的差异。

PS：以前混 OpenResty 的时候，也是复制的玩法，只是有一点区别是，Lua string 的 internal 归一化在大内存场景下，会有相对较大的开销；Go string 则没有这一层开销，只有 memory copy + GC 的开销。

复制时机

首先是复制时机，我们选择了按需复制，比如 header，body data 并不是一开始就复制到 Go 里面，只在有对应的 API 调用时，才会真的去 Envoy 侧获取 & 复制。

如果没有被真实需要，则并不会产生复制，这个优化对于 header 这种常用的，效果倒是不太明显，对于 body 这种经常不需要获取内容的，效果则会比较的明显。

复制方式

另一个则是复制方式，比如 header 获取上，我们采用的是在 Go 侧预先申请内存，在 C++ 侧来完成赋值的方式，这样我们只需要一次内存赋值即可完成。

这里值得一提的是，因为我们在进入 Go 的时候，已经把 header 的大小传给了 Go，所以我们可以在 Go 侧预先分配好需要的内存。

不过呢，这个玩法确实有点 tricky，并不是 Go 文档上注明推荐的用法，但是呢，也确实是我们发现的最优的解法了。

如果按照 Go 常规的玩法，我们可能需要一次半/两次内存拷贝，才能保证安全，这里有个半次的差异，就是我们下回要说的并发造成的。

另外，在 API 实现上，我们并不是每次获取一个 header，而是直接一次性把所有的 header 全复制过来了，在 Go 侧缓存了。这是因为大多数场景下，我们需要获取的 header 数量会有多个，在权衡了 cgo 的调用开销和内存拷贝的开销之后，我们认为一次性全拷贝是更优的选择。

最后

相对来说，不考虑并发的内存安全，还是比较简单的，只有复制最安全，需要权衡考虑的则更多是优化的事情了。

比较复杂的还是并发时的安全处理，这个我们下回再聊。

Blog: MoE 系列 [四] - Go 扩展的异步模式

Sat, 18 Mar 2023 00:00:00 +0000

上一篇我们体验了用 Istio 做控制面，给 Go 扩展推送配置，这次我们来体验一下，在 Go 扩展的异步模式下，对 goroutine 等全部 Go 特性的支持。

异步模式

之前，我们实现了一个简单的 basic auth，但是，那个实现是同步的，也就是说，Go 扩展会阻塞，直到 basic auth 验证完成，才会返回给 Envoy。

因为 basic auth 是一个非常简单的场景，用户名密码已经解析在 Go 内存中了，整个过程只是纯 CPU 计算，所以，这种同步的实现方式是没问题的。

但是，如果我们要实现一个更复杂的需求，比如，我们要将用户名密码，调用远程接口查询，涉及网络操作，这个时候，同步的实现方式就不太合适了。因为，同步模式下，如果我们要等待远程接口返回，那么，Go 扩展就会阻塞，Envoy 也就无法处理其他请求了。

所以，我们需要一种异步模式：

我们在 Go 扩展中，启动一个 goroutine，然后立即返回给 Envoy，当前正在处理的请求会被挂起，Envoy 则可以继续处理其他请求。
goroutine 在后台异步执行，当 goroutine 中的任务完成之后，再回调通知 Envoy，挂起的请求可以继续处理了。

注意：虽然 goroutine 是异步执行，但是 goroutine 中的代码，与同步模式下的代码，几乎是一样的，并不需要特别的处理。

为什么需要

为什么需要支持 Goroutine 等全部 Go 的特性呢？

有两方面的原因：

有了 full feature supported Go，我们可以实现很非常强大，复杂的扩展
可以非常方便的集成现有的 Go 世界的代码，享受 Go 生态的红利

如果不支持全部的 Go 特性，那么在集成现有 Go 代码的时候，会有诸多限制，导致需要重写大量的代码，这样，就享受不到 Go 生态的红利了。

实现

接下来，我们还是通过一个示例来体验，这次我们实现 basic auth 的远程校验版本，关键代码如下：

func (f *filter) DecodeHeaders(header api.RequestHeaderMap, endStream bool) api.StatusType {
	go func() {
        // verify 中的代码，可以不需要感知是否异步
        // 同时，verify 中是可以使用全部的 Go 特性，比如，http.Post
		if ok, msg := f.verify(header); !ok {
			f.callbacks.SendLocalReply(401, msg, map[string]string{}, 0, "bad-request")
			return
		}
        // 这里是唯一的 API 区别，异步回调，通知 Envoy，可以继续处理当前请求了
		f.callbacks.Continue(api.Continue)
	}()
    // Running 表示 Go 还在处理中，Envoy 会挂起当前请求，继续处理其他请求
	return api.Running
}

再来看 verify 的代码，重点是，我们可以在这里使用全部的 Go 特性：

// 这里使用了 http.Post
func checkRemote(config *config, username, password string) bool {
	body := fmt.Sprintf(`{"username": "%s", "password": "%s"}`, username, password)
	remoteAddr := "http://" + config.host + ":" + strconv.Itoa(int(config.port)) + "/check"
	resp, err := http.Post(remoteAddr, "application/json", strings.NewReader(body))
	if err != nil {
		fmt.Printf("check error: %v\n", err)
		return false
	}
	if resp.StatusCode != 200 {
		return false
	}
	return true
}

// 这里操作 header 这个 interface，与同步模式完全一样
func (f *filter) verify(header api.RequestHeaderMap) (bool, string) {
	auth, ok := header.Get("authorization")
	if !ok {
		return false, "no Authorization"
	}
	username, password, ok := parseBasicAuth(auth)
	if !ok {
		return false, "invalid Authorization format"
	}
	fmt.Printf("got username: %v, password: %v\n", username, password)

	if ok := checkRemote(f.config, username, password); !ok {
		return false, "invalid username or password"
	}
	return true, ""
}

另外，我们还需要实现一个简单的 HTTP 服务，用来校验用户名密码，这里就不展开了，用户名密码还是 foo:bar。

完整的代码，请移步 github。

测试

老规矩，启动之后，我们使用 curl 来测试一下：

$ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST:$INGRESS_PORT/status/200"
HTTP/1.1 401 Unauthorized

# valid foo:bar
$ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST:$INGRESS_PORT/status/200" -H 'Authorization: basic Zm9vOmJhcg=='
HTTP/1.1 200 OK

依旧符合预期。

总结

在同步模式下，Go 代码中常规的异步非阻塞，也会变成阻塞执行，这是因为 Go 和 Envoy 是两套事件循环体系。

而通过异步模式，Go 可以在后台异步执行，不会阻塞 Envoy 的事件循环，这样，就可以用上全部的 Go 特性了。

由于 Envoy Go 暴露的是底层的 API，所以实现 Go 扩展的时候，需要关心同步和异步的区别。

当然，这对于普通的扩展开发而言，并不是一个友好的设计，只所有这么设计，更多是为了极致性能的考量。

大多数场景下，其实并不需要到这么极致，所以，我们会在更上层提供一种，默认异步的模式，这样，Go 扩展的开发者，就不需要关心同步和异步的区别了。

欢迎感兴趣的持续关注~

Blog: MoE 系列 [三] - 使用 Istio 动态更新 Go 扩展配置

Thu, 16 Mar 2023 00:00:00 +0000

上一篇我们用 Go 扩展实现了 basic auth，体验了 Go 扩展从 Envoy 接受配置。

只所以这么设计，是想复用 Envoy 原有的 xDS 配置推送通道，这不，今天我们就来体验一番，云原生的配置变更。

前提准备

这次我们需要一套 k8s 环境，如果你手头没有，推荐使用 kind 安装一套。具体安装方式，这里就不展开了。

安装 Istio

我们直接安装最新版的 Istio：

# 下载最新版的 istioctl
$ export ISTIO_VERSION=1.18.0-alpha.0
$ curl -L https://istio.io/downloadIstio | sh -

# 将 istioctl 加入 PATH
$ cd istio-$ISTIO_VERSION/
$ export PATH=$PATH:$(pwd)/bin

# 安装，包括 istiod 和 ingressgateway
$ istioctl install

是的，由于 Go 扩展已经贡献给了上游官方，Istiod（pilot）和 ingressgateway 都已经默认开启了 Go 扩展，并不需要重新编译。

Istio 配置 Ingress

我们先用 Istio 完成标准的 Ingress 场景配置，具体可以看 istio 的官方文档

配置好了之后，简单测试一下：

$ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST:$INGRESS_PORT/status/200"
HTTP/1.1 200 OK
server: istio-envoy
date: Fri, 10 Mar 2023 15:49:37 GMT

基本的 Ingress 已经跑起来了。

挂载 Golang so

之前我们介绍过，Go 扩展是单独编译为 so 文件的，所以，我们需要把 so 文件，挂载到 ingressgateway 中。

这里我们把上次 basic auth 编译出来的 libgolang.so，通过本地文件挂载进来。简单点搞，直接 edit deployment 加了这些配置：

# 申明一个 hostPath 的 volume
volumes:
- name: golang-so-basic-auth
  hostPath:
    path: /data/golang-so/example-basic-auth/libgolang.so
    type: File

# 挂载进来
volumeMounts:
- mountPath: /etc/golang/basic-auth.so
  name: golang-so-basic-auth
  readOnly: true

开启 Basic auth 认证

Istio 提供了 EnvoyFilter CRD，所以，用 Istio 来配置 Go 扩展也比较的方便，apply 这段配置，basic auth 就开启了。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: golang-filter
  namespace: istio-system
spec:
  configPatches:
    # The first patch adds the lua filter to the listener/http connection manager
  - applyTo: HTTP_FILTER
    match:
      context: GATEWAY
      listener:
        filterChain:
          filter:
            name: "envoy.filters.network.http_connection_manager"
            subFilter:
              name: "envoy.filters.http.router"
    patch:
      operation: INSERT_BEFORE
      value: # golang filter specification
       name: envoy.filters.http.golang
       typed_config:
          "@type": "type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config"
          library_id: example
          library_path: /etc/golang/basic-auth.so
          plugin_name: basic-auth
          plugin_config:
            "@type": "type.googleapis.com/xds.type.v3.TypedStruct"
            type_url: typexx
            value:
              username: foo
              password: bar

虽然有点长，但是，也很明显，配置的用户名密码还是：foo:bar

测试

我们测试一下：

$ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST:$INGRESS_PORT/status/200"
HTTP/1.1 401 Unauthorized

# valid foo:bar
$ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST:$INGRESS_PORT/status/200" -H 'Authorization: basic Zm9vOmJhcg=='
HTTP/1.1 200 OK

符合预期。

接下来，我们改一下 EnvoyFilter 中的密码，重新 apply，再测试一下：

# foo:bar not match the new password
$ curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST:$INGRESS_PORT/status/200" -H 'Authorization: basic Zm9vOmJhcg=='
HTTP/1.1 401 Unauthorized

此时的 Envoy 并不需要重启，新的配置就立即生效了，云原生的体验就是这么溜~

总结

因为 Go 扩展可以利用 Envoy 原有的 xDS 来接受配置，所以，从 Istio 推送配置也变得很顺利。

不过呢，Istio 提供的 EnvoyFilter CRD 在使用上，其实并不是那么方便 & 自然，后面我们找机会试试 EnvoyGateway，看看 k8s Gateway API 的体验咋样。

至此，我们已经体验了整个 Envoy Go 的开发 & 使用流程，在云原生时代，人均 Golang 的背景下，相信可以很好的完成网关场景的各种定制需求。

下一篇，我们将介绍，如何在 Go 扩展中使用异步协程。这意味着，我们可以使用的是一个全功能的 Go 语言，而不是像 Go Wasm 那样，只能用阉割版的。

敬请期待 ~

Blog: MoE 系列 [二] - Golang 扩展从 Envoy 接收配置

Thu, 09 Mar 2023 00:00:00 +0000

上一篇我们用一个简单的示例，体验了用 Golang 扩展 Envoy 的极速上手。

这次我们再通过一个示例，来体验 Golang 扩展的一个强大的特性：从 Envoy 接收配置。

Basic Auth

我们还是从一个小示例来体验，这次我们实现标准的 basic auth 的认证，与上一次示例不同的是，这次认证的用户密码信息，需要从 Envoy 传给 Go，不能在 Go 代码中写死了。

完整的代码可以看 example-basic-auth，下面我们展开介绍一番。

获取配置

为了更加灵活，在设计上，Envoy 传给 Go 的配置是 Protobuf 的 Any 类型，也就是说，配置内容对于 Envoy 是透明的，我们在 Go 侧注册一个解析器，来完成这个 Any 配置的解析。

如下示例：

func init() {
	// 注册 parser
	http.RegisterHttpFilterConfigParser(&parser{})
}

func (p *parser) Parse(any *anypb.Any) interface{} {
	configStruct := &xds.TypedStruct{}
	if err := any.UnmarshalTo(configStruct); err != nil {
		panic(err)
	}

	v := configStruct.Value
	conf := &config{}
	if username, ok := v.AsMap()["username"].(string); ok {
		conf.username = username
	}
	if password, ok := v.AsMap()["password"].(string); ok {
		conf.password = password
	}
	return conf
}

这里为了方便，Any 中的类型是 Envoy 定义的 TypedStruct 类型，这样我们可以直接使用现成的 Go pb 库。

值得一提的是，这个配置解析，只有在首次加载的时候需要执行，后续在 Go 使用的是解析后的配置，所以，我们解析到一个 Go map 可以拥有更好的运行时性能。

同时，由于 Envoy 的配置，也是有层级关系的，比如 http-filter, virtual host, router, virtual clusters 这四级，我们也支持这四个层级同时有配置，在 Go 侧来组织 merge。

当然，这个只有在 Go 侧有复杂的 filter 组织逻辑的时候用得上，后面我们在 MOSN 的上层封装的时候，可以看到这种用法，这里暂时不做展开介绍。

认证

具体的 Basic Auth 认证逻辑，我们可以参考 Go 标准 net/http 库中的 BasicAuth 实现。

func (f *filter) verify(header api.RequestHeaderMap) (bool, string) {
	auth, ok := header.Get("authorization")
	if !ok {
		return false, "no Authorization"
	}
	username, password, ok := parseBasicAuth(auth)
	if !ok {
		return false, "invalid Authorization format"
	}
	if f.config.username == username && f.config.password == password {
		return true, ""
	}
	return false, "invalid username or password"
}

这里面的 parseBasicAuth 就是从 net/http 库中的实现，是不是很方便呢。

配置

简单起见，这次我们使用本地文件的配置方式。如下是关键的配置：

http_filters:
  - name: envoy.filters.http.golang
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config
      library_id: example
      library_path: /etc/envoy/libgolang.so
      plugin_name: basic-auth
      plugin_config:
        "@type": type.googleapis.com/xds.type.v3.TypedStruct
        value:
          username: "foo"
          password: "bar"

这里我们配置了用户名密码：foo:bar。

预告一下，下一篇我们会体验通过 Istio 来推送配置，体会一番动态更新配置的全流程。

测试

编译，运行，跟上篇一样，我们还是使用 Envoy 官方提供的镜像即可。

跑起来之后，我们测试一下：

$ curl -s -I 'http://localhost:10000/'
HTTP/1.1 401 Unauthorized

# invalid username:password
$ curl -s -I 'http://localhost:10000/' -H 'Authorization: basic invalid'
HTTP/1.1 401 Unauthorized

# valid foo:bar
$ curl -s -I 'http://localhost:10000/' -H 'Authorization: basic Zm9vOmJhcg=='
HTTP/1.1 200 OK

是不是很简单呢，一个标准的 basic-auth 扩展就完成了。

总结

Envoy 是面向云原生的架构设计，提供了配置动态变更的机制，Go 扩展可以从 Envoy 接受配置，也就意味着 Go 扩展也可以很好的利用这套机制。

Go 扩展的开发者，不需要关心配置的动态更新，只需要解析配置即可，非常的方便~

下一篇我们会介绍，配合 Istio 来动态更新用户名密码，体验一番云原生的配置变更体验。

后续还有更多 Golang 扩展的特性介绍，原理解析，以及，更上层的 MOSN 集成体验，欢迎持续关注。

Blog: MoE 系列 - 如何使用 Golang 扩展 Envoy [一]

Mon, 27 Feb 2023 00:00:00 +0000

背景

MoE，MOSN on Envoy 是 MOSN 团队提出的技术架构，经过近两年的发展，在蚂蚁内部已经得到了很好的验证；并且去年我们也将底层的 Envoy Go 七层扩展贡献了 Envoy 官方，MOSN 也初步支持了使用 Envoy 作为网络底座的能力。

准备写一系列的文章，逐一介绍这里面的技术，本文是开篇，重点介绍 MoE 中的基础技术，Envoy Go 扩展。

FAQ

开始前，先回答几个基本的问题：

MoE 与 Envoy Go 扩展的区别

MoE 是技术架构，Envoy Go 扩展是连接 MOSN 和 Envoy 的基础技术
Envoy Go 扩展，与用 Go 来编译 Wasm 有什么区别

Envoy Go 支持 Go 语言的所有特性，包括 Goroutine，Go Wasm 则只能使用少量的 Go 语言特性，尤其是没有 Goroutine 的支持
Go 是静态链接到 Envoy 么？

不是的，Go 扩展编译成为 so，Envoy 动态加载 so，不需要重新编译 Envoy
Envoy Go 支持流式处理么？

支持的。

由于 Go 扩展提供的是底层的 API，非常的灵活，使用上相对会稍微复杂一些；如果只想简单的使用，可以使用 MOSN 的 filter，后面我们也会介绍。

需求

我们先实现一个小需求，来实际体会一下：

对请求需要进行验签，大致是从 URI 上的某些参数，以及私钥计算一个 token，然后和 header 中的 token 进行对比，对不上就返回 403。

很简单的需求，仅仅作为示例，主要是体验一下过程。

代码实现

完整的代码可以看 envoy-go-filter-example 这个仓库

这里摘录最核心的两个函数：

const secretKey = "secret"

func verify(header api.RequestHeaderMap) (bool, string) {
	token, ok := header.Get("token")
	if ok {
		return false, "missing token"
	}

	path, _ := header.Get(":path")
	hash := md5.Sum([]byte(path + secretKey))
	if hex.EncodeToString(hash[:]) != token {
		return false, "invalid token"
	}
	return true, ""
}

func (f *filter) DecodeHeaders(header api.RequestHeaderMap, endStream bool) api.StatusType {
	if ok, msg := verify(header); !ok {
		f.callbacks.SendLocalReply(403, msg, map[string]string{}, 0, "bad-request")
        return api.LocalReply
    }
	return api.Continue
}

DecodeHeaders 是扩展 filter 必须实现的方法，我们就是在这个阶段对请求 header 进行校验。

verfiy 是校验函数，这里的 RequestHeaderMap 是 Go 扩展提供的 interface，我们可以通过它来读写 header，其他都是常见的 Go 代码写法。

编译

编译很简单，与常见的 Go 编译一样，这里我们使用 Golang 官方的 docker 镜像来编译：

docker run --rm -v `pwd`:/go/src/go-filter -w /go/src/go-filter \
        -e GOPROXY=https://goproxy.cn \
        golang:1.19.8 \
        go build -v -o libgolang.so -buildmode=c-shared .

Go 编译还是很快的，只需要几秒钟，当前目录下，就会产生一个 libgolang.so 的文件。

反观 Envoy 的编译速度，一次全量编译，动辄几十分钟，上小时的，这幸福感提升了不止一个档次。

运行

我们可以使用 Envoy 官方提供的镜像来运行，如下示例：

docker run --rm -v `pwd`/envoy.yaml:/etc/envoy/envoy.yaml \
        -v `pwd`/libgolang.so:/etc/envoy/libgolang.so \
        -p 10000:10000 \
        envoyproxy/envoy:contrib-v1.26-latest \
        envoy -c /etc/envoy/envoy.yaml

只需要把上一步编译的 libgolang.so 和 envoy.yaml 挂载进去就可以了。

值得一提的是，我们需要在 envoy.yaml 配置中启用 Go 扩展，具体是这段配置：

http_filters:
  - name: envoy.filters.http.golang
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.golang.v3alpha.Config
      library_id: example
      library_path: /etc/envoy/libgolang.so
      plugin_name: example-1

跑起来之后，我们测试一下：

$ curl 'http://localhost:10000/'
missing token

$ curl -s 'http://localhost:10000/' -H 'token: c64319d06364528120a9f96af62ea83d' -I
HTTP/1.1 200 OK

符合期望，是不是很简单呢

后续

什么？这个示例太简单？

是的，这里主要是体验下开发流程，下篇我们再介绍更高级的玩法：

Go 接受来自 Envoy 侧的配置，异步 Goroutine，以及与 Istio 配合的用法。

Blog: 构建 subset 优化

Thu, 12 May 2022 00:00:00 +0000

前言

MOSN 使用了 subset 算法作为其标签匹配路由负载均衡的方式，本文主要介绍 Subset 的原理，同时在超大规模集群下MOSN的 subset 所遇到的一些性能瓶颈与优化算法。

Subset 基本原理

在一个集群里，通常机器会有不同的标签，如何将一个请求路由到指定标签的一组机器呢？MOSN 把一个服务下的机器按照机标签组合进行预先分组成多个子集，在请求的时候，根据请求中的metadata信息可以快速查询到这个请求应该匹配到哪个子集。

当前有4个节点

[
   {
      "hostname":"h1",
      "metadata":{
         "zone":"zone1",
         "mosn_version":"version1",
         "mosn_aig":"aig1"
      }
   },
   {
      "hostname":"h2",
      "metadata":{
         "zone":"zone1",
         "mosn_version":"version2",
         "mosn_aig":"aig1"
      }
   },
   {
      "hostname":"h1",
      "metadata":{
         "zone":"zone2",
         "mosn_version":"version1",
         "mosn_aig":"aig1"
      }
   },
   {
      "hostname":"h4",
      "metadata":{
         "zone":"zone2",
         "mosn_version":"version2",
         "mosn_aig":"aig1"
      }
   }
]

标签匹配规则会根据 zone 、mosn_aig 、mosn_version 这 3 个字段进行匹配路由，根据这3个key排序后进行组合得到以下匹配路径

[zone]
[mosn_version]
[mosn_version, zone]
[mosn_aig]
[mosn_aig, zone]
[mosn_aig, mosn_version]
[mosn_aig, mosn_version, zone]

相对应的匹配树如下

假设需要访问 {zone: zone1, mosn_aig: aig1} , 那么经过排序后查找顺序为 mosn_aig:aig1 -> zone:zone1 , 查找到 [h1, h2]

以上就是subset的基本原理

Subset 构建

那么如何构建上述的匹配树呢？首先输入参数有两个

带标签的机器列表hosts，比如 [h1, h2, h3, h4]

用于匹配的subSetKeys, 比如

[zone]
[mosn_version]
[mosn_version, zone]
[mosn_aig]
[mosn_aig, zone]
[mosn_aig, mosn_version]
[mosn_aig, mosn_version, zone]

我们阅读源码看一下MOSN的subsetLoadbalancer是如何构建这棵树

MOSN遍历每一个 Host的labels 和 SubsetKey 递归去创建一棵树

对于树的每一个节点，都会遍历一次hosts列表过滤出匹配这个节点的kvs的subHosts，每个节点创建一个子 loadbalancer

构建 profile

在生产的超大集群，我们发现MOSN在接收到注册中心的机器列表推送的时候，出现了较高的cpu毛刺，短暂的内存出现了上涨，gc频率也大幅度增加。

通过对生产的profile，我们发现 subsetLoadbalancer 的 createSubsets 在cpu和alloc的火焰图中都占比较高。

下面我们开始编写benchmark优化这一部分的性能

我们的输入参数为：

subsetKeys

func benchSubsetConfig() *v2.LBSubsetConfig {
	return &v2.LBSubsetConfig{
		SubsetSelectors: [][]string{
			{"zone", "physics"},
			{"zone"},
			{"physics"},
			{"zone", "physics", "mosn_aig"},
			{"zone", "physics", "mosn_version"},
			{"zone", "physics", "mosn_aig", "mosn_version"},
			{"zone", "mosn_aig"},
			{"zone", "mosn_version"},
			{"zone", "mosn_aig", "mosn_version"},
			{"physics", "mosn_aig"},
			{"physics", "mosn_version"},
			{"physics", "mosn_aig", "mosn_version"},
			{"mosn_aig"},
			{"mosn_version"},
			{"mosn_aig", "mosn_version"},
		}}
}

8000个 hosts

每个 hosts 都有4个label, 每个label 3 种value

func BenchmarkSubsetLoadBalancer(b *testing.B) {
	ps := createHostset(benchHostConfigs(8000, 3))
	subsetConfig := benchSubsetConfig()
	b.Run("subsetLoadBalancer", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			newSubsetLoadBalancer(types.RoundRobin, ps, newClusterStats("BenchmarkSubsetLoadBalancer"), NewLBSubsetInfo(subsetConfig))
		}
	})
}

cpu

alloc_space

从上面的火焰图可以看到HostMatches和setFinalHost 占较多的cpu_time 和 alloc_space

我们首先看下HostMatches

他的作用是判断一个host是不是完全匹配给定的键值对，用于判断这个host有没有匹配这个匹配树节点

开销主要在于执行次数过多：树节点数 * len(hosts) 。在集群变大时，这边的运行开销会大幅度上升。

下面我们来看一下 setFinalHost

他的主要逻辑是按IP进行去重，同时会附带copy。

如果我们在subsetLoadbalancer的顶层进行去重，那么他的任意subset都不需要再次去重的，因此这边可以改成不去重

构建优化

HostMatches的那么多次匹配中，实际上有很多的重复操作，对host label中某个kv判断equals，在构建过程中重复了相当多的次数，优化的思路可以基于避免这部分重复的开销，预先构建倒排索引出发。

输入参数

subsetKeys

[
    {"zone", "physics"},
    {"zone"},
    {"physics", "mosn_aig", "mosn_version"},
    {"zone", "physics", "mosn_version"}]
    ...
]

hosts


[
   {
      "hostname":"h1",
      "metadata":{
         "zone":"zone1",
         "mosn_version":"version_none",
         "mosn_aig":"aig_none",
         "physics":"m1"
      }
   },
   {
      "hostname":"h2",
      "metadata":{
         "zone":"zone1",
         "mosn_version":"version_none",
         "mosn_aig":"aig_none"
      }
   },
   {
      "hostname":"h3",
      "metadata":{
         "zone":"zone2",
         "mosn_version":"version_none",
         "mosn_aig":"aig_none",
         "physics":"m1"
      }
   }
]

遍历一次 hosts 针对每个kv我们用bitmap构建倒排索引

{
    "zone": {
      "zone1": bitmap(110)
      "zone2": bitmap(001)
    },
    "physics": {
      "m1": bitmap(101)
    },
    "mosn_aig": {
      "aig_none": bitmap(111)
    },
    "mosn_version": {
      "version_none": bitmap(111)
    }
}

根据subsetKeys和倒排索引中的kvs，构建出匹配树，因为索引中是去重的与hosts数目无关，这个操作开销占比很低
对于树的每个节点，利用倒排索引中的bitmap做交集快速得到匹配全部kv的hosts的索引bitmap
使用Bitmap中存储的index从hosts中取出对应subHosts构建子loadbalancer，同时此处不需要使用setFinalHosts进行去重

基于上述思路过程开发新的subset preIndex 构建算法，代码参考 https://github.com/mosn/mosn/pull/2010

添加benchmark进行测试

func BenchmarkSubsetLoadBalancer(b *testing.B) {
	ps := createHostset(benchHostConfigs(8000, 3))
	subsetConfig := benchSubsetConfig()
	b.Run("subsetLoadBalancer", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			newSubsetLoadBalancer(types.RoundRobin, ps, newClusterStats("BenchmarkSubsetLoadBalancer"), NewLBSubsetInfo(subsetConfig))
		}
	})
	b.Run("subsetLoadBalancerPreIndex", func(b *testing.B) {
		for i := 0; i < b.N; i++ {
			newSubsetLoadBalancerPreIndex(types.RoundRobin, ps, newClusterStats("BenchmarkSubsetLoadBalancer"), NewLBSubsetInfo(subsetConfig))
		}
	})
}

 dzdx@B-QBDRMD6M-0201  ~/Documents/mosn-open/pkg/upstream/cluster   perf/subsetlb ±✚  go test -bench=^BenchmarkSubsetLoadBalancer . -run=^$ -benchmem 
2022-04-14 18:55:42,662 [INFO] [network] [ register pool factory] register protocol: mock factory
goos: darwin
goarch: amd64
pkg: mosn.io/mosn/pkg/upstream/cluster
BenchmarkSubsetLoadBalancer/subsetLoadBalancer-12                      9         118816550 ns/op        10105291 B/op       7217 allocs/op
BenchmarkSubsetLoadBalancer/subsetLoadBalancerPreIndex-12            246           5452478 ns/op         2427298 B/op      11463 allocs/op
PASS
ok      mosn.io/mosn/pkg/upstream/cluster       4.993s

可以看到相对于之前的构建方式，构建速度快了20倍，alloc_space 减小了75%， alloc次数少量上升，因为需要额外构建一次倒排索引。

下面观察一下gc：

default:
gc 7 @0.247s 5%: 0.006+16+0.017 ms clock, 0.027+0/15/32+0.070 ms cpu, 48->49->34 MB, 50 MB goal, 4 P

preIndex:
gc 7 @0.229s 7%: 0.005+17+0.017 ms clock, 0.021+3.6/17/33+0.069 ms cpu, 44->46->33 MB, 45 MB goal, 4 P

相对之前的构建方式，运行期间的内存更小，cpu回收的内存也变少，gc并行扫描的时长小幅上涨，STW时间变短。

测试一下在不同hosts数目下的优化程度，可以看到在hosts数目较多（>100) ，新的构建算法都会大幅度优于旧的构建算法

hosts	cpu (before)	cpu (after)	alloc (before)	alloc (after)
20	0.23ms	0.35ms	65KB	189KB
100	0.93ms	0.38ms	154KB	214KB
500	8.1ms	0.56ms	632KB	322KB
2000	27ms	1.3ms	2.4MB	738KB
8000	102ms	5.1ms	10MB	2.4MB

总结

通过预先构建 bitmap 倒排索引加速subset构建，cpu有超过10倍的提升，alloc_space也降低了数倍，gc的扫描时长小幅增加，STW时长小幅减少

Blog: Holmes 原理浅析

Sat, 19 Mar 2022 00:00:00 +0000

前言

对于系统的性能尖刺问题，我们通常使用Go官方内置的pprof包进行分析，但是难点是对于一闪而过的“尖刺”，开发人员很难及时地保存现场：当你收到告警信息，从被窝中爬起来，打开电脑，链接VPN，系统说不定都已经重启三四趟了。

MOSN社区的Holmes是一个基于golang实现的，轻量级性能监控系统，当应用的性能指标发生了异常波动时，holmes会在第一时间保留现场，让你第二天上班可以一边从容地喝着枸杞茶，一边追查问题的根因。

本文将介绍如何使用 holmes对您的应用进行监控，并简单分析了holmes的实现原理。

Quick Start

使用holmes的方式十分简单，只需要在您的系统初始化逻辑内添加以下代码：

    // 配置规则
    h, _ := holmes.New(
        holmes.WithCollectInterval("5s"), // 指标采集时间间隔
        holmes.WithDumpPath("/tmp"),      // profile保存路径
    
        holmes.WithCPUDump(10, 25, 80, 2 * time.Minute),  // 配置CPU的性能监控规则
        holmes.WithMemDump(30, 25, 80, 2 * time.Minute),// 配置Heap Memory 性能监控规则
        holmes.WithGCHeapDump(10, 20, 40, 2 * time.Minute), // 配置基于GC周期的Heap Memory 性能监控规则
        holmes.WithGoroutineDump(500, 25, 20000, 100*1000, 2 * time.Minute),    //配置Goroutine数量的监控规则
    )

    // enable all
    h.EnableCPUDump().
    EnableGoroutineDump().
	EnableMemDump().
	EnableGCHeapDump().Start()

类似于holmes.WithGoroutineDump(min, diff, abs,max,2 * time.Minute)的API含义为:

当goroutine指标满足以下条件时，将会触发dump操作。 current_goroutine_num > 10 && current_goroutine_num < 100*1000 && current_goroutine_num > 125% * previous_average_goroutine_num ||current_goroutine_num > 2000.
当goroutine数大于max时，holmes会跳过本次dump操作，因为当goroutine数过大时，goroutine dump操作成本很高。
2 * time.Minute 是两次dump操作之间最小时间间隔，避免频繁profiling对性能产生的影响。

更多使用案例点击这里。

Profile Types

holmes支持以下五种Profile类型，用户可以按需配置。

mem: 内存分配
cpu: cpu使用率
thread: 线程数
goroutine: 协程数
gcHeap: 基于GC周期监控的内存分配

指标采集

mem, cpu, thread, goroutine这四种类型是根据用户配置的CollectInterval,每隔一段时间采集一次应用当前的性能指标，而gcHeap时基于GC周期采集性能指标。本小节会分析一下两种指标。

根据`CollectInterval`周期采集

holmes每隔一段时间采集应用各项指标，并使用一个固定大小的循环链表来存储它们。

根据`GC`周期采集

在一些场景下，我们无法通过定时的memory dump保留到现场, 比如应用在一个CollectInterval周期内分配了大量内存，又快速回收了它们，此时holmes在周期前后的采集到内存使用率没有产生过大波动，与实际情况不符。

为了解决这种情况，holmes开发了基于GC周期的 Profile类型，它会在堆内存使用率飙高的前后两个GC周期内各dump一次profile，然后开发人员可以使用pprof --base命令去对比两个时刻堆内存之间的差异。具体实现介绍。

根据GC周期采集到的数据也会放在循环列表中。

规则判断

本小节介绍holmes是如何根据规则判断系统出现异常的。

阈值含义

每个Profile都可以配置min,diff,abs,coolDown四个指标，含义如下:

当前指标小于min时，不视为异常。
当前指标大于(100+diff)*100%*历史指标，说明系统此时产生了波动，视为异常。
当前指标大于abs(绝对值)，视为异常。

cpu和goroutine这两个profile类型提供max参数配置，基于以下考虑。

cpu 的profiling操作大约会有5%的性能损耗，所以当在cpu过高时，不应当进行profiling操作，否则会拖垮系统。
当goroutine数过大时，goroutine dump操作成本很高，会进行STW操作，从而拖垮系统。

Warming up

当holmes启动时，会根据CollectInterval周期采集十次各项指标，在这期间内采集到的指标只会存入循环链表中，不会进行规则判断。

扩展功能

除了基本的监控之外，holmes还提供了一些扩展功能。

事件上报

您可以通过实现Reporter 来实现以下功能：

发送告警信息，当holmes触发Dump操作时。
将Profiles上传到其他地方，以防实例被销毁，从而导致profile丢失，或进行分析。

        type ReporterImpl struct{}
        func (r *ReporterImple) Report(pType string, buf []byte, reason string, eventID string) error{
            // do something	
        }
        ......
        r := &ReporterImpl{} // a implement of holmes.ProfileReporter Interface.
    	h, _ := holmes.New(
            holmes.WithProfileReporter(reporter),
            holmes.WithDumpPath("/tmp"),
            holmes.WithLogger(holmes.NewFileLog("/tmp/holmes.log", mlog.INFO)),
            holmes.WithBinaryDump(),
            holmes.WithMemoryLimit(100*1024*1024), // 100MB
            holmes.WithGCHeapDump(10, 20, 40, time.Minute),
)

动态配置

您可以通过Set方法在应用运行时更新holmes的配置。它的使用十分简单，和初始化时的New方法一样。

有些配置时不支持动态更改的，比如Core数，如果在系统运行期间更改这个参数，会导致CPU使用率产生巨大波动，从而触发Dump操作。

    h.Set(
        WithCollectInterval("2s"),
        WithGoroutineDump(10, 10, 50, 90, time.Minute))

配置中心支持

利用Set方法，您可以轻松地对接自己公司的配置中心，比如，将holmes作为数据面，配置中心作为控制面。并对接告警系统(邮件/短信等)，搭建一套简单的监控系统。

具体架构如下:

总结

本文简单地介绍了Holmes的使用方法与原理。希望holmes能在您提高应用的稳定性时帮助到你。

参考

Blog: MOSN 反向通道详解

Thu, 17 Feb 2022 00:00:00 +0000

MOSN（Modular Open Smart Network）是一款主要使用 Go 语言开发的云原生网络代理平台，由蚂蚁集团开源并经过双11大促几十万容器的生产级验证，具备高性能、易扩展的特点。 MOSN 可以和 Istio 集成构建 Service Mesh，也可以作为独立的四、七层负载均衡，API Gateway、云原生 Ingress 等使用。

MOSN的反向通道实现

在云边协同的网络场景，通常都是单向网络，云侧节点无法主动发起连接与边缘节点通讯。这种限制极大程度保证了边缘节点的安全，但缺点也很明显，即只允许边缘节点主动发起访问云端节点。

云边隧道旨在解决云端无法主动访问边缘节点的问题，其本质是一个反向通道（后文统称为反向通道）。通过在边缘侧主动发起建连的方式与云端节点之间构建一条专用的全双工连接，用来传输云端节点的请求数据和回传最终的响应结果。

目前例如SuperEdge、Yurttunnel等业界知名云边协同开源框架，对于云边通信的实现方案都基于反向通道。

本文将着重介绍MOSN之上的反向通道运作流程和原理。

总体架构如下所示(图中箭头表示TCP建连反向)：

整个运作流程简单概括：

边缘侧的mosn实例（后文统称为tunnel agent）在启动时tunnel agent相关服务协程。
通过指定的静态配置或者动态服务发现方式拿到需要反向建连的公有云侧的mosn server地址列表（后文统称tunnel server），并且建立反向连接。
云侧的Frontend与tunnel server侧的转发端口进行数据交互，这部分数据会被托管到之前建立的反向连接进行发送。
边缘节点接受到请求之后，再将请求转发给实际的后端目标节点，回包过程则原路返回。

反向通道启动过程

MOSN Agent通过ExtendConfig特性，在MOSN启动时加载和完成初始化Tunnel Agent的工作。

ExtendConfig中定义AgentBootstrapConfig结构如下：

type AgentBootstrapConfig struct {
	Enable bool `json:"enable"`
	// The number of connections established between the agent and each server
	ConnectionNum int `json:"connection_num"`
	// The cluster of remote server
	Cluster string `json:"cluster"`
	// After the connection is established, the data transmission is processed by this listener
	HostingListener string `json:"hosting_listener"`
	// Static remote server list
	StaticServerList []string `json:"server_list"`

	// DynamicServerListConfig is used to specify dynamic server configuration
	DynamicServerListConfig struct {
		DynamicServerLister string `json:"dynamic_server_lister"`
	}

	// ConnectRetryTimes
	ConnectRetryTimes int `json:"connect_retry_times"`
	// ReconnectBaseDuration
	ReconnectBaseDurationMs int `json:"reconnect_base_duration_ms"`

	// ConnectTimeoutDurationMs specifies the timeout for establishing a connection and initializing the agent
	ConnectTimeoutDurationMs int    `json:"connect_timeout_duration_ms"`
	CredentialPolicy         string `json:"credential_policy"`
	// GracefulCloseMaxWaitDurationMs specifies the maximum waiting time to close conn gracefully
	GracefulCloseMaxWaitDurationMs int `json:"graceful_close_max_wait_duration_ms"`

	TLSContext *v2.TLSConfig `json:"tls_context"`
}

ConnectionNum：tunnel agent和每个tunnel server建立的物理连接数量。

HostingListener：指定agent建立连接之后托管的mosn listener，即tunnel server发来的请求会由该listener托管处理。

DynamicServerListConfig：动态tunnel server的服务发现相关配置，可通过自定义的服务发现组件提供动态的地址服务。

CredentialPolicy：自定义的连接级别的鉴权策略配置。

TLSContext：MOSN TLS配置，提供TCP之上通信的保密性和可靠性。

针对每个远端的tunnel server实例，agent对应一个AgentPeer对象，启动时除了主动建立ConnectionNum个反向通信连接，还会额外建立一条旁路连接，这条旁路连接主要是用来发送一些管控参数，例如平滑关闭连接、调整连接比重。

func (a *AgentPeer) Start() {
	connList := make([]*AgentClientConnection, 0, a.conf.ConnectionNumPerAddress)
	for i := 0; i < a.conf.ConnectionNumPerAddress; i++ {
	  // 初始化和建立反向连接
		conn := NewAgentCoreConnection(*a.conf, a.listener)
		err := conn.initConnection()
		if err == nil {
			connList = append(connList, conn)
		}
	}
	a.connections = connList
	// 建立一个旁路控制连接
	a.initAside()
}

initConnection方法进行具体的初始化完整的反向连接，采取指数退避的方式保证在最大重试次数之内建连成功。

func (a *connection) initConnection() error {
	var err error
	backoffConnectDuration := a.reconnectBaseDuration

	for i := 0; i < a.connectRetryTimes || a.connectRetryTimes == -1; i++ {
		if a.close.Load() {
			return fmt.Errorf("connection closed, don't attempt to connect, address: %v", a.address)
		}
		// 1. 初始化物理连接和传输反向连接元数据
		err = a.init()
		if err == nil {
			break
		}
		log.DefaultLogger.Errorf("[agent] failed to connect remote server, try again after %v seconds, address: %v, err: %+v", backoffConnectDuration, a.address, err)
		time.Sleep(backoffConnectDuration)
		backoffConnectDuration *= 2
	}
	if err != nil {
		return err
	}
	// 2. 托管listener
	utils.GoWithRecover(func() {
		ch := make(chan api.Connection, 1)
		a.listener.GetListenerCallbacks().OnAccept(a.rawc, a.listener.UseOriginalDst(), nil, ch, a.readBuffer.Bytes(), []api.ConnectionEventListener{a})
	}, nil)
	return nil
}

该方法主要步骤：

a.init()方法会调用initAgentCoreConnection`方法初始化物理连接并完成建连交互过程。tunnel server通过agent传输的元数据信息，进行管理反向连接。具体的交互过程和协议后文会细讲。
建连成功之后，tunnel agent托管raw conn给指定的listener。之后该raw conn的生命周期由该listener全权管理，并且完全复用该listener的能力。

其定义了初始化反向连接的交互流程，具体代码细节可以看pkg/filter/network/tunnel/connection.go:250，本文不展开技术细节。

交互过程

目前MOSN的反向通道只支持了raw conn的实现，因此定义了一套简单明了的网络通信协议。

主要包括：

协议魔数：2 byte
协议版本：1 byte
主体结构类型：1 byte，包括初始化、平滑关闭等。
主体数据长度：2 byte
json序列化的主体数据

MOSN反向通道完整的生命周期交互过程：

建连过程中由tunnel agent主动发起，并且在TCP连接建立成功（TLS握手成功）之后，将反向建连的关键信息ConnectionInitInfo序列化并传输给对端tunnel server，该结构体定义了反向通道的元数据信息。

// ConnectionInitInfo is the basic information of agent host,
// it is sent immediately after the physical connection is established
type ConnectionInitInfo struct {
	ClusterName      string                 `json:"cluster_name"`
	Weight           int64                  `json:"weight"`
	HostName         string                 `json:"host_name"`
	CredentialPolicy string                 `json:"credential_policy"`
	Credential       string                 `json:"credential"`
	Extra            map[string]interface{} `json:"extra"`
}

tunnel server接受该元数据信息之后，主要工作包括：

如果有设置自定义鉴权方式，则进行连接鉴权。
clusterManager将该连接加入到指定的ClusterSnapshot并回写建连结果。

此时建连过程才算完成。

func (t *tunnelFilter) handleConnectionInit(info *ConnectionInitInfo) api.FilterStatus {
	// Auth the connection
	conn := t.readCallbacks.Connection()
	if info.CredentialPolicy != "" {
		// 1. 自定义鉴权操作，篇幅原因省略
	}
	if !t.clusterManager.ClusterExist(info.ClusterName) {
		writeConnectResponse(ConnectClusterNotExist, conn)
		return api.Stop
	}
	// Set the flag that has been initialized, subsequent data processing skips this filter
	err := writeConnectResponse(ConnectSuccess, conn)
	if err != nil {
		return api.Stop
	}
	conn.AddConnectionEventListener(NewHostRemover(conn.RemoteAddr().String(), info.ClusterName))
	tunnelHostMutex.Lock()
	defer tunnelHostMutex.Unlock()
	snapshot := t.clusterManager.GetClusterSnapshot(context.Background(), info.ClusterName)
	// 2. host加入到指定的cluster
	_ = t.clusterManager.AppendClusterTypesHosts(info.ClusterName, []types.Host{NewHost(v2.Host{
		HostConfig: v2.HostConfig{
			Address:    conn.RemoteAddr().String(),
			Hostname:   info.HostName,
			Weight:     uint32(info.Weight),
			TLSDisable: false,
		}}, snapshot.ClusterInfo(), CreateAgentBackendConnection(conn))})
	t.connInitialized = true
	return api.Stop
}

然后是通信过程，为了便于理解，以下图请求单向流转示意图举例，

在传统的MOSN sidecar应用场景中，Frontend发送的请求首先经过Client-MOSN，然后通过路由模块，主动创建连接(虚线部分)并流转到对端，经由Server-MOSN biz-listener处理转交给Backend。

而在云边场景的反向通道实现中，Client MOSN(tunnel server)在接受到对端tunnel agent发起创建反向通道的请求后，即将该物理连接加入路由到对端MOSN的cluster snapshot中。从而Frontend的请求流量能由该反向通道流转到对端MOSN，而因为tunnel agent侧把该连接托管给了biz-listener，则读写处理都由biz-listener进行处理，biz-listener将处理完的请求再转发给真正的Backend服务，

总结和规划：

本文主要介绍了MOSN反向通道的实现原理和设计思路，MOSN作为高性能的云原生网络代理，希望反向通道的能力能更加有效地支持其作为云边协同场景中承接东西向流量的职责。

当然，后续我们也会继续做一系列的拓展支持，包括但不限于：

反向通道支持gRPC实现，gRPC作为云原生时代最通用的服务通讯框架，本身内置了各种强大的治理能力。
结合更多云原生场景，内置更加通用的tunnel server动态服务发现能力组件。
更多的配套自动化运维和部署工具。

Blog: 利用 SidecarSet 实现 MOSN 容器原地热升级

Fri, 10 Dec 2021 00:00:00 +0000

前言

MOSN 作为 Sidecar 容器部署时，对于 MOSN 容器自身的升级，可以采用的一种形式是先将业务切流，再升级版本。这种形式用户POD需要销毁、重新调度、重建，带来较大开销的同时，也可能影响业务的稳定性。

为此 MOSN 提供了对业务无感的热升级方式，具体的原理可移步这里查阅。

本文将介绍如何利用 OpenKruise 对 Kubernetes 的扩展 SidecarSet，来具体操作 MOSN 容器的原地热升级。

环境准备

在 k8s 中安装 OpenKruise, 安装步骤见 OpenKruise 官方文档

测试步骤

打包 MOSN 镜像

本文利用当前 MOSN 社区提供的构建镜像的方式来准备测试用的 MOSN 镜像，在构建镜像之前需要做如下调整：

修改etc/supervisor/supervisord.conf, 因为当前 supervisor 配置使用/dev/shm/目录，同一 POD 内不同容器之间会冲突，会导致新容器启动失败

[unix_http_server]
-file=/dev/shm/supervisor.sock
+file=/var/run/supervisor_mosn.sock

修改 MOSN 配置文件configs/mosn_config.json, 添加配置：

{
    "uds_dir": "/home/admin/mosn/logs",
    "inherit_old_mosnconfig": true,
    ...
}

其中uds_dir为 MOSN reconfig.sock存储目录，该目录需要挂载为共享卷，使得热升级过程中两个容器之间可以相互访问。

如果从pilot获取动态下发的配置，则需要添加inherit_old_mosnconfig配置项，新的 MOSN 进程启动之后继承老的 MOSN 进程监听的fd，避免端口冲突导致进程启动失败。

构建镜像，并上传至可访问的镜像仓库

make image
docker tag [imageid] [repo:tag]
docker push [repo:tag]

创建SidecarSet资源

注意
- image 修改为自己使用版本
- volume 挂载目录和配置文件中uds_dir目录保持一致

$ kubectl apply -f sidecarset.yaml 
$ cat sidecarset.yaml
apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
  name: mosn
spec:
  containers:
  - image: tinyqian/mosn:v1
    imagePullPolicy: IfNotPresent
    name: mosn
    podInjectPolicy: BeforeAppContainer
    resources: {}
    shareVolumePolicy:
      type: enabled
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    upgradeStrategy:
      hotUpgradeEmptyImage: openkruise/hotupgrade-sample:empty
      upgradeType: HotUpgrade
    volumeMounts:
    - mountPath: /home/admin/mosn/logs
      name: mosn-log
    lifecycle:
      postStar:
        exec:
          command:
          - /bin/sh
          - -c
          - sleep 30

  injectionStrategy: {}
  namespace: default
  selector:
    matchLabels:
      mesh.apsara-edge.com/mosn-injected: "true"
  updateStrategy:
    maxUnavailable: 1
    partition: 0
    type: RollingUpdate
  volumes:
  - emptyDir: {}
    name: mosn-log

部署测试应用

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    mesh.apsara-edge.com/mosn-injected: "true"
  name: test-app
spec:
  selector:
    matchLabels:
      mesh.apsara-edge.com/mosn-injected: "true"
  replicas: 1
  template:
    metadata:
      labels:
        mesh.apsara-edge.com/mosn-injected: "true"
    spec:
      containers:
        - name: test-app
          image: nginx:1.20

部署应用之后，查看 POD

$ kubectl get pods -n ppe-t-e3496bc319e941ed8ec8349b8c65b366-cn3691    -o wide
NAME                             READY   STATUS                     RESTARTS   AGE
test-app-5fd64d788c-g9wg9        3/3     Running                    0          2m56s

可以看到 POD 一共创建了三个容器，一个是业务容器，一个是 MOSN 容器，一个是 empty容器。

测试升级镜像版本

部署成功后，可以测试升级 MOSN 容器的镜像版本，更新前面创建的 sidecarset 资源的 image 版本。

$ kubectl edit sidecarset mosn
application.core.oam.dev/mosn edited

升级过程中可以看到 RESTARTS 字段变化，POD内容器有重启，但是POD没有重建

NAME                             READY   STATUS                     RESTARTS   AGE
test-app-5fd64d788c-g9wg9        3/3     Running                    2          10m

实际的升级过程为：

empty 容器升级为 MOSN v2 版本容器
MOSN v2 版本容器和v1版本容器之间进行连接迁移
MOSN v1 版本容器退出，变更为 empty 容器

查看升级过程中的进程可以发现，在v1版本的容器没有退出之前，新老容器中的进程是并存的

同时，升级的过程中你可以不断地发送通过 MOSN 代理的测试请求，可以验证升级过程中 MOSN 一直处于可用状态，对业务是无损的。

总结

通过上述步骤，可以实现用户 POD 和 sidecar 容器的部署，同时实现 sidecar 容器的原地热升级，做到 sidecar 容器升级业务无感。需要注意的是 SidecarSet 支持image版本升级，修改其他字段将会导致容器无法升级。

参考

OpenKruise SidecarSet 介绍

OpenKruise 安装指南

Blog: MOSN 路由框架详解

Tue, 07 Dec 2021 00:00:00 +0000

前言

MOSN 作为网络边缘代理组件，路由功能是核心功能，本文将介绍 MOSN 路由如何使用，以及 MOSN 路由的一些高级使用技巧，MOSN 官网介绍了路由功能的基本使用配置: 点击链接

路由基本设计

在 MOSN 的路由设计中，cluster 和 route 是高度关联的，说白了，route 的配置，就是为了表达如何准确的找到你想找到的 cluster，另外，一个 cluster 可以有多个 host 机器，例如一个 cluster 有 100 台机器，其中有50台是 v1 版本，50台是 v2 版本，如何根据一些特定的规则，准确地把请求路由到 v1 版本或者 v2 版本呢？

再例如，我想根据 header 里的某个值，再将这个值和“配置中心”里的某个值进行计算，才能找到 cluster，那么我该如何配置呢？

首先，我们看最简单的路由设置。

上图是一个简单的 json 配置，其中，cluster manager 和 routers 的配置，是路由的关键。我们可以 cluster manager 中配置多个 cluster，每个 cluster 配置多个 host。

然后在 routers 配置中，根据一些规则，告诉 MOSN，如何将请求路由到 cluster 中。如下图：

此配置表示，现在有一个 rouer 配置，名为 server_router，有一个虚拟主机，可配置多个域名，这里匹配所有域名，同时，这个域名有多个路由配置，这里暂且配置了一个路由配置：前缀匹配，只要是 / 开头的，就转发到 serverCluster 里的 host 中，也就是下面的 cluster manager 配置里的 serverCluster。

这样，就实现了一个简单的 mosn 路由的配置。

动态路由 cluster

大部分情况下，如果我们的路由逻辑很简单，例如根据 header 里的某个名字，找到对应的 cluster，代码或者配置就是这么写的：

router := v2.Router{
    // header 匹配
    RouterConfig: v2.RouterConfig{
        Match: v2.RouterMatch{
            Headers: []v2.HeaderMatcher{
                // 这个 header 匹配, 就转发到 app.Name cluster.
                {
                    Name:  "X-service-id",
                    Value: app.Name,
                },
            },
        },
        // cluster 名称匹配.
        Route: v2.RouteAction{
            RouterActionConfig: v2.RouterActionConfig{
                ClusterName: app.Name,
            },
        },
    },
}
r.VirtualHosts[0].Routers = append(r.VirtualHosts[0].Routers, router)

上面代码的意思是如果 header 里有 X-service-id 这个 kv，那么就能找到下面 RouteAction 对应的 Cluster 了。

那如果是更复杂的逻辑呢？比如利用请求里的 header 和“配置中心”的某个值进行计算，才能找到 cluster？

此时，通过配置已经无法解决这个需求，因为这其中涉及到了计算逻辑。

MOSN 通过动态配置可以支持该需求。如下图配置：

我们设置了一个 "cluster_variable": "My-ClusterVariable" 的 KV 配置。

同时，我们还需要在 StreamFilter 中，利用变量机制，设置 key 为 “My-ClusterVariable” 的 value，这个 value 就是计算出来的 Cluster 名称。

代码如下

// 先注册这个 key 到变量表中。
func init() {
	variable.Register(variable.NewStringVariable("My-ClusterVariable", nil, nil, variable.DefaultStringSetter, 0))
}


var clusterMap = make(map[int]string, 0)

func (f *MyFilter) OnReceive(ctx context.Context, headers api.HeaderMap, buf buffer.IoBuffer, trailers api.HeaderMap) api.StreamFilterStatus {
	l := len(clusterMap)
    // 找 Cluster
	cluster := // 执行一些计算
    // 设置到上下文变量中。这个 key 必须和配置文件中保持一致。
	variable.SetString(ctx, "My-ClusterVariable", cluster)
	return api.StreamFilterContinue
}

上面的代码展示了如何基于变量机制动态的找到 Cluster，这种机制在面对复杂路由逻辑的场景时，能够解决你的问题。

MOSN subset

如上面所述，我们经常有在一个集群里，有多个版本，如何根据某些标签，将请求路由到指定的版本呢？通常，我们会使用 subset 方案，即，子集合，可在一个 cluster 里面，为每个应用打标，同时我们的路由也配置相关的配置（MOSN 称为 metadata），实现较为复杂的路由。

MOSN 官方文档中，简单介绍了 metadata 的使用：metadata

下面让我们更详细的介绍 subset 的使用。

上图中,左边是 cluster host 配置,右边是 router 配置.

这个路由配置的 match 意思是,当请求者的 header 里指定了 name 和 value, 且其值匹配这个路由值 service 和 service.green, 那么该请求就被路由到了这个 cluster_subset 集群中。

然后, 这个集群可能有多个机器, 那么需要这个机器的元数据和路由配置的元数据相同，必须都是 subset:green, 才能匹配上这个 Host，否则提示找不到（fall_back_policy 策略是 0 为前提）。

由此，我们解决了一个 cluster 里面有多个版本的 host 的路由问题。

再进一步，一个 cluster 会有多个 host，每个 host 可能有不同的 subset，这可能就需要很多的路由，如果都使用配置文件的方式写死，就比较麻烦。

MOSN 支持基于 stream filter 的方式，设置动态路由。如下：

基于 MOSN 的变量机制，在请求级别的 VarRouterMeta 中设置 kv metadata 组合，效果和上面配置文件的方式类似。

另外, 如果路由配置中配置 MetaData, 请求级别也配置了 MetaData, 那么, MOSN 会将 2 个元数据进行合并, 来和 Host 进行匹配. 这个逻辑在 pkg/proxy/downstream.go:1497 代码中有体现.

来个简单的例子：

例如分组里指定机器调用；

1 请求时, 可在 header 里，指定 ip，并在 varRouterMeta 里设置这个 ip。

2 host 配置，可在 metadata 里，配置 ip kv，例如 ip：192.168.2.3；如下图:

这样，就能匹配到指定机器了。

ps: 关于这个例子，我们其实也可以使用 MOSN 的 ORIGINAL_DST 机制，将 cluster 的 type 设置为 ORIGINAL_DST（MOSN 还支持 DNS 集群类型），然后配置 cluster.original_dst_lb_config.use_header = true，这样，我们请求的时候，在 header 里加入 host = {目标地址}， MOSN 就会根据这个指定的 host header 进行转发。当然，MOSN 也可以自定义名字，不一定要叫 host。

来个复杂的例子。假设一个场景：单个 host 存在于多个分组，而请求时，只能指定一个分组。如下图：

我们现在有 2 台机器，共 3 个分组，AAA，BBB，CCC。每个机器都包含 AAA 分组。现在有 3 个请求，每个请求都是不同的分组，此时，我们该如何配置元数据呢？首先，本质上，给机器加分组，其实就是打标。我们将元数据想象成 tag 列表即可。

上面的代码，展示了：我们将多个分组标签，转换成 MOSN 可以认识的元数据 kv，每个标签对应一个固定的 value true（为什么设置为 true 呢？value 自身其实在 MOSN 的 subsetLB 中是有含义的，即最终根据请中携带的 metadata 的值去匹配 cluster 中满足条件的 subset host entry。但由于 metadata 是个 map，而因为我们这个例子的特殊性，只能使用 key 自身做分组，所有的 value 都保持一样，本质上任何值都是可以的）。同时注意，这些 key，都要保存到 SubsetSelectors 中，否则，MOSN 无法识别。每次调用时，我们在 filter 里，从 header 里面取出分组标签，然后设置进“上下文变量”中。例如：

这样，我们就能够完成更加复杂的分组路由。

那 MOSN 是如何寻找 subset 的呢？代码如下:

当执行 choose host 时，subsetLoadBalancer.findSubset 函数会根据当前请求的元数据，从 subSetLoadbalancer 里找出匹配的 host List。

总结

总结一下，我们先讲了基于简单的配置，来实现简单的 router 和 cluster 的配置文件路由。再讲了可以基于 stream filter 的方式实现动态寻找 cluster。同时 MOSN 支持 subset，可以基于 route 配置文件来进行路由和 cluster host 进行匹配，如果逻辑复杂，也可以基于 stream filter + varRouterMeta 变量的方式来动态寻找 subset。

其实大部分情况下，我们用 json 配置就能解决我们的路由问题。如果复杂的话，我们就用 stream filter + varRouterMeta / stream filter + cluster_variable 这两种动态机制解决我们的需求。下面尝试用一张图来结束本文。

参考

Router 配置 MOSN SubsetLB 开发文档 Load Balancer Subsets

Blog: WebAssembly 在 MOSN 中的实践 - 基础框架篇

Mon, 22 Mar 2021 00:00:00 +0000

作为金融级服务网格中的流量代理组件，MOSN 在承载蚂蚁数十万服务容器之间流量的同时，也承载着诸多例如限流、鉴权、路由等中间件基础能力。这些能力以不同的扩展形式与 MOSN 运行于同一进程内。非隔离的运行方式在保障性能的同时，却也给 MOSN 带来了不可预知的安全风险。

针对上述问题，我们采用 WebAssembly(Wasm) 技术，给 MOSN 实现了一个安全隔离的沙箱环境，让扩展程序能够运行在隔离沙箱之中，并对其资源、能力进行严格限制，使程序故障止步于沙箱，从而实现安全隔离的目标。本文将着重叙述 MOSN 中的 Wasm 扩展框架，并介绍我们在 Proxy-Wasm 这一代理扩展规范上的工作。

总体设计

上图为 MOSN Wasm 扩展框架的整体示意图。如图所示，对于 MOSN 的任意扩展点(Codec、NetworkFilter、StreamFilter 等)，用户均能够通过 Wasm 扩展框架，以隔离沙箱的形式运行自定义的扩展代码。而 MOSN 与 Wasm 扩展代码之间的交互，是通过 Proxy-Wasm 标准 ABI 来完成的。

隔离沙箱

当我们在讨论 Wasm 时，都明白 Wasm 能够提供一个安全隔离的沙箱环境，但并不是每个人都了解 Wasm 实现隔离沙箱的技术原理。这时又要搬出计算机科学中的至理名言: “计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决”。Wasm 实际上也是通过引用一个“中间层”来实现的安全隔离。简单来说，Wasm 通过一个运行时(Runtime)来运行 Wasm 沙箱扩展，每个 Wasm 沙箱都有其独立的线性内存空间和一组导入/导出模块。

一方面，每个 Wasm 沙箱都有其独立的线性内存空间，其内存模型如上图所示。Wasm 代码只能通过简单的 load/store 等指令访问线性内存空间的有限部分，并通过符号(下标)的方式来间接访问函数、全局变量等，杜绝了类似 C 语言中访问任意内存地址的骚操作。同时，用于间接调用函数的符号表对于 Wasm 代码而言是只读的，从而保证 Wasm 代码的执行是受控的。此外，Wasm 沙箱的整个线性内存空间由宿主机(Wasm Runtime)分配及管理，通过严格的内存管理保证沙箱的隔离性。

另一方面，Wasm 也规定了代码中任何可能产生外部影响的操作只能通过导入/导出模块来实现。以 C 语言为例，我们可以直接通过系统调用来访问系统的环境变量、文件、网络等资源。而在 Wasm 的世界中，并不存在系统调用相关的指令，任何对外部资源的访问必须通过导入模块来间接实现。以文件读写为例，在 Wasm 中要想进行文件读写，需要宿主机提供实现文件读写功能的导入函数，Wasm 代码调用该导入函数，由宿主机间接进行文件读写，再将操作结果返回给 Wasm 扩展。在上述过程中，实际的文件读写操作由宿主机完成，宿主机对这一过程有绝对的控制权，包括但不限于只允许读写指定文件、限制读写内容、完全禁止读写等。

扩展框架

MOSN 以插件(Plugin) 的形式对 Wasm 扩展进行统一管理，插件是指一组 Wasm 沙箱实例及其相应配置的集合。用户通过配置来加载、更新以及卸载 Wasm 插件，并通过配置来描述沙箱实例的运行规格(使用的执行引擎、Wasm 文件路径、实例数量等)。下面展示了一个典型的 Wasm 插件配置:

{
  "plugin_name": "global_plugin_id",    // 1. 插件名
  "instance_num": 4,                    // 2. 沙箱实例个数
  "vm_config": {
    "engine": "wasmer",                 // 3. 使用的虚拟机(Runtime)
    "path": "/foo/bar.wasm",            // 4. wasm 文件路径
    "url": "http://xxx/bar.wasm"
  }
}

当 MOSN 加载上述插件配置时，会按照以下流程生成插件对应的 Wasm 沙箱实例:

在后续运行的过程中，用户通过 Wasm 扩展框架获取指定插件的沙箱实例，然后通过沙箱实例暴露的 API 与扩展程序进行交互。本文的下一小节将对此交互过程进行详细描述。在 MOSN 中，Wasm 扩展框架与具体用途无关，在 MOSN 已有的任何一处扩展点，均可以直接使用 Wasm 框架来获取安全隔离的插件执行能力。

如下图所示，Wasm 扩展框架主要分为 Manager、VM 和 ABI 三个子模块。其中

Manager 模块负责对 Wasm 插件的配置进行统一管理，提供插件的增删查改功能，负责将用户提供的配置渲染成最终的 Wasm 沙箱实例
VM 模块提供对 Wasm Runtime(虚拟机) 的统一封装，负责 .wasm 文件的编译、执行，以及 Wasm 沙箱实例的资源管理
ABI 模块则提供对外的使用接口，可以看作是 MOSN 与 Wasm 扩展代码之间交互的胶水层

本文不再对框架内的具体子模块进行介绍，感兴趣的读者可以阅读开源 PR 的文档了解细节。

由于当前市面上几乎不存在使用 Go 语言直接编写的 Wasm Runtime，因此 MOSN 只能通过 CGO 调用的方式来间接地调用由 C++/Rust 编写的 Wasm 执行引擎。我们从 SDK 完善程度、性能、项目活跃度等角度综合考虑，经过一系列横向对比之后，选择了 Wasmer 作为 MOSN 默认的执行引擎。

Proxy-Wasm ABI 规范

本小节将介绍 MOSN 具体是如何跟 Wasm 扩展程序进行交互的。先说结论: MOSN 跟 Wasm 扩展代码之间的交互采用的是社区规范: Proxy-Wasm

Proxy-Wasm 是开源社区针对「网络代理场景」设计的一套 ABI 规范，属于当前的事实规范。当前支持该规范的网络代理软件包括 Envoy、MOSN 和 ATS(Apache Traffic Server)，支持该规范的 Wasm 扩展 SDK 包括 C++、Rust 和 Go。采用该规范的好处在于能让 MOSN 复用社区既有的 Wasm 扩展 (包括 Go 实现以及 C++/Rust 实现)，也能让本为 MOSN 开发的 Wasm 扩展运行在 Envoy 等网络代理产品上。

Proxy-Wasm 规范定义了宿主机与 Wasm 扩展程序之间的交互细节，包括 API 列表、函数调用规范以及数据传输规范这几个方面。其中，API 列表包含了 L4/L7、property、metrics、日志等方面的扩展点，涵盖了网络代理场景下所需的大部分交互点，且可以划分为宿主侧扩展和 Wasm 侧扩展点。这里简单展示规范中的部分内容，完整内容请参考 spec。

// Functions implemented in the Wasm module
// 由 Wasm 侧实现的扩展点
// L7:
proxy_on_http_request_headers
	params:
		i32 (uint32_t) context_id
		i32 (size_t) num_headers
		i32 (bool) end_of_stream
	returns:
		i32 (proxy_action_t) next_action

// L4:
proxy_on_downstream_data
	params:
		i32 (uint32_t) context_id
		i32 (size_t) data_size
		i32 (bool) end_of_stream
	returns:
		i32 (proxy_action_t) next_action


// Functions implemented in the host environment
// 由宿主侧实现的扩展点
// 日志
proxy_log
	params:
		i32 (proxy_log_level_t) log_level
		i32 (const char*) message_data
		i32 (size_t) message_size
	returns:
		i32 (proxy_result_t) call_result

// 数据
proxy_get_map
	params:
		i32 (proxy_map_type_t) map_type
		i32 (const char**) return_map_data
		i32 (size_t*) return_map_size
	returns:
		i32 (proxy_result_t) call_result


// MapData Format
// Map 数据传输规范
mapsize | key1size | value1size | key2size | value2size | ... | key1 | \0 | value1 | \0 | ...

规范的实现需要宿主侧和 Wasm 侧两边配合才能正常工作。对于 Wasm 侧，社区已经有 C++、Rust 和 Go 三种语言实现的 SDK，用户可以直接使用这些 SDK 来编写与宿主无关的 Wasm 扩展程序。而对于宿主侧，社区只提供了 C++ 和 Rust 的宿主侧实现。为此，我们在项目中使用 Go 语言对 Proxy-Wasm 规范的宿主侧进行了实现，并将其贡献给开源社区，使之成为社区推荐的 Go-Host 实现。需要强调的是，宿主侧实现并不依赖具体的网络代理程序，理论上任何直接通过 Host 程序与 Wasm 扩展进行交互。

我们以 HTTP 场景为例，介绍在 MOSN 中是如何通过 Proxy-Wasm 规范来与 Wasm 扩展程序进行交互，处理 HTTP 请求的。

MOSN 收到 HTTP 请求时，将请求解码成 Header、Body、Trailer 三元组结构，按照配置依次执行 StreamFilters
执行到 Wasm StreamFilter 时，MOSN 将请求三元组传递给 Proxy-Wasm 宿主侧实现 proxy-wasm-go-host
宿主侧 go-host 将 MOSN 请求三元组编码成规范指定的格式，并调用规范中的 proxy_on_request_headers 等接口，将请求信息传递至 Wasm 侧
Wasm 侧 SDK 将请求数据从规范格式转换为便于用户使用的格式，随后调用用户编写的扩展代码
用户代码返回，Wasm 侧将返回结果按规范格式传递回 MOSN 侧
MOSN 继续执行后续 StreamFilter

工程实践

Quick Start

本小节主要演示如何在 MOSN 中进行配置并运行 Wasm 扩展插件流程。演示所需的源文件参考 example。

在演示中，我们通过配置让 Wasm 扩展插件来处理 MOSN 接收的 HTTP 请求，MOSN 的监听端口为 2045。在 Wasm 处理请求的源码中，我们通过 Proxy-Wasm 规范中的 proxy_dispatch_http_call 接口向外部 HTTP 服务器发起请求，Wasm 源码内指定外部 HTTP 服务器的监听端口为 2046。演示场景的流程如下图所示:

该演示流程主要分为以下步骤:

将扩展程序编译成 .wasm 文件
启动 MOSN 并加载 Wasm 插件
启动外部 HTTP 服务器
请求验证

1. 编译 Wasm 扩展程序

我们在示例工程中提供了 C 和 Go 两种语言实现的 Wasm 扩展源码，对 Proxy-Wasm 规范的采用使得我们能够利用多种语言 (C++/Rust/Go) 来编写 Wasm 扩展代码。出于编译的便利性，这里使用 Go 源码实现进行演示。进入 example/wasm/httpCall 目录，执行命令:

make

上述操作会将目录下的 filter-go.go 源码文件编译成 filter-go.wasm 文件

2. 启动 MOSN

示例工程提供了一份加载 filter-go.wasm 扩展文件的配置，通过以下命令即可启动:

./mosn start -c config.json

上述命令中使用的 MOSN 可执行程序可以通过以下命令由源码构建:

# step 1: 
# 创建源码路径
mkdir -p $GOPATH/src/mosn.io
cd $GOPATH/src/mosn.io

# step 2: 
# 下载 MOSN 代码仓库
git clone https://github.com/mosn/mosn.git 

# step 3: 
# 编译，以下命令最终将产生 mosn 可执行文件
sudo make build-local tags=wasmer
mv build/bundles/v0.21.0/binary/mosn mosn

3. 启动外部 HTTP 服务器

该示例工程中，Wasm 扩展源码会通过 MOSN 向外部 HTTP 服务器发起请求，请求的 URL 为

http://127.0.0.1:2046/

为此，示例工程也提供了一段 HTTP 服务器代码，当其收到 HTTP 请求时，均会返回响应头: from: external http server，返回响应体: response body from external http server 执行以下命令将启动上述 HTTP 服务器:

go run server.go

4. 请求验证

上述操作准备就绪后，便可通过 Curl 来进行请求验证了

curl -v http://127.0.0.1:2045/

执行上述命令后，MOSN 终端将能够观察到以下日志:

[INFO] response header from http://127.0.0.1:2046/: From: external http server
[INFO] response header from http://127.0.0.1:2046/: Date: Wed, 17 Mar 2021 12:12:38 GMT
[INFO] response header from http://127.0.0.1:2046/: Content-Length: 39
[INFO] response header from http://127.0.0.1:2046/: Content-Type: text/plain; charset=utf-8
[INFO] response body from http://127.0.0.1:2046/: response body from external http server

性能测试

本小节对 Wasm 框架的性能进行测试

测试环境:

OS: macOS Catalina 10.15.4
CPU: Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz 4Core
MEM: 16 GB 2133 MHz LPDDR3
Go Version: go1.14.13 darwin/amd64

测试场景:

拓扑: client –http1.1–> MOSN 操作: MOSN 收到 H1 请求后，往请求头中添加一个 Header 随后返回 200

测试数据:

「native」表示添加 Header 的操作使用 MOSN 原生的 Stream Filter 完成；

「wasm」表示添加 Header 的操作使用 Wasm 扩展完成

固定 QPS 模式，将 QPS 固定为 2000 进行压测

压测命令: sofaload –h1 -c 100 -t 4 –qps=2000 -D 30 http://127.0.0.1:2045/

	qps	avg	P75	P90	P99
native	2000	698us	856us	1.09ms	1.87ms
wasm	2000	763us	940us	1.21ms	2.35ms
		-9.3%

压测模式，不限制压测 QPS，将流量打到最大

压测命令: sofaload –h1 -c 100 -t 4 -n 1000000 http://127.0.0.1:2045/

	qps	avg	P75	P90	P99
native	36013	2.78ms	3.80ms	5.44ms	10.39ms
wasm	26542	3.77ms	5.14ms	7.42ms	14.00ms
	-26%

异常调试

对于实际的工程项目而言，光能运行是不够的，必须具备一定的问题排查和定位能力，才能在遇到程序故障时，解析异常源码的调用堆栈，快速定位第一现场，从而提高开发及调试的效率。

由于 Wasm 本身的定位是与编程语言无关的字节码规范，不同语言的源代码 (C++/Go/JavaScript 等) 均能够编译为统一的 Wasm 字节码，因此如何屏蔽具体编程语言的细节模型，制定语言无关的调试信息规范，是社区需要解决的难题之一。针对这一问题，在当前的工程实践中，JavaScript 语言采用的是 Source Map 格式，而 C++、Rust 和 Go 语言采用的是 Dwarf 格式的调试信息。对具体调试信息格式的介绍并不在本文的范围之内，读者可自行参考外部文章。这里需要强调的是，对于 Wasm 而言，还需要对调试信息的格式进行一定的扩展，才能满足实际的应用需要。与其他编程语言不同的是，.wasm 文件是能够被转换成 .wat 格式，并手动编辑内容的，编译好的 .wasm 文件仍然有修改段内容的可能。为了适应这种场景，Wasm 调试规范对 Dwarf 格式中的位置信息编码进行了调整，指令的偏移值被设置成基于 Code 段的偏移:

With WebAssembly, the .debug_line section maps Code section-relative instruction offsets to source locations.

为此，我们在解析指令偏移时，需要偏移数值进行调整，减去 Code 段的偏移量，才能得到 Wasm 指令的实际偏移值，进而利用 .debug_line 段定位到准确的源码行。下图展示了利用 MOSN 输出的错误日志定位 Wasm 故障源码行的示例。

总结

对于蚂蚁而言，安全可信永远是我们追求的目标，而面对越来越多的扩展场景，MOSN 需要一个安全可靠的隔离环境，以避免扩展代码给 MOSN 运行造成的安全风险。为此，我们采用 WebAssembly 技术，为 MOSN 实现了一个基于 Wasm 隔离沙箱的插件扩展框架。MOSN 采用网络代理社区中的 Proxy-Wasm 规范，实现了语言无关、宿主无关的网络代理扩展能力。同时，我们也向开源社区贡献了 Proxy-Wasm-Go-Host 实现，积极融入开源社区。

需要注意的是，当前 WebAssembly 技术仍处于发展阶段，Go 语言自身对 WebAssenbly 生态的支持仍有巨大的提升空间。我们在实践的过程中，也总是面临 Go 语言在 Wasm 生态中不够给力的情况。由于 Go 官方编译器还不支持将 Go 源码程序编译成 WASI 系统接口 (GOOS=wasi) 的 .wasm 文件，我们不得不借助 TinyGo 来完成 Go 扩展程序的编译，而这也导致我们需要面对 TinyGo 在语言特性支持程度、性能、稳定性等方面不足的痛点。与之相比，C++/Rust 对 Wasm 生态的支持程度就要完善得多。

总而言之，WebAssembly 技术的出现仍然为我们提供了一种启发和希望，促使我们进一步思考如何在云原生时代更好地践行安全可信这一信条。

Blog: 在 MOSN 中玩转 dubbo-go

Mon, 15 Jun 2020 00:00:00 +0000

Service Mesh 简介

Service Mesh 本身的理念并不复杂，就是将现代微服务应用的功能性与非功能性需求进行分离，并将非功能性需求下沉到应用的外部模块，从而使应用模块可以尽量聚焦于业务，不用关心诸如：服务发现、限流、熔断、tracing 这类非业务需求。下沉之后，相关的 Service Mesh 模块可以交由基础架构团队进行维护，使基础设施和业务能够完成解耦。

Service Mesh 设计一般划分为两个模块，控制面和数据面。可以通过下图来理解相应的职责：

对于应用来说，所有流量都会经过 Service Mesh 中的数据面进行转发。而能顺利转发的前提：数据面需要知道转发的目标地址，目标地址本身是由一些业务逻辑来决定的(例如服务发现)，所以自然而然地，我们可以推断控制面需要负责管理数据面能正常运行所需要的一些配置：

需要知道某次请求转发去哪里：服务发现配置
外部流量进入需要判断是否已经达到服务流量上限：限流配置
依赖服务返回错误时，需要能够执行相应的熔断逻辑：熔断配置

开源界目前比较有名的主要是 istio，envoy 和 linkerd 这几个项目，今天我们来介绍一下蚂蚁推出的 Service Mesh 数据面项目：MOSN。

MOSN 简介

MOSN 是蚂蚁集团出品的用 Go 语言实现的 Service Mesh 数据面，在蚂蚁内部已大规模落地，在开源过程中我们了解到外部用户有较多的 dubbo 用户，这些 dubbo 用户也希望能够享受 Service Mesh 社区的发展红利。同时可以针对自己公司的特殊业务场景，对 Service Mesh 的数据面进行一定的扩展。

谈到扩展，MOSN 使用 Go 编写的优势就体现出来了。相比 C++，Go 语言通过自带的内存分配器与 GC 实现了一定程度的内存安全，解放了程序员的心智。相比 C++ 编写的 envoy，无论是编程和问题定位都要轻松不少。

MOSN 同时提供了强大的 XProtocol 协议扩展框架，用户可以根据自己的需求编写自定义协议解析。如果你使用的是 SOFA/Dubbo/HTTP/HTTP2，那么 MOSN 已经为你准备好了现成的实现。开箱即用。

为了满足社区的需求，从今年 4 月开始，MOSN 社区与 dubbo-go 社区进行了深入的交流与合作。可能还有些同学对 dubbo-go 不太了解，简单介绍一下。

dubbo-go 简介

Dubbo 是阿里巴巴出品一个非常优秀的 Java RPC 框架，相比其它框架，有较为全面的服务治理功能。

dubbo-go 是 dubbo 的 Go 语言版本，该项目已进入 apache 一年有余，开发社区很活跃，版本发布节奏较快。功能上也基本和 dubbo 的 Java 版都对齐了。

对于喜欢 dubbo 的 gopher 来说，dubbo-go 是个不错的选择。使用它来构建整个公司的服务框架，省时省心。

MOSN + dubbo-go 双剑合璧

Service Mesh 能够给微服务的整体架构带来很多好处，然而业界提供的全家桶方案不一定能很好地在企业内落地，有下面一些原因：

要求数据面和控制面一起上线，早期 istio 因为设计问题，有众多模块。会大幅增加企业的运维负担。
企业上 mesh 一定是渐进部署，不可能一次性让所有服务全部上。这样就会有在 mesh 中的应用和非 mesh 中的应用需要能够互通的需求。

蚂蚁的 Service Mesh 落地过程相对较为成功，值得参考。在内部落地时，首先只落地数据面，这样运维负担较轻，同时出问题时也容易排查。

但只落地数据面的话，有些控制面的功能我们就没有了，比如服务发现、路由配置订阅等等。因此在 MOSN 中，又额外对这些功能进行了支持(相当于目前的数据面单模块同时承载了数据面和控制面的部分功能)。当数据面稳定落地之后，再进行控制面的落地相对来说负担就小很多了。

上面的是蚂蚁内部的情况，在社区内，MOSN 借助 dubbo-go 的能力，已经实现了服务发现功能，用户应用启动、退出时需要和 MOSN 进行简单的交互，以完成服务的发布和订阅功能，下面是发布流程：

在应用启动时，访问本地的 MOSN http 接口，告知需要将本地的服务发布出去，MOSN 收到请求后对外发布 MOSN 的 ip 和端口到注册中心。这样监听本服务的 consumer 便可以从注册中心收到服务变更的通知，并将本实例加入到相应的 provider 列表。当应用退出时，需要主动进行 unpub。

这种情况下的改造成本：

对于业务方来说，只需要升级 sdk。
对于 sdk 维护方，在执行 sub/pub/unsub/unpub 时，需要增加一个开关判断，开关打开时，说明本实例已上 Service Mesh。请求相应的本地 MOSN 接口。
对于 mesh 提供方，只要做好配置和部署就可以了。

接入 MOSN 后，mesh 化和非 mesh 化的应用可以互通：

当然，开发过程也并不是一帆风顺的。在我们刚开始使用 dubbo-go 时，便遇到了 dubbo-go 的依赖与 MOSN 的依赖有冲突的问题：

Go 语言的 go mod 语义会“自作聪明”地认为 0.y.z 的外部依赖都是彼此兼容的，然而我们从 semver 规范可以学习到：

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

0.y.z 只是用来做初始的开发，本身 API 的变化就是很频繁的，依赖管理工具不应该自动去升级这些依赖。但是 Go 社区的人有不少人坚持 go mod 的行为正确，并且祭出 MVS 算法，表示碰到问题的只是不懂 Go 的哲学。

当前 Go 的依赖管理使得两个大项目发生依赖冲突时，比较难处理，我们只能根据实际情况去 go.mod 中去写一些 replace 逻辑，来锁定外部依赖库版本。

除了依赖问题以外，dubbo-go 最初的设计大量使用了 init 函数。init 函数用来实现一些初始化和依赖注入确实比较方便，但如果一个项目中的模块会被其它外部项目依赖时，init 则可能给我们造成麻烦，举个简单的例子：

package x
var GlobalMap = map[string]int{}

package a
func init() {
    x.GlobalMap["x"] = 1
}

package b
func init() {
    x.GlobalMap["x"] = 2
}

如果我们在某个包中同时依赖 a 和 b，那么下面的两种写法，得到的结果是不一样的：

package show
import (
    "a"
    "b"
    "x"
)

func main() {
    println(x.GlobalMap["x"])
}

package show
import (
    "b"
    "a"
    "x"
)
func main() {
    println(x.GlobalMap["x"])
}

为了避免这些隐式的 init 行为，我们实际上是 fork 了 dubbo-go 并进行了少量修改的。当然，改动并不多，未来如果 dubbo-go 有更好的模块化方法的话，我们也可以很轻松地迁移回直接依赖 dubbo-go。

在 MOSN 集成 dubbo-go 的过程中，dubbo-go 社区的老哥们给予了我们大量的支持，贤哥（@zouyx）帮助我们在 dubbo-go 中实现了之前不支持的 unsub/unpub 功能，并帮助我们解决了很多技术方面的问题。dubbo-go 社区负责人于雨（@alexstocks）也在开发过程中提供了大量的信息和技术支持。有这两位的支持，MOSN 和 dubbo 的集成才顺畅无比，否则的话要多走很多弯路。

其它选择

除了本文提到的 MOSN + dubbo-go 集成方式，多点的陈鹏同学为我们提供了另一种思路进行集成，本文就不展开了，感兴趣的同学可以参考文末的资料。

作者简介

曹春晖，开源 MOSN committer，@cch123，蚂蚁集团系统部技术专家，主攻 Service Mesh 方向。个人技术网站 xargin.com，和他人合著《Go 语言高级编程》。

参考资料

Blog: 记一次在 MOSN 对 Dubbo、dubbo-go-hessian2 的性能优化

Tue, 02 Jun 2020 00:00:00 +0000

蚂蚁集团内部对 Service Mesh 的稳定性和性能要求是比较高的，内部 MOSN 广泛用于生产环境。在云上和开源社区，RPC 领域 Dubbo 和 Spring Cloud 同样广泛用于生产环境，我们在 MOSN 基础上，支持了 Dubbo 和 spring cloud 流量代理。我们发现在支持 Dubbo 协议过程中，经过 Mesh 流量代理后，性能有非常大的性能损耗，在大商户落地 Mesh 中也对性能有较高要求，因此本文会重点描述在基于 Go 语言库 dubbo-go-hessian2 、Dubbo 协议中对 MOSN 所做的性能优化。

性能优化概述

根据实际业务部署场景，并没有选用高性能机器，使用普通 linux 机器，配置和压测参数如下：

Intel (R) Xeon (R) Platinum 8163 CPU @ 2.50GHz 4 核 16G 。
pod 配置 2c、1g，JVM 参数 -server -Xms1024m -Xmx1024m。
网络延迟 0.23 ms, 2 台 linux 机器，分别部署 server + mosn, 压测程序 rpc-perfomance。

经过 3 轮性能优化后，使用优化版本 MOSN 将会获得以下性能收益（框架随机 512 和 1k 字节压测）：

512 字节数据：MOSN + Dubbo 服务调用 TPS 整体提升 55-82.8%，RT 降低 45% 左右，内存占用 40M，
1k 数据：MOSN + Dubbo 服务调用 TPS 整体提升 51.1-69.3%，RT 降低 41% 左右，内存占用 41M。

性能优化工具 pprof

磨刀不误砍柴工，在性能优化前首先要找到性能卡点，找到性能卡点后，另一个难点就是如何用高效代码优化替代 slow code。因为蚂蚁集团 Service Mesh 是基于 go 语言实现的，我们首选 go 自带的 pprof 性能工具，我们简要介绍这个工具如何使用。如果我们 go 库自带 http.Server 时并且在 main 头部导入 import _ "net/http/pprof"，go 会帮我们挂载对应的 handler , 详细可以参考 godoc 。

因为 mosn 默认会在 34902 端口暴露 http 服务，通过以下命令轻松获取 mosn 的性能诊断文件：

go tool pprof -seconds 60 http://benchmark-server-ip:34902/debug/pprof/profile
# 会生成类似以下文件，该命令采样cpu 60秒
# pprof.mosn.samples.cpu.001.pb.gz

然后继续用 pprof 打开诊断文件，方便在浏览器查看，在图 1-1 给出压测后 profiler 火焰图：

# http=:8000代表pprof打开8000端口然后用于web浏览器分析
# mosnd代表mosn的二进制可执行文件，用于分析代码符号
# pprof.mosn.samples.cpu.001.pb.gz是cpu诊断文件
go tool pprof -http=:8000 mosnd pprof.mosn.samples.cpu.001.pb.gz

图 1-1 MOSN 性能压测火焰图

在获得诊断数据后，可以切到浏览器 Flame Graph（火焰图，go 1.11 以上版本自带），火焰图的 x 轴坐标代表 CPU 消耗情况， y 轴代码方法调用堆栈。在优化开始之前，我们借助 go 工具 pprof 可以诊断出大致的性能卡点在以下几个方面（直接压 server 端 MOSN）：

MOSN 在接收 Dubbo 请求，CPU 卡点在 streamConnection.Dispatch
MOSN 在转发 Dubbo 请求，CPU 卡点在 downStream.Receive

可以点击火焰图任意横条，进去查看长方块耗时和堆栈明细（请参考图 1-2 和 1-3 所示）：

图 1-2 Dispatch 火焰图明细

图 1-3 Receive 火焰图明细

性能优化思路

本文重点记录优化了哪些 case 才能提升 50% 以上的吞吐量和降低 RT，因此后面直接分析当前优化了哪些 case。在此之前，我们以 Dispatch 为例，看下它为甚么那么吃性能。在 terminal 中通过以下命令可以查看代码行耗费 CPU 数据（代码有删减）：

go tool pprof mosnd pprof.mosn.samples.cpu.001.pb.gz
(pprof) list Dispatch
Total: 1.75mins
     370ms     37.15s (flat, cum) 35.46% of Total
      10ms       10ms    123:func (conn *streamConnection) Dispatch(buffer types.IoBuffer) {
      40ms      630ms    125:   log.DefaultLogger.Tracef("stream connection dispatch data string = %v", buffer.String())
         .          .    126:
         .          .    127:   // get sub protocol codec
         .      250ms    128:   requestList := conn.codec.SplitFrame(buffer.Bytes())
      20ms       20ms    129:   for _, request := range requestList {
      10ms      160ms    134:       headers := make(map[string]string)
         .          .    135:       // support dynamic route
      50ms      920ms    136:       headers[strings.ToLower(protocol.MosnHeaderHostKey)] = conn.connection.RemoteAddr().String()
         .          .    149:
         .          .    150:       // get stream id
      10ms      440ms    151:       streamID := conn.codec.GetStreamID(request)
         .          .    156:       // request route
         .       50ms    157:       requestRouteCodec, ok := conn.codec.(xprotocol.RequestRouting)
         .          .    158:       if ok {
         .     20.11s    159:           routeHeaders := requestRouteCodec.GetMetas(request)
         .          .    165:       }
         .          .    166:
         .          .    167:       // tracing
      10ms       80ms    168:       tracingCodec, ok := conn.codec.(xprotocol.Tracing)
         .          .    169:       var span types.Span
         .          .    170:       if ok {
      10ms      1.91s    171:           serviceName := tracingCodec.GetServiceName(request)
         .      2.17s    172:           methodName := tracingCodec.GetMethodName(request)
         .          .    176:
         .          .    177:           if trace.IsEnabled() {
         .       50ms    179:               tracer := trace.Tracer(protocol.Xprotocol)
         .          .    180:               if tracer != nil {
      20ms      1.66s    181:                   span = tracer.Start(conn.context, headers, time.Now())
         .          .    182:               }
         .          .    183:           }
         .          .    184:       }
         .          .    185:
         .      110ms    186:       reqBuf := networkbuffer.NewIoBufferBytes(request)
         .          .    188:       // append sub protocol header
      10ms      950ms    189:       headers[types.HeaderXprotocolSubProtocol] = string(conn.subProtocol)
      10ms      4.96s    190:       conn.OnReceive(ctx, streamID, protocol.CommonHeader(headers), reqBuf, span, isHearbeat)
      30ms       60ms    191:       buffer.Drain(requestLen)
         .          .    192:   }
         .          .    193:}

通过上面 list Dispatch 命令，性能卡点主要分布在 159 、 171 、172 、 181 、和 190 等行，主要卡点在解码 dubbo 参数、重复解参数、tracer、发序列化和 log 等。

1. 优化 dubbo 解码 GetMetas

我们通过解码 dubbo 的 body 可以获得以下信息，调用的目标接口（ interface ）和调用方法的服务分组（ group ）等信息，但是需要跳过所有业务方法参数，目前使用开源的 dubbo-go-hessian2 库，解析 string 和 map 性能较差，提升 hessian 库解码性能，会在本文后面讲解。

优化思路：

在 mosn 的 ingress 端（ mosn 直接转发请求给本地 java server 进程）, 我们根据请求的 path 和 version 窥探用户使用的 interface 和 group , 构建正确的 dataID 可以进行无脑转发，无需解码 body，榨取性能提升。

我们可以在服务注册时，构建服务发布的 path 、version 和 group 到 interface 、group 映射。在 mosn 转发 dubbo 请求时可以通过读锁查 cache + 跳过解码 body，加速 mosn 性能。

因此我们构建以下 cache 实现（数组 + 链表数据结构）, 可参见优化代码 diff ：

// metadata.go
// DubboPubMetadata dubbo pub cache metadata
var DubboPubMetadata = &Metadata{}

// DubboSubMetadata dubbo sub cache metadata
var DubboSubMetadata = &Metadata{}

// Metadata cache service pub or sub metadata.
// speed up for decode or encode dubbo peformance.
// please do not use outside of the dubbo framwork.
type Metadata struct {
    data map[string]*Node
    mu   sync.RWMutex // protect data internal
}

// Find cached pub or sub metatada.
// caller should be check match is true
func (m *Metadata) Find(path, version string) (node *Node, matched bool) {
    // we found nothing
    if m.data == nil {
        return nil, false
    }

    m.mu.RLocker().Lock()
    // for performance
    // m.mu.RLocker().Unlock() should be called.

    // we check head node first
    head := m.data[path]
    if head == nil || head.count <= 0 {
        m.mu.RLocker().Unlock()
        return nil, false
    }

    node = head.Next
    // just only once, just return
    // for dubbo framwork, that's what we're expected.
    if head.count == 1 {
        m.mu.RLocker().Unlock()
        return node, true
    }

    var count int
    var found *Node

    for ; node != nil; node = node.Next {
        if node.Version == version {
            if found == nil {
                found = node
            }
            count++
        }
    }

    m.mu.RLocker().Unlock()
    return found, count == 1
}

// Register pub or sub metadata
func (m *Metadata) Register(path string, node *Node) {
    m.mu.Lock()
    // for performance
    // m.mu.Unlock() should be called.

    if m.data == nil {
        m.data = make(map[string]*Node, 4)
    }

    // we check head node first
    head := m.data[path]
    if head == nil {
        head = &Node{
            count: 1,
        }
        // update head
        m.data[path] = head
    }

    insert := &Node{
        Service: node.Service,
        Version: node.Version,
        Group:   node.Group,
    }

    next := head.Next
    if next == nil {
        // fist insert, just insert to head
        head.Next = insert
        // record last element
        head.last = insert
        m.mu.Unlock()
        return
    }

    // we check already exist first
    for ; next != nil; next = next.Next {
        // we found it
        if next.Version == node.Version && next.Group == node.Group {
            // release lock and no nothing
            m.mu.Unlock()
            return
        }
    }

    head.count++
    // append node to the end of the list
    head.last.Next = insert
    // update last element
    head.last = insert
    m.mu.Unlock()
}

通过服务注册时构建好的 cache，可以在 MOSN 的 stream 做解码时命中 cache , 无需解码参数获取接口和 group 信息，可参见优化代码 diff :

// decoder.go
// for better performance.
// If the ingress scenario is not using group,
// we can skip parsing attachment to improve performance
if listener == IngressDubbo {
    if node, matched = DubboPubMetadata.Find(path, version); matched {
        meta[ServiceNameHeader] = node.Service
        meta[GroupNameHeader] = node.Group
    }
} else if listener == EgressDubbo {
    // for better performance.
    // If the egress scenario is not using group,
    // we can skip parsing attachment to improve performance
    if node, matched = DubboSubMetadata.Find(path, version); matched {
        meta[ServiceNameHeader] = node.Service
        meta[GroupNameHeader] = node.Group
    }
}

在 MOSN 的 egress 端（ mosn 直接转发请求给本地 java client 进程）, 我们采用类似的思路，我们根据请求的 path 和 version 去窥探用户使用的 interface 和 group , 构建正确的 dataID 可以进行无脑转发，无需解码 body，榨取性能提升。

2. 优化 dubbo 解码参数

在 dubbo 解码参数值的时候，MOSN 采用的是 hessian 的正则表达式查找，非常耗费性能。我们先看下优化前后 benchmark 对比，性能提升 50 倍。

go test -bench=BenchmarkCountArgCount -run=^$ -benchmem
BenchmarkCountArgCountByRegex-12    200000  6236 ns/op  1472 B/op   24 allocs/op
BenchmarkCountArgCountOptimized-12  10000000    124 ns/op   0 B/op  0 allocs/op

优化思路：

可以消除正则表达式，采用简单字符串解析识别参数类型个数， Dubbo 编码参数个数字符串实现并不复杂，主要给对象加 L 前缀、数组加 [、primitive 类型有单字符代替。采用 go 可以实现同等解析，可以参考优化代码 diff ：

func getArgumentCount(desc string) int {
    len := len(desc)
    if len == 0 {
        return 0
    }

    var args, next = 0, false
    for _, ch := range desc {

        // is array ?
        if ch == '[' {
            continue
        }

        // is object ?
        if next && ch != ';' {
            continue
        }

        switch ch {
        case 'V', // void
            'Z', // boolean
            'B', // byte
            'C', // char
            'D', // double
            'F', // float
            'I', // int
            'J', // long
            'S': // short
            args++
        default:
            // we found object
            if ch == 'L' {
                args++
                next = true
                // end of object ?
            } else if ch == ';' {
                next = false
            }
        }

    }
    return args
}

3. 优化 dubbo hessian go 解码 string 性能

在图 1-2 中可以看到 dubbo hessian go 在解码 string 占比 CPU 采样较高，我们在解码 dubbo 请求时，会解析 dubbo 框架版本、调用 path 、接口版本和方法名，这些都是 string 类型，dubbo hessian go 解析 string 会影响 RPC 性能。

我们首先跑一下 benchmar k 前后解码 string 性能对比，性能提升 56.11%，对应到 RPC 中有 5% 左右提升。

BenchmarkDecodeStringOriginal-12     1967202     613 ns/op     272 B/op     6 allocs/op
BenchmarkDecodeStringOptimized-12     4477216     269 ns/op     224 B/op     5 allocs/op

优化思路：

直接使用 UTF-8 byte 解码，性能最高，之前先解码 byte 成 rune , 对 rune 解码成 string ，及其耗费性能。增加批量 string chunk copy ，降低 read 调用，并且使用 unsafe 转换 string （避免一些校验），因为代码优化 diff 较多，这里给出优化代码 PR 。

go SDK 代码 runtime/string.go#slicerunetostring（ rune 转换成 string ），同样是把 rune 转成 byte 数组，这里给了我优化思路启发。

4. 优化 hessian 库编解码对象

虽然消除了 dubbo 的 body 解码部分，但是 MOSN 在处理 dubbo 请求时，必须要借助 hessian 去 decode 请求头部的框架版本、请求 path 和接口版本值。但是每次在解码的时候都会创建序列化对象，开销非常高，因为 hessian 每次在创建 reader 的时候会 allocate 4k 数据并 reset。

      10ms       10ms     75:func unSerialize(serializeId int, data []byte, parseCtl unserializeCtl) *dubboAttr {
      10ms      140ms     82:   attr := &dubboAttr{}
      80ms      2.56s     83:   decoder := hessian.NewDecoderWithSkip(data[:])
ROUTINE ======================== bufio.NewReaderSize in /usr/local/go/src/bufio/bufio.go
      50ms      2.44s (flat, cum)  2.33% of Total
         .      220ms     55:   r := new(Reader)
      50ms      2.22s     56:   r.reset(make([]byte, size), rd)
         .          .     57:   return r
         .          .     58:}

我们可以写个池化内存前后性能对比，性能提升 85.4% , benchmark 用例：

BenchmarkNewDecoder-12  1487685 803 ns/op   4528 B/op   9 allocs/op
BenchmarkNewDecoderOptimized-12 10564024    117 ns/op   128 B/op    3 allocs/op

优化思路：

在每次编解码时，池化 hessian 的 decoder 对象，新增 NewCheapDecoderWithSkip 并支持 reset 复用 decoder 。

var decodePool = &sync.Pool{
    New: func() interface{} {
        return hessian.NewCheapDecoderWithSkip([]byte{})
    },
}

// 在解码时按照如下方法调用
decoder := decodePool.Get().(*hessian.Decoder)
// fill decode data
decoder.Reset(data[:])
hessianPool.Put(decoder)

5. 优化重复解码 service 和 methodName 值

xprotocol 在实现 xprotocol.Tracing 获取服务名称和方法时，会触发调用并解析 2 次，调用开销比较大。

10ms      1.91s    171:           serviceName := tracingCodec.GetServiceName(request)
   .      2.17s    172:           methodName := tracingCodec.GetMethodName(request)

优化思路：

因为在 GetMetas 里面已经解析过一次了，可以把解析过的 headers 传进去，如果 headers 有了就不用再去解析了，并且重构接口名称为一个，返回值为二元组，消除一次调用。

6. 优化 streamID 类型转换

在 go 中将 byte 数组和 streamID 进行互转的时候，比较费性能。

优化思路：

生产代码中，尽量不要使用 fmt.Sprintf 和 fmt.Printf 去做类型转换和打印信息。可以使用 strconv 去转换。

   .      430ms    147: reqIDStr := fmt.Sprintf("%d", reqID)
60ms      4.10s    168: fmt.Printf("src=%s, len=%d, reqid:%v\n", streamID, reqIDStrLen, reqIDStr)

7. 优化昂贵的系统调用

mosn 在解码 dubbo 的请求时，会在 header 中塞一份远程 host 的地址，并且在 for 循环中获取 remote IP，系统调用开销比较高。

优化思路：

50ms      920ms    136:        headers[strings.ToLower(protocol.MosnHeaderHostKey)] = conn.connection.RemoteAddr().String()

在获取远程地址时，尽可能在 streamConnection 中 cache 远程 IP 值，不要每次都去调用 RemoteAddr。

8. 优化 slice 和 map 触发扩容和 rehash

在 mosn 处理 dubbo 请求时，会根据接口、版本和分组去构建 dataID ，然后匹配 cluster , 会创建默认 slice 和 map 对象，经过性能诊断，导致不断 allocate slice 和 grow map 容量比较费性能。

优化思路：

使用 slice 和 map 时，尽可能预估容量大小，使用 make (type, capacity) 去指定初始大小。

9. 优化 trace 日志级别输出

mosn 中不少代码在处理逻辑时，会打很多 trace 级别的日志，并且会传递不少参数值。

优化思路：

调用 trace 输出前，尽量判断一下日志级别，如果有多个 trace 调用，尽可能把所有字符串写到 buf 中，然后把 buf 内容写到日志中，并且尽可能少的调用 trace 日志方法。

10. 优化 tracer、log 和 metrics

在大促期间，对机器的性能要求较高，经过性能诊断，tracer、mosn log 和 cloud metrics 写日志（ IO 操作）非常耗费性能。

优化思路：

通过配置中心下发配置或者增加大促开关，允许 API 调用这些 feature 的开关。

/api/v1/downgrade/on
/api/v1/downgrade/off

11. 优化 route header 解析

MOSN 中在做路由前，需要做大量的 header 的 map 访问，比如 IDC、antvip 等逻辑判断，商业版或者开源 mosn 不需要这些逻辑，这些也会占用一些开销。

优化思路：

如果是云上逻辑，主站的逻辑都不走。

12. 优化 featuregate 调用

在 MOSN 中处理请求时，为了区分主站和商业版路由逻辑，会通过 featuregate 判断逻辑走哪部分。通过 featuregate 调用开销较大，需要频繁的做类型转换和多层 map 去获取。

优化思路：

通过一个 bool 变量记录 featuregate 对应开关，如果没有初始化过，就主动调用一下 featuregate。

未来性能优化思考

经过几轮性能优化，目前看火焰图，卡点都在 connection 的 read 和 write ，可以优化的空间比较小了。但是可能从以下场景中获得收益：

减少 connection 的 read 和 write 次数 (syscall) 。
优化 IO 线程模型，减少携程和上下文切换等。

作为结束，给出了最终优化后的火焰图，大部分卡点都在系统调用和网络读写，请参考图 1-4。

图 1-4 优化版本 MOSN + Dubbo 火线图

其他

pprof 工具异常强大，可以诊断 CPU、memory、go 协程、tracer 和死锁等，该工具可以参考 godoc，性能优化参考：

关于作者

商宗海（诣极），GitHub ID zonghaishang，Apache Dubbo PMC，目前就职于蚂蚁集团金服中间件团队，主攻 RPC 和 Service Mesh 方向。《深入理解 Apache Dubbo 与实战》一书作者。

Blog: MOSN 源码解析 - 总览

Fri, 08 May 2020 00:00:00 +0000

起因

在2020年伊始，MOSN 团队在社区发起了 MOSN 源码解析系列活动，本次活动旨在增强社区对 MOSN 的认知，促进开源社区的交流，是大家学习和使用 MOSN，与 MOSN 的核心开发者直接交流的一个良好契机。

经过十几位社区同学的参与，目前十四篇文章都已经完成，本文将做一个整体介绍，方便大家更好的了解 MOSN。查看原文解析系列文章请访问： https://mosn.io/blog/code/。

模块能力

首先是 MOSN 的启动流程，通过这篇文章，你可以了解 MOSN 的启动过程，包括配置解析，日志初始化，Xds 初始化，各子模块启动。另外通过启动流程（v0.4.0）这篇文章针对 AdminApi 初始化等过程做了分析，同时也介绍了普通启动和热升级启动的区别，对 MOSN 的平滑升级能力有一个初步的了解。

路由这个章节，你可以了解路由的配置解析，运行方式和动态路由等能力。

在 TLS 你可以了解 MOSN 怎样集成 Go Runtime 的 TLS 能力，并在此基础上我们进行了那些能力的加强，比如明文密文自动识别能力，SDS 能力支持，对 TLS 握手进行自定义校验的扩展能力等。

多协议机制是 MOSN 比较重要的一部分，你可以了解多协议机制产生的背景与实践痛点，一些常见的协议扩展思路初探，SOFABolt 协议接入实践，以及 MOSN 多协议机制设计解读。通过阅读本文，你可以很容易的实现一个自己的协议了。

变量机制是 MOSN 的一个核心能力，通过该机制，MOSN 可以方便的获取和设置一些自定义的值，来满足打印日志，路由规则，请求自定变量等能力。

共享内存模型讲解了 MOSN 的共享内存框架，MOSN 通过这个框架实现了共享内存 metrics 实现，用于平滑升级时保证 metric 数据的准确性。

为了支持 MOSN 跨语言的扩展机制能力，我们开发了 plugin机制，通过独立进程进行GRPC交互，让用户可以用任何语言来开发插件。

连接池介绍了 MOSN 针对连接池的管理和使用。连接池是上下游 MOSN 之间进行长连接复用以提高转发效率与降低时延的关键，MOSN 连接池提供基于 HTTP1, HTTP2, SOFARPC, XProtocol 协议的连接池。

协程模型讲解了MOSN的整个转发流程，包括读写IO流程，proxy状态机，协程池等核心能力，可以让读者更加清晰的了解 MOSN 的处理流程。

Go 语言的 GC 对程序的性能有很大的影响，针对于此我们开发了内存复用机制，减少 GC 来提升 MOSN 性能，本文分析了 MOSN 对内存复用的设计和用法，其基于 sync.Pool 之上封装了一层自己的注册管理逻辑，增强了管理能力、易用性和复用性。

log系统介绍了 log 日志和 metric 两部分内容，log 也作为一个单独的库，读者可以单独使用。

xds 介绍了 MOSN 对齐 xds 能力的细节。

HTTP能力介绍 MOSN 对 HTTP 的处理流程，包括适配 fasthttp，内存复用，连接池等能力。

filter扩展机制分析了 filter 扩展机制的实现，并简述了实现自己的 filter 需要做的东西。大家可以通过该机制，使用 MOSN 来处理自己的业务场景。

最后

感谢社区同学的热情参与，MOSN 源码解析活动圆满收尾，也敬请关注我们后续的其他活动。

Blog: MOSN 支持使用 SkyWalking 进行分布式追踪

Tue, 28 Apr 2020 00:00:00 +0000

相比传统的巨石（Monolith）应用，微服务的一个主要变化是将应用中的不同模块拆分为了独立的进程。在微服务架构下，原来进程内的方法调用成为了跨进程的远程方法调用。相对于单一进程内的方法调用而言，跨进程调用的调试和故障分析是非常困难的，难以使用传统的代码调试程序或者日志打印来对分布式的调用过程进行查看和分析。

如上图右边所示，微服务架构中系统中各个微服务之间存在复杂的调用关系。

一个来自客户端的请求在其业务处理过程中经过了多个微服务进程。我们如果想要对该请求的端到端调用过程进行完整的分析，则必须将该请求经过的所有进程的相关信息都收集起来并关联在一起，这就是“分布式追踪”。

以上关于分布式追踪的介绍引用自 Istio Handbook。

MOSN 中 tracing 的架构

MOSN 的 tracing 框架由 Driver、Tracer 和 Span 三个部分组成。

Driver 是 Tracer 的容器，管理注册的 Tracer 实例，Tracer 是 tracing 的入口，根据请求信息创建一个 Span，Span 存储当前跨度的链路信息。

目前 MOSN tracing 有 SOFATracer 和 SkyWalking 两种实现。SOFATracer 支持 http1 和 xprotocol 协议的链路追踪，将 trace 数据写入本地日志文件中。SkyWalking 支持 http1 协议的链路追踪，使用原生的 Go 语言探针 go2sky 将 trace 数据通过 gRPC 上报到 SkyWalking 后端服务。

快速开始

下面将使用 Docker 和 docker-compose 来快速开始运行一个集成了 SkyWalking 的分布式追踪示例，该示例代码请见 MOSN GitHub。

准备

安装 docker 和 docker-compose。

需要一个编译好的 MOSN 程序，您可以下载 MOSN 源码自行编译，或者直接下载 MOSN v0.12.0 发行版以获取 MOSN 的运行时二进制文件。

下面将以源码编译的方式演示 MOSN 如何与 SkyWalking 集成。

cd ${projectpath}/cmd/mosn/main
go build

获取示例代码目录。

${targetpath} = ${projectpath}/examples/codes/trace/skywalking/http/

将编译好的程序移动到示例代码目录。

mv main ${targetpath}/
cd ${targetpath}

目录结构

下面是 SkyWalking 的目录结构。

* skywalking
└─── http
│           main                           # 编译完成的 MOSN 程序
|           server.go                      # 模拟的 Http Server
|           clint.go                       # 模拟的 Http Client
|           config.json                    # MOSN 配置
|           skywalking-docker-compose.yaml # skywalking docker-compose

运行说明

启动 SkyWalking oap & ui。

docker-compose -f skywalking-docker-compose.yaml up -d

启动一个 HTTP Server。

go run server.go

启动 MOSN。

./main start -c config.json

启动一个 HTTP Client。

go run client.go

打开 http://127.0.0.1:8080 查看 SkyWalking-UI，SkyWalking Dashboard 界面如下图所示。

在打开 Dashboard 后请点击右上角的 Auto 按钮以使页面自动刷新。

Demo 视频

下面来看一下该 Demo 的操作视频。

清理

要想销毁 SkyWalking 后台运行的 docker 容器只需要下面的命令。

cd ${projectpath}/examples/codes/trace/skywalking/http/
docker-compose -f skywalking-docker-compose.yaml down

未来计划

在今年五月份，SkyWalking 8.0 版本会进行一次全面升级，采用新的探针协议和分析逻辑，探针将更具互感知能力，更好的在 Service Mesh 下使用探针进行监控。同时，SkyWalking 将开放之前仅存在于内核中的 metrics 指标分析体系。Prmoetheus、Spring Cloud Sleuth、Zabbix 等常用的 metrics 监控方式，都会被统一的接入进来，进行分析。此外， SkyWalking 与 MOSN 社区将继续合作：支持追踪 Dubbo 和 SOFARPC，同时适配 sidecar 模式下的链路追踪。

关于 MOSN

MOSN 是一款使用 Go 语言开发的网络代理软件，由蚂蚁集团开源并经过几十万容器的生产级验证。 MOSN 作为云原生的网络数据平面，旨在为服务提供多协议、模块化、智能化、安全的代理能力。 MOSN 是 Modular Open Smart Network 的简称。 MOSN 可以与任何支持 xDS API 的 Service Mesh 集成，亦可以作为独立的四、七层负载均衡，API Gateway、云原生 Ingress 等使用。

GitHub：https://github.com/mosn/mosn
官网：https://mosn.io

关于 Skywalking

SkyWalking 是观察性分析平台和应用性能管理系统。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。支持 Java、.Net Core、PHP、NodeJS、Golang、LUA 语言探针，支持 Envoy/MOSN + Istio 构建的 Service Mesh。

GitHub：https://github.com/apache/skywalking
官网：https://skywalking.apache.org

关于本文中的示例请参考 MOSN GitHub 和 MOSN 官方文档。

Blog: MOSN 源码解析 - TLS

Sun, 26 Apr 2020 00:00:00 +0000

本文基于的内容是 MOSN v0.12.0。

概述

MOSN 提供了基于 TLS 加密的安全通信的能力，本文主要从三个方面介绍 MOSN 的 TLS 相关实现，包括：MOSN 作为服务端提供 TLS 的能力、MOSN 作为客户端提供 TLS 的能力，以及 TLS 模块的实现。关于 TLS 的配置，可以参考配置文件说明的文档。

服务端 (Listener)

MOSN 作为服务端的时候，就是有请求发送到 MOSN，基于 MOSN 的 Listener 处理请求。Listener 做配置解析的时候，如果存在 TLS 相关的配置，会尝试生成一个 TLSManager，在连接建立的时候，会根据 TLSManager 返回的状态判断是否需要建立 TLS 加密连接，代码如下：

func newActiveListener(lc *v2.Listener, ...) (*activeListener, error) { // 其他参数省略
    ... // 省略
  mgr, err := mtls.NewTLSServerContextManager(lc)
  if err != nil {
    return nil,err
  }
  al.tlsMng = mgr
  return al, nil
}

func (al *activeListener) OnAccept(rawc net.Conn, ch chan api.Connection, ...) { // 其他参数省略
    ...// 省略
    // if ch is not nil, the conn has been initialized in func transferNewConn
    if al.tlsMng != nil && ch == nil {
        conn, err := al.tlsMng.Conn(rawc)
        if err != nil {
            rawc.Close()
            return
        }
        rawc = conn
    }
    arc := newActiveRawConn(rawc, al)
    ...// 省略
}

判断是否需要建立 TLS 连接会基于 TLSManager 的状态。

如果 TLSManager 是关闭 TLS 状态，则一定不支持 TLS 连接。
如果 TLSManager 是开启 TLS 状态，还需要额外判断是否支持 Inspector 模式，如果支持 Inspector，则说明 MOSN 的 Listener 可以同时处理 TLS 加密连接和明文的非加密连接；此时 MOSN 会等待连接上收到的第一个数据，判断请求是明文还是 TLS，从而决定使用连接状态。如果不支持 Inspector 模式，那么就只支持 TLS 连接。

判断是否兼容 Inspector 的逻辑如下。MOSN 会在建立上执行Peek，尝试获取连接上第一个数据字节，如果是 0x16（来自 TLS 握手的 Client Hello 的第一个字节），则判断为 TLS 连接，否则判断为明文连接。

func (mng *serverContextManager) Conn(c net.Conn) (net.Conn, error) {
        if _, ok := c.(*net.TCPConn); !ok {
                return c, nil
        }
        if !mng.Enabled() {
                return c, nil
        }
        if !mng.inspector {
                return &TLSConn{
                        tls.Server(c, mng.config.Clone()),
                }, nil
        }
        // inspector
        conn := &Conn{
                Conn: c,
        }
        buf, err := conn.Peek()
        if err != nil {
                return nil, err
        }
        switch buf[0] {
        // TLS handshake
        case 0x16:
                return &TLSConn{
                        tls.Server(conn, mng.config.Clone()),
                }, nil
        // Non TLS
        default:
                return conn, nil
        }
}

除了普通的 TLS 以外，MOSN 还支持双向 TLS，即 Server 端要求 Client 端也提供证书，也是可以配置不同的兼容场景，包括：

Client 必须提供 TLS 证书，完成双向 TLS 加密。
要求 Client 提供 TLS 证书，但是如果 Client 没有提供证书，也可以兼容执行普通的 TLS 加密逻辑实现如下。

func (ctx *tlsContext) setServerConfig(tmpl tls.Config, cfg *v2.TLSConfig, hooks ConfigHooks) {
        tlsConfig := &tmpl
        // no certificate should be set no server tls config
        if len(tlsConfig.Certificates) == 0 {
                return
        }
        if !cfg.RequireClientCert {
                tlsConfig.ClientAuth = tls.NoClientCert
        } else {
                if cfg.VerifyClient {
                        tlsConfig.ClientAuth = tls.RequireAndVerifyClientCert
                } else {
                        tlsConfig.ClientAuth = tls.VerifyClientCertIfGiven
                }
        }
        tlsConfig.VerifyPeerCertificate = hooks.ServerHandshakeVerify(tlsConfig)
        ctx.server = tlsConfig
        // build matches
        ctx.buildMatch()
}

客户端 (Cluster)

MOSN 作为客户端的时候，就是 MOSN 在把请求向后端（Upstream）转发的时候，基于 MOSN 的 Cluster 配置转发请求。在 Cluster 配置解析的时候，如果存在 TLS 相关的配置，会尝试生成一个 TLSManager。在转发请求向后端建立连接的时候，会基于两个维度判断是否要建立 TLS 连接。

首先判断建立连接的 Host 配置是否允许建立 TLS 连接，这个是考虑到有的场景特定的 Host 不希望建立 TLS 连接或者不支持 TLS 连接进行的设计。默认配置情况下，Host 配置都是允许建立 TLS 连接的。
在 Host 允许建立 TLS 的情况下，会根据 TLSManager 的状态，判断是否要建立 TLS 连接。

func newSimpleCluster(clusterConfig v2.Cluster) *simpleCluster {
    ... // 省略
    mgr, err := mtls.NewTLSClientContextManager(&clusterConfig.TLS)
    if err != nil {
       // 日志记录，此时 Cluster 还可以正常创建，等同于不支持 TLS
    }
    info.tlsMng = mgr
    cluster := &simpleCluster{
        info: info,
    }
    ... //
    return cluster
}

func (sh *simpleHost) CreateConnection(context context.Context) types.CreateConnectionData {
    var tlsMng types.TLSContextManager
    if sh.SupportTLS() {
         tlsMng = sh.clusterInfo.TLSMng()
    }
    clientConn := network.NewClientConnection(nil, sh.clusterInfo.ConnectTimeout(), tlsMng, sh.Address(), nil)
    ... // 省略
}

TLS 模块

MOSN 的 TLS 能力，都通过 TLSManager 提供，TLSManager 分为 ServerManager 和 ClientManager，分别有各自的逻辑，其核心都是通过 Conn 方法，利用 Provider 提供tls.Config，建立 TLS 连接。

provider

provider 是 MOSN 的 TLS 模块中提供 TLS 运行时配置的模块，支持静态配置模式staticProvider和动态 SDS 模式sdsProvider。无论是哪种模式，provider 中最终存储的对象都是 MOSN 定义的tlsContext。

MOSN 在进行配置解析时，会判断使用哪种模式，然后基于不同的情况解析出 tlsContext。同时需要说明的是，静态模式只是区别于动态 SDS 模式的一种模式，通过 TLS 的扩展，我们也可以做到静态模式下，让证书动态获取，这一点在后文中会进行介绍。

func NewProvider(cfg *v2.TLSConfig) (types.TLSProvider, error) {
    if !cfg.Status { // 未开启 TLS
        return nil,nil
    }
    if cfg.SdsConfig != nil { // 动态 SDS 模式
        ... // 省略
        return getOrCreateProvider(cfg), nil
    } else { // 静态配置模式
        ctx, err := newTLSContext(cfg, secret)
        ... // 省略
    }
}

tlsContext

tlsContext是 MOSN 中 TLS 运行时的基础单元，主要功能是负责提供 MOSN 运行时所需要的tls.Config。其定义与方法如下。

type tlsContext struct {
        serverName string
        ticket     string
        matches    map[string]struct{}
        client     *tls.Config
        server     *tls.Config
}
func (ctx *tlsContext) buildMatch() {}
func (ctx *tlsContext) setServerConfig(tmpl tls.Config, cfg *v2.TLSConfig, hooks ConfigHooks) {}
func (ctx *tlsContext) setClientConfig(tmpl tls.Config, cfg *v2.TLSConfig, hooks ConfigHooks) {}
func (ctx *tlsContext) MatchedServerName(sn string) bool {}
func (ctx *tlsContext) MatchedALPN(protos []string) bool {}
func (ctx *tlsContext) GetTLSConfig(client bool) *tls.Config {}

基于 TLS 的配置，通过newTLSContext生成tlsContext，随后在 TLSManager 中通过MatchedServerName和MatchedALPN判断是否要选择该tlsContext，最后通过GetTLSConfig提供tls.Config建立 TLS 连接。

func newTLSContext(cfg *v2.TLSConfig, secret *secretInfo) (*tlsContext, error) {
    ... // 省略
    // extension config
    factory := getFactory(cfg.Type)
    hooks := factory.CreateConfigHooks(cfg.ExtendVerify)
    // pool can be nil, if it is nil, TLS uses the host's root CA set.
    pool, err := hooks.GetX509Pool(secret.Validation)
    if err != nil {
        return nil, err
    }
    tmpl.RootCAs = pool
    tmpl.ClientCAs = pool
    // set tls context
    ctx := &tlsContext{
        serverName: cfg.ServerName,
        ticket:     cfg.Ticket,
    }
    cert, err := hooks.GetCertificate(secret.Certificate, secret.PrivateKey)
    ... // 省略
    // needs copy template config
    if len(tmpl.Certificates) > 0 {
        ctx.setServerConfig(*tmpl, cfg, hooks)
    }
    ctx.setClientConfig(*tmpl, cfg, hooks)
    return ctx, nil
}

secretInfo包含了可以获取完整的 TLS 证书信息的内容，完整的证书信息包括证书、私钥、以及签发证书的 CA 信息。通常情况下，secretInfo 就是完整的 TLS 证书信息，在有 tls 扩展的场景，则是利用secretInfo通过扩展实现进行获取。代码中通过getFactory获取到的hooks就是扩展实现，在没有扩展的时候，返回的就是默认的hooks。

动态 SDS 模式下，当 MOSN 收到来自 SDS 服务端的信息以后，也是通过调用newTLSContext生成tlsContext提供 TLS 能力。

TLS 扩展

考虑到一些 TLS 运行时的配置安全需求以及证书校验需求，MOSN 对 TLS 运行时配置提供了一个扩展点，可以按照需求扩展两种类型，四个功能：

解析证书和私钥的方式可扩展，默认是读取证书 / 私钥的明文字符串或明文文件
解析 CA 证书的方式可扩展，默认是读取 CA 证书的明文字符串或明文文件
Server 端握手校验的方式可扩展，默认是标准的 TLS 握手校验方式
Client 端握手校验的方式可扩展，默认是标准的 TLS 握手校验方式

// ConfigHooks is a  set of functions used to make a tls config
type ConfigHooks interface {
        // GetCertificate returns the tls.Certificate by index.
        // By default the index is the cert/key file path or cert/key pem string
        GetCertificate(certIndex, keyIndex string) (tls.Certificate, error)
        // GetX509Pool returns the x509.CertPool, which is a set of certificates.
        // By default the index is the ca certificate file path or certificate pem string
        GetX509Pool(caIndex string) (*x509.CertPool, error)
        // ServerHandshakeVerify returns a function that used to set "VerifyPeerCertificate" defined in tls.Config.
        // If it is returns nil, the normal certificate verification will be used.
        // Notice that we set tls.Config.InsecureSkipVerify to make sure the "VerifyPeerCertificate" is called,
        // so the ServerHandshakeVerify should verify the trusted ca if necessary.
        // If the TLSConfig.RequireClientCert is false, the ServerHandshakeVerify will be ignored
        ServerHandshakeVerify(cfg *tls.Config) func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error
        // ClientHandshakeVerify returns a function that used to set "VerifyPeerCertificate" defined in tls.Config.
        // If it is returns nil, the normal certificate verification will be used.
        // Notice that we set tls.Config.InsecureSkipVerify to make sure the "VerifyPeerCertificate" is called,
        // so the ClientHandshakeVerify should verify the trusted ca if necessary.
        // If TLSConfig.InsecureSkip is true, the ClientHandshakeVerify will be ignored.
        ClientHandshakeVerify(cfg *tls.Config) func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error
}

Blog: MOSN 源码解析 - 路由

Sun, 26 Apr 2020 00:00:00 +0000

本文基于的内容是 MOSN v0.12.0。

MOSN 的路由能力目前仍然处于不断更新完善的阶段，详细的配置介绍可以参考 MOSN 配置文档中的路由部分。本文将主要从三个方面来介绍 MOSN 的路由功能：

针对路由模块的配置解析
路由模块是如何运行的
动态路由的实现

配置解析逻辑

路由的配置要在 MOSN 中生效，包含两个部分：

proxy 的配置中，指定路由的名字router_config_name，说明 proxy 需要引用对应名字的路由。
路由的配置，包含路由的名字以及其他路由配置。

其中路由的配置可以配置在两个地方，一个是通过connection_manager进行配置，这个方式是历史遗留配置，作为兼容性保留的内容，不推荐使用这种方式；另一个是通过routers进行配置。如果两处配置包含同名的路由配置，会以routers中的配置为准。代码如下：

func NewMosn(c *v2.MOSNConfig) *Mosn {
     ... // 省略
     for _, serverConfig := range c.Servers {
         ... // 省略
         for idx, _ := range serverConfig.Listeners {
             lc := configmanager.ParseListenerConfig(&serverConfig.Listeners[idx], inheritListeners)
             // deprecated: keep compatible for route config in listener's connection_manager
             deprecatedRouter, err := configmanager.ParseRouterConfiguration(&lc.FilterChains[0])
             if err != nil {
                 log.StartLogger.Fatalf("[mosn] [NewMosn] compatible router: %v", err)
             }
             if deprecatedRouter.RouterConfigName != "" {
                 m.routerManager.AddOrUpdateRouters(deprecatedRouter)
             }
             ... // 省略
         }
         // Add Router Config
         for _, routerConfig := range serverConfig.Routers {
             if routerConfig.RouterConfigName != "" {
                 m.routerManager.AddOrUpdateRouters(routerConfig)
             }
         }
     }
     ... // 省略
 }

根据代码，可以看到在解析配置时，会先解析 Listener 中的路由配置（已废弃字段，兼容逻辑），随后单独解析 Routers 配置。配置解析完成以后，都是通过AddOrUpdateRouters使配置生效，所以后解析的 Routers 配置如果与 Listener 中的配置同名，则会通过 Update 覆盖掉 Listener 中的配置。由此我们也可以看到不同的 Listener、不同的 Proxy，如果引用了相同名字的路由，则对应的是同一份路由规则。

路由模块运行

当前的路由能力，是与proxy进行绑定的。为了说明路由的逻辑，我们先来看一下在proxy 模式下的 MOSN，收到一个请求后，是如何处理的。

首先在 MOSN 的 Listener 新建一个连接的时候，通过OnNewConnection创建NetworkFilters，而proxy就是其中一个，因此一个连接对应一个proxy。在proxy创建的时候会基于配置获取对应的路由信息routersWrapper，所以在连接创建以后，在此连接上的请求会使用哪个路由配置就已经决定了。

func (al *activeListener) OnNewConnection(ctx context.Context, conn api.Connection) {
    filterManager := conn.FilterManager()
    for _, nfcf := range al.networkFiltersFactories {
        nfcf.CreateFilterChain(ctx, filterManager)
    }
    ... // 省略
}
func NewProxy(ctx context.Context, config *v2.Proxy) Proxy {
    ... // 省略
    if routersWrapper := router.GetRoutersMangerInstance().GetRouterWrapperByName(proxy.config.RouterConfigName); routersWrapper != nil {
        proxy.routersWrapper = routersWrapper
    }
    ... // 省略
}

func NewProxy(ctx context.Context, config *v2.Proxy) Proxy {
    ... // 省略
    if routersWrapper := router.GetRoutersMangerInstance().GetRouterWrapperByName(proxy.config.RouterConfigName); routersWrapper != nil {
        proxy.routersWrapper = routersWrapper
    }
    ... // 省略
}

在连接创建以后，开始处理请求。每次收到一个请求，经过协议解析以后，最终会走到proxy中downStream的OnReceive方法。在OnReceive中，经过一系列处理，可能会走到路由匹配阶段matchRoute。MOSN 通过routersWrapper获取到当前运行时的routers，随后执行路由匹配逻辑，完成路由匹配。

func (s *downStream) matchRoute() {
    if s.proxy.routersWrapper == nil || s.proxy.routersWrapper.GetRouters() == nil {
        s.requestInfo.SetResponseFlag(api.NoRouteFound)
        s.sendHijackReply(types.RouterUnavailableCode, headers)
        return
    }
    routers := s.proxy.routersWrapper.GetRouters()
    ... // 省略
}

动态路由

MOSN 在路由模块中，设计了动态更新的接口，可以让 MOSN 在运行时动态更新路由的配置。经过前面的分析，我们可以看到 MOSN 配置解析时，也时通过动态更新的接口让路由配置生效的。除了配置解析以外，MOSN 默认可以通过 xDS 完成路由的动态更新，也可以通过扩展调用动态更新的接口完成动态路由配置更新。

路由动态更新主要提供了三个接口。

func (rm *routersManagerImpl) AddOrUpdateRouters(routerConfig *v2.RouterConfiguration) error {}
func (rm *routersManagerImpl) AddRoute(routerConfigName, domain string, route *v2.Router) error {}
func (rm *routersManagerImpl) RemoveAllRoutes(routerConfigName, domain string) error {}

默认情况下，都是使用AddOrUpdateRouters，使用一个完整的路由配置，对路由进行更新。AddRoute和RemoveAllRoutes是在特殊情况下，用于特定的路由配置追加 / 删除路由匹配规则使用的。

动态路由更新还涉及到一个问题就是更新以后需要动态生效。从之前的路由运行逻辑分析中，我们知道 MOSN 在连接建立的时候，就通过GetRouterWrapperByName完成了路由选择，为了让路由配置更新对存量连接也可以生效，AddOrUpdateRouters的逻辑进行了针对性处理。

// 省略了日志部分
func (rm *routersManagerImpl) AddOrUpdateRouters(routerConfig *v2.RouterConfiguration) error {
    if routerConfig == nil {
        return ErrNilRouterConfig
    }
    if v, ok := rm.routersWrapperMap.Load(routerConfig.RouterConfigName); ok {
        rw, ok := v.(*RoutersWrapper)
        if !ok {
            return ErrUnexpected
        }
        routers, err := NewRouters(routerConfig)
        if err != nil {
            return err
        }
        rw.mux.Lock()
        rw.routers = routers
        rw.routersConfig = routerConfig
        rw.mux.Unlock()
    } else {
        routers, _ := NewRouters(routerConfig)
        rm.routersWrapperMap.Store(routerConfig.RouterConfigName, &RoutersWrapper{
            routers:       routers,
            routersConfig: routerConfig,
        })
    }
    // update admin stored config for admin api dump
    store.SetRouter(routerConfig.RouterConfigName, *routerConfig)
}
func (rm *routersManagerImpl) GetRouterWrapperByName(routerConfigName string) types.RouterWrapper {
    if v, ok := rm.routersWrapperMap.Load(routerConfigName); ok {
        rw, ok := v.(*RoutersWrapper)
        if !ok {
            return nil
        }
        return rw
    }
}

当一个路由配置是新增的时候，MOSN 会忽略掉NewRouters的错误，即允许路由配置解析失败，此时的目的是为了让GetRouterWrapperByName能返回一个RoutersWrapper。但是如果是路由配置更新，则不会忽略NewRouters的错误，必须是有效的配置才能完成更新。在之后的运行过程中，如果存在路由配置更新，更新的是RoutersWrapper中的routers，存量连接中的RoutersWrapper也可以获取到最新的routers，实现路由规则的动态生效。

总结

Blog: MOSN 扩展机制解析

Thu, 09 Apr 2020 21:00:00 +0800

本文根据 SOFAChannel#14 直播分享整理，主题：云原生网络代理 MOSN 扩展机制解析。

大家好，我是今天的讲师永鹏，来自蚂蚁集团，目前主要负责 MOSN 的开发，也是 MOSN 的Committer。今天我为大家分享的是云原生网络代理 MOSN 的扩展机制，希望通过这次分享以后，能让大家了解 MOSN 的可编程扩展能力，可以基于 MOSN 的扩展能力，按照自己实际的业务需求进行二次开发。

前言

今天我们将从以下几个方面，对 MOSN 的扩展机制进行介绍：

MOSN 扩展能力和扩展机制的详细介绍；
结合示例对 MOSN 的 Filter 扩展机制与插件扩展机制进行详细介绍；
MOSN 后续扩展能力规划与展望；

欢迎大家有兴趣一起共建 MOSN。在本次演讲中涉及到的示例就在我们的 Github 的 examples/codes/mosn-extensions 目录下，大家有兴趣的也可以下载下来运行一下，关于这些示例我们还做了一些小活动，也希望大家可以踊跃参与。

MOSN：https://github.com/mosn/mosn

MOSN 简介

MOSN 作为云原生的网络代理，旨在为服务提供多协议、模块化、智能化、安全的代理能力。在实际生产使用中，不同的厂商会有不同的使用场景，通用的网络代理能力面对具体的业务场景会显得有些不足，通常都需要进行二次开发以满足业务需求。MOSN 在核心框架中，提供了一系列的扩展机制和扩展点，就是为了满足需要基于业务进行二次开发的场景，同时 MOSN 提供的部分通用逻辑也是基于扩展机制和扩展点的实现。

比如通过 MOSN “内置实现”的透明劫持的能力，就是通过 MOSN Filter 机制实现。而要实现消息的代理，则可以通过类似的扩展实现。在通用代理的情况下，可以通过 Filter 机制实现业务的认证鉴权，也可以实现定制的负载均衡逻辑；除了转发流程可以扩展实现以外，MOSN 还可以扩展日志的实现，用于对标已有的日志系统，也可以扩展 XDS 实现定制的配置更新；根据不同的业务场景还会有很多具体的扩展情况，就不在此展开了，有兴趣的可以关注 MOSN 社区正在建设的源代码分析系列文章与文档。

MOSN 作为一款网络代理，在转发链路上的网络层、协议层、转发层，在非转发链路上的配置、日志、Admin API 等都提供了扩展能力，对于协议扩展的部分，有兴趣的可以看一下上期直播讲的 MOSN 多协议机制解析，我们今天将重点介绍一下转发层的 Stream Filter 扩展机制与 MOSN 的插件机制。

Stream Filter 机制

在实际业务场景中，在转发请求之前或者回写响应之前，都可能需要对请求/响应做一些处理，如判断是否需要进行转发的认证/鉴权，是否需要限流，又或者需要对请求/响应做一些具有业务语义的记录，需要对协议进行转换等。这些场景都与具体的业务高度耦合，是一个典型的需要进行二次开发的情况。MOSN 的 Stream Filter 机制就是为了满足这样的扩展场景所设计的，它也成为目前 MOSN 扩展中使用频率最高的扩展点。

在目前的内置 MOSN 实现中，Stream Filter 机制暂时与内置的 network filter: proxy 是绑定的，后面我们也考虑将这部分能力进行抽象，让其他 network filter 也可以复用这部分能力。

关于 Stream Filter，今天会为大家讲解两个部分的内容：

一个 Stream Filter 包含哪些部分以及在 MOSN 中是如何工作的；
通过一个 Demo 演示来加深对 Stream Filter 的实现与应用；

一个完整的 Stream Filter

一个完整的 StreamFilter，包含三个部分的内容：

一个 StreamFilter 对象，存在于每一个请求/响应当中，在 MOSN 收到请求的时候发挥作用，我们称为 ReceiverFilter，在 MOSN 收到响应时发挥作用，我们称为 SenderFilter。一个 StreamFilter 可以是其中任意一种，也可以是两种都是；
一个 StreamFilterFactory 对象，用于 MOSN 在每次收到请求时，生成 StreamFilter 对象。在 Listener 配置解析时，一个 StreamFilter 的配置会生成一个其对于的 StreamFilterFactory。同一个 StreamFilter 在不同的 Listener 下可能对应不同的 StreamFilterFactory，但是也有的特殊情况下，StreamFilterFactory 可能需要实现为单例；
一个 CreateStreamFilterFactory 方法，配置解析时生成 StreamFilterFactory 就是调用它；

Stream Filter 在 MOSN 中是如何工作的

接下来，我们看下 Stream Filter 在 MOSN 中是如何工作的。

当 MOSN 经过协议解析，收到一个完整的请求时，会创建一个 Stream。此时收到请求的 Listener 中每存在 StreamFilterFactory，就会生成一个 StreamFilter 对象，随后进入到 proxy 流程。

进入 proxy 流程以后，如果存在 ReceiverFilter，那么就会执行对应的逻辑，ReceiverFilter 包括两个阶段，“路由前”和“路由后”，在每个 Filter 处理完成以后，会返回一个状态，如果是 Stop 则会中止后续尚未执行的 ReceiverFilter，通常情况下，返回 Stop 状态的 Filter 都会回写一个响应。如果是 Continue 则会执行下一个 ReceiverFilter，直到本阶段的 ReceiverFilter 都执行完成或中止；路由前阶段的 ReceiverFIlter 执行完成后，就会执行路由后阶段，其逻辑和路由前一致。如果是正常转发，那么随后 MOSN 会收到一个响应或者发现其他异常直接回写一个响应，此时就会进入到 SenderFilter 的流程中，完成 SenderFilter 的处理。SenderFilter 处理完成以后，MOSN 会写响应给 Client，并且完成最后的收尾工作，收尾工作包括一些数据的回收、日志的记录，以及 StreamFilter 的“销毁”（调用 OnDestroy）。

Stream Filter Demo

对 StreamFilter 有了一个基本的认识以后，我们来看一个实际的 Demo 代码来看下如何实现一个 StreamFilter 并且让它在 MOSN 中发挥作用。

按照刚才我们的介绍，一个 Stream FIlter 要包含三部分：Filter、Factory、CreateFactory。

首先我们实现一个 Filter，其逻辑是模拟一个鉴权的 Filter：只有请求的 Header 中包含所配置的 Key-Value 时，MOSN 才会对请求做继续转发，否则直接返回 403 错误；
然后我们实现一个 Factory，它负责生成我们实现的 Filter，并且说明 Filter 应该发挥作用的阶段（在请求阶段、路由匹配之前）；
最后我们定义了一个生成 DemoFactory 的函数 CreateDemoFactory，并且通过 init 将其“注册”，注册完成以后，MOSN 配置解析就可以识别这个 StreamFilter；

完成实现以后，我们就可以通过具体的配置来实现对应的功能了。在示例的配置中，配置 StreamFilter 为我们刚才实现的 Filter，只转发 Header 中包含 user:admin 的请求。示例配置中监听的端口是 2046，转发的后端 server 端口是 8080。在演示之前，我已经完成了 8080 server 的启动，这个 server 会对收到的任意请求返回 200 。我们来看一下 MOSN 转发情况。Demo 操作可以在文末直播的视频回顾中查看。

Stream Filter Demo: https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions/simple_streamfilter
Demo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions

MOSN Plugin 机制

下面我们来了解一下 MOSN 的 Plugin 机制。

刚才我们对 Stream Filter 有了一个了解，MOSN 中其余的扩展实现也是类似的方法，思路就是编码实现 MOSN 扩展点所需要的接口然后利用 MOSN 的框架运行扩展的实现。

但是这里会发现一个问题，就是有时候我们需要的扩展能力已经有现成可用的实现了，那么我们是否可以做简单的改造就让 MOSN 可以获取对应的能力，哪怕目前可用的实现不是 Go 语言的实现，比如现成的限流能力的实现、注入能力的实现等；又或者对于某些特定的能力，它需要有更严格的控制，更高的标准，比如安全相关的能力。

类似这样的场景，我们引入了 MOSN 的 Plugin 机制，它支持我们可以对 MOSN 需要的能力进行独立开发或者我们对现有的程序进行适当的改造以后，就可以将它们引入到 MOSN 当中来。

MOSN 的 Plugin 机制包含了两部分内容，一是 MOSN 自定义的 Plugin 框架，它支持通过在 MOSN 中实现 agent 与一个独立的进程进行交互来完成 MOSN 扩展能力的实现。二是基于 Golang 的 Plugin 框架，通过动态库（SO）加载的方式，实现 MOSN 的扩展。其中动态库加载的方式目前还存在一些局限性，还处于 beta 阶段。

我们先来看一下多进程 Plugin 框架。

多进程 Plugin 框架

MOSN 的 Plugin 框架是 MOSN 封装的一个可以让 MOSN 通过 gRPC 和独立进程进行交互的方式，它包含两部分：

独立的进程通过 MOSN Plugin 框架管理，作为 MOSN 的子进程；MOSN 的 Plugin 框架可以管理它们，如启动、关闭等；
通过在 MOSN 中实现的 agent，使用 gRPC 的方式和子进程进行交互，gRPC 可以是基于 tcp 的，也可以是基于 domain socket 的；

基于这个框架，我们只需要开发或者进行一些改造，让程序满足 MOSN 框架的规范，就可以作为 MOSN 多进程插件的一部分。

首先我们需要提供一个 gRPC 的服务，并且满足 MOSN 框架下的 proto 定义。当 gRPC server 启动完成以后，向标准输出（stdout）输出一段约定的字符串，作为 MOSN 和子进程之间的握手协议。MOSN 中的对应 agent 会通过握手协议完成与子进程之间的连接建立。握手协议的字符串包含5个字段，每个字段之间用"|“分割，其中带$符号的是根据实际进程情况需要填写的值，其余的是当前约定的固定字段。network 支持 tcp/unix，代表通过 tcp 方式还是 unix domain socket 的方式进行通信，addr 表示 gRPC server 监听的地址。

MOSN 提供了 go 语言的子进程 server 封装，在 go 语言场景下，作为子进程的程序只需要实现一个 MOSN 框架下的 plugin.Service 接口，并且通过 plugin.Serve 方法启动即可。

通过 Plugin 框架，让 MOSN 做到在扩展功能实现的时候，支持隔离性、支持异构语言扩展能力、支持模块化，以及具备进程管理的能力。

对于 MOSN 通过多进程方式完成扩展，今天准备了两个示例和大家进行分享。一个是基于 MOSN 的 TLS 扩展，模拟了通过一个安全等级比较高的证书管理程序来获取 TLS 配置证书、私钥等敏感信息的能力；第二个是将之前演示的 Stream Filter 修改为了“子进程”，模拟“如何将现成的能力”引入 MOSN。

基于 MOSN 的 TLS 扩展示例

首先来看 TLS 的扩展，示例包含两部分内容：

独立的子进程，用 Go 语言实现，实现了 plugin.Service 接口，并通过 plugin.Serve 方法启动；
MOSN 扩展点实现交互 agent。在这里就不详细展开TLS扩展点的细节了，只关注交互过程：通过 Call 方法发送 gRPC 请求，获取响应，完成相关逻辑；

load cert demo: https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions/plugin/cert_loader Demo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions

下面我们来看一下效果，首先配置依然是监听 2046 的端口，配置了扩展的 TLS 配置，就需要 HTTPS 才可以访问 MOSN。

Stream Filter 作为 agent 示例

下面我们来看下 Stream Filter 作为 agent，与多进程之间的示例，模拟“如何将现成的能力”引入 MOSN。在示例中我们把之前的“鉴权”认为是一个“现成的”能力。

独立进程中实现和之前一样的“鉴权”能力，其配置来自进程的启动参数。Stream Filter 作为 agent 实现，其中“校验”逻辑修改为和子进程交互，在生成 Factory 时完成子进程的启动和配置设置。

这个示例运行以后和之前 Stream Filter 的效果是一样的。

Stream Filter Plugin demo: https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions/plugin/filter
Demo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions

动态库(SO)扩展机制

在目前的多进程框架中，虽然扩展能力可以通过一个独立的子程序实现，但是仍然需要在 MOSN 中实现一个 agent 用于交互，依然需要在MOSN中编写一部分代码；而我们希望引入动态库（SO）加载的机制，实现在不重新编译 MOSN 的情况下，通过加载不同的 SO，做到不同的扩展能力。

与子程序模式相比，SO 虽然也是一个独立的二进制，但是最终启动的时候，不会有额外的子进程存在，其生命周期可以和 MOSN 完全保持一致，而且动态库机制还有一个优势：它可以让扩展代码和 MOSN 完全解耦合。

但是，目前使用动态库加载的方式还存在一些限制，因此 MOSN 对于这个能力也还处于 Beta 阶段，并没有投入实际使用，需要完善。相关的原因包括：

部分 MOSN 扩展的实现需要用到 MOSN 中的一些定义，因此在动态库实现时不能完全做到解耦合。

为了解决这个问题，MOSN 将一些基础库（如日志、buffer 等），一些 API 定义从 MOSN 的核心仓库中独立出来，这样扩展实现和 MOSN 核心都引用这些“独立”的库，减少扩展对 MOSN 核心代码的依赖。

如果某一个扩展点要支持完全解耦合的动态库扩展，那么对应的扩展点都需要进行支持动态库加载的改造，包括配置模型与实现。

MOSN 动态库加载的方式，其实是基于 Go 语言的 plugin 包实现的，它可以加载用 Go 语言编译的动态库。但是对于动态库的编译环境存在一些限制，编译它时必须和 MOSN 编译时的 GOPATH 保持一致；同时引用的代码路径都需要保持一致，如果存在 vendor 目录，那么意味着编译动态库时的项目路径也得和 MOSN 核心保持一致。

为了解决这个问题，我们考虑使用 Docker 编译，在编译时统一 GOPATH，强制修改代码目录结构，屏蔽掉 Vendor 目录差异的方式来解决，这种方式目前仍然在验证中。

因此理论上 MOSN 目前所有的扩展点都可以使用 Go 语言原生机制通过加载 SO 的方式来实现，而目前 MOSN 最适合实现这个能力的一个扩展点就是 Stream Filter。

我们只需要实现一个通用的、可以加载 SO 的 Filter，然后在具体的 SO 中实现真正的 StreamFilter 逻辑，由于 StreamFilter 实现所需要的接口定义都在 mosn.io/api 中，所以 SO 可以做到和 MOSN 核心框架解耦合。

关键点就是这个通用 Filter 的设计和实现，我们也通过 Demo 来看一下。

通用 Filter 的设计和实现

这个通用的 Filter 和普通的 StreamFilter 不同，它只包含一个要素：CreateFactory。思路是通过通用的 CreateFactory，加载 SO 中的 CreateFactory 并执行，让 SO 中的 Factory 发挥作用。

通用 CreateFactory 包括：

配置解析，解析出两部分内容：一是需要加载的 SO 路径，二是 SO 中对应 Filter 所需要的配置；
SO 路径就代表了 SO 中 Filter 的“注册”，以及本次会选择这个 Filter；
加载 SO，基于其中约定好的函数名，获取真正的 CreateFactory 函数；
调用真正的 CreateFactory 函数，实现 SO 中 StreamFilter 的加载；

由此，我们可以看到，SO 中的 StreamFIlter 也和普通的 FIlter 有些区别：

生成 StreamFilterChainFactory 的函数必须是固定的名字；
不再需要 init “注册”该函数；
Stream Filter SO Demo: https://github.com/mosn/mosn/tree/master/examples/codes/mosn-extensions/plugin/so
Demo Readme：https://github.com/mosn/mosn/tree/master/examples/cn_readme/mosn-extensions

下面我们来看一下这个 Demo 的效果。本次 Demo 中的 Filter 实现依然是之前的“鉴权”示例。经过验证，我们发现这个思路是可行的，但是离生产实践还需要完善更多的细节。

代码扩展活动

经过这些演示，相信大家对 MOSN 的扩展能力也有所了解了，这里我们来做一个代码扩展活动，希望大家可以踊跃参与。完成活动任务，提交相关代码 PR 到 MOSN 的仓库，我们会进行 CodeReview 和验证，第一个验证通过的代码将合并到 MOSN 的 example 中，并且对提交的同学送上一份奖励；对于前3名提交、同样结果正确并且是原创的，虽然我们不能合并对应的代码，但是我们也将送上奖励。

活动任务共有五个：

多进程 Demo 中证书加载的独立进程，使用 python 或者 java 实现以后，demo 运行演示成功。任意一种语言就算完成一个任务。

examples/codes/mosn-extensions/plugin/cert_loader/python/
examples/codes/mosn-extensions/plugin/cert_loader/java/

多进程 Demo 中 stream filter 的独立进程，使用 python 或者 java 实现以后，demo 运行演示成功。任意一种语言就算完成一个任务。

examples/codes/mosn-extensions/plugin/filter/python/
examples/codes/mosn-extensions/plugin/filter/java/

SO 动态加载 Demo 中，SO 里实现的 Stream Filter 结合多进程框架（GO 语言）实现，Demo 运行演示成功。

examples/codes/mosn-extensions/plugin/so/subprocess/

跨语言相关的实现可以参考以下示例：

https://github.com/mosn/mosn/tree/master/examples/codes/plugin/across-languages/server/

规划与展望

最后向大家介绍一下 MOSN 后续扩展能力的规划，也希望大家有需求的可以向我们反馈，有兴趣的一起参与到 MOSN 的建设中来。首先就是要完善 SO 动态库加载机制，让 MOSN 支持 SO 方式加载扩展；然后就是针对 LUA 的脚本扩展以及支持 WASM 的扩展能力；最后 MOSN 还会增加更多的扩展点，以满足更多更复杂的场景。非常欢迎大家参与到 MOSN 社区的共建中。

MOSN：https://github.com/mosn/mosn
MOSN 官网：https://mosn.io/

以上就是本期分享的全部内容，如果大家对 MOSN 有问题以及建议，欢迎在群内与我们交流。

本期直播视频回顾以及 PPT 查看地址见：https://tech.antfin.com/community/live/1152。

Blog: MOSN 源码分析 - 连接池

Tue, 07 Apr 2020 00:00:00 +0000

本文的内容基于 MOSN v0.10.0。

在连接管理中我们主要介绍 MOSN 实现连接池的功能，连接池是上下游 MOSN 之间进行长连接复用以提高转发效率与降低时延的关键，MOSN 连接池提供基于 HTTP1, HTTP2, SOFARPC, XProtocol 协议的连接池。

而“健康检查”是一种实时检测上游服务器是否正确提供服务的机制，一般分为“主动健康检查”和“被动健康检查”。主动健康检查由健康检查模块主动发起，通过周期性的发送健康检查数据包对服务器进行健康检查；被动健康检查则是在转发业务数据报文时发现上游服务器无法正确的提供服务，而被动摘除的手段。

MOSN 当前只支持主动健康检查，支持的协议包括 SOFARPC 以及 HTTP2，它是 Cluster 的一个模块，可通过配置决定是否开启对 Cluster 中的 Host 进行健康检查，以及配置健康检查时使用的参数。

通过主动健康检查，MOSN 可以及时摘除不健康的机器，从而为连接管理提供有效的 Upstream，提高建连的成功率。同时基于健康检查模块还可以做连接的保活，从而维持长连接。

MOSN 连接管理

HTTP/1.0 默认使用短连接，即客户端和服务器每进行一次 HTTP 操作建立一次连接，任务结束中断连接。HTTP/1.1 起默认使用长连接用以保持连接特性。使用长连接的 HTTP 协议需在响应头添加 Connection:keep-alive。HTTP/1.0 虽然能够维持长连接，但是单条连接同一时间只能处理一个请求/响应，意味着如果同时收到4个请求需要建立4条 TCP 连接，连接的成本相对来说比较高昂；HTTP/2 引入 Stream/Frame 的概念，支持分帧多路复用能力，在逻辑上区分出成对的请求 Stream 和响应 Stream，从而单条连接并发处理多个请求/响应，解决 HTTP/1.0 连接数与并发数成正比的问题。

HTTP/1.1 不支持多路复用，使用经典的 Ping-Pong 模式：在请求发送之后必须独占当前连接等待服务器端给出这个请求的应答然后才能释放连接。因此 HTTP/1.1 下并发多个请求就必须采用多连接，为了提升性能通常使用长连接+连接池的设计。MOSN 长连接多路复用处理流程：

MOSN 从 downstream 接收一个请求 request，依据报文扩展多路复用接口 GetRequestId 获取到请求在这条连接上的身份标识并且记录到关联映射中待用；
请求经过 MOSN 的路由、负载均衡处理，选择一个 upstream，同时在这条连接上新建一个请求流，并调用文扩展多路复用接口 SetRequestId 封装新的身份标识，并记录到关联映射中与 downstream 信息组合；
MOSN 从 upstream 接收一个响应 response，依据报文扩展多路复用接口 GetRequestId 获取到请求在这条连接上的身份标识。此时可以从上下游关联映射表中，根据 upstream 信息找到对应的 downstream 信息；
依据 downstream request 的信息，调用文扩展多路复用接口 SetRequestId 设置响应的 requestId，并回复给 downstream。

MOSN 在 Proxy 下游 Request 时，会根据 Upstream Host 地址以及与 Upstream Host 的应用层协议获取对应的长连接，之后在长连接上封装对应协议的 Stream, 并转发数据，从而避免每次与 Upstream 新建连接带来的握手开销以提高转发性能、降低时延。在创建 Stream 的时候，连接池还提供熔断保护功能，将 Stream 创建的数量约束在一个阈值以下。当前 MOSN 支持的连接池包括：SOFARPC、HTTP1、HTTP2、XProocol 等应用层协议的连接池.

MOSN 的 Proxy 模块在 Downstream 收到 Request 的时候，在经过路由、负载均衡等模块处理获取到 Upstream Host 以及对应的转发协议时，会去 Cluster Manager 获取连接池，如果连接池不存在则创建并加入缓存，之后在长连接上创建 Stream，并发送数据。

如下图所示为连接池工作的示意图：

接口描述

连接池接口

Protocol() 用于返回当前连接池对应的协议；
NewStream() 用于在当前连接池上创建 Stream；
Close() 用于关闭长连接中的 TCP 套接字。

连接池事件监听的接口

OnFailure 用于创建 Stream 失败时的回调，用于 reset stream 相关工作；
OnReady 是连接池准备就绪，Stream 创建成功时的回调，用于 Stream 发送数据。

数据结构

ConnNewPoolFactories 为不同协议创建对应连接池的工厂类，HTTP1、SOFARPC、 HTTP2、XProtocol 等协议分别调用注册函数 RegisterNewPoolFactory ，注册自己的创建方法。
类 clusterManager 中的 protocolConnPool 为全局连接池的实现，其类型为二级 sync.Map，其中第一级 Map 的 key 为协议类型，第二级 Map 的 key 为 Host 地址，value 为 ConnectionPool。
类 upstreamRequest 中维护 connPool 是 connPool 的使用者，用来创建连接。

连接池使用

初始化连接池

clusterManager 在查询本地连接池时，如果对应协议和 Host 的连接池不存在，则调用对应协议的工厂方法创建连接池，如果存在的话，则直接返回连接池。

获取连接池

downstream 在收到下游的 request 并往上游转发时，会根据协议和挑选的 upstream 地址选择连接池并赋值给 upstream 的 connPool。

使用连接池

upstreamRequest 在往上游转发数据时，会调用 connPool 对应的 Newstream 方法封装 stream 并发送。

MOSN 健康检查

MOSN 的健康检查是一种主动健康检查机制，他是 Cluster 内在的一个模块。当前支持的健康检查功能包括：

健康检查支持可配置，配置包括健康检查使用的协议、健康检查报文发送间隔、超时时间、更新阈值等；
提供健康检查接口，允许不同健康检查协议的扩展；
提供基于健康检查结果的 callback 机制，允许自定义对健康检查结果的处理方式；
基于周期性的健康检查，可实现心跳机制，用于长连接的保活。

如下为当前健康检查工作的示意图：

Cluster 的 HealthChecker 模块在开启的情况下，会根据配置的协议创建基于 SOFARPC， HTTP2 或者其他协议的健康检查；健康检查模块会与 Cluster 中的所有 Host - 创建 HealthCheckSession，在 Session 上周期性发送健康检查报文，并开启定时器，如果 Response 在规定时间内未达/到达则判断健康检查失败/成功，健康检查失败/成功次数到一定阈值后 Callback 模块会更新机器的健康状态。

健康检查配置

对 Cluster 的健康检查支持的配置包括：

发起健康检查的应用层协议，如果子协议存在，还支持配子协议
健康检查报文的超时时间
发起健康检查报文的间隔
更新 Host 状态的阈值
健康检查的路径和对应的 Service 信息

接口描述

HealthChecker 接口用来控制对整个 Cluster 进行健康检查，其中：

Start/Stop 开启/关闭对 Cluster 的健康检查，会开启 Host 的健康检查 Session;
AddHostCheckCompleteCb 用来设置对健康检查结果的回调，关于 cb 的定义在下面会介绍;
OnClusterMemberUpdate 是在外部 Cluster 的 Hosts 发生变化时，例如主机上下线等，来更新健康检查的范围。

HealthCheckCb 是基于健康检查结果对 Host 状态进行更新的回调函数，发生在健康检查的结果对 Host 的状态产生影响之后，如果健康检查失败，则会将 Host 置为 Unhealty，否则置为 Healthy。

HealthCheckSession 是健康检查模块与每个 Host 建立的用于健康检查的 session，在这个 session 上可以发送健康检查数据包并处理 response。

Start/Stop 开启/停止对 Host 的健康检查；
SetUnhealthy 为健康检查失败达到一定阈值之后将 Host 的状态设置为 Unhealthy。

数据结构

Cluster 中的 healthChecker 在 Cluster 创建的时候基于配置进行初始化，如果配置支持健康检查，则开启。
healthChecker 是实现 Cluster 健康检查的类，其中包含对所有的 Host 的进行健康检查的 healthCheckSessions。在实现基于不同的协议的健康检查时，会继承这个类，并重写一些方法。
healthCheckSesion 是对 Host 健康检查的 session，其中包含两个定时器，以及对应的健康状态更新阈值。在实现基于不同的协议的健康检查时，会继承这个类，并重写一些方法。

工作流程

下图是健康检查的工作时序图，包括从Cluster 创建健康检查器开始，到对每个 Host 创建健康检查的 Session，到对 Host 发送健康检查数据包，到处理 Host 的响应，到更新 Host 的状态。

总结

本文根据 MOSN 的源码分析 MOSN 对连接池的设计与实现，其基于 upstreamRequest 往上游转发数据调用 connPool 对应的 Newstream 方法发送 Stream。

Blog: MOSN 多协议机制解析

Thu, 26 Mar 2020 00:00:00 +0000

本文根据 SOFAChannel#13 直播分享整理，主题：云原生网络代理 MOSN 多协议机制解析，查看视频回顾。

作者：无钩，目前主要从事蚂蚁集团网络代理相关的研发工作，也是 MOSN 的 Committer。

今天我要和大家分享的是《云原生网络代理 MOSN 多协议机制解析》，并介绍对应的私有协议快速接入实践案例以及对 MOSN 实现多协议低成本接入的设计进行解读。

我们将按以下顺序进行介绍：

多协议机制产生的背景与实践痛点；
常见的协议扩展思路初探；
SOFABolt 协议接入实践；（重点）
MOSN 多协议机制设计解读；（重点）
后续规划及展望；

其中第三点「接入实践」是今天分享的重点，希望能给大家就「如何在 MOSN 中快速扩展私有协议接入」有一个具体的感受。另外「MOSN 如何实现多协议框架」也是很多人关心和问题，我们将摘选几个技术功能，对其背后的设计思考进行解读。

MOSN 简介

云原生网络代理 MOSN 定位是一个全栈的网络代理，支持包括网络接入层(Ingress)、API Gateway、Service Mesh 等场景，目前在蚂蚁集团内部的核心业务集群已经实现全面落地，并经受了 2019 年双十一大促的考验。今天要向大家介绍的是云原生网络代理 MOSN 核心特性之一的多协议扩展机制，目前已经支持了包括 SOFABolt、Dubbo、TARS 等多个协议的快速接入。

MOSN：https://github.com/mosn/mosn

多协议机制产生的背景与实践痛点

首先介绍一下多协议机制产生的背景。

前面提到，蚂蚁集团 2019 年双十一核心链路百分之百 Mesh 化，是业界当时已知的最大规模的 Service Mesh 落地，为什么我们敢这么做？因为我们具备能够让架构平滑迁移的方案。“兼容性"是任何架构演进升级都必然要面对的一个问题，这在早已实践微服务化架构的蚂蚁集团内部同样如此。为了实现架构的平滑迁移，需要让新老节点的外在行为尽可能的表现一致，从而让依赖方无感知，这其中很重要的一点就是保持协议兼容性。

因此，我们需要在 Service Mesh 架构下，兼容现有微服务体系中的通信协议——也就是说需要在 MOSN 内实现对目前蚂蚁集团内部通信协议的扩展支持。

基于 MOSN 本身的扩展机制，我们完成了最初版本的协议扩展接入。但是在实践过程中，我们发现这并不是一件容易的事情：

相比编解码，协议自身的处理以及与框架集成才是其中最困难的环节，需要理解并实现包括请求生命周期、多路复用处理、链接池等等机制；
社区主流的 xDS 路由配置是面向 HTTP 协议的，无法直接支持私有协议，存在适配成本；

基于这些实践痛点，我们设计了 MOSN 多协议框架，希望可以降低私有协议的接入成本，加快普及 ServiceMesh 架构的落地推进。

常见的协议扩展思路初探

前面介绍了背景，那么具体协议扩展框架要怎么设计呢？我们先来看一下业界的思路与做法。

协议扩展框架 - Envoy

注：图片来自 Envoy 分享资料

第一个要介绍的是目前发展势头强劲的 Envoy。从图上可以看出，Envoy 支持四层的读写过滤器扩展、基于 HTTP 的七层读写过滤器扩展以及对应的 Router/Upstream 实现。如果想要基于 Envoy 的扩展框架实现 L7 协议接入，目前的普遍做法是基于 L4 filter 封装相应的 L7 codec，在此基础之上再实现对应的协议路由等能力，无法复用 HTTP L7 的扩展框架。

协议扩展框架 - Nginx

第二个则是老牌的反向代理软件 Nginx，其核心模块是基于 Epoll/Kqueue 等 I/O 多路复用技术之上的离散事件框架，基于事件框架之上构建了 Mail、Http 等协议模块。与 Envoy 类似，如果要基于 Nginx 扩展私有协议，那么也需要自行对接事件框架，并完整实现包括编解码、协议处理等能力。

协议扩展框架 - MOSN

最后回过头来，我们看一下 MOSN 是怎么做的。实际上，MOSN 的底层机制与 Envoy、Nginx 并没有核心差异，同样支持基于 I/O 多路复用的 L4 读写过滤器扩展，并在此基础之上再封装 L7 的处理。但是与前两者不同的是，MOSN 针对典型的微服务通信场景，抽象出了一套适用于基于多路复用 RPC 协议的扩展框架，屏蔽了 MOSN 内部复杂的协议处理及框架流程，开发者只需要关注协议本身，并实现对应的框架接口能力即可实现快速接入扩展。

三种框架成本对比

最后对比一下，典型微服务通信框架协议接入的成本，由于 MOSN 针对此类场景进行了框架层面的封装支持，因此可以节省开发者大量的研发成本。

SOFABolt 协议接入实践

初步了解多协议框架的设计思路之后，让我们以 SOFABolt 协议为例来实际体验一下协议接入的过程。

SOFABolt 简介

这里先对 SOFABolt 进行一个简单介绍，SOFABolt 是一个开源的轻量、易用、高性能、易扩展的 RPC 通信框架，广泛应用于蚂蚁集团内部。

SOFABolt：https://github.com/sofastack/sofa-bolt

基于 MOSN 的多协议框架，实际编写了 7 个代码文件，一共 925 行代码(包括 liscence、comment 在内)就完成了接入。如果对于协议本身较为熟悉，且具备一定的 MOSN/Golang 开发经验，甚至可以在一天内就完成整个协议的扩展，可以说接入成本是非常之低。

Github: https://github.com/mosn/mosn/tree/master/pkg/protocol/xprotocol/bolt

下面让我们进入正题，一步一步了解接入过程。

Step1：确认协议格式

第一步，需要确认要接入的协议格式。为什么首先要做这个，因为协议格式是一个协议最基本的部分，有以下两个层面的考虑：

任何协议特性以及协议功能都能在上面得到一些体现，例如有无 requestId/streamId 就直接关联到协议是否支持连接多路复用；
协议格式与报文模型直接相关，两者可以构成逻辑上的映射关系；而这个映射关系也就是所谓的编解码逻辑；

以 SOFABolt 为例，其第一个字节是协议 magic，可以用于校验当前报文是否属于 SOFABolt 协议，并可以用于协议自动识别匹配的场景；第二个字节是 type，用于标识当前报文的传输类型，可以是 Request / RequestOneway / Response 中的一种；第三个字节则是当前报文的业务类型，可以是心跳帧，RPC 请求/响应等类型。后面的字段就不一一介绍了，可以发现，**理解了协议格式本身，其实对于协议的特性支持和模型编解码就理解了一大半，**因此第一步协议格式的确认了解是重中之重，是后续一切工作开展的前提。

Step2：确认报文模型

顺应第一步，第二步的主要工作是确认报文编程模型。一般地，在第一步完成之后，应当可以很顺利的构建出相应的报文模型，SOFABolt 例子中可以看出，模型字段设计基本与协议格式中的 header / payload 两部分相对应。有了编程模型之后，就可以继续进行下一步——基于模型实现对应的框架扩展了。

Step3：接口实现 - 协议

协议扩展，顾名思义，是指协议层面的扩展，描述的是协议自身的行为（区别于报文自身）。

目前多协议框架提供的接口包括以下五个：

Name：协议名称，需要具备唯一性；
Encoder：编码器，用于实现从报文模型到协议传输字节流的映射转换；
Decoder：解码器，用于实现从协议传输字节流到报文模型的映射转换；
Heartbeater：心跳处理，用于实现心跳保活报文的构造，包括探测发起与回复两个场景；
Hijacker：错误劫持，用于在特定错误场景下错误报文的构造；

Step4：接口实现 - 报文

前面介绍了协议扩展，接下里则是报文扩展，这里关注的是单个请求报文需要实现的行为。

目前框架抽象的接口包括以下几个：

Basic：需要提供 GetStreamType、GetHeader、GetBody 几个基础方法，分别对应传输类型、头部信息、载荷信息；
Multiplexing：多路复用能力，需要实现 GetRequestId 及 SetRequestId；
HeartbeatPredicate：用于判断当前报文是否为心跳帧；
GoAwayPredicate：用于判断当前报文是否为优雅退出帧；
ServiceAware：用于从报文中获取 service、method 等服务信息；

举个例子

这里举一个例子，来让大家对框架如何基于接口封装处理流程有一个体感：服务端心跳处理场景。当框架收到一个报文之后：

根据报文扩展中的 GetStreamType 来确定当前报文是请求还是响应。如果是请求则继续 2；
根据报文扩展中的 HeartbeatPredicate 来判断当前报文是否为心跳包，如果是则继续 3；
当前报文是心跳探测(request + heartbeat)，需要回复心跳响应，此时根据协议扩展中的 Heartbeater.Reply 方法构造对应的心跳响应报文；
再根据协议扩展的 Encoder 实现，将心跳响应报文转换为传输字节流；
最后调用 MOSN 网络层接口，将传输字节流回复给发起心跳探测的客户端；

当协议扩展与报文扩展都实现之后，MOSN 协议扩展接入也就完成了，框架可以依据协议扩展的实现来完成协议的处理，让我们实际演示一下 SOFABolt 接入的 example。

Demo 地址：https://github.com/mosn/mosn/tree/master/examples/codes/sofarpc-with-xprotocol-sample

MOSN 多协议机制设计解读

通过 SOFABolt 协议接入的实践过程，大家对如何基于 MOSN 来做协议扩展应该有了一个初步的认知。那么 MOSN 多协议机制究竟封装了哪些逻辑，背后又是如何思考设计的？接下来将会挑选几个典型技术案例为大家进行解读。

协议扩展框架

协议扩展框架 - 编解码

最先介绍的是编解码机制，这个在前面 SOFABolt 接入实践中已经简单介绍过，MOSN 定义了编码器及解码器接口来屏蔽不同协议的编解码细节。协议接入时只需要实现编解码接口，而不用关心相应的接口调用上下文。

协议扩展框架 - 多路复用

接下来是多路复用机制的解读，这也是流程中相对不太好理解的一部分。首先明确一下链接多路复用的定义：允许在单条链接上，并发处理多个请求/响应。那么支持多路复用有什么好处呢？

以 HTTP 协议演进为例，HTTP/1 虽然可以维持长连接，但是单条链接同一时间只能处理一个请求/相应，这意味着如果同时收到了 4 个请求，那么需要建立四条 TCP 链接，而建链的成本相对来说比较高昂；HTTP/2 引入了 stream/frame 的概念，支持了分帧多路复用能力，在逻辑上可以区分出成对的请求 stream 和响应 stream，从而可以在单条链接上并发处理多个请求/响应，解决了 HTTP/1 链接数与并发数成正比的问题。

类似的，典型的微服务框架通信协议，如 Dubbo、SOFABolt 等一般也都实现了链接多路复用能力，因此 MOSN 封装了相应的多路复用处理流程，来简化协议接入的成本。让我们跟随一个请求代理的过程，来进一步了解。

MOSN 从 downstream(conn=2) 接收了一个请求 request，依据报文扩展多路复用接口 GetRequestId 获取到请求在这条连接上的身份标识(requestId=1)，并记录到关联映射中待用；
请求经过 MOSN 的路由、负载均衡处理，选择了一个 upstream(conn=5)，同时在这条链接上新建了一个请求流(requestId=30)，并调用文扩展多路复用接口 SetRequestId 封装新的身份标识，并记录到关联映射中与 downstream 信息组合；
MOSN 从 upstream(conn=5) 接收了一个响应 response，依据报文扩展多路复用接口 GetRequestId 获取到请求在这条连接上的身份标识(requestId=30)。此时可以从上下游关联映射表中，根据 upstream 信息(connId=5, requestId=30) 找到对应的 downstream 信息(connId=2, requestId=1)；
依据 downstream request 的信息，调用文扩展多路复用接口 SetRequestId 设置响应的 requestId，并回复给 downstream；

在整个过程中，框架流程依赖的报文扩展 Multiplexing 接口提供的能力，实现了上下游请求的多路复用关联处理，除此之外，框架还封装了很多细节的处理，例如上下游复用内存块合并处理等等，此处限于篇幅不再展开，有兴趣的同学可以参考源码进行阅读。

统一路由框架

接下来要分析的是「统一路由框架」的设计，此方案主要解决的是非 HTTP 协议的路由适配问题。我们选取了以下三点进行具体分析：

通过基于属性匹配(attribute-based)的模式，与具体协议字段解耦；
引入层级路由的概念，解决属性扁平化后带来的线性匹配性能问题；
通过变量机制懒加载的特定，按需实现深/浅解包；

统一路由框架 – 基于属性匹配

首先来看一下典型的 RDS 配置，可以看到其中的 domains、path 等字段，对应的是 HTTP 协议里的域名、路径概念，这就意味着其匹配条件只有 HTTP 协议才有字段能够满足，配置结构设计是与 HTTP 协议强相关的。这就导致了如果我们新增了一个私有协议，无法复用 RDS 的配置来做路由。

那么如何解决配置模型与协议字段强耦合呢？简单来说就是把匹配字段拆分为扁平属性的键值对(key-value pair)，匹配策略基于键值对来处理，从而解除了匹配模型与协议字段的强耦合，例如可以配置 key: $http_host，也可以配置 key:$dubbo_service，这在配置模型层面都是合法的。

但是这并不是说匹配就有具体协议无关了，这个关联仍然是存在的，只是从强耦合转换为了隐式关联，例如配置 key: $http_host，从结构来说其与 HTTP 协议并无耦合，但是值变量仍然会通过 HTTP 协议字段来进行求值。

统一路由框架 - 层级路由

在引入「基于属性的匹配」之后，我们发现了一个问题，那就是由于属性本身的扁平化，其内在并不包含层级关系。如果没有层级关系，会导致匹配时需要遍历所有可能的情况组合，大量条件的场景下匹配性能近似于线性的 O(n)，这显然是无法接受的。

举例来说，对于 HTTP 协议，我们总是习惯与以下的匹配步骤：

匹配 Host(:authority) ；
匹配 Path ；
匹配 headers/args/cookies ；

这其实构成了一个层级关系，每一层就像是一个索引，通过层级的索引关系，在大量匹配条件的情况下仍然可以获得一个可接受的耗时成本。但是对于属性(attribute)，多个属性之间并没有天然的层级关系(相比于 host、path 这种字段)，这依赖于属性背后所隐式关联的字段，例如对于 Dubbo 协议，我们希望的顺序可能是：

匹配 $dubbo_service；
匹配 $dubbo_group；
匹配 $dubbo_version；
匹配 $dubbo_attachments_xx；

因此在配置模型上，我们引入了对应的索引层级概念，用于适配不同协议的结构化层级路由，解决扁平属性的线性匹配性能问题。

统一路由框架 - 浅解包优化

最后，介绍一下浅解包优化的机制。利用 MOSN 变量懒加载的特性，我们可以在报文解析时，先不去解析成本较高的部分，例如 dubbo 协议的 attachments。那么在代理请求的实际过程中，需要使用到 attachments 里的信息时，就会通过变量的 getter 求值逻辑来进行真正的解包操作。依靠此特性，可以大幅优化在不需要深解包的场景下 dubbo 协议代理转发的性能表现，实现按需解包。

解读总结

最后，对设计部分的几个技术案例简单总结一下，整体的思路仍然是对处理流程进行抽象封装，并剥离可扩展点，从而降低用户的接入成本。

在协议扩展支持方面：

封装编解码流程，抽象编解码能力接口作为协议扩展点
封装协议处理流程，抽象多路复用、心跳保活、优雅退出等能力接口作为协议扩展点

在路由框架方面：

通过改为基于属性匹配的机制，与具体协议字段解耦，支持多协议适配；
引入层级路由机制，解决属性扁平化的匹配性能问题；
利用变量机制懒加载特性，按需实现深/浅解包；

后续规划及展望

社区标准方案推进

与此同时，我们注意到 Istio 社区其实也有类似的需求，希望设计一套协议无关的路由机制——“Istio Meta Routing API”。其核心思路与 MOSN 的多协议路由框架基本一致，即通过基于属性的路由来替代基于协议字段的路由。目前该草案还处于一个比较初级的阶段，对于匹配性能、字段扩展方面还没有比较完善的设计说明，后续 MOSN 团队会积极参与社区方案的讨论，进一步推动社区标准方案的落地。

以上就是本期分享的全部内容，如果大家对 MOSN 有问题以及建议，欢迎加入 MOSN 社区与我们交流。

Blog: MOSN 源码解析 - HTTP 系能力

Sat, 07 Mar 2020 00:00:00 +0000

本文的目的是分析 MOSN 源码中的 HTTP 系能力，内容基于 MOSN 0.9.0

概述

HTTP 是互联网界最常用的一种协议之一，MOSN 也提供了对其强大的支持。

MOSN HTTP 报文组成

上图是图解 HTTP 中关于 HTTP 报文报文的介绍。MOSN 对于 HTTP 报文的处理并没有使用go 官网 net/http中的结构也没有独立设计一套相关结构而是复用了业界开源的fasthttp 的结构。

type stream struct {
	str.BaseStream

	id               uint64
	readDisableCount int32
	ctx              context.Context
    // 请求报文
	request  *fasthttp.Request
    // 响应报文
	response *fasthttp.Response

	receiver types.StreamReceiveListener
}

MOSN HTTP 处理流程

上图是HTTP请求在MOSN中的流动过程，下面将具体讲解。

流程注册

func init() {
	str.Register(protocol.HTTP1, &streamConnFactory{})
}

在 pkg/stream/http 包加载过程中将包含 HTTP 对于MOSN上下游连接的处理逻辑的结构体值注册到统一的stream处理工厂。

捕获请求

由上图可知，MOSN捕捉到一个请求之后会开启一个goroutine读取连接中的数据，也就是 serverStreamConnection.serve 函数。

func (conn *serverStreamConnection) serve() {
	for {
		// 1. pre alloc stream-level ctx with bufferCtx
		ctx := conn.contextManager.Get()
		// 通过sync.Pool 实现实现内存复用
		buffers := httpBuffersByContext(ctx)
		request := &buffers.serverRequest

		// 2. blocking read using fasthttp.Request.Read
		err := request.ReadLimitBody(conn.br, defaultMaxRequestBodySize)
		if err == nil {
			// 3. 'Expect: 100-continue' request handling.
			// See http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html for details.
			if request.MayContinue() {
				// Send 'HTTP/1.1 100 Continue' response.
				conn.conn.Write(buffer.NewIoBufferBytes(strResponseContinue))

				// read request body
				err = request.ContinueReadBody(conn.br, defaultMaxRequestBodySize)

				// remove 'Expect' header, so it would not be sent to the upstream
				request.Header.Del("Expect")
			}
		}
		// 读取错误的处理
		if err != nil {
			// "read timeout with nothing read" is the error of returned by fasthttp v1.2.0
			// if connection closed with nothing read.
			if err != errConnClose && err != io.EOF && err.Error() != "read timeout with nothing read" {
				// write error response
				conn.conn.Write(buffer.NewIoBufferBytes(strErrorResponse))

				// close connection with flush
				conn.conn.Close(api.FlushWrite, api.LocalClose)
			}
			return
		}

		// 数据读取结束
		id := protocol.GenerateID()
		s := &buffers.serverStream

		// 4. request processing
		s.stream = stream{
			id:       id,
			ctx:      mosnctx.WithValue(ctx, types.ContextKeyStreamID, id),
			request:  request,
			response: &buffers.serverResponse,
		}
		s.connection = conn
		s.responseDoneChan = make(chan bool, 1)
		s.header = mosnhttp.RequestHeader{&s.request.Header, nil}

		var span types.Span
		if trace.IsEnabled() {
			tracer := trace.Tracer(protocol.HTTP1)
			if tracer != nil {
				span = tracer.Start(ctx, s.header, time.Now())
			}
		}
		// 上下文 中注入链式追踪信息
		s.stream.ctx = s.connection.contextManager.InjectTrace(ctx, span)

		if log.Proxy.GetLogLevel() >= log.DEBUG {
			log.Proxy.Debugf(s.stream.ctx, "[stream] [http] new stream detect, requestId = %v", s.stream.id)
		}

		s.receiver = conn.serverStreamConnListener.NewStreamDetect(s.stream.ctx, s, span)

		conn.mutex.Lock()
		conn.stream = s
		conn.mutex.Unlock()

		if atomic.LoadInt32(&s.readDisableCount) <= 0 {
			s.handleRequest()
		}

		// 5. wait for proxy done
		select {
		case <-s.responseDoneChan:
		case <-conn.connClosed:
			return
		}

		conn.contextManager.Next()
	}
}

由以上代码可以得知，因为不能判断连接是长连接还是短连接，所以MOSN调用方不主动关闭连接，MOSN也不会主动关闭，除非出现错误。

转发请求

由上图可知，MOSN在捕获请求之后，开启一个goroutine 创建对upstream的连接，并且通过这个连接和upstream进行数据交互，与此同时开启另外一个goroutine对这个连接进行监控用来处理连接返回数据。其主要处理逻辑在downStream.receive中。

for i := 0; i <= int(types.End-types.InitPhase); i++ {
		fmt.Println("yu",i,s.downstreamReqTrailers == nil,phase,int(types.End-types.InitPhase),types.WaitNofity)
		switch phase {
		// init phase
		case types.InitPhase:
			phase++

			// downstream filter before route
		case types.DownFilter:
			if log.Proxy.GetLogLevel() >= log.DEBUG {
				log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
			}
			s.runReceiveFilters(phase, s.downstreamReqHeaders, s.downstreamReqDataBuf, s.downstreamReqTrailers)

			if p, err := s.processError(id); err != nil {
				return p
			}
			phase++

			// match route
		case types.MatchRoute:
			if log.Proxy.GetLogLevel() >= log.DEBUG {
				log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
			}
			s.matchRoute()
			if p, err := s.processError(id); err != nil {
				return p
			}
			phase++

			// downstream filter after route
		case types.DownFilterAfterRoute:
			if log.Proxy.GetLogLevel() >= log.DEBUG {
				log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
			}
			s.runReceiveFilters(phase, s.downstreamReqHeaders, s.downstreamReqDataBuf, s.downstreamReqTrailers)

			if p, err := s.processError(id); err != nil {
				return p
			}
			phase++

			// downstream receive header
		case types.DownRecvHeader:
			if s.downstreamReqHeaders != nil {
				if log.Proxy.GetLogLevel() >= log.DEBUG {
					log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
				}
				s.receiveHeaders(s.downstreamReqDataBuf == nil && s.downstreamReqTrailers == nil)

				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++

			// downstream receive data
		case types.DownRecvData:
			if s.downstreamReqDataBuf != nil {
				if log.Proxy.GetLogLevel() >= log.DEBUG {
					log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
				}
				s.downstreamReqDataBuf.Count(1)

				s.receiveData(s.downstreamReqTrailers == nil)

				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++

			// downstream receive trailer
		case types.DownRecvTrailer:
			if s.downstreamReqTrailers != nil {
				if log.Proxy.GetLogLevel() >= log.DEBUG {
					log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
				}
				s.receiveTrailers()

				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++

			// downstream oneway
		case types.Oneway:
			if s.oneway {
				if log.Proxy.GetLogLevel() >= log.DEBUG {
					log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
				}
				s.cleanStream()

				// downstreamCleaned has set, return types.End
				if p, err := s.processError(id); err != nil {
					return p
				}
			}

			// no oneway, skip types.Retry
			phase = types.WaitNofity

			// retry request
		case types.Retry:
			if log.Proxy.GetLogLevel() >= log.DEBUG {
				log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
			}

			if s.downstreamReqDataBuf != nil {
				s.downstreamReqDataBuf.Count(1)
			}
			s.doRetry()
			if p, err := s.processError(id); err != nil {
				return p
			}
			phase++

			// wait for upstreamRequest or reset
		case types.WaitNofity:
			if log.Proxy.GetLogLevel() >= log.DEBUG {
				log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
			}
			if p, err := s.waitNotify(id); err != nil {
				return p
			}

			if log.Proxy.GetLogLevel() >= log.DEBUG {
				log.Proxy.Debugf(s.context, "[proxy] [downstream] OnReceive send downstream response %+v", s.downstreamRespHeaders)
			}

			phase++

			// upstream filter
		case types.UpFilter:
			if log.Proxy.GetLogLevel() >= log.DEBUG {
				log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
			}
			s.runAppendFilters(phase, s.downstreamRespHeaders, s.downstreamRespDataBuf, s.downstreamRespTrailers)

			if p, err := s.processError(id); err != nil {
				return p
			}

			// maybe direct response
			if s.upstreamRequest == nil {
				fakeUpstreamRequest := &upstreamRequest{
					downStream: s,
				}

				s.upstreamRequest = fakeUpstreamRequest
			}

			phase++

			// upstream receive header
		case types.UpRecvHeader:
			// send downstream response
			if s.downstreamRespHeaders != nil {
				if log.Proxy.GetLogLevel() >= log.DEBUG {
					log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
				}
				s.upstreamRequest.receiveHeaders(s.downstreamRespDataBuf == nil && s.downstreamRespTrailers == nil)

				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++

			// upstream receive data
		case types.UpRecvData:
			if s.downstreamRespDataBuf != nil {
				if log.Proxy.GetLogLevel() >= log.DEBUG {
					log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
				}
				s.upstreamRequest.receiveData(s.downstreamRespTrailers == nil)

				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++

			// upstream receive triler
		case types.UpRecvTrailer:
			if s.downstreamRespTrailers != nil {
				if log.Proxy.GetLogLevel() >= log.DEBUG {
					log.Proxy.Debugf(s.context, "[proxy] [downstream] enter phase %d, proxyId = %d  ", phase, id)
				}
				s.upstreamRequest.receiveTrailers()

				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++

			// process end
		case types.End:
			return types.End

		default:
			log.Proxy.Errorf(s.context, "[proxy] [downstream] unexpected phase: %d", phase)
			return types.End
		}
	}

	log.Proxy.Errorf(s.context, "[proxy] [downstream] unexpected phase cycle time")
	return types.End
}

这个函数是处理转发逻辑的核心函数规定在处理的各个阶段需要做的事情。比如在case types.UpRecvHeader的时候进行连接创建以及对下游数据的初步读取。

其他

连接复用

在MOSN处理 HTTP 请求的过程中我们可以很明显的看到，针对可能频繁使用的连接，MOSN实现了一套复用机制。

type connPool struct {
	MaxConn int

	host types.Host

	statReport bool

	clientMux        sync.Mutex
	availableClients []*activeClient // available clients
	totalClientCount uint64          // total clients
}
func (p *connPool) getAvailableClient(ctx context.Context) (*activeClient, types.PoolFailureReason) {
	p.clientMux.Lock()
	defer p.clientMux.Unlock()

	n := len(p.availableClients)
	// no available client
	if n == 0 {
		// max conns is 0 means no limit
		maxConns := p.host.ClusterInfo().ResourceManager().Connections().Max()
		if maxConns == 0 || p.totalClientCount < maxConns {
			ac, reason := newActiveClient(ctx, p)
			if ac != nil && reason == "" {
				p.totalClientCount++
			}
			return ac, reason
		} else {
			p.host.HostStats().UpstreamRequestPendingOverflow.Inc(1)
			p.host.ClusterInfo().Stats().UpstreamRequestPendingOverflow.Inc(1)
			return nil, types.Overflow
		}
	} else {
		n--
		c := p.availableClients[n]
		p.availableClients[n] = nil
		p.availableClients = p.availableClients[:n]
		return c, ""
	}
}

由上述代码可知，MOSN 维护了一个有效长连接的栈，当栈中还有有效连接则从栈顶取出有效的长连接，如果不存在则新建一个tcp长连接。MOSN通过这种方式维护了连接池来实现高效的连接复用。

内存复用

HTTP 的处理过程中会频繁的申请空间来解析 HTTP 报文，为了减少频繁的内存申请，常规的做法是内存复用，MOSN也不例外，其基于sync.pool 设计了内存复用模块。

func httpBuffersByContext(context context.Context) *httpBuffers {
	ctx := buffer.PoolContext(context)
	return ctx.Find(&ins, nil).(*httpBuffers)
}

总结

本文简单的分析了MOSN中对于HTTP请求的处理过程，其中优化方式主要如下：

tcp 黏包：使用fasthttp 的request和response来解析报文。
实现连接复用：连接池。
实现内存复用：sync.pool。

Blog: MOSN 源码解析 - log 系统

Tue, 03 Mar 2020 00:00:00 +0000

本文的目的是分析 MOSN 源码中的Log系统。

本文的内容基于 MOSN v0.10.0。

概述

MOSN 日志系统分为日志和Metric两大部分，其中日志主要包括errorlog和accesslog，Metrics主要包括console数据和prometheus数据

日志

errorlog

errorlog 主要是用来记录MOSN运行时候的日志信息，配置结构:

type ServerConfig struct {
......
	DefaultLogPath  string `json:"default_log_path,omitempty"`
	DefaultLogLevel string `json:"default_log_level,omitempty"`
	GlobalLogRoller string `json:"global_log_roller,omitempty"`
......
}

初始化 errorlog 包括两个对象StartLogger和DefaultLogger

StartLogger 主要用来记录 mosn 启动的日志信息，日志级别是 INFO
DefaultLogger 主要是用来记录MOSN启动之后的运行日志信息，默认和 StartLogger 一样，可以通过配置文件覆盖

代码如下：

func init() {
	......
	// use console as start logger
	StartLogger, _ = GetOrCreateDefaultErrorLogger("", log.INFO) // 默认INFO
	// default as start before Init
	log.DefaultLogger = StartLogger
	DefaultLogger = log.DefaultLogger
	// default proxy logger for test, override after config parsed
	log.DefaultContextLogger, _ = CreateDefaultContextLogger("", log.INFO)
	......
}

......

func InitDefaultLogger(output string, level log.Level) (err error) {
	// 使用配置文件来覆盖默认配置
	DefaultLogger, err = GetOrCreateDefaultErrorLogger(output, level)
	......
}

accesslog

accesslog 主要用来记录上下游请求的数据信息，配置结构:

type AccessLog struct {
	Path   string `json:"log_path,omitempty"`
	Format string `json:"log_format,omitempty"`
}

每个配置文件下面 servers->listener->access_logs，具体配置示例如下：

{
	"servers": [
		{
			"mosn_server_name": "mosn_server_1",
			......
			"listeners": [
				{
					"name": "ingress_sofa",
					......
					"log_path": "./logs/ingress.log",
					"log_level": "DEBUG",
					"access_logs": [
						{
							"log_path": "./logs/access_ingress.log",
							"log_format": "%start_time% %request_received_duration% %response_received_duration% %bytes_sent% %bytes_received% %protocol% %response_code% %duration% %response_flag% %response_code% %upstream_local_address% %downstream_local_address% %downstream_remote_address% %upstream_host%"
						}
					]
				}
			]
		}
	]
}

accesslog 实现如下接口:

AccessLog interface {
    // Log write the access info.
    Log(ctx context.Context, reqHeaders HeaderMap, respHeaders HeaderMap, requestInfo RequestInfo)
}

调用 Log 记录日志的时候，通过使用变量机制来填充log_format里面的变量，相关信息保存在 ctx 里面。用于保存变量信息的 entries 通过 NewAccessLog 初始化的时候，调用 parseFormat 方法来初始化的，参考相关代码。

log 的具体实现

log 的具体实现已经分离到了 mosn/pkg/log 下面，errorlog 和 accesslog 的具体实现都是通过 log.GetOrCreateLogger 来初始化的。当 roller 为空的时候使用默认的 defaultRoller，默认每天轮转。

defaultRoller = Roller{MaxTime: defaultRotateTime}
......
defaultRotateTime = 24 * 60 * 60

start

根据不同的输出方式，初始化不同的 io.Writer 对象，详情

type	io.Writer
“”, “stderr”, “/dev/stderr”	os.Stderr
“stdout”, “/dev/stdout”	os.Stdout
“syslog”	gsyslog本地对象
其他	gsyslog远程对象

创建好 log 对象之后，通过 loggers 保存起来，避免创建多个对象，loggers 是一个 sync.Map对象，是 golang1.9 之后加入的一个新的线程安全的 map。

start 启动之后会创建一个一直循环读取的协程 handler

handler

reopenChan

通过重命名文件之后，重新调用 start 方法创建新文件，主要使用在文件轮转的时候。os.Stdout os.Stderr 不支持操作，会报错。

closeChan

把当前 writeBufferChan 需要写入的数据写入到对象中，然后退出当前协程。

writeBufferChan

for i := 0; i < 20; i++ {
	select {
	case b := <-l.writeBufferChan:
		buf.Write(b.Bytes())
		buffer.PutIoBuffer(b)
	default:
		break
	}
}
buf.WriteTo(l)
buffer.PutIoBuffer(buf)

当收到第一次写数据的时候不是立刻写入数据到 log 对象，而是在等待 20 次读取信息，一起写入到对 log 象中，在大量写日志的时候不会导致调用太频繁。如频繁写入文件、频繁调用写日志接口，相反，这会增加内存分配，最好的其实是使用 writev，但是 go runtime 的 io 库没有这个实现。可以采用 plugin 机制来接管日志的打印，减少 io 卡顿对 go runtime 的调度影响

*当一次循环处理完之后，会调用 runtime.Gosched() 主动让出当前协程的 cpu 资源

Metrics

Metrics 是一种规范的度量，分为如下类型，摘抄至 METRIC TYPES

Gauges: 代表可以任意上下波动的单个数值，通常用来表示测量值。比如内存，cpu，磁盘等信息。
Counters: 累计度量，代表单调递增的计数器，只有在重启或者重置的时候数量为 0，其他时候一般不使用减少。可以用来表示请求的数量。
Histograms: 直方图，对观察值(通常是请求持续时间或返回大小之类的数据)进行采样，并将其计数放到对应的配置桶中，也提供所有观测值总和信息。
Summary: 类似于直方图，摘要采样的观测结果，可以计算滑动时间窗口内的可配置分位数。

主要代码在 pkg/metrics 下面包括 pkg/metrics/sink 和 pkg/metrics/shm。

sink

pkg/metrics/sink 包含 console 和 prometheus，两者都实现了 types.MetricsSink 接口。prometheus 是通过工厂方法注册进去使用的；console 是通过直接调用 console.NewConsoleSink() 来使用的。

prometheus

主要是通过 prometheus 的 metrics 统计请求的信息，配置文件示例:

{
	"metrics": {
		......
		"sinks": [
			{
				"type": "prometheus",
				"config": {
					"port": 34903
				}
			}
		]
	}
}

其中 type 目前只支持 prometheus

通过 prometheus 库提供的 http 能力，使用配置信息启动一个 http 服务，把 Metrics 信息通过 http://host:port/metrics 的方式供prometheus收集或展示。

console

主要用于 admin api 的 /api/v1/stats 展示。所以必须配置 admin 相关信息，示例：

{
  "admin": {
    "address": {
      "socket_address": {
        "address": "0.0.0.0",
        "port_value": 34901
      }
    }
  }
}

如果不配置会打印 no admin config, no admin api served 告警信息，参考

admin api 中还包括如下接口

/api/v1/config_dump
/api/v1/stats
/api/v1/update_loglevel
/api/v1/enable_log
/api/v1/disbale_log
/api/v1/states
/api/v1/plugin
/

其中 update_loglevel 用于更新 errorlog 日志的输出级别，enable_log 和 disbale_log 用于启用/禁用 errorlog 的输出

shm

pkg/metrics/shm 主要是通过 mmap 将一个文件或者其它对象映射进内存，让多个进程共用，可以让 MOSN 在热升级的过程中 metrics 数据不会出现 "断崖"，关于 shm 的分析内容可以参考共享内存模型。

不鼓励在 Go 里面使用共享内存，除非你有明确的使用场景

总结

通过分析 MOSN 源码的 log系统 模块，不单单是了解了日志部分，从配置、启动流程，到上下游请求都有所涉及。学习了很多，希望 MOSN 越来越强大。

MOSN 源码 v0.10.0
pkg 源码 commit 1e41847

Blog: 直播预告：MOSN 的多协议机制解析

Tue, 03 Mar 2020 00:00:00 +0000

作为云原生网络代理，Service Mesh 是 MOSN 的重要应用场景。随着 Service Mesh 概念的日益推广，大家对这套体系都已经不再陌生，有了较为深入的认知。但是与理论传播相对应的是，生产级别的大规模落地实践案例却并不多见。这其中有多方面的原因，包括社区方案饱受诟病的“大规模场景性能问题”、“配套的运维监控基础设施演进速度跟不上”、“存量服务化体系的兼容方案”等等。

现实场景中，大部分中国厂商都有一套自研 RPC 的服务化体系，属于「存量服务化体系的兼容方案」中的协议适配问题。为此，MOSN 设计了一套多协议框架，用于降低自研体系的协议适配及接入成本，加速 Service Mesh 的落地普及。本次演讲将向大家介绍 MOSN 实现多协议低成本接入的设计思路，以及相应的快速接入实践案例。

讲师：无钩（@neverhook）

本期大纲

一个请求的 MOSN 之旅
如何在 MOSN 中接入新的协议
SOFABolt 协议接入实践
未来发展：统一路由框架

直播报名：https://tech.antfin.com/community/live/1131

扫描社区页面的二维码加入钉钉群参与互动。

Blog: MOSN 源码解析 - 协程模型

Tue, 25 Feb 2020 00:00:00 +0000

基本概念

MOSN 中的概念比较多，以sofarpc-sample下面的config.json为例，结合上图依次看下：

Downstream：调用端的数据流向统称。
Upstream：服务端的数据流向统称。
clientListener：用于接收调用端（业务进程）请求数据的监听端口。
serverListener：作为服务端流量代理，用于接收调用端的请求
clientCluster：服务提供者的地址列表，实际应用中这块数据应该来自于注册中心。
serverCluster：真正提供服务的业务进程，也就是说一个MOSN可以代理多个服务端进程。

流程概述

这是官方提供的一张流程图，已经很清晰了，这里简要说明一下：

MOSN 无论是收到调用端（Downstream）发来的请求还是服务端（Upstream）发来的响应，都需要通过网络层，然后根据指定协议解码request跟response，最后交给stream层处理（当然这中间会有各式各样的过滤器链可以进行扩展，后面跟着源码会说）。
由于 MOSN 夹在调用端跟服务端中间，分别跟调用端、服务端都会建立连接，因此在stream层采用的是同步阻塞的方式，也就是说调用端的请求转发出去以后对应的协程就会挂起，在收到服务端发来的响应以后再唤醒该等待协程，而关联请求跟响应的关键就是 requestID。

明白了大致流程以后，下面就通过源码来分析一下整个过程。

源码分析

为了便于理解，这里从下往上看，也就是先从网络层接收数据的逻辑开始，一步一步来分析 MOSN 是怎么做编解码，怎么转发请求。

发起请求

MOSN 对于网络层的操作，无论是调用端还是服务端，都封装在eventloop.go文件中，每当连接建立以后，MOSN 都会开启两个协程分别处理该连接上的读写操作，分别对应startReadLoop跟startWriteLoop两个方法。

当调用端（业务进程）发起请求时，根据clientListener指定的地址跟 MOSN 建立连接，然后发起调用。MOSN 在建立连接以后，会等待请求数据的到达，这部分逻辑就在startReadLoop 中：

func (c *connection) startReadLoop() {
	var transferTime time.Time
	for {
        //省略部分逻辑...
		select {
		case <-c.internalStopChan:
			return
		case <-c.readEnabledChan:
		default:
			if c.readEnabled { //readEnabled 默认为true
				//真正的读取数据逻辑在这里
				err := c.doRead()
				if err != nil {
					//读取失败进行处理
				}
			} else {
				select {
				case <-c.readEnabledChan:
				case <-time.After(100 * time.Millisecond):
				}
			}
		}
	}
}

逻辑比较直观，就是一个死循环不断的读取该连接上面的数据。下面看一下关键的doRead()方法：

func (c *connection) doRead() (err error) {
    //为该连接创建一个buffer来保存读入的数据
	if c.readBuffer == nil {
		c.readBuffer = buffer.GetIoBuffer(DefaultBufferReadCapacity)
	}

	var bytesRead int64

	//从连接中读取数据，返回实际读取到的字节数，rawConnection对应的就是原始连接
	bytesRead, err = c.readBuffer.ReadOnce(c.rawConnection)
	if err != nil {
	      //错误处理
	}

	//没有读取到数据，也没有报错
	if bytesRead == 0 && err == nil {
		err = io.EOF
	}

	//进行读取字节函数的回调，可以进行数据统计
	for _, cb := range c.bytesReadCallbacks {
		cb(uint64(bytesRead))
	}

	//通知上层读取到了新的数据
	c.onRead()
	return
}

上面的ReadOnce 方法比较简单，就不单独列出来了，其实就是在该连接上设置一个超时时间进行读取，并把读取到的数据放入buffer中，结合最外层的死循环，不难理解这个不断尝试读取数据的模型。

下面重点看一下回调方法onRead()

func (c *connection) onRead() {
	//不再可读，这里可能跟热升级有关？
	if !c.readEnabled {
		return
	}
	//没有需要处理的数据
	if c.readBuffer.Len() == 0 {
		return
	}

	//filterManager过滤器管理者，把读取到的数据交给过滤器链路进行处理
	c.filterManager.OnRead()
}

//上述OnRead方法实现
func (fm *filterManager) OnRead() {
	fm.onContinueReading(nil)
}

func (fm *filterManager) onContinueReading(filter *activeReadFilter) {
	var index int
	var uf *activeReadFilter

	if filter != nil {
		index = filter.index + 1
	}

	//这里可以清楚的看到网络层读取到数据以后，通过filterManager把数据交给整个过滤器链路处理
	for ; index < len(fm.upstreamFilters); index++ {
		uf = fm.upstreamFilters[index]
		uf.index = index
        //针对还没有初始化的过滤器回调其初始化方法OnNewConnection
		if !uf.initialized {
			uf.initialized = true
			status := uf.filter.OnNewConnection()
			if status == api.Stop {
				return
			}
		}

		//取出该连接中刚才读取到的数据
		buf := fm.conn.GetReadBuffer()
		if buf != nil && buf.Len() > 0 {
			//通知过滤器进行处理
			status := uf.filter.OnData(buf)
			if status == api.Stop {
				return
			}
		}
	}
}

在sofarpc-sample中，这个过滤器对应的实现就在proxy.go文件中，一起来看下具体实现：

func (p *proxy) OnData(buf buffer.IoBuffer) api.FilterStatus {
    //针对使用的协议类型初始化serverStreamConn
	if p.serverStreamConn == nil {
		var prot string
		if conn, ok := p.readCallbacks.Connection().RawConn().(*mtls.TLSConn); ok {
			prot = conn.ConnectionState().NegotiatedProtocol
		}
		protocol, err := stream.SelectStreamFactoryProtocol(p.context, prot, buf.Bytes())
		if err == stream.EAGAIN {
			return api.Stop
		} else if err == stream.FAILED {
			var size int
			if buf.Len() > 10 {
				size = 10
			} else {
				size = buf.Len()
			}
			log.DefaultLogger.Errorf("[proxy] Protocol Auto error magic :%v", buf.Bytes()[:size])
			p.readCallbacks.Connection().Close(api.NoFlush, api.OnReadErrClose)
			return api.Stop
		}
		log.DefaultLogger.Debugf("[proxy] Protoctol Auto: %v", protocol)
		p.serverStreamConn = stream.CreateServerStreamConnection(p.context, protocol, p.readCallbacks.Connection(), p)
	}
	//把数据分发到对应协议的的解码器，在这里当然就是sofa协议解析器
	p.serverStreamConn.Dispatch(buf)
    //结合上面过滤器链路的调用逻辑看，返回Stop表示处理完成，不会再继续调用剩余的过滤器
	return api.Stop
}

由于我们是以sofarcp-sample为例进行分析，所以上述的Dispatch()方法自然落在了pkg/stream/sofarpc/stream.go文件中，一起来看一下：

func (conn *streamConnection) Dispatch(buf types.IoBuffer) {
	for {
		// 1. pre alloc stream-level ctx with bufferCtx
		ctx := conn.contextManager.Get()

		// 2. decode process
		// 针对读取到的数据，按照协议类型进行解码
		cmd, err := conn.codecEngine.Decode(ctx, buf)
		// No enough data
		//如果没有报错且没有解析成功，那就说明当前收到的数据不够解码，推出循环，等待更多数据到来
		if cmd == nil && err == nil {
			break
		}
		if err != nil {
			//错误处理
		}

		// Do handle staff. Error would also be passed to this function.
		//解码成功以后，开始处理该请求
		//注意不能并行对数据进行解码，不然数据都乱了，解码之后可以引入多线程提高吞吐量
		conn.handleCommand(ctx, cmd, err)
		if err != nil {
			break
		}
		conn.contextManager.Next()
	}
}

上述解码过程的具体实现就不单独列出来了，根据协议规范处理字节即可。

下面重点看一下解码成功后的后续处理，继续handleCommand方法：

func (conn *streamConnection) handleCommand(ctx context.Context, model interface{}, err error) {
	if err != nil {
		conn.handleError(ctx, model, err)
		return
	}
    //类型校验
	cmd, ok := model.(sofarpc.SofaRpcCmd)
	if !ok {
		conn.handleError(ctx, model, ErrNotSofarpcCmd)
		return
	}
    //根据数据类型创建对应的stream
	stream := conn.processStream(ctx, cmd)

	//处理该stream的后续工作
	if stream != nil {
		timeoutInt := cmd.GetTimeout()
		timeout := strconv.Itoa(timeoutInt) // timeout, ms
		cmd.Set(types.HeaderGlobalTimeout, timeout)

		//转发数据的逻辑封装在这里
		stream.receiver.OnReceive(stream.ctx, cmd, cmd.Data(), nil)
	}
}

//这里是区分请求跟响应的关键部分，关系到数据流向
func (conn *streamConnection) processStream(ctx context.Context, cmd sofarpc.SofaRpcCmd) *stream {
	switch cmd.CommandType() {
	case sofarpc.REQUEST, sofarpc.REQUEST_ONEWAY:
		var span types.Span
		if trace.IsEnabled() {
			// try build trace span
			tracer := trace.Tracer(protocol.SofaRPC)
			if tracer != nil {
				span = tracer.Start(ctx, cmd, time.Now())
			}
		}
        //请求处理
		return conn.onNewStreamDetect(ctx, cmd, span)
	case sofarpc.RESPONSE:
        //响应处理
		return conn.onStreamRecv(ctx, cmd)
	}
	return nil
}

上述stream的处理逻辑，是我认为整个数据流处理中最复杂的部分，首先这里出现了分歧，根据当前的数据是request还是response进行不同的处理，顺着我们的思路，现在还在请求转发阶段，因此我们先来看下请求处理：

func (conn *streamConnection) onNewStreamDetect(ctx context.Context, cmd sofarpc.SofaRpcCmd, span types.Span) *stream {
	//每个请求新建一个stream
	buffers := sofaBuffersByContext(ctx)
	stream := &buffers.server
        //保存requestID，后面要用来关联请求及响应
	stream.id = cmd.RequestID()
	stream.ctx = mosnctx.WithValue(ctx, types.ContextKeyStreamID, stream.id)
	stream.ctx = mosnctx.WithValue(ctx, types.ContextSubProtocol, cmd.ProtocolCode())
	stream.ctx = conn.contextManager.InjectTrace(stream.ctx, span)
	//数据流向
	stream.direction = ServerStream
	stream.sc = conn
    //根据请求类型进行处理
	if cmd.CommandType() == sofarpc.REQUEST_ONEWAY {
		stream.receiver = conn.serverStreamConnectionEventListener.NewStreamDetect(stream.ctx, nil, span)
	} else {
		//为该stream创建一个用于处理收到响应以后的对象
		stream.receiver = conn.serverStreamConnectionEventListener.NewStreamDetect(stream.ctx, stream, span)
	}

	return stream
}

//receiver的具体实现
func (p *proxy) NewStreamDetect(ctx context.Context, responseSender types.StreamSender, span types.Span) types.StreamReceiveListener {
	//再次是一个新的stream
	stream := newActiveStream(ctx, p, responseSender, span)

	if value := mosnctx.Get(p.context, types.ContextKeyStreamFilterChainFactories); value != nil {
		ff := value.(*atomic.Value)
		ffs, ok := ff.Load().([]api.StreamFilterChainFactory)
		if ok {
			for _, f := range ffs {
				f.CreateFilterChain(p.context, stream)
			}
		}
	}

	p.asMux.Lock()
	stream.element = p.activeSteams.PushBack(stream)
	p.asMux.Unlock()

	return stream
}

//真正receiver的创建过程
func newActiveStream(ctx context.Context, proxy *proxy, responseSender types.StreamSender, span types.Span) *downStream {
	if span != nil && trace.IsEnabled() {
		ctx = mosnctx.WithValue(ctx, types.ContextKeyActiveSpan, span)
		ctx = mosnctx.WithValue(ctx, types.ContextKeyTraceSpanKey, &trace.SpanKey{TraceId: span.TraceId(), SpanId: span.SpanId()})
	}

	//从对象池中选一个
	proxyBuffers := proxyBuffersByContext(ctx)

	stream := &proxyBuffers.stream
	stream.ID = atomic.AddUint32(&currProxyID, 1)
	stream.proxy = proxy
	stream.requestInfo = &proxyBuffers.info
	stream.requestInfo.SetStartTime()
	stream.requestInfo.SetDownstreamLocalAddress(proxy.readCallbacks.Connection().LocalAddr())
	stream.requestInfo.SetDownstreamRemoteAddress(proxy.readCallbacks.Connection().RemoteAddr())
	stream.context = ctx
	stream.reuseBuffer = 1
	stream.notify = make(chan struct{}, 1)
    //省略部分数据
	if responseSender == nil || reflect.ValueOf(responseSender).IsNil() {
		stream.oneway = true
	} else {
		stream.responseSender = responseSender
		stream.responseSender.GetStream().AddEventListener(stream)
	}
	return stream
}

整个stream的构建过程代码多且复杂，但其实总的来说就是针对每个请求创建了两个stream对象，一个用于封装请求逻辑，一个用于封装收到响应以后的处理逻辑。

接下来需要回到handleCommand方法，当stream创建好之后，会直接调用其receiver的OnReceive方法，由于现在还是处理请求，所以对应的是downstream.go中的实现：

注意：每个请求数据都分为了header，body，trailers三部分。

func (s *downStream) OnReceive(ctx context.Context, headers types.HeaderMap, data types.IoBuffer, trailers types.HeaderMap) {
	//head body trailer
	s.downstreamReqHeaders = headers
	if data != nil {
		s.downstreamReqDataBuf = data.Clone()
		data.Drain(data.Len())
	}
	s.downstreamReqTrailers = trailers

	id := s.ID
	//把给任务丢给协程池进行处理即可
	pool.ScheduleAuto(func() {
		defer func() {
			if r := recover(); r != nil {
				if id == s.ID {
					s.delete()
				}
			}
		}()

		//一旦该协程被CPU调度到以后，就开始继续执行发送请求的逻辑：
		phase := types.InitPhase
		for i := 0; i < 10; i++ {
			s.cleanNotify()
            //真正的处理逻辑在这里
			phase = s.receive(ctx, id, phase)
			switch phase {
			case types.End:
				return
			case types.MatchRoute:
			case types.Retry:
			case types.UpFilter:
			}
		}
	})
}

receive方法的逻辑我觉得很有意思，总体来说在请求转发阶段，依次需要经过DownFilter -> MatchRoute -> DownFilterAfterRoute -> DownRecvHeader -> DownRecvData -> DownRecvTrailer -> WaitNofity这么几个阶段，从字面意思可以知道MatchRoute就是构建路由信息，也就是转发给哪个服务，而WaitNofity则是转发成功以后，等待被响应数据唤醒。

下面就依次来看一下：

func (s *downStream) receive(ctx context.Context, id uint32, phase types.Phase) types.Phase {
	for i := 0; i <= int(types.End-types.InitPhase); i++ {
		switch phase {
		// init phase
		case types.InitPhase:
			phase++
			// downstream filter before route
		case types.DownFilter:
			s.runReceiveFilters(phase, s.downstreamReqHeaders, s.downstreamReqDataBuf, s.downstreamReqTrailers)
            //有错误就退出
			if p, err := s.processError(id); err != nil {
				return p
			}
			phase++
			// match route
		case types.MatchRoute:
            //生成服务提供者的地址列表以及路由规则
			s.matchRoute()
			if p, err := s.processError(id); err != nil {
				return p
			}
			phase++

			// downstream filter after route
		case types.DownFilterAfterRoute:
			s.runReceiveFilters(phase, s.downstreamReqHeaders, s.downstreamReqDataBuf, s.downstreamReqTrailers)

			if p, err := s.processError(id); err != nil {
				return p
			}
			phase++

			// downstream receive header
		case types.DownRecvHeader:
            //这里开始依次发送数据
			if s.downstreamReqHeaders != nil {
				s.receiveHeaders(s.downstreamReqDataBuf == nil && s.downstreamReqTrailers == nil)

				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++

			// downstream receive data
		case types.DownRecvData:
			if s.downstreamReqDataBuf != nil {
				s.downstreamReqDataBuf.Count(1)
				s.receiveData(s.downstreamReqTrailers == nil)

				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++

			// downstream receive trailer
		case types.DownRecvTrailer:
			if s.downstreamReqTrailers != nil {
				s.receiveTrailers()

				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++
		case types.WaitNofity:
			//这里阻塞等待返回及结果
			if p, err := s.waitNotify(id); err != nil {
				return p
			}
			phase++
		}
	}
	return types.End
}

真正的发送数据逻辑是在receiveHeaders、receiveData 、receiveTrailers 这三个方法里，当然每次请求不一定都需要有这三部分的数据，这里我们以receiveHeaders方法为例来进行说明：

func (s *downStream) receiveHeaders(endStream bool) {
	s.downstreamRecvDone = endStream
    //省略部分逻辑。。。

    //这里的的clusterName就对应上面的"clientCluster"
	clusterName := s.route.RouteRule().ClusterName()
	s.cluster = s.snapshot.ClusterInfo()
	s.requestInfo.SetRouteEntry(s.route.RouteRule())

	//初始化连接池
	pool, err := s.initializeUpstreamConnectionPool(s)
	if err != nil {
		//错误处理
	}

	parseProxyTimeout(&s.timeout, s.route, s.downstreamReqHeaders)
	prot := s.getUpstreamProtocol()

	s.retryState = newRetryState(s.route.RouteRule().Policy().RetryPolicy(), s.downstreamReqHeaders, s.cluster, prot)

	//构建对应的upstream请求
	proxyBuffers := proxyBuffersByContext(s.context)
	s.upstreamRequest = &proxyBuffers.request
	s.upstreamRequest.downStream = s
	s.upstreamRequest.proxy = s.proxy
	s.upstreamRequest.protocol = prot
	s.upstreamRequest.connPool = pool
	s.route.RouteRule().FinalizeRequestHeaders(s.downstreamReqHeaders, s.requestInfo)

	//这里发送数据
	s.upstreamRequest.appendHeaders(endStream)

	//这里开启超时计时器
	if endStream {
		s.onUpstreamRequestSent()
	}
}

//
func (r *upstreamRequest) appendHeaders(endStream bool) {
	if r.downStream.processDone() {
		return
	}
	r.sendComplete = endStream
	if r.downStream.oneway {
		r.connPool.NewStream(r.downStream.context, nil, r)
	} else {
		r.connPool.NewStream(r.downStream.context, r, r)
	}
}

//
func (p *connPool) NewStream(ctx context.Context, responseDecoder types.StreamReceiveListener, listener types.PoolEventListener) {
	subProtocol := getSubProtocol(ctx)
    //从连接池中获取连接
	client, _ := p.activeClients.Load(subProtocol)
	if client == nil {
		listener.OnFailure(types.ConnectionFailure, p.host)
		return
	}

	activeClient := client.(*activeClient)
	if atomic.LoadUint32(&activeClient.state) != Connected {
		listener.OnFailure(types.ConnectionFailure, p.host)
		return
	}

	if !p.host.ClusterInfo().ResourceManager().Requests().CanCreate() {
		listener.OnFailure(types.Overflow, p.host)
		p.host.HostStats().UpstreamRequestPendingOverflow.Inc(1)
		p.host.ClusterInfo().Stats().UpstreamRequestPendingOverflow.Inc(1)
	} else {
		atomic.AddUint64(&activeClient.totalStream, 1)
		p.host.HostStats().UpstreamRequestTotal.Inc(1)
		p.host.ClusterInfo().Stats().UpstreamRequestTotal.Inc(1)

		var streamEncoder types.StreamSender
		// oneway
		if responseDecoder == nil {
			streamEncoder = activeClient.client.NewStream(ctx, nil)
		} else {
            //这里会把streamId对应的stream保存起来
			streamEncoder = activeClient.client.NewStream(ctx, responseDecoder)
			streamEncoder.GetStream().AddEventListener(activeClient)
		}
        //发送数据
		listener.OnReady(streamEncoder, p.host)
	}
	return
}

//
func (c *client) NewStream(context context.Context, respReceiver types.StreamReceiveListener) types.StreamSender {
	// oneway
	if respReceiver == nil {
		return c.ClientStreamConnection.NewStream(context, nil)
	}
	wrapper := &clientStreamReceiverWrapper{
		streamReceiver: respReceiver,
	}
	streamSender := c.ClientStreamConnection.NewStream(context, wrapper)
	wrapper.stream = streamSender.GetStream()
	return streamSender
}

//
func (conn *streamConnection) NewStream(ctx context.Context, receiver types.StreamReceiveListener) types.StreamSender {
	buffers := sofaBuffersByContext(ctx)
	stream := &buffers.client
	stream.id = atomic.AddUint64(&conn.currStreamID, 1)
	stream.ctx = mosnctx.WithValue(ctx, types.ContextKeyStreamID, stream.id)
	stream.direction = ClientStream
	stream.sc = conn
	stream.receiver = receiver
	//oneway的请求不需要处理结果
	if stream.receiver != nil {
		conn.mutex.Lock()
		//按照id放进map
		conn.streams[stream.id] = stream
		conn.mutex.Unlock()
	}
	return stream
}

//
func (r *upstreamRequest) OnReady(sender types.StreamSender, host types.Host) {
	r.requestSender = sender
	r.host = host
	r.requestSender.GetStream().AddEventListener(r)
	r.startTime = time.Now()

	endStream := r.sendComplete && !r.dataSent && !r.trailerSent
    //发送数据
	r.requestSender.AppendHeaders(r.downStream.context, r.convertHeader(r.downStream.downstreamReqHeaders), endStream)

	r.downStream.requestInfo.OnUpstreamHostSelected(host)
	r.downStream.requestInfo.SetUpstreamLocalAddress(host.AddressString())

}

//
func (s *stream) AppendHeaders(ctx context.Context, headers types.HeaderMap, endStream bool) error {
	cmd, ok := headers.(sofarpc.SofaRpcCmd)
	var err error、
	switch s.direction {
	case ClientStream:
		s.sendCmd = cmd
	case ServerStream:
		switch cmd.CommandType() {
		case sofarpc.RESPONSE:
			s.sendCmd = cmd
		case sofarpc.REQUEST, sofarpc.REQUEST_ONEWAY:
			//服务端发给调用端的数据
			s.sendCmd, err = s.buildHijackResp(cmd)
		}
	}
	if endStream {
		s.endStream()
	}
	return err
}

//
func (s *stream) endStream() {
	if s.sendCmd != nil {
		s.sendCmd.SetRequestID(s.id)
		s.sendCmd.Del(types.HeaderGlobalTimeout)

		//编码
		buf, err := s.sc.codecEngine.Encode(s.ctx, s.sendCmd)
		if err != nil {
        //...
		}

		//这里相当于是上面的编码只编码的头部，如果有body那就一起发送？
		if dataBuf := s.sendCmd.Data(); dataBuf != nil {
			err = s.sc.conn.Write(buf, dataBuf)
		} else {
			err = s.sc.conn.Write(buf)
		}
		//错误处理
		if err != nil {
		}
	}
}

网络层的write：

func (c *connection) Write(buffers ...buffer.IoBuffer) (err error) {
    //同样经过过滤器
	fs := c.filterManager.OnWrite(buffers)

	if fs == api.Stop {
		return nil
	}

	if !UseNetpollMode {
		if c.useWriteLoop {
			c.writeBufferChan <- &buffers
		} else {
			err = c.writeDirectly(&buffers)
		}
	} else {
		//netpoll模式写
	}

	return
}

在对应的eventloop.go中的startWriteLoop方法：

func (c *connection) startWriteLoop() {
	var err error
	for {
		select {
		case <-c.internalStopChan:
			return
		case <-c.transferChan:
			needTransfer = true
			return
		case buf, ok := <-c.writeBufferChan:
			if !ok {
				return
			}
			c.appendBuffer(buf)
            c.rawConnection.SetWriteDeadline(time.Now().Add(types.DefaultConnWriteTimeout))
			_, err = c.doWrite()
		}

		if err != nil {
			//错误处理
		}
	}
}

请求数据发出去以后当前协程就阻塞了，看下waitNotify方法的实现：

func (s *downStream) waitNotify(id uint32) (phase types.Phase, err error) {
	if s.ID != id {
		return types.End, types.ErrExit
	}
	//阻塞等待
	select {
	case <-s.notify:
	}
	return s.processError(id)
}

经过上面的几个步骤，请求被成功转发出去，并且对应的stream在阻塞等待响应。

结果响应

接下来我们再回头看看收到响应时候的处理过程，由于网络层的处理逻辑都是一样的，所以我们从前面出现分歧的地方开始看，也就是processStream方法，当收到的数据类型是RESPONSE时，它会调用onStreamRecv，一起来看下：

func (conn *streamConnection) onStreamRecv(ctx context.Context, cmd sofarpc.SofaRpcCmd) *stream {
	requestID := cmd.RequestID()
	conn.mutex.Lock()
	defer conn.mutex.Unlock()
	
	//通过requestID找到对应的阻塞的stream
	if stream, ok := conn.streams[requestID]; ok {
		delete(conn.streams, requestID)
		buffer.TransmitBufferPoolContext(stream.ctx, ctx)
		return stream
	}
	return nil
}

该stream同样会走到handleCommand方法中的OnReceive，如下：

func (w *clientStreamReceiverWrapper) OnReceive(ctx context.Context, headers types.HeaderMap, data types.IoBuffer, trailers types.HeaderMap) {
	w.stream.DestroyStream()
	w.streamReceiver.OnReceive(ctx, headers, data, trailers)
}

func (r *upstreamRequest) OnReceive(ctx context.Context, headers types.HeaderMap, data types.IoBuffer, trailers types.HeaderMap) {
	if r.downStream.processDone() || r.setupRetry {
		return
	}
	r.endStream()
	if code, err := protocol.MappingHeaderStatusCode(r.protocol, headers); err == nil {
		r.downStream.requestInfo.SetResponseCode(code)
	}
	r.downStream.requestInfo.SetResponseReceivedDuration(time.Now())
	r.downStream.downstreamRespHeaders = headers
	if data != nil {
		r.downStream.downstreamRespDataBuf = data.Clone()
		data.Drain(data.Len())
	}
	r.downStream.downstreamRespTrailers = trailers
	//唤醒downstream
	r.downStream.sendNotify()
}

逻辑很简单，就是把根据requestID匹配到的stream唤醒，下面来看一下唤醒以后的处理逻辑，这里需要回到前面阻塞的receive方法中，唤醒以后会从之前阻塞的地方开始继续执行，如下：

func (s *downStream) receive(ctx context.Context, id uint32, phase types.Phase) types.Phase {
	for i := 0; i <= int(types.End-types.InitPhase); i++ {
		switch phase {
		case types.WaitNofity:
			//从这里醒来
			if p, err := s.waitNotify(id); err != nil {
				return p
			}
			phase++
		case types.UpFilter:
			s.runAppendFilters(phase, s.downstreamRespHeaders, s.downstreamRespDataBuf, s.downstreamRespTrailers)
			if p, err := s.processError(id); err != nil {
				return p
			}
			if s.upstreamRequest == nil {
				fakeUpstreamRequest := &upstreamRequest{
					downStream: s,
				}
				s.upstreamRequest = fakeUpstreamRequest
			}
			phase++
		case types.UpRecvHeader:
			//同样是在这里返回响应结果
			if s.downstreamRespHeaders != nil {
				s.upstreamRequest.receiveHeaders(s.downstreamRespDataBuf == nil && s.downstreamRespTrailers == nil)
				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++
		case types.UpRecvData:
			if s.downstreamRespDataBuf != nil {
				s.upstreamRequest.receiveData(s.downstreamRespTrailers == nil)
				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++
		case types.UpRecvTrailer:
			if s.downstreamRespTrailers != nil {
				s.upstreamRequest.receiveTrailers()
				if p, err := s.processError(id); err != nil {
					return p
				}
			}
			phase++
		case types.End:
			return types.End
		default:
			return types.End
		}
	}

	log.Proxy.Errorf(s.context, "[proxy] [downstream] unexpected phase cycle time")
	return types.End
}

上面的receiveXXX方法会把响应数据转发给业务进程，之前分析过了，这里就不再赘述。

协程池

前面在请求处理过程中提到了会把请求任务交给一个协程池去处理，这里就简单看一下 MOSN 中协程池的实现原理：

type workerPool struct {
	work chan func()
	sem  chan struct{}
}
func NewWorkerPool(size int) WorkerPool {
	return &workerPool{
		work: make(chan func()),
		sem:  make(chan struct{}, size),
	}
}

初始化过程很简单，协程池的默认大小为poolSize := runtime.NumCPU() * 256，接下来看一下调度方法的实现：

func (p *workerPool) ScheduleAuto(task func()) {
	select {
	case p.work <- task:
		return
	default:
	}
	select {
	case p.work <- task:
	case p.sem <- struct{}{}:
		go p.spawnWorker(task)
	default:
		//如果有多余的任务，则会临时创建协程执行
		utils.GoWithRecover(func() {
			task()
		}, nil)
	}
}
//额外创建出来的协程在执行完任务以后会自动退出
func GoWithRecover(handler func(), recoverHandler func(r interface{})) {
	go func() {
		//省略defer方法...
		handler()
	}()
}
func (p *workerPool) spawnWorker(task func()) {
	defer func() {
		if r := recover(); r != nil {
			log.DefaultLogger.Errorf("[syncpool] panic %v\n%s", p, string(debug.Stack()))
		}
		//整个函数退出时，协程数量减1，后面可以再创建出来
		//这里正常情况下下面的死循环是不会退出的，也就是说基础协程一旦创建就不会被回收
		<-p.sem
	}()
	for {
		//执行任务
		task()
		//如果还有任务等待执行，则循环执行任务，否则等待
		task = <-p.work
	}
}

总结

MOSN 对于数据的处理及转发这块非常复杂，主要是概念很多，尤其是stream部分，对象之间互相引用，错综复杂，考虑到篇幅原因，本文只说明了流程，其他比如路由策略的细节等需要通过其他文章进行分析。

Blog: UDPA 最新进展深度介绍

Mon, 24 Feb 2020 00:00:00 +0000

前言

在2019年5月，CNCF 筹建通用数据平面API工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准API。

当时我写了一个博客文章 “CNCF正在筹建通用数据平面API工作组，以制定数据平面的标准API” 对此进行了介绍。当时 UDPA 还处于非常早期的筹备阶段，信息非常的少。

现在9个月过去了，我最近收集并整理了一下 UDPA 目前的情况和信息，给大家介绍一下 UDPA 目前最新的进展（截止2020年2月24日）。

UDPA介绍

首先快速介绍一下什么是 UDPA：

UDPA ：“Universal Data Plane API”的缩写， “通用数据平面API”。
UDPA-WG：”Universal Data Plane API Working Group”的缩写，这是CNCF下的一个工作组，负责制定 UDPA。

UDPA的目标，援引自 https://github.com/cncf/udpa 的描述：

通用数据平面API工作组（UDPA-WG）的目标是召集对数据平面代理和负载均衡器的通用控制和配置API感兴趣的业界人士。

UDPA的愿景，同样援引：

通用数据平面API（UDPA）的愿景在 https://blog.envoyproxy.io/the-universal-data-plane-api-d15cec7a 中阐明。我们将寻求一组API，它们为L4/L7数据平面配置提供事实上的标准，类似于SDN中L2/L3/L4的OpenFlow所扮演的角色。

这些API将在proto3中规范定义，并通过定义良好的稳定API版本控制策略，从现有的Envoy xDS API逐步演进。 API将涵盖服务发现，负载均衡分配，路由发现，监听器配置，安全发现，负载报告，运行状况检查委托等。

我们将对API进行改进和成型，以支持客户端 lookaside 负载均衡（例如gRPC-LB），Envoy之外的数据平面代理，硬件LB，移动客户端以及其他范围。我们将努力尽可能与供应商和实现无关，同时坚持支持已投入生产的UDPA的项目（到目前为止，Envoy和gRPC-LB）。

对 UDPA 感兴趣的同学，可以通过以下两个途径进一步深入了解：

UDPA @ GitHub：UDPA 在 github 上的项目，UDPA API 定义的代码都在这里
Universal Data Plane API Working Group (UDPA-WG)：CNCF 的 UDPA 工作组，可以通过加入工作组的方式了解更多信息

UDPA和xDS的关系

在展开 UDPA 的细节之前，有必要先解释清楚 UDPA 和 xDS 的关系，因为这对理解 UDPA 会有很大帮助。

在2019年11月的 EnvoyCon 上，Envoy 的开发者，也是目前 UDPA 最主要的负责人之一，来自 Google 的 Harvey Tuch，有一个演讲非常详细而清晰的解答了这个问题，这个演讲的标题是：“The Universal Dataplane API (UDPA): Envoy’s Next Generation APIs”。

备注：这里我直接援引这份演讲的部分内容，以下两张图片均出自 [这份演讲的PPT](https://static.sched.com/hosted_files/envoycon2019/ac/EnvoyCon UDPA 2019.pdf) 。鸣谢 Harvey。

下图展示了近年来 xDS 协议的演进历程和未来规划：

2017年，xDS v2 引入 proto3 和 gRPC，同年 Istio 项目启动
2018和2019年，xDS v2 API继续发展，陆续引入了新的API定义，如 HDS / LRS / SDS 等，尤其是为了改进 Pilot 下发性能，开始引入增量推送机制
xDS v3 API 原计划于2019年年底推出，但目前看技术推迟，目前 v3 还是 alpha1 状态，预计在即将发布的 Istio 1.5 中会有更多的 v3 API 引入。同时 v3 API 也引入了 UDPA 的部分内容，但是由于 UDPA 目前进展缓慢，对 xDS 的影响并不大，主要还是 xDS 自身的发展，比如对API和技术债务的清理
但在2020年，预计 UDPA 会有很大的进展，尤其是下面我们将会展开的 UDPA-TP 和 UDPA-DM 的设计开始正式制定为 API 之后。而 xDS v4 预计将基于 UDPA ，因此 xDS v4 可能会迎来比较大的变动。

简单总结说：xDS 将逐渐向 UDPA 靠拢，未来将基于 UDPA 。

下面的图片则展示了 Envoy 在 xDS 版本支持上的时间线：

目前看这个计划在执行时稍微有一点点延误，原计划于2019年年底推出的 v3 的 stable 版本实际上是在1月中定稿的。（备注：具体可参考 Envoy PR api: freeze v3 API ）。然后目前正在广泛使用的 v2 API 将被标记为 depreated。而且在2020年底，v3 API 预计被 v4 API 取代（注意v4 API 将会是基于 UDPA），而目前我们最熟悉的 v2 API 将计划在2020年底移除，不再支持！

上图也展示了未来 xDS 协议的大版本演进和更替的方式，总的来说规律是这样：

一年一个大版本：2019 v2 -》 2020 v3 -》2021 v4 -》2022 v5
每个大版本都要经历 alpha -》 stable -》deprecated -》removed 四个阶段，每个阶段历时一年
稳定后 Envoy 会同时存在三个API大版本：正在使用的稳定版本，已经弃用的上一个稳定版本，准备开发的新的下一个大版本（但只会是Alpha）
发布一个新的 stable 的大版本，就一定会 deprecated 上一个稳定的大版本，同时 remove 更前一个已经 deprecated 的大版本

所谓 “长江后浪推前浪，前浪死在沙滩上”，又或者说，“江山代有新版出，各领风骚12个月”。

备注：Envoy 具体的稳定API版本控制策略，可以参见 Envoy 的设计文档 “Stable Envoy API versioning” ，不过这个文档长的有点过分，嫌长的同学可以直接看这个文档的缩减版本 API versioning guidelines。

UDPA API进展

言归正传，我们来看一下 UDPA 目前的最新进展。

从 https://github.com/cncf/udpa ，可以看到目前 UDPA 中已经定义好的部分 API 内容：

类型定义

目前只定义了一个类型 TypedStruct。

TypedStruct包含任意 JSON 序列化后的 protocol buffer 消息，以及一个描述序列化消息类型的URL。这与 google.protobuf.Any 非常相似，它使用 google.protobuf.Struct 作为值，而不是使用 protocol buffer 二进制。

message TypedStruct {
  // 用于唯一标识序列化 protocol buffer 消息的类型的URL
  // 这与 google.protobuf.Any 中描述的语义和格式相同：
  // https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/any.proto
  string type_url = 1;

  // 上述指定类型的JSON表示形式。
  google.protobuf.Struct value = 2;
}

TypedStruct 定义的背景是：如何在 protocol buffer 的静态类型报文中嵌入一个不透明的配置？这是一个普遍需求，涉及 google.protobuf.Any 和 google.protobuf.Struct 的差别和权衡使用。具体内容请见我之前翻译的博客文章 “[译] 动态可扩展性和Protocol Buffer”，对此做了非常好的介绍和分析讨论。

TypedStruct 可以说是到目前为止对此需求的最佳实践，算是为这一话题正式画上了句号。

数据定义

数据定义也只定义了一个数据 OrcaLoadReport。

其中 ORCA 是 Open Request Cost Aggregation 的缩写，OrcaLoadReport 用于提交请求开销汇总的负载报告。

ORCA的简短介绍：

如今，在Envoy中，可以通过考虑后端负载（例如CPU）的本地或全局知识来做出简单的负载均衡决策。更复杂的负载均衡决策可能需要借助特定于应用的知识，例如队列深度，或组合多个指标。

这对于可能在多个维度上受到资源限制的服务（例如，CPU和内存都可能成为瓶颈，取决于所应用的负载和执行环境，无法确定是哪个先触及瓶颈），以及这些维度不在预定类别中的位置时很有用（例如，资源可能是“池中的可用线程数”，磁盘IOPS等）。

有关 Orca 的更详细的信息，请见设计文档 Open Request Cost Aggregation (ORCA) 。

目前 Envoy 正在实现对 ORCA 的支持，然后这个特性被作为 UPDA 标准的一部分直接在 UDPA API 中定义。

以下为 OrcaLoadReport 定义，可以看到包含有CPU/内存的利用率和RPS信息：

message OrcaLoadReport {
  // CPU利用率表示为可用CPU资源的一部分。 应该来自最新的样本或测量。
  double cpu_utilization = 1 [(validate.rules).double.gte = 0, (validate.rules).double.lte = 1];

  // 内存利用率表示为可用内存资源的一部分。 应该来自最新的样本或测量。
  double mem_utilization = 2 [(validate.rules).double.gte = 0, (validate.rules).double.lte = 1];

  // 端点已服务的总RPS。 应该涵盖端点负责的所有服务。
  uint64 rps = 3;
  ...
}

服务定义

服务定义依然也只定义了一个服务 OpenRcaService。

OpenRcaService是一个带外（Out-of-band/OOB）负载报告服务，它不在请求路径上。OpenRcaService定期以足够的频率对报告进行采样，以提供与请求的关联。 OOB报告弥补了带内（in-band）报告的局限性。

service OpenRcaService {
  rpc StreamCoreMetrics(OrcaLoadReportRequest) returns (stream udpa.data.orca.v1.OrcaLoadReport);
}

注解定义

UDPA目前定义了四个注解（Annotation）：

MigrateAnnotation：用于标记在前后版本中的和迁移相关的API变更，包括 rename / oneof_promotion / move_to_package 等多种语义。
SensitiveAnnotation：将某个字段标记为“敏感”字段，例如个人身份信息，密码或私钥
StatusAnnotation：标记状态，比如将某个文件标记为“work_in_progress/进行中”
VersioningAnnotation：用于记录版本信息，比如通过 previous_message_type 表示当前message在上一个版本中的类型

还有一个 ProtodocAnnotation 在提出设计后，存在分歧，暂时还没有正式加入 UDPA。这个注解的目的是标记当前尚未实现的UDPA消息。

UDPA API总结

从上面列出的UDPA API列表可以看到，目前 UDPA 中正式推出的API 内容非常的少，也就：

一个TypedStruct类型定义
一个OpenRcaService服务定义和配套的OracLoadReport数据定义
4个注解

考虑到UDPA推出的时间是 2019年5月份，迄今有9个月的时间，这个进展有些出乎意料。

翻了一遍 https://github.com/cncf/udpa 上的内容，包括所有的 commit 和 PR ，发现活跃的开发者主要是两位同学：Google 的 htuch 和 Tetrate公司的 Lizan。然后 cncf/UDPA 项目的 star 数量也非常低，才 55 个 star，可以认为社区基本上没什么人关注。

但是，稍后当我看到 UDPA 的设计文档时，才发现原来 UDPA 的精华都在设计中，只是进度原因还未能正式出成型的API。

UDPA设计

我们来重点看一下 UDPA 的设计，主要的设计文档有两份：

UDPA-TP strawman: UDPA设计之传输协议(TransPort)，是用于UDPA的下一代传输协议
UDPA-DM: L7 routing strawman: UDPA设计之数据模型(Data Model)，是对通过 UDPA-TP 传输的资源定义

UDPA对此的解释是：

Envoy v2 xDS API 当前正在转向通用数据平面API（Universal Dataplane API/UDPA）。重点是传输协议与数据模型的关注点分离。

关于传输协议与数据模型的关注点分离，一个典型的例子是“集装箱运输机制”（类比 UDPA-TP ）和 “集装箱中标准规格”（类比 UDPA-DM）。在 UDPA 的设计中，数据模型的定义和传输协议的实现是分离的，这意味着只要设计不同的数据模型，就可以重用一套统一的传输协议。因此，UDPA 的可扩展性就变得非常强大。

对此，我个人有些惊喜，因为去年年底我和彦林同学在商讨通过 MCP/xDS/UDPA 协议融合注册中心和控制平面时，就发现这三者的工作机制非常类似。考虑到后续可能会有各种不同的资源需要定义并在这个工作机制上做资源同步和分发，当时有过类似的想法，希望能把底层这套资源同步机制标准化，以便重用：

目前看来，UDPA-TP 已经在朝这个目标迈出了坚实的步伐。当然如果能再往前迈进一步就更好了：这个底层资源同步的工作机制，没有必要限制在 UDPA 的范畴，完全可以变成一个用途更加广泛的通用机制。

下面来详细看一下 UDPA-TP 和 UDPA-DM 的设计，以下内容来自 UDPA 的两份设计文档以及个人的解读。

UDPA-TP设计

UDPA-TP的设计文档，在开始部分列出了 UDPA-TP 的关键设计动机，具体包括：

在保留 Core v2 xDS 中存在的概念性pub-sub模型的同时，还支持高级功能，例如LRS/HDS。
支持Envoy Mobile和其他DPLB客户端的大规模扩展
简单的客户端和简单的管理服务器实现。
使增量更新资源高效而简单。（备注：增量更新是目前 Istio/Envoy 正在努力实现的重点特性）
支持资源联邦。（备注：和我之前构想的通过MCP协议聚合多个注册中心/配置中心的思路一致，当现实中存在多个资源的来源时，就必须提供机制来聚合这些资源并提供一个全局的视图）
使API资源的子资源变得简单且实现成本低，并且使其可以增量更新和可联合
维护对一致性模型的支持
消除v2 xDS奇怪之处：
- ACK/NACK与订阅消息的合并。在v2 xDS中，DiscoveryRequest既是订阅请求，又是对先前消息的潜在确认。这导致了一些复杂的实现和调试体验。（备注：这会造成 UDPA 交互模式和xDS的不同）
- CDS/LDS是与EDS/RDS不同的API层。在v2 xDS中，EDS/RDS是准增量的，而CDS/LDS是最新状态。
从概念上讲，在Envoy v2 xDS API 基础上小范围变更。我们不希望对UDPA管理服务器实现者造成重大的概念和实现开销。（备注：个人理解，这应该是目前 UDPA 没有大张旗鼓的制定各种API的原因，UDPA 和 xDS，包括和 xDS 的实际实现者 Envoy 的关系过于紧密，因此需要考虑从 xDS 到 UDPA 的过渡，不能简单的推出一套全新的API）

以下是 UDPA 的术语，对于后面理解 UDPA 非常有帮助：

DPLB：data plane load balancer的缩写。涵盖诸如代理（例如Envoy）或客户端RPC库（例如gRPC和Envoy Mobile）的用例。 DPLB是UDPA客户端。他们负责启动到管理服务器的UDPA流。（备注：注意，DPLB不仅仅包含以Envoy为代表的service mesh sidecar，也包括了以SDK形式存在的类库如 gRPC，而 gRPC 目前已经在实现对 xDS 接口的支持）
Management server/管理服务器：能够提供UDPA服务的实体。管理服务器可以仅是UDPA服务器，也可以是UDPA客户端和服务器（在联邦的情况下）。
UDPA：通用数据平面API，其中包括数据模型（UDPA-DM）和传输协议（UDPA-TP）。
UDPA-TP：UDPA API的基准传输协议。
UDPA-DM：UDPA API的数据模型。
UaaS：UDPA-as-a-service，云托管的UDPA管理服务。（备注：Google在 GCP 上提供的 Google Traffic Director 和 AWS 提供的 App Mesh，可以视为就是 UaaS 雏形）

然后是和联邦相关的术语：

Federation/联邦：多个UDPA管理服务器的互操作以生成UDPA配置资源。
Direct federation/直接联邦：当DPLB直接连接到多个UDPA管理服务器并能够从这些流中合成其配置资源时。
Indirect federation/间接联邦：当DPLB一次最多连接一个UDPA管理服务器（对于某些给定的资源类型），并且UDPA管理服务器执行所有与联邦有关的工作时。
Advanced DPLB/高级DPLB：支持直接联邦的DPLB（需要UDPA-Fed-TP）。
Simple DPLB/简单DPLB：不支持直接联邦的DPLB，即仅基线UDPA-TP。
UDPA-Fed-DM：UDPA-DM的超集，具有用于联邦的其他资源类型。
UDPA-Fed-TP：支持联邦的UDPA-TP的超集。

下图可以帮助理解这些术语：

(备注：图中可能有误，simple UDPA management server 和 Advanced UDPA management server 之间应该是 “UDPA-TP”, 而不应该是 “UDPA-Fed-TP”。)

UDPA-TP 传输协议提供了在管理服务器和 DPLB 客户端之间传输命名和版本化资源的方法。我们称这些实体为 UDPA-TP 端点。 UDPA-TP 端点可以是客户端和管理服务器，也可以是两个管理服务器（例如，在联邦配置时）。上图说明了使用 UDPA 在 UDPA-TP 端点之间传送资源的各种方式。

其中，UDPA管理服务器分为两种：

简单(simple)：实际上只是对不透明资源的缓存（几乎不了解UDPA-DM），主要功能是从上游高级UDPA管理服务器获取资源，并分发资源给 DPLB，自身不产生资源。
高级(advanced)：对 UDPA-DM 有感知，通常是用来获取信息并转换为标准化的资源（典型如 Istio 中的 Pilot）。可以直接分发资源给到 DPLB，也可以发送资源给简单UDPA管理服务器，然后由简单UDPA管理服务器再分发给 DPLB。

而对应的 DPLB 客户端也分为两种：

简单(simple)：对于任何配置源，简单的DPLB在任何时间点最多只能与一台管理服务器进行对话。
高级(advanced)：将实现对 UDPA-Fed-TP 的支持，并能够直接作为联邦端点参与。

简单 DPLB 虽然只能连接一台管理服务器，但是也是可以实现联邦的：简单 DPLB 连接的管理服务器可以实现联邦，然后为 DPLB 实现了间接联邦。（备注：上图中的简单 DPLB就是例子，两个 Advanced UDPA management server 之间做了联邦）

UDPA-TP设计解读

在解读 UDPA-TP 的设计之前，我们回顾一下 Istio 经典的组件和架构图，下面分别是 Istio 1.0 和 Istio 1.1 的架构图：

考虑到 Mixer 和 Citadel 两个组件和 UDPA 的关系相比没那么大，我们重点看 Proxy / Pilot / Galley：

Proxy在 Istio 中就是 Envoy （我们的MOSN正在努力成为候选方案），直接对等 UDPA 中的 DPLB 的概念。但是Istio 中的 Proxy，功能上只和上图中的 Simple DPLB 对齐。相比之下，UDPA-TP 设计中增加了一个能够连接多个 UDPA management server进行联邦的 Advanced DPLB。
Pilot 和 Galley，从和 DPLB 的连接关系看，分别对应着UDPA-TP 设计中的 Simple UDPA management server 和 Advanced UDPA management server。但从实际实现的功能看，目前Pilot的职责远远超过了 Simple UDPA management server 的设计，而 Galley 的功能则远远少于 Advanced UDPA management server。如果未来 Istio 的架构和组件要向 UDPA 的设计靠拢，则显然 Pilot 和 Galley 的职责要发生巨大调整。
最大的差异还是在于 UDPA-TP 中引入了联邦的概念，而且同时支持在 DPLB 和 Advanced UDPA management server 上做联邦。尤其是 DPLB 要实现联邦功能，则必然会让 DPLB 的功能大为增加，相应的 DPLB 和 UDPA management server 的通讯协议（目前是xDS）也将为联邦的实现增加大量内容。

对照 UDPA-TP 的设计：

UDPA-TP的设计目前应该还没有对应的具体的实现产品，而且我也还没有找到 UDPA-Fed-TP 的详细的API设计。资料来源太少，所以只能简单的做一些个人的初步解读：

首先，Simple UDPA management server 的引入是一大亮点，功能足够简单而且专注，聚焦在将数据（在UDPA中体现为资源）分发给 DPLB （如大家熟悉的数据平面）。毫无疑问，Simple UDPA management server 的重点必然会在诸如容量 / 性能 / 下发效率 / 稳定性等关键性能指标，弥补目前 Istio 设计中 Pilot 下发性能赢弱的短板。从这个角度说，我倾向于将 Simple UDPA management server 理解为一个新的组件，介于 DPLB 和 Pilot 之间。

小结：解决容量和性能问题。
其次，Advanced UDPA management server 引入了联邦的概念，上面的图片显示是为了在两个不同的云供应商（Cloud Provider X 和 Cloud Provider Y）和本地（On-premise）之间进行联邦，这是典型的混合云的场景。而我的理解是，联邦不仅仅用于多云，也可以用于多数据来源，比如打通多个不同的注册中心，解决异构互通问题。

小结：解决多数据来源的全局聚合问题。
然后，比较费解的是引入了 Advanced DPLB 的概念，而且从图上看，使用场景还非常复杂：1. 第一个DPLB是间接联邦的典型场景，还比较简单 2. 第二个 DPLB除了以同样的方式做了间接联邦，还直接通过 UDPA-Fed-TP 协议和 On-Premise 的 Advanced UDPA management server 连接，实现了直接联邦 3. 第三个 DPLB 则更复杂，做了三个management server的联邦。

小结：复杂的场景必然带来复杂的机制，背后推动力待查

对于 UDPA-TP 的设计，我个人有些不太理解，主要是对于联邦的使用场景上，我的疑虑在于：真的有这么复杂的场景吗？尤其是将联邦的功能引入到 DPLB，这必然会使得 xDS/UDPA 协议不得不为此提供联邦 API 支持，而 Envoy/MOSN 等的实现难度也要大为提升。因此，除非有特别强烈的需求和场景推动，否则最好能在复杂度和功能性之间做好平衡。

我个人更倾向于类似下面的设计：

维持 DPLB 和 Simple UDPA management server 的简单性
DPLB 只对接 Simple UDPA management server，协议固定为 UDPA-TP，联邦对DPLB透明（只实现间接联邦）
Simple UDPA management server 重点在于容量和性能的提升，包括目前正在进行中的支持各种资源的增量更新。
Advanced UDPA management server 负责完成联邦，包括和其他环境的Advanced UDPA management server做联邦，以及从本地的其他注册中心聚合数据。

总之，我个人更倾向于让 DPLB 和 Simple UDPA management server 保持简单和高性能，而将复杂功能交给 Advanced UDPA management server 。后续我会重点关注 UDPA 在联邦功能的实现，如有新进展尽量及时撰文分享。

UDPA的资源定义和设计

在 UDPA-TP 的设计中，根据资源的来源，资源被划分为两类类型：

Configuration Resources/配置资源：控制平面生成，由管理服务器分发到 DPLB。平常大家熟悉的，通过xDS协议传输的 Listener / Route / Cluster / Endpoint 等资源就属于这种类型。
Client Resources/客户资源：DPLB生成，准备交给控制平面使用。前面 UDPA 中定义的 OracLoadReport 就是典型例子，这是最近才有的新特性，由 DPLB 收集统计信息和状态，汇报给到控制平面，以便控制平面在决策时可以有多完善的参考信息。

资源在定义时，将有三个重要属性：

名称/Name：对于给定类型是唯一的，而且资源名称是结构化的，其路径层次结构如下：/ ，例如 com.acme.foo/service-a 。注意 namespace 的引入，是后面的资源联邦和所有权委派的基础。
类型/Type：资源类型由 Type URL 提供的字符串来表示。
版本/Version：对于给定的命名资源，它可能在不同的时间点具有不同的版本。在资源定义中带上版本之后，检测资源是否有更新就非常方便了。

以下是资源定义的实例（只是示意，暂时还没正式成为 UDPA API的内容）：

message Resource {
  // 资源的名称，以区别于其他同类型的资源。
  // 遵循反向DNS格式，例如 com.acme.foo/listener-a
  string name = 1;

  // 资源级别版本
  string version = 2;

  // 资源有效负载。
  // 通过 Any 的 type URL 指定资源类型
  google.protobuf.Any resource = 3;

  // 资源的TTL。
  // 此时间段后，资源将在DPLB上失效。
  // 当管理服务器的连接丢失时，将支持资源的优雅降级，例如端点分配。
  // 使用新的TTL接收到相同的资源 name/version/type 将不会导致除了刷新TTL之外的任何状态更改。
  // 按需资源可能被允许过期，并且可能在TTL过期时被重新获取。
  // TTL刷新消息中的resource字段可能为空，name/version/type用于标识要刷新的资源。
  google.protobuf.Duration ttl = 4;
 
  // 资源的出处（所有权，来源和完整性）。
  Provenance origin_info = 5;
}

UDPA-TP 设计中的其他内容，如安全 / 错误处理 / 传输 / 用户故事等，就不一一展开了，这些设计目前看离正式成为 API 还有点远。如有兴趣可以直接翻阅 UDPA-TP 的设计文档。

UDPA-DM设计

UDPA 设计的一个核心内容就是将传输（TransPort）与数据模型（Date Model）的关注点分离，前面介绍了 UDPA-TP 的设计，可以说目前还在进行中，并未完全定型。

而 UDPA-DM 的设计，感觉进度上比 UDPA-TP 还要更早期，这多少有点出乎意料：原以为 UDPA 会基于 xDS 现有的成熟 API 定义，快速推出一套覆盖常见通用功能的 API ，甚至直接把 xDS 中的部分内容清理干净之后搬过来。但事实是：目前 UDPA-DM 中已经定义的 API 内容非常少，仅有 L7 Routing ，而且还在设计中，其他大家熟悉的 Listener / Cluster / Endpoint / Security / RatingLimit 等API都还没有看到。

而 UDPA-DM 的设计和实现方式，也因为资料较少而有些不够明朗。在 UDPA-DM 的设计文档的开头，有如下一段描述：

As a starting point, we recognize that the UDPA-DM is not required to be as expressive as any given DPLB client’s full set of capabilities, instead it should be possible to translate from UDPA-DM to various DPLB native configuration formats. We envisage UDPA-DM as a lingua franca that captures a large amount of useful functionality that a DPLB may provide, making it possible to build common control planes and ecosystems around UDPA capable DPLBs.

首先，我们认识到 UDPA-DM 不需要像任何已有的 DPLB 客户端那样，全部能力都具备表现力，而是应该可以从 UDPA-DM 转换为各种 DPLB 原生配置格式。我们将 UDPA-DM 设想为一种通用语言，它具备大量 DPLB 应该提供的有用的功能，从而有可能在支持 UDPA 的 DPLB 周围构建通用的控制平面和生态系统。

The UDPA-DM will be a living standard. We anticipate that it will initially cover some obvious common capabilities shared by DPLBs, while leaving other behaviors to proxy specific API fields. Over time, we expect that the UDPA-DM will evolves via a stable API versioning policy to accommodate functionalities as we negotiate a common representation.

UDPA-DM 将成为事实标准。我们期望它最初将涵盖 DPLB 共有的一些显而易见的通用功能，同时将其他行为留给代理特定的API字段。随着时间的推移，我们期望 UDPA-DM 将通过稳定的API版本控制策略来发展，以容纳各种功能，而我们将协商通用的表示形式。

对这两段文字描述的理解，我是有一些困惑的，主要在清楚解 UDPA-DM 的定义和具体的 DPLB 原生实现（典型如 Envoy 的 xDS）之间的关系。下面这张图是我画的：

左边的图是转换方案：按照第一段文字的描述，UDPA-DM 是做通用定义，然后转换（Translate）为各种 DPLB 的原生配置格式。这意味着 UDPA-DM API 和实际的 DPLB 原生配置格式可能会有非常大的不同，甚至有可能是完全不一样的格式定义。这个关系有点类似 Istio API 和 xDS API 的关系，也类似于 SMI （微软推出的 Service Mesh Interface）和 xDS 的关系。
右边的图是子集方案：按照第二段文字的描述，UDPA-DM 是做通用定义，但是不会做转换，其他 DPLB 会直接复用这些 UDPA-DM 的 API 定义，然后补充自身特有的 API 定义。这样 UDPA-DM 会以通用子集的形式出现，逐渐扩大范围，然后其他 API 会逐渐将自身的 API 中和 UDPA-DM 重叠的部分替换为 UDPA-DM API，只保留自身特有的扩展API。

前面谈到 xDS 的演进路线， v3 / v4 会逐渐向 UDPA 靠拢，尤其 v4 会基于 UDPA 来。目前由于 UDPA API 远未成型，而 xDS v3 中对 UDPA API 的使用非常少（基本只用到了 annotation 定义），因此目前到底是哪个方案尚不明朗。

以下是 UDPA-DM 设计文档中描述的 UDPA-DM 的关键设计：

描述L7路由层，该层描述主要 L7 DPLB 之间的常见行为，包括 Envoy，HAproxy，Nginx，Google Cloud Platform URL mapping 和 Linkerd。
为代理/LB的特有扩展提供灵活性，用于不适合通用抽象的行为。即逃生舱口（escape hatch）（备注：类似SQL 方言）
提供L7路由表的可伸缩性和有效的对数评估（logarithmic evaluation）。例如，Envoy v2 xDS是严格线性评估的路由表，具有明显的扩展限制。对于可以支持 UDPA-TP 这个特性的DPLB，应该可以按需获取路由表段。
在v2 Envoy xDS API中支持线性匹配路由表的旧有用户。
删除多xDS样式API的需求，例如 RDS，VHDS和SRDS。
资源的可组合性；应该有可能支持UDPA联邦用例，带有诸如虚拟主机这种被独立管理的资源等

下面重点看 L7 Routing 的设计。

Routing API 设计

Routing API 中有三个术语：

服务/Service：描述后端服务的不透明字符串（或在Envoy的术语中，为集群/Cluster）。当前文档未提供有关服务表示的任何进一步详细说明，这留待以后的工作。
路由表/Route table：一组匹配条件，用于HTTP请求和相关操作。操作可以包括重定向或转发到特定服务。
L7路由/L7 routing：根据路由表评估给定的HTTP请求。

在 UDPA-DM 的 Routing API 设计中，针对请求匹配的方式，相比 xDS 做了重大的改动，主要体现在除了线性匹配之外，还支持分层匹配。

这里先解释一下线性匹配和分层匹配这两种路由时需要用到的请求匹配方式：

线性（Linear）：其中路由表类似于[([Match], Action)] 类型。在此模型中，路由表是匹配 criteria-action 条件的有序列表。每个匹配的 criteria 是匹配 criteria 的逻辑”与”，例如
- If :authority == foo.com AND path == / AND x-foo == bar THEN route to X
- If :authority == bar.com AND x-baz == wh00t THEN route to Y
分层(Hierarchical)：其中路由表类似于树结构，每个节点具有(MatchCriteria, [(Value, Action)]) 类型。通过这种结构，任何给定的节点都会只评估单个匹配条件，例如:authority 的值。分层匹配能提供相对高效的实现。

目前 xDS v2 API使用的是线性匹配方式，而 UDPA-DM 的 Routing API 会引入分层匹配，形成线性-分层的混合匹配方式，如下图所示：

设计文档对这个混合匹配模型有如下说明：

The model does not map directly to any given DPLB today but borrows from some Envoy concepts and should have an efficient realization. It may be possible to use HAproxy ACLs to model this topology.

目前该模型并没有直接映射到任何给定的DPLB，而是借鉴了Envoy的一些概念，这个模型应该会有一个有效的实现。可能会使用HAproxy ACL对这种拓扑进行建模。

由于目前 Routing API 并没有完成设计，也没有正式成为 UDPA 的API，而在最新刚定稿的 xDS v3 协议中，RoutesDiscoveryService 和 ScopedRoutesDiscoveryService 也都没有引入这个新的模型，因此预期这个模型将在2020年继续完成设计和定稿，可能在年底的 xDS v4 中会有所体现。然后，UDPA-DM 和 xDS 之间到底会是转换模型，还是子集模型，届时就清楚了。

由于 Routing API 尚未设计完成，所以这里不详细展开 Routing API 的定义了。Routing API 的相关资料如下，有兴趣的同学可以关注（然而已经很长时间没有新的进展了）：

Issue 讨论 [WiP] L7 routing straw man
在 PR 中提交的 Routing API 定义文件 udpa/config/v1alpha/routing.proto：可以自行和xDS v3 的API 做一个比较

总结

UDPA 目前还处于早期设计阶段，关键的 UDPA-TP 和 UDPA-DM 的设计有推出草稿但是远未完成，内容也和我们期望的一个完整的通用数据平面API有很长的距离。

而且项目进展并不理想，感觉重视程度和人力投入都有限。

附言

最近因为想了解一下 UDPA 的进展，所以做了 UDPA 的调研和学习，比较遗憾的是 UDPA 的资料非常匮乏，除了我本文列出来的几个官方网站和设计文档之外，基本就只有 Harvey 的演讲。

调研完成之后发现 UDPA 的进展不如人意，尤其是最近的工作几乎停滞，关键的 UDPA-TP 和 UDPA-DM 的设计未能完稿，xDS v3 中也只引用了极少的 UDPA API 定义。这篇总结文章差点因此难产，因为未知/待定/未完成的内容太多，而且由于缺乏资料输入，很多信息也只是我个人的理解和想法，按说这不是一个严谨的深度介绍文章应有的态度。

但考虑到目前 UDPA 的资料实在是太少，本着“有比没有好”的想法，我硬着头皮完成了这篇文章。后续如果有新的输入，我会及时完善或者修订本文，也欢迎对 UDPA 有兴趣和了解的同学联系我讨论和指导。

参考资料

https://github.com/cncf/udpa ：UDPA在 github 的项目，API 定义来自这里
Universal Data Plane API Working Group (UDPA-WG): UDPA设计文档，但是内容很少
Universal Data Plane API Working Group (UDPA-WG)：CNCF 下的 UDPA 工作组，加入之后能看到一些资料
UDPA-TP strawman: UDPA-TP的设计文档
UDPA-DM: L7 routing strawman: UDPA-DM的设计文档
Stable Envoy API versioning ：Envoy 官方文档，讲述 Envoy 的稳定API版本控制策略
CNCF正在筹建通用数据平面API工作组，以制定数据平面的标准API：我去年写的 UDPA 介绍文章
The Universal Dataplane API (UDPA): Envoy’s Next Generation APIs：Harvey Tuch 的演讲，帮助理解 xDS 和 UDPA 的关系

Blog: MOSN 源码解析 - 共享内存模型

Sun, 23 Feb 2020 00:00:00 +0000

本文记录了对 MOSN 的源码研究 - MOSN 的共享内存模型。

本文的内容基于 MOSN v0.9.0，commit id b2a239f5。

机制

MOSN 用共享内存来存储 metrics 信息。MOSN 用 mmap 将文件映射到内存，在内存数组之上封装了一层关于 metrics 的存取逻辑，实现了 go-metrics 包的关于 metrics 的接口，通过这种方式组装出了一种基于共享内存的 metrics 实现供 MOSN 使用。

创建共享内存：Mmap

操作共享内存的方法主要在 pkg/shm/shm.go 文件下：

func Alloc(name string, size int) (*ShmSpan, error) {
	...
	return NewShmSpan(name, data), nil
}

func Free(span *ShmSpan) error {
	Clear(span.name)
	return syscall.Munmap(span.origin)
}

func Clear(name string) error {
	return os.Remove(path(name))
}

都是围绕着 ShmSpan 结构体的几个操作方法。再来看 ShmSpan 结构体：

type ShmSpan struct {
	origin []byte // mmap 返回的数组
	name   string // span 名, 创建时指定

	data   uintptr // 保存 mmap 内存段的首指针
	offset int // span 已经使用的字节长度
	size   int // span 大小
}

Alloc 方法按照给定的 name 参数，在配置文件的目录下创建文件，并执行 sync.Mmap，其文件尺寸即 size 参数大小。Mmap 过后，将信息保存在 ShmSpan结构内返回。

代码逻辑比较简单，大家可以自行阅读：https://github.com/mosn/mosn/blob/b2a239f5/pkg/shm/shm.go#L28

由此看出，一个 ShmSpan 可以看做是一个共享内存块。

下面我们将会分析共享内存块在 MOSN 里的使用场景：metrics。

操作共享内存：配置

在分析如何通过共享内存存取 metrics 之前，首先看这相关的功能是如何配置的。

https://github.com/mosn/mosn/blob/b2a239f5/pkg/mosn/starter.go#L318

func initializeMetrics(config v2.MetricsConfig) {
	// init shm zone
	if config.ShmZone != "" && config.ShmSize > 0 {
		shm.InitDefaultMetricsZone(config.ShmZone, int(config.ShmSize), store.GetMosnState() != store.Active_Reconfiguring)
        ...

从这里看出，通过读取配置文件的 ShmZone 和 ShmSize 来初始化共享内存，即配置文件的以下两个字段是控制着共享内存的文件名和大小的：

{
  ...
  "metrics": {
    ...
    "shm_zone": "文件名",
    "shm_size": "共享内存文件大小"
  },
  ...
}

操作共享内存：metrics

metrics 相关的逻辑在 pkg/metrics 包下。

上文说的 ShmSpan 是保存共享内存信息的结构体，而要理解 MOSN metrics 对共享内存的使用，还要先理解 MOSN 封装的几个结构体：zone、hashSet 和 hashEntry。

type zone struct {
	span *shm.ShmSpan

	
	ref   *uint32

	set *hashSet // mutex + ref = 64bit, so atomic ops has no problem
}
...
type hashSet struct {
	entry []hashEntry
	meta  *meta
	slots []uint32
}
...
type hashEntry struct {
	metricsEntry
	next uint32

	// Prevents false sharing on widespread platforms with
	// 128 mod (cache line size) = 0 .
	pad [128 - unsafe.Sizeof(metricsEntry{})%128 - 4]byte
}

这几个结构体与 ShmSpan 的关系大致是这样的：

ShmSpan 是共享内存块，而 zone、hashSet 和 hashEntry 对 ShmSpan 进行了划分：

hashSet 封装出了 metrics name 映射到 metrics value 的哈希表
hashEntry 是哈希表的值，也是 metrics 值的保存的共享内存空间
zone 对 ShmSpan 进行了划分，划分出了一个 int32 值作为互斥锁；一个 int32 值作为 zone 的引用计数；也划分出了一片空间保存 hashSet

以上步骤做好后，创建一个 metrics 就可以通过创建对应的哈希 key value，拿到对应的共享内存地址，存取 metrics 信息。

实现小细节

hashEntry 内部有一个 pad 字段，其作用是保持 hashEntry 结构体大小是 128 的倍数，避免 false sharing

结构体内的字段顺序和大小是调整过的，比如 hashEntry.value、zone.set，目的是满足原子操作的内存对齐

下面是源码步骤，大家可以自行跟踪调试：

1) 创建 zone：

https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/zone.go#L81

func newSharedMetrics(name string, size int) (*zone, error) {
	alignedSize := align(size, pageSize)

    // 申请 ShmSpan
	span, err := shm.Alloc(name, alignedSize)
	if err != nil {
		return nil, err
	}
	// 1. mutex and ref
	// 从 span 里取 4 个字节做互斥锁
	mutex, err := span.Alloc(4)
	if err != nil {
		return nil, err
	}

    // 从 span 里取 4 个字节做引用计数
	ref, err := span.Alloc(4)
	if err != nil {
		return nil, err
	}

	zone := &zone{
		span:  span,
		mutex: (*uint32)(unsafe.Pointer(mutex)),
		ref:   (*uint32)(unsafe.Pointer(ref)),
	}

	// 2. hashSet
	// 划分哈希表过程

	// assuming that 100 entries with 50 slots, so the ratio of occupied memory is
	// entries:slots  = 100 x 128 : 50 x 4 = 64 : 1
	// so assuming slots memory size is N, total allocated memory size is M, then we have:
	// M - 1024 < 65N + 28 <= M

    // 计算 slot 的数量和内存占用大小
	slotsNum := (alignedSize - 28) / (65 * 4)
	slotsSize := slotsNum * 4
	// 计算 entry 数量和内存占用大小
	entryNum := slotsNum * 2
	entrySize := slotsSize * 64
	
	// 哈希表内存大小 = entry 内存占用 + 20 字节 + slot 内存占用大小
	hashSegSize := entrySize + 20 + slotsSize
	hashSegment, err := span.Alloc(hashSegSize)
	if err != nil {
		return nil, err
	}

	// if zones's ref > 0, no need to initialize hashset's value
	// 初始化哈希表结构
	set, err := newHashSet(hashSegment, hashSegSize, entryNum, slotsNum, atomic.LoadUint32(zone.ref) == 0)
	if err != nil {
		return nil, err
	}
	zone.set = set

	// add ref
	atomic.AddUint32(zone.ref, 1)

	return zone, nil
}

这里可以大致说一下哈希表初始化的算法：首先 alignedSize 表示 4k 对齐后的 ShmSpan 大小，前 8 个字节被分配为互斥锁和引用计数，另外 20 个字节被分配为哈希表的 meta 结构体，

https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/hashset.go#L54

type hashSet struct {
	entry []hashEntry
	meta  *meta
	slots []uint32
}

...


type meta struct {
	cap       uint32
	size      uint32
	freeIndex uint32

	slotsNum uint32
	bytesNum uint32
}

所以真正能被分配为哈希表信息储存的空间 = 总空间 - 8 字节 - 20 字节。那能分配多少个哈希表信息呢？要看看 MOSN 的哈希表组织形式：entry 最开始首尾相连，后面会被组织成一个一个的 slot 链表供哈希碰撞时遍历查询。所以 slot 和 entry 的比例控制着哈希表查找的性能：entry 比 slot 作为比例的话，比例越高意味着更容易碰撞，链表越长，查找性能下降；相反比例越低链表越短，查找性能越高，但是有越多 slot 闲置，空间会浪费。

从注释看，MOSN 将比例写死为 2：1。假设 100 个 entry + 50 个 slot，其内存比等于 100 * 128（entry 内存占用）：50 * 4 = 64：1，即一份 2：1 的 entry+slot 需要用到（64 + 1）* 4 个字节。

所以，如果按照 2：1 来分配的话，一共可以分配的份数 = 哈希表信息储存空间 / 每一份空间占用 = (总空间 - 8 - 20) / (64 + 1) * 4 份。由此就可以算出 entry 和 slot 可以分配多少份了。

2) 创建指标：

https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/counter.go#L56

func NewShmCounterFunc(name string) func() gometrics.Counter {
	return func() gometrics.Counter {
		if defaultZone != nil {
			if entry, err := defaultZone.alloc(name); err == nil {
			...

https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/zone.go#L166

func (z *zone) alloc(name string) (*hashEntry, error) {
	z.lock()
	defer z.unlock()

	entry, create := z.set.Alloc(name)
	...

https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/hashset.go#L135

func (s *hashSet) Alloc(name string) (*hashEntry, bool) {
	// 1. search existed slots and entries
	// 计算 hash 值作为 slot index
	h := hash(name)
	slot := h % s.meta.slotsNum

	// name convert if length exceeded
	if len(name) > maxNameLength {
		// if name is longer than max length, use hash_string as leading character
		// and the remaining maxNameLength - len(hash_string) bytes follows
		hStr := strconv.Itoa(int(h))
		name = hStr + name[len(hStr)+len(name)-maxNameLength:]
	}

	nameBytes := []byte(name)

    // 查找链表找到对应的 entry
	var entry *hashEntry
	for index := s.slots[slot]; index != sentinel; {
		entry = &s.entry[index]

		if entry.equalName(nameBytes) {
			return entry, false
		}

		index = entry.next
	}

	// 2. create new entry
	// 如果找不到, 创建新的 entry
	if s.meta.size >= s.meta.cap {
		return nil, false
	}

    // 创建新的 entry 从 hashset 的 meta 信息里拿 next free index
	newIndex := s.meta.freeIndex
	newEntry := &s.entry[newIndex]
	newEntry.assignName(nameBytes)
	newEntry.ref = 1

	if entry == nil {
		// 所以是链表头,保存 index 到 slot
		s.slots[slot] = newIndex
	} else {
		// 否则保存在上一个 entry 的 next 字段内
		entry.next = newIndex
	}

	s.meta.size++
	// 设置 next free index
	s.meta.freeIndex = newEntry.next
	// 设置队尾
	newEntry.next = sentinel

	return newEntry, true
}

3) 用 Entry 保存 metrics 值

https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/counter.go#L56

func NewShmCounterFunc(name string) func() gometrics.Counter {
	return func() gometrics.Counter {
		if defaultZone != nil {
			if entry, err := defaultZone.alloc(name); err == nil {
			    return ShmCounter(unsafe.Pointer(&entry.value))
			}
			...

可以看出，entry 的 value 是真正被用作记录 metrics 值的地方，它是一个 64 位的空间。

为什么使用共享内存保存 metrics

看到这里你可能会问，为什么要这么辛苦封装共享内存来保存 metrics 值？为什么不直接使用堆空间来做呢？

其实在源码里也有答案：

https://github.com/mosn/mosn/blob/b2a239f5/pkg/mosn/starter.go#L318

func initializeMetrics(config v2.MetricsConfig) {
	// init shm zone
	if config.ShmZone != "" && config.ShmSize > 0 {
		shm.InitDefaultMetricsZone(config.ShmZone, int(config.ShmSize), store.GetMosnState() != store.Active_Reconfiguring)
        ...

https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/zone.go#L58

func createMetricsZone(name string, size int, clear bool) *zone {
	if clear {
		shm.Clear(name)
	}
    ...

如果 clear 为真，共享内存就会被清除，那么什么时候为假呢？当 store.GetMosnState() 方法返回 store.Active_Reconfigureing 的时候。即，当 MOSN reconfig 重启的时候，已经保存的 metrics 是会被保留的。

而且从这里可以看出：

https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/zone.go#L124

func newSharedMetrics(name string, size int) (*zone, error) {
    ...
	set, err := newHashSet(hashSegment, hashSegSize, entryNum, slotsNum, atomic.LoadUint32(zone.ref) == 0)
	...

https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/hashset.go#L78

func newHashSet(segment uintptr, bytesNum, cap, slotsNum int, init bool) (*hashSet, error) {
	set := &hashSet{}
	...

当 zone.ref 引用计数不为 0 的时候，哈希表里面的信息也是会被保留的。

再来看 zone.mutex 互斥锁的使用：

https://github.com/mosn/mosn/blob/b2a239f5/pkg/metrics/shm/zone.go#L136

func (z *zone) lock() {
	times := 0

	// 5ms spin interval, 5 times burst
	for {
		if atomic.CompareAndSwapUint32(z.mutex, 0, pid) {
			return
		}
	...

是通过设置进程 ID 来获取锁的，由此能看出 MOSN 的用意：这个以文件作为 mmap 的共享内存是可以被多个 MOSN 进程共用的。

例如 MOSN 支持跨容器热重启的场景，基于内存共享的 metrics 可以保证热重启过程中不出现指标抖动而造成监控异常。而且这个文件可以看作是一种文件格式，在任何时候都可以被持久化保存和提取分析使用的。

当你不需要这个功能时，可以关闭内存共享 metrics 的配置即可，MOSN 会 fallback 到 go-metrics 的实现，该实现就是通过堆分配内存保存 metrics 信息。

总结

本文通过分析 MOSN 源码，简述了 MOSN 的共享内存模型，分析了 MOSN 创建共享内存、配置 metrics 和 metrics 对共享内存块的使用。

最后，不鼓励在 Go 里面使用共享内存，除非你有明确的使用场景，例如 MOSN 热升级场景下的 metrics 共享。

参考资料:

MOSN 源码

Blog: MOSN 源码解析 - 变量机制

Sun, 16 Feb 2020 00:00:00 +0000

本文的目的是分析 MOSN 源码中的变量机制。

什么是变量机制

我们通过一个单元测试来理解什么是变量机制，完整代码清参考这里:

// DefaultAccessLogFormat provides a pre-defined format
const DefaultAccessLogFormat = "%start_time% %request_received_duration% %response_received_duration% %bytes_sent%" + " " +
    "%bytes_received% %protocol% %response_code% %duration% %response_flag% %response_code% %upstream_local_address%" + " " +
    "%downstream_local_address% %downstream_remote_address% %upstream_host%"

func TestAccessLog(t *testing.T) {
    registerTestVarDefs()

    format := types.DefaultAccessLogFormat
    logName := "/tmp/mosn_bench/benchmark_access.log"
    os.Remove(logName)
    accessLog, err := NewAccessLog(logName, format)
    ...
    ctx := prepareLocalIpv6Ctx()
    accessLog.Log(ctx, nil, nil, nil)
    ...
}

执行这个单元测试，并查看日志内容：

go test mosn.io/mosn/pkg/log -run ^TestAccessLog$
ok      mosn.io/mosn/pkg/log    2.867s
cat /tmp/mosn_bench/benchmark_access.log
2020/02/16 21:26:26.078 2.543µs 2.000004307s 2048 2048  0 24.471µs false 0 127.0.0.1:23456 [2001:db8::68]:12200 127.0.0.1:53242 -

请留意 accessLog.Log 打印出来的日志，可以发现 DefaultAccessLogFormat 中的变量, 都被替换成了实际的值。比如：%start_time% 被替换成 2020/02/16 21:26:26.078, %request_received_duration% 被替换成 2.543µs。

变量机制允许用户在配置中使用预定义的变量，而非确定值；变量将在请求处理过程中被替换成其对应的实际值。

变量机制的原理

请留意上面的变量机制原理图，它分为 3 部分；最上边的是Variable 缓存，左边虚线框的是初始化阶段，而右边虚线是对变量的使用。

Variable 缓存

Variable 缓存 是一组 Variable 的 key-value 对，key 是变量的名字，value 是 Variable 接口；以 map 的形式存在于内存中。Variable 接口含有变量的名字，变量值的获取方式, 变量值的设置方式 等属性。

初始化阶段

在初始化阶段中，首先定义好各变量的 Variable（预定义变量）；然后注册到 Variable 缓存中。另外，还需初始化 mosn ctx，mosn ctx 是一个 context.Context，里面含有变量实际值的相关信息；在后续获取变量的实际值时会用到它。

对变量的使用

在请求处理的过程中，根据变量名去缓存中获取相应的 Variable。然后调用 Variable 的 Getter 方法，得到变量的获取方式 getter。最后调用 getter 函数，getter 函数会根据 mosn ctx 生成变量的实际值。

可以看出，变量机制 用到了 生产者-消费者模式。生产者 负责定义变量对应的 Variable，并注册到 Variable 缓存中。而这些 Variable 会在请求处理过程中被消费，生成变量的实际值。

了解完变量机制的原理后，我们继续围绕什么是变量机制中的单元测试，深入探讨它背后的实现逻辑。

注册变量

该单元测试通过函数 registerTestVarDefs 进行变量的注册，代码片段如下，完整代码清参考这里:

var (
    builtinVariables = []variable.Variable{
        variable.NewBasicVariable(varStartTime, nil, startTimeGetter, nil, 0),
        variable.NewBasicVariable(varRequestReceivedDuration, nil, receivedDurationGetter, nil, 0),
        ...
    }

    prefixVariables = []variable.Variable{
        variable.NewBasicVariable(reqHeaderPrefix, nil, requestHeaderMapGetter, nil, 0),
        variable.NewBasicVariable(respHeaderPrefix, nil, responseHeaderMapGetter, nil, 0),
    }
)

func registerTestVarDefs() {
    // register built-in variables
    for idx := range builtinVariables {
        variable.RegisterVariable(builtinVariables[idx])
    }

    // register prefix variables, like header_xxx/arg_xxx/cookie_xxx
    for idx := range prefixVariables {
        variable.RegisterPrefixVariable(prefixVariables[idx].Name(), prefixVariables[idx])
    }
}

通过 variable.NewBasicVariable 初始化各种 variable.Variable 的定义，再利用 variable.RegisterVariable 或 RegisterPrefixVariable 函数进行注册

接口 variable.Variable 的定义如下, 完整代码清参考这里：

type Variable interface {
	// variable name
	Name() string
	// variable data, which is useful for getter/setter
	Data() interface{}
	// variable flags
	Flags() uint32
	// value getter
	Getter() GetterFunc
	// value setter
	Setter() SetterFunc
}

Name: 获取变量名
Data: 获取变量的实际值
Flags: 是否需要缓存的标志
Getter: 获取变量值的函数
Setter: 设置变量值的函数

再来看函数 variable.RegisterVariable, 完整代码清参考这里：

var (
    // global scope
    mux              sync.RWMutex
    variables        = make(map[string]Variable, 32) // all built-in variable definitions
    indexedVariables = make([]Variable, 0, 32)       // indexed variables
    ...
)

func RegisterVariable(variable Variable) error {
    mux.Lock()
    defer mux.Unlock()

    name := variable.Name()

    // check conflict
    if _, ok := variables[name]; ok {
        return errors.New(errVariableDuplicated + name)
    }

    // register
    variables[name] = variable

    // check index
    if indexer, ok := variable.(Indexer); ok {
        index := len(indexedVariables)
        indexer.SetIndex(uint32(index))

        indexedVariables = append(indexedVariables, variable)
    }
    return nil
}

定义全局变量 variables 和 indexedVariables
由于使用了全局变量，为了防止竞态条件，使用了互斥锁
检查变量是否已经存在，如果已存在，返回错误；否则，变量正常注册到缓存 variables 中
将 variables 转化成 Indexer, 设置 index，并注册到缓存 indexedVariables 中

RegisterPrefixVariable 函数的功能和 RegisterVariable 大同小异，RegisterVariable 根据变量名注册，而 RegisterPrefixVariable 通过变量名的前缀注册。

变量注册大致的过程是：在代码初始化的时候，实例化所有定义好的变量（主要含有变量名，变量的获取方式 getter），并通过函数 RegisterVariable 或 RegisterPrefixVariable 注册到缓存（全局变量）中。

获取变量

获取变量的原来则需要分析函数 NewAccessLog，完整代码清参考这里：

func NewAccessLog(output string, format string) (api.AccessLog, error) {
    ...
    entries, err := parseFormat(format)
    if err != nil {
        return nil, err
    }

    l := &accesslog{
        output:  output,
        entries: entries,
        logger:  lg,
    }
    ...
}

解析字符串 format, 创建想要的变量，记录到变量条目 entries 里
将变量条目 entries 赋给结构体 accesslog

再来分析解析 format 的函数 parseFormat, 完整代码清参考这里：

func parseFormat(format string) ([]*logEntry, error) {
    ...
    for pos, ch := range format {
        switch ch {
        case '%':
            // check previous character, '\' means it is escaped
            if pos > 0 && format[pos-1] == '\\' {
                continue
            }
            // parse entry
            if pos > lastMark {
                if varDef {
                    // empty variable definition: %%
                    if pos == lastMark+1 {
                        return nil, ErrEmptyVarDef
                    }
                    // var def ends, add variable
                    varEntry, err := variable.AddVariable(format[lastMark+1 : pos])
                    if err != nil {
                        return nil, err
                    }
                    entries = append(entries, &logEntry{variable: varEntry})
                } else {
                    // ignore empty text
                    if pos > lastMark+1 {
                        // var def begin, add text
                        textEntry := format[lastMark+1 : pos]
                        entries = append(entries, &logEntry{text: textEntry})
                    }
                }
                lastMark = pos
            }
            ...
        }
    }
    ...
}

根据标识符 % 截取变量名
利用函数 variable.AddVariable 检查该变量名是否已经注册过了，并返回对应的变量
所有变量记录到切片 entries 中，一并返回

接下来分析函数 variable.AddVariable，完整代码清参考这里：

func AddVariable(name string) (Variable, error) {
    mux.Lock()
    defer mux.Unlock()

    // find built-in variables
    if variable, ok := variables[name]; ok {
        return variable, nil
    }

    // check prefix variables
    for prefix, variable := range prefixVariables {
        if strings.HasPrefix(name, prefix) {
            return variable, nil
            ...
        }
    }

    return nil, errors.New(errUndefinedVariable + name)
}

如果能在注册了变量的缓存 variables 找到 name 对应的变量，则直接返回变量
如果能在注册了变量的缓存 prefixVariables 找到变量名前缀是 name 的变量，则返回变量
没有找到想要的变量，则返回错误，改错误可以在程序启动的时候被发现

获取变量大致的流程是：format 解析中解析出变量名，然后去注册了变量的缓存 variables 或 prefixVariables 中获取相应的变量。

变量生效

本小节将会分析方法 accessLog.Log 的逻辑，从而了解变量生效的过程，完整代码清参考这里：

func (l *accesslog) Log(ctx context.Context, reqHeaders api.HeaderMap, respHeaders api.HeaderMap, requestInfo api.RequestInfo) {
    // return directly
    if l.logger.Disable() {
        return
    }

    buf := buffer.GetIoBuffer(AccessLogLen)
    for idx := range l.entries {
        l.entries[idx].log(ctx, buf)
    }
    buf.WriteString("\n")
    l.logger.Print(buf, true)
}

一些日志的处理逻辑
遍历变量条目 entries，执行 l.entries[idx].log，获取变量对应的实际值

再来分析方法 l.entries[idx].log, 完整代码清参考这里：

func (le *logEntry) log(ctx context.Context, buf buffer.IoBuffer) {
    if le.text != "" {
        buf.WriteString(le.text)
    } else {
        value, err := variable.GetVariableValue(ctx, le.variable.Name())
        if err != nil {
            buf.WriteString(variable.ValueNotFound)
        } else {
            buf.WriteString(value)
        }
    }
}

主要是利用函数 variable.GetVariableValue 获取变量的实际值
将获取到的实际值写到 buf 里

接着分析函数 variable.GetVariableValue，完整代码清参考这里：

func GetVariableValue(ctx context.Context, name string) (string, error) {
    // 1. find built-in variables
    if variable, ok := variables[name]; ok {
        // 1.1 check indexed value
        if indexer, ok := variable.(Indexer); ok {
            return getFlushedVariableValue(ctx, indexer.GetIndex())
        }

        // 1.2 use variable.Getter() to get value
        getter := variable.Getter()
        if getter == nil {
            return "", errors.New(errGetterNotFound + name)
        }
        return getter(ctx, nil, variable.Data())
    }

    // 2. find prefix variables
    for prefix, variable := range prefixVariables {
        if strings.HasPrefix(name, prefix) {
            getter := variable.Getter()
            if getter == nil {
                return "", errors.New(errGetterNotFound + name)
            }
            return getter(ctx, nil, name)
        }
    }

    return "", errors.New(errUndefinedVariable + name)
}

根据变量名，重新从缓存 variables 中获取相应的变量 variable
调用变量的 Getter 方法，获取函数 getter(GetterFunc)，一个获取变量实际值的方法
执行 getter 函数，得到变量的实际值

接下来分析类型是 GetterFunc 的函数，以 startTimeGetter 为例，完整代码清参考这里：

// StartTimeGetter
// get request's arriving time
func startTimeGetter(ctx context.Context, value *variable.IndexedValue, data interface{}) (string, error) {
	info := ctx.Value(requestInfoKey).(api.RequestInfo)

	return info.StartTime().Format("2006/01/02 15:04:05.000"), nil
}

调用 ctx.Value, 根据 requestInfoKey 从 ctx 中获取相应的对象
该对象已经事先在这里，通过 ctx 的 WithValue 设置到了 ctx 里
转化成接口 api.RequestInfo，改接口有获取 StartTime 的能力
获取 StartTime 并格式化

变量生效大致的流程是：遍历已获取的变量条目 entries, 根据变量名获取缓存中的变量，调用变量中的 getter 方法, 获取相应的变量值。

总结

变量机制 的实现是比较面向对象的，首先定义了结构体 Variable, 主要记录了变量名和获取对应变量值的实现GetterFunc；GetterFunc 定义好了获取变量值的函数定义，每个变量都得实现自己的 getter（面向接口编程）。然后在代码初始化的时候把所有变量都实例化，并注册到作为缓存的全局变量 variables 中（表驱动法）; 最后，更加变量名去缓存 variables 获取相应的实现，获取变量的实际值。

另外，很好地利用了 golang 特有的 context 贯穿了整个流程。

Blog: MOSN 源码解析 - 内存复用机制

Sat, 15 Feb 2020 00:00:00 +0000

本文的内容基于 MOSN v0.9.0，commit id 1609ae14。

MOSN 在内存管理复用方面有 内存对象注册/管理 和 ByteBuffer/IOBuffer 复用 两部分内容。MOSN 最新的 master 分支用了 mod 管理依赖，发现后一部分也迁移到了 vendor 目录下，可单独使用。下面就分这两部分来讲述 MOSN 的内存复用机制。

机制

简述一下两部分内容的机制，具体实现原理会在后面带上源码解析。

1. 内存对象注册/管理

MOSN 在 go sync 包外，对 sync.Pool 对象进行了进一步封装，增加了管理和易用性。

MOSN 的 buffer 包提供了注册函数和统一的接口。将实现了接口的不同类型的 buffer 对象注册到 buffer 包，在用到的时候通过 buffer 包导出的方法进行初始化和管理，增强了内存对象的管理。

而易用性方面，MOSN 封装了 bufferValue 对象，管理上面初始化出来的对象，并且将 bufferValue 对象也进行了池化管理。在这之上，封装出方法 NewBufferPoolContext 和 PoolContext，使内部根据 context 传值的场景更加易用。MOSN 里面在不同协程协作（比如连接被协程1 accept 后，交由 worker 协程2 进行 IO）的过程，会将必要参数使用内部实现的 context with value 机制进行传递，其中 buffer 传递的方法就是通过上述封装的方法进行传递的。

2. ByteBuffer/IOBuffer 复用

为了提高 byte 数组的复用率，MOSN 封装出了对齐64字节的 byte buffer pool 管理，以及在其之上的 IO buffer pool 管理包，内部需要用到的时候可以直接调用。

之前这部分代码是放在 pkg 下的，在最新的 master 迁移到了 vendor 下，不依赖 pkg 包下任何的其他包。这种情况下如果开发者自己的项目有这部分需求，其实也可以直接使用 MOSN 写好的包，不用重复造轮子。

源码解析

1. 内存对象注册/管理

注册管理

这是 bufferPool 相关的简单类图。

MOSN 定义了 bufferPoolCtx 接口，使用 buffer 包需要将实现了这个接口的对象，比如图中的 ABufferCtx、BBufferCtx，通过 RegisterBuffer 方法注册到 buffer 包。

其中 Index() 方法返回注册时写入的 index 值；New() 方法是用来初始化待缓存对象的；而 Reest() 方法是将内存对象放回 pool 前的重置逻辑。

https://github.com/mosn/mosn/blob/1609ae1441/pkg/buffer/buffer.go#L70

RegisterBuffer(poolCtx types.BufferPoolCtx) {
	...
	bPool[i].ctx = poolCtx
	setIndex(poolCtx, int(i))
	...

注册过程大致是将传入的对象保存在全局变量 bPool 中，并给它分配一个全局唯一标记。

注册后的结构图大概是这样的：

bPool 全局变量保存着已注册的 ctx, 在需要获取对象时找到对应的 pool，调用 ctx.New()，或 sync.Pool.Get()；在需要 give 对象时，先调用 ctx.Reset() 方法对复用对象进行重置，然后调用 sync.Pool.Put()，至此实现了对 sync.Pool 的封装管理和扩展。

https://github.com/mosn/mosn/blob/1609ae1441/pkg/buffer/buffer.go#L91

// Take returns a buffer from buffer pool
func (p *bufferPool) take() (value interface{}) {
	value = p.Get()
	if value == nil {
		value = p.ctx.New()
	}
	return
}

// Give returns a buffer to buffer pool
func (p *bufferPool) give(value interface{}) {
	p.ctx.Reset(value)
	p.Put(value)
}

易用性

然后是结构图右边的 valuePool 部分。valuePool 是 bufferValue 对象的 sync.Pool。我们先来看 valuePool 的结构：

http://github.com/mosn/mosn/blob/1609ae1441/pkg/buffer/buffer.go#L105

// bufferValue is buffer pool's Value
type bufferValue struct {
	value    [maxBufferPool]interface{}
	transmit [maxBufferPool]interface{}
}

其中 value/transmit 域用来保存从注册表初始化出来的内存对象的指针（transmit 域保存着从其他 context 复制过来的内存对象）。全局变量 vPool 保存了 bufferValue 的 sync.Pool，即 bufferValue 本身也是可以复用的。

这里为什么要一个 transmit 域和复制功能呢？可以从使用到的地方看到，在接收到 upstream response 的时候，因为还没解析 stream， goroutine 还不能知道对应的 downstream request 和其 context 的 bufferValue，这时需要分配一个 bufferValue 保存解析 stream 的信息，等能够关联上的时候再拷贝到 transmit 域，等释放的时候统一释放。

https://github.com/mosn/mosn/blob/1609ae1441/pkg/stream/http2/stream.go#L652


func (conn *clientStreamConnection) handleFrame(ctx context.Context, i interface{}, err error) {
	...
	mbuffer.TransmitBufferPoolContext(stream.ctx, ctx)

回到易用性的介绍，在使用时，通过 NewBufferPoolContext 方法新建一个 bufferValue：

https://github.com/mosn/mosn/blob/1609ae1441/pkg/buffer/buffer.go#L112

// NewBufferPoolContext returns a context with bufferValue
func NewBufferPoolContext(ctx context.Context) context.Context {
	return mosnctx.WithValue(ctx, types.ContextKeyBufferPoolCtx, newBufferValue())
}


// newBufferValue returns bufferValue
func newBufferValue() (value *bufferValue) {
	// 从 vPool 里 get 复用的 bufferValue
	v := vPool.Get()
	if v == nil {
		value = new(bufferValue)
	} else {
		value = v.(*bufferValue)
	}
	return
}

获取内存对象时，调用 PoolContext 方法获取 bufferValue 对象，传入注册表对象调用其 Find 方法，Find 方法会根据注册表对象获取对应的 pool，并且初始化一个内存对象放在 value 域里。

https://github.com/mosn/mosn/blob/1609ae1441/pkg/buffer/buffer.go#L182

PoolContext(ctx context.Context) *bufferValue {
	if ctx != nil {
		if val := mosnctx.Get(ctx, types.ContextKeyBufferPoolCtx); val != nil {
			return val.(*bufferValue)
		}
	}
	return newBufferValue()
}

https://github.com/mosn/mosn/blob/1609ae1441/pkg/buffer/buffer.go#L138

(bv *bufferValue) Find(poolCtx types.BufferPoolCtx, x interface{}) interface{} {
	i := poolCtx.Index()
	if i <= 0 || i > int(index) {
		panic("buffer should call buffer.RegisterBuffer()")
	}
	if bv.value[i] != nil {
		return bv.value[i]
	}
	return bv.Take(poolCtx)
}

// Take returns buffer from buffer pools
func (bv *bufferValue) Take(poolCtx types.BufferPoolCtx) (value interface{}) {
	i := poolCtx.Index() // 获取全局唯一标记
	value = bPool[i].take() // 调用注册表获取对象
	bv.value[i] = value // 放入 value
	return
}

使用完毕，只需调用 bufferValue 的 Give 方法，该方法会将其下管理的内存对象都归还到对应的 Pool 去，并且将自己归还到 vPool。

https://github.com/mosn/mosn/blob/1609ae1441/pkg/buffer/buffer.go#L158

// Give returns buffer to buffer pools
func (bv *bufferValue) Give() {
	if index <= 0 {
		return
	}
	// first index is 1
	// 归还 value & transmit
	for i := 1; i <= int(index); i++ {
		value := bv.value[i]
		if value != nil {
			bPool[i].give(value)
		}
		value = bv.transmit[i]
		if value != nil {
			bPool[i].give(value)
		}
	}
	bv.value = nullBufferValue
	bv.transmit = nullBufferValue

	// Give bufferValue to Pool
	// 归还自己
	vPool.Put(bv)
}

使用场景

上述的方法会在哪里用到呢？

MOSN 的请求处理是交给不同的 goroutine 来进行的，而请求上下文信息，如 host、header、body 等信息通过 context 来在不同的协程之间传递。而内存复用 bufferValue 与 context 进行绑定，意味着在请求处理期间不同的协程都可以通过 context 获取到请求上下文信息。所以，bufferValue 在请求 accept 时申请，在请求处理结束时释放。

https://github.com/mosn/mosn/blob/1609ae1441/pkg/stream/http/stream.go#L338

func newServerStreamConnection(ctx context.Context, connection api.Connection,
	...

	// init first context
	// Next 方法会调用上文的 NewBufferPoolContext 方法
	ssc.contextManager.Next()
    ...

使用完毕，清理 downstream 时清理 bufferValue：

https://github.com/mosn/mosn/blob/1609ae1441/pkg/proxy/downstream.go#L1325

func (s *downStream) giveStream() {
	...
	// Give buffers to bufferPool
	if ctx := mbuffer.PoolContext(s.context); ctx != nil {
		ctx.Give()
	}
}

小结：MOSN 的 buffer 包保存了待复用的内存对象的注册表（bPool对象），用来对待复用对象的初始化和管理；另外，MOSN 定义了统一管理待缓存对象的结构：bufferValue，统一保存通过注册表初始化出来的对象。

2. ByteBufer/IOBuffer 复用

ByteBuffer

先来看相关的结构体：

// byteBufferPool is []byte pools
type byteBufferPool struct {
	minShift int
	minSize  int
	maxSize  int

	pool []*bufferSlot
}

type bufferSlot struct {
	defaultSize int
	pool        sync.Pool
}

每个 slot 对应一种尺寸的 byteBuffer 的 pool，以及 defaultSize 域保存着尺寸。byteBufferPool 对象的 pool 域保存着多个 slot。

再来看操作方法 GetBytes PutBytes，具体逻辑主要是操作 take 和 give 方法。这两个方法后面会分析。

https://github.com/mosn/mosn/blob/1609ae1441/vendor/mosn.io/pkg/buffer/bytebuffer_pool.go#L28

https://github.com/mosn/mosn/blob/1609ae1441/vendor/mosn.io/pkg/buffer/bytebuffer_pool.go#L145

...
// global bbPool
var bbPool *byteBufferPool
...

// GetBytes returns *[]byte from byteBufferPool
func GetBytes(size int) *[]byte {
	return bbPool.take(size)
}

// PutBytes Put *[]byte to byteBufferPool
func PutBytes(buf *[]byte) {
	bbPool.give(buf)
}
...

为了提高复用率，当申请一个非 64 字节对齐尺寸的 byte buffer 时（如 200），MOSN 实际上会从 slot 2，即 defaultSize = 256 的 slot 返回对象，并返回切片 len = 200 的 byte 切片。

初始化时，将 64、128、256… 以此类推的尺寸的 byte slot 初始化到 byteBufferPool 的 pool 域内：

https://github.com/mosn/mosn/blob/1609ae1441/vendor/mosn.io/pkg/buffer/bytebuffer_pool.go#L49

// newByteBufferPool returns byteBufferPool
func newByteBufferPool() *byteBufferPool {
	p := &byteBufferPool{
		minShift: minShift,
		minSize:  1 << minShift,
		maxSize:  1 << maxShift,
	}
	for i := 0; i <= maxShift-minShift; i++ {
		slab := &bufferSlot{
			// 通过左移算出 defaultSize = 64/128/256...等等
			defaultSize: 1 << (uint)(i+minShift),
		}
		// 依次append
		p.pool = append(p.pool, slab)
	}

	return p
}

使用时，根据尺寸算出对应的 slot，从对应的 slot 返回该尺寸的 byte 数组：

https://github.com/mosn/mosn/blob/1609ae1441/vendor/mosn.io/pkg/buffer/bytebuffer_pool.go#L65

func (p *byteBufferPool) slot(size int) int {
	// 比如要获取 200 size 的 buffer
	if size > p.maxSize {
		return errSlot
	}
	slot := 0
	shift := 0
	if size > p.minSize {
		// size - 199
		// 位: 1100 0111,经过 8 次右移会<=0
		size--
		for size > 0 {
			size = size >> 1
			shift++
		}
		// slot = 8 - 6 = 2, 该 slot 的 defaultSize = 256
		slot = shift - p.minShift
	}

	return slot
}

https://github.com/mosn/mosn/blob/1609ae1441/vendor/mosn.io/pkg/buffer/bytebuffer_pool.go#L87

// take returns *[]byte from byteBufferPool
func (p *byteBufferPool) take(size int) *[]byte {
	slot := p.slot(size)
	if slot == errSlot {
		b := newBytes(size)
		return &b
	}
	// slot = 2, 
	v := p.pool[slot].pool.Get()
	if v == nil {
		// 如果 slot get 方法没有返回, new 一个
		b := newBytes(p.pool[slot].defaultSize)
		b = b[0:size]
		return &b
	}
	b := v.(*[]byte)
	// 调整切片长度为请求的 size
	*b = (*b)[0:size]
	return b
}

byte 数组使用完毕时，对应的就是将 byte 数组放回对应的 slot 里，这里比较好理解，各位可以自行看源码：

https://github.com/mosn/mosn/blob/1609ae1441/vendor/mosn.io/pkg/buffer/bytebuffer_pool.go#L106

这两处使用切片指针，主要考虑操作 sync.Pool 的 Get、Put 方法时避免参数拷贝问题。

IOBuffer

IOBuffer 及 IO buffer pool 就比较好理解了，主要是定义了与 IO 相关的接口，然后实现方法是基于上文 byte buffer 的使用方法的封装，即 read 是从 byte buffer 里读取、write 是将数据 copy 进 byte buffer。有了上文的基础，这里大家可以根据源码去看具体的实现，并不难。

https://github.com/mosn/mosn/blob/1609ae1441/vendor/mosn.io/pkg/buffer/types.go#L34

IO 相关的接口：

type IoBuffer interface {
	Read(p []byte) (n int, err error)

	ReadOnce(r io.Reader) (n int64, err error)

	Write(p []byte) (n int, err error)

	WriteString(s string) (n int, err error)

	WriteTo(w io.Writer) (n int64, err error)
	...

}

总结

本文根据 MOSN 的源码分析了 MOSN 对内存复用的设计和用法，其基于 sync.Pool 之上封装了一层自己的注册管理逻辑，增强了管理能力、易用性和复用性。

参考资料:

MOSN 源码

Blog: MOSN 源码解析 - Plugin 机制

Fri, 14 Feb 2020 00:00:00 +0000

概述

Plugin 机制是 MOSN 提供的一种方式，可以让 MOSN 和一个独立的进程进行交互，这个进程可以用任何语言开发，只要满足 gRPC 的 proto 定义。

为什么我们支持这个功能，跟我们遇到的一些业务场景有关：

比如 log 打印，在 io 卡顿的时候会影响 Go Runtime 的调度，导致请求延迟。我们需要把 log 独立成进程做隔离。
我们会有一些异构语言的扩展，比如 streamfilter 的实际逻辑是一个 Java 语言实现的。
我们需要快速更新一些业务逻辑，但不能频繁的去更新 MOSN 的代码。
作为类似 Supervisor 的管理工具，管理一些其他进程。

总结下来就是隔离性，支持异构语言扩展，模块化，进程管理等场景，大家也可以看看还有哪些场景可以用到。

使用方法

examples/codes/plugin/pluginfilter/提供了一个使用示例，通过 streamfilter 把数据传递给一个独立进程处理并反馈。
我们这儿简单看下pkg/plugin/example/：

client

	client, err := plugin.Register("plugin-server", nil)
	if err != nil {
		fmt.Println(err)
		return
	}
	response, err := client.Call(&proto.Request{
		Body: []byte("hello"),
	}, time.Second)
}

通过 plugin.Register注册一个 plugin，name 需要和编译的二进制名字一样，然后函数会去启动这个程序，这个程序就是下面的 server 代码。
调用 client.Call 发送请求给 server 进程，然后收到响应并处理。

server

type filter struct{}

func (s *filter) Call(request *proto.Request) (*proto.Response, error) {
	if string(request.GetBody()) != "hello" {
		return nil, errors.New("request body error")
	}

	response := new(proto.Response)
	response.Body = []byte("world")
	response.Status = 1
	return response, nil
}

func main() {
	plugin.Serve(&filter{})
}

首先实现 plugin.Service接口，Call 函数将接收 client 的请求，处理之后返回响应。
main函数执行plugin.Serve，运行服务监听 client 的请求。

运行

执行如下命令：

$ go build -o plugin-client client/plugin.go
$ go build -o plugin-server server/plugin.go
$ ./plugin-client  2> /tmp/1
success! response body: world

初始化

MOSN 的 plugin 底层使用了github.com/hashicorp/go-plugin库，该库是 HashiCorp 公司提供的一个成熟的扩展系统，可以方便的扩展自己的插件机制。

先看一下配置文件：

	"plugin": {
		"log_base": "/home/admin/mosn/logs/"
	}

log_base plugin 传递给扩展进程的日志目录

在看一下 proto 定义，Request 和 Resonse 定义了几个通用的数据结构，在使用的时候可以选择使用，比如打印 log 就需要使用 Request 的 boy 字段。Call 方法就是我们需要实现的，来进行请求的发送和处理处理。

syntax = "proto3";
package proto;

message Request {
	map<string, string> header=1;
	map<string, string> trailer=2;
	bytes body = 3;
	string type = 4;
}

message Response {
	map<string, string> header=1;
	map<string, string> trailer=2;
	bytes body = 3;
	int32 status = 4;
}

service Plugin {
	rpc Call(Request) returns (Response);
}

Client管理 client 的整个生命周期，用户使用该结构体发送请求。

// Client is a plugin client, It's primarily used to call request.
type Client struct {
	pclient  *plugin.Client
	config   *Config
	name     string
	fullName string
	service  *client
	enable   bool
	on       bool

	sync.Mutex
}

Config初始化 Client 的时候使用，MaxProcs表示独立进程的 GOMAXPROCS 配置，Args表示独立进程的启动参数。

type Config struct {
	MaxProcs int
	Args     []string
}

启动

Register用于 client 端注册 plugin，参数name表示 server 的二进制名字，文件路径同于 client 的二进制路径。返回的 Client 用于管理整个 agent-client 的生命周期。

// Register called by plugin client and start up the plugin main process.
func Register(name string, config *Config) (*Client, error) {
	pluginLock.Lock()
	defer pluginLock.Unlock()

	if c, ok := pluginFactories[name]; ok {
		return c, nil
	}
	c, err := newClient(name, config)
	if err != nil {
		return nil, err
	}
	pluginFactories[name] = c

	return c, nil
}

newClient生成 Client，其中最重要的是Check方法，用于启动 server。

首先把GOMAXPROCS和日志路径通过环境变量传递给server进程。
plugin.NewClient开启 plugin 框架之后， pclient.Client()启动 server 子进程。
rpcClient.Dispense("MOSN_SERVICE") 返回真正的实例 client。

client 的整个启动过程就完成了，主要就是启动了 server 子进程，然后初始化了 client GRPC 的实例，用于请求发送和接收。

func (c *Client) Check() error {
	.
	.
	cmd := exec.Command(c.fullName, c.config.Args...)

	procs := 1
	if c.config != nil && c.config.MaxProcs >= 0 && c.config.MaxProcs <= 4 {
		procs = c.config.MaxProcs
	}
	cmd.Env = append(cmd.Env, fmt.Sprintf("MOSN_PROCS=%d", procs))
	cmd.Env = append(cmd.Env, fmt.Sprintf("MOSN_LOGBASE=%s", pluginLogBase))

	pclient := plugin.NewClient(&plugin.ClientConfig{
		HandshakeConfig: Handshake,
		Plugins:         PluginMap,
		Cmd:             cmd,
		AllowedProtocols: []plugin.Protocol{
			plugin.ProtocolGRPC},
	})

	rpcClient, err := pclient.Client()
	if err != nil {
		return err
	}

	raw, err := rpcClient.Dispense("MOSN_SERVICE")
 .
 .
}

接下来是 server，server 端的代码也可以用其他语言实现，只要满足一定的规范，下面看看 Go 的实现：

首先执行checkParentAlive()主要是检查父进程(也就是 client )是否退出，如果退出了，自己也需要退出。
然后读取环境变量，来设置GOMAXPROCS。
最后调用plugin.Serve启动 GRPC Server 服务接收处理请求。

// Serve is a function used to serve a plugin. This should be ran on the plugin's main process.
func Serve(service Service) {
	checkParentAlive()

	p := os.Getenv("MOSN_PROCS")
	if procs, err := strconv.Atoi(p); err == nil {
		runtime.GOMAXPROCS(procs)
	}

	plugin.Serve(&plugin.ServeConfig{
		HandshakeConfig: Handshake,
		Plugins: map[string]plugin.Plugin{
			"MOSN_SERVICE": &Plugin{Impl: service},
		},
		GRPCServer: plugin.DefaultGRPCServer,
	})
}

server 最主要的就是实现Service接口，用于处理请求，之前的 exmple 就有一个简单的实现。

// Service is a service that Implemented by plugin main process
type Service interface {
	Call(request *proto.Request) (*proto.Response, error)
}

执行

client 只需要执行Call函数就可以发送和接收请求，实现会先通过Check()来检查 server 是否健康，如果不健康会先启动 server，然后调用真正的实现。

// Call invokes the function synchronously.
func (c *Client) Call(request *proto.Request, timeout time.Duration) (*proto.Response, error) {
	if err := c.Check(); err != nil {
		return nil, err
	}
	return c.service.Call(request, timeout)
}

首先设置 timeout 请求超时时间，然后在调用 GRPC 的接口发送请求。

func (c *client) Call(request *proto.Request, timeout time.Duration) (*proto.Response, error) {
	var ctx context.Context
	var cancel context.CancelFunc
	if timeout > 0 {
		ctx, cancel = context.WithTimeout(context.Background(), timeout)
		defer cancel()
	} else {
		ctx = context.Background()
	}
	response, err := c.PluginClient.Call(ctx, request)
	return response, err
}

在 server 端会直接执行我们实现的 Call 接口。

func (s *server) Call(ctx context.Context, req *proto.Request) (*proto.Response, error) {
	return s.Impl.Call(req)
}

管理

MOSN 提供了 HTTP 接口来查看 plugin 的运行状态，以及开启关闭 Plugin。

Usage:
/plugin?status=all
/plugin?status=pluginname
/plugin?enable=pluginname
/plugin?disable=pluginname

在 disable 之后，server 就会被关闭，并且不会再启动，主要为了防止 server 有问题的时候可以关闭掉。

总结

寄托于开源社区，我们方便的搭建了自己的扩展机制，MOSN 也把自己的想法反馈给社区，共同进步。

拥抱开源，反哺开源。

Blog: MOSN 源码解析 - XDS

Thu, 13 Feb 2020 00:00:00 +0000

本文的内容基于 MOSN v0.9.0。

XDS用来与pilot-discovery通讯做服务发现功能。

XDS是一类发现服务的总称，包含LDS， RDS， CDS， EDS以及SDS。

MOSN通过XDS API可以动态获取Listener（监听器），Route（路由）， Cluster（集群）， Endpoint（集群成员）以及Secret（证书）配置。

XDS的基本流程：Pilot-Discovery的Model -> XDS.pb -> GRPC -> XDS.pb -> MOSN的Model （GRPC包括序列化和网络传输）。

配置文件&解析

if len(DynamicResources) > 0 && len(StaticResources) > 0 进入XDS模式。

XDS模式下的MOSN配置文件mosn_config.json:

{
  "dynamic_resources": {
    "lds_config": {
      "ads": {}
    },
    "cds_config": {
      "ads": {}
    },
    "ads_config": {
      "api_type": "GRPC",
      "cluster_names": ["xxx"],
      "grpc_services": [
        {
          "envoy_grpc": {
            "cluster_name": "xds-grpc"
          }
        }
      ]
    }
  },
  "static_resources": {
    "clusters": [
      {
        "name": "xds-grpc",
        "type": "STRICT_DNS",
        "lb_policy": "RANDOM",
        "hosts": [
          {
            "socket_address": {"address": "istio-pilot.istio-system.svc.boss.twl", "port_value": 15010}
          }
        ],
        "http2_protocol_options": { }
      }
    ]
  }
}

解析配置文件构建XDSConfig（XDS客户端的配置）。

构建adsClient（XDS客户端）。

func (c *Client) Start(config *config.MOSNConfig) error {
	log.DefaultLogger.Infof("xds client start")

    //解析配置文件
	dynamicResources, staticResources, err := UnmarshalResources(config)
	if err != nil {
		log.DefaultLogger.Warnf("fail to unmarshal xds resources, skip xds: %v", err)
		return errors.New("fail to unmarshal xds resources")
	}
    
    //构建xdsConfig
	xdsConfig := v2.XDSConfig{}
	err = xdsConfig.Init(dynamicResources, staticResources)
	if err != nil {
		log.DefaultLogger.Warnf("fail to init xds config, skip xds: %v", err)
		return errors.New("fail to init xds config")
	}

    //构建adsCLient
	stopChan := make(chan int)
	sendControlChan := make(chan int)
	recvControlChan := make(chan int)
	adsClient := &v2.ADSClient{
		AdsConfig:         xdsConfig.ADSConfig,
		StreamClientMutex: sync.RWMutex{},
		StreamClient:      nil,
		MosnConfig:        config,
		SendControlChan:   sendControlChan,
		RecvControlChan:   recvControlChan,
		StopChan:          stopChan,
	}
	adsClient.Start()
	c.adsClient = adsClient
	return nil
}

初始化和启动xds连接

adsClient.start()

func (adsClient *ADSClient) Start() {
    //构建grpc双向流连接。
	adsClient.StreamClient = adsClient.AdsConfig.GetStreamClient()
	utils.GoWithRecover(func() {
        //认证和开启xds传输，并且设置定时重传
		adsClient.sendThread()
	}, nil)
	utils.GoWithRecover(func() {
        //接受下发数据，并根据类型选择不同的handler处理
		adsClient.receiveThread()
	}, nil)
}

函数细节： https://github.com/mosn/mosn/blob/master/pkg/xds/v2/adssubscriber.go

XDS消息处理和发送

四种类型处理器注册。

func init() {
	RegisterTypeURLHandleFunc(EnvoyListener, HandleEnvoyListener)
	RegisterTypeURLHandleFunc(EnvoyCluster, HandleEnvoyCluster)
	RegisterTypeURLHandleFunc(EnvoyClusterLoadAssignment, HandleEnvoyClusterLoadAssignment)
	RegisterTypeURLHandleFunc(EnvoyRouteConfiguration, HandleEnvoyRouteConfiguration)
}

接受数据类型，将XDS类型转换成MOSN数据类型，并且加入对应的manager。

以HandlerListener为例：

func HandleEnvoyListener(client *ADSClient, resp *envoy_api_v2.DiscoveryResponse) {
	log.DefaultLogger.Tracef("get lds resp,handle it")
    //解析返回消息，生成envoy_listener
	listeners := client.handleListenersResp(resp)
	log.DefaultLogger.Infof("get %d listeners from LDS", len(listeners))
    //转换envoy_listener为mosn_listener，并且加入ListenerAdapter
	conv.ConvertAddOrUpdateListeners(listeners)
	if err := client.reqRoutes(client.StreamClient); err != nil {
		log.DefaultLogger.Warnf("send thread request rds fail!auto retry next period")
	}
}

函数细节： https://github.com/mosn/mosn/blob/master/pkg/xds/v2/default_handler.go

请求与处理流程简单所示，也可接受pilot-discovery的推送：

switch(type):
  case: cluster:
    接收cluster返回，根据clusterName请求Endpoints
  case: endpoint:
    接收Endpoints，请求Listener
  case: listener
    接受Listener，请求Routes
  case: router
    接受Routes

XDS类型转换

XDS.pd数据结构类型在： https://github.com/envoyproxy/go-control-plane

收到数据并反序列化为XDS的Model之后，进行结构体转换。

类型转换代码如下： https://github.com/mosn/mosn/blob/master/pkg/xds/conv/convertxds.go

Blog: MOSN 源码解析 - filter扩展机制

Sun, 09 Feb 2020 00:00:00 +0000

本文的内容基于 MOSN v0.9.0。

机制

使用过滤器模式来实现扩展是常见的设计模式，MOSN 也是使用了这种方式来构建可扩展性。

MOSN 把过滤器相关的代码放在了 pkg/filter 目录下：

➜  mosn git:(2c6f58c5) ✗ ll pkg/filter
total 24
drwxr-xr-x   8 mac  staff   256 Feb  5 08:52 .
drwxr-xr-x  30 mac  staff   960 Feb  5 08:52 ..
drwxr-xr-x   3 mac  staff    96 Aug 28 22:37 accept
-rw-r--r--   1 mac  staff  2556 Feb  5 08:52 factory.go
-rw-r--r--   1 mac  staff  2813 Feb  5 08:52 factory_test.go
drwxr-xr-x   6 mac  staff   192 Aug 28 22:37 network
drwxr-xr-x   7 mac  staff   224 Aug 28 22:37 stream
-rw-r--r--   1 mac  staff  1248 Feb  5 08:52 types.go
➜  mosn git:(2c6f58c5) ✗

包括 accept 过程的 filter，network 处理过程的 filter，以及 stream 处理的 filter。其中 accept filters 目前暂不提供扩展（加载、运行写死在代码里面，如要扩展需要修改源码）， steram、network filters 是可以通过定义新包在 pkg/filter 目录下实现扩展。

每一个 filter 包都会有一个 init 函数，拿 pkg/filter/network/proxy 包为例：

...

 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package proxy

import (
    ...
)

func init() {
	filter.RegisterNetwork(v2.DEFAULT_NETWORK_FILTER, CreateProxyFactory)
}

...

包被运行时会将 filter 注册到 filter factory 里，在必要时候，注册的回调函数（如例子里的 CreateProxyFactory）就会被调用。

加载 & 运行 filters

下面来详细看看 filters 被加载和运行的过程。

加载

我们可以看看，init 函数注册的回调函数是在什么时机被调用的：

mosn.io/mosn/pkg/filter/factory.go L57:

...
// CreateNetworkFilterChainFactory creates a StreamFilterChainFactory according to filterType
func CreateNetworkFilterChainFactory(filterType string, config map[string]interface{}) (types.NetworkFilterChainFactory, error) {
	if cf, ok := creatorNetworkFactory[filterType]; ok {
...

↓

mosn.io/mosn/pkg/config/parser.go L372:

...
// GetNetworkFilters returns a network filter factory by filter.Type
func GetNetworkFilters(c *v2.FilterChain) []types.NetworkFilterChainFactory {
	var factories []types.NetworkFilterChainFactory
	for _, f := range c.Filters {
		factory, err := filter.CreateNetworkFilterChainFactory(f.Type, f.Config)
...

可见，MOSN 在调用 config.GetNetworkFilters 会根据配置信息中 filter.Type 作为名字，在已注册的 filters 中找到需要加载的 filter，并返回 networkFilterChainFactory。可以看到， filter.Type 其实就是 init 函数调用时，包调用 filter.RegisterNetwork 函数的第一个参数：filter 名。

那么，配置信息又是从哪里来的呢？

来源1： 配置文件。

用户可以通过定义 MOSN 的 config.json，MOSN 启动时会根据 listener 指定的 filter 数组进行 filters 的初始化。

https://github.com/mosn/mosn/blob/0.9.0/pkg/mosn/starter.go#L173

func NewMosn(c *config.MOSNConfig) *Mosn {
    ...
  
    var nfcf []types.NetworkFilterChainFactory
  	var sfcf []types.StreamFilterChainFactory
  
    // Note: as we use fasthttp and net/http2.0, the IO we created in mosn should be disabled
    // network filters
  	if !lc.UseOriginalDst {
  	    // network and stream filters
        nfcf = config.GetNetworkFilters(&lc.FilterChains[0])
  		sfcf = config.GetStreamFilters(lc.StreamFilters)

    ...

来源2：XDS 信息解析。

MOSN 里的 XDS client 会将 XDS resources 解析成 MOSN 的 config，当 downstream client 连接进来的时候根据 config 进行组装需要用到的 filters。

https://github.com/mosn/mosn/blob/0.9.0/pkg/xds/conv/update.go#L71

// ConvertAddOrUpdateListeners converts listener configuration, used to  add or update listeners
func ConvertAddOrUpdateListeners(listeners []*envoy_api_v2.Listener) {
...
		var streamFilters []types.StreamFilterChainFactory
		var networkFilters []types.NetworkFilterChainFactory

		if !mosnListener.UseOriginalDst {
			for _, filterChain := range mosnListener.FilterChains {
				nf := config.GetNetworkFilters(&filterChain)
				networkFilters = append(networkFilters, nf...)
			}
			streamFilters = config.GetStreamFilters(mosnListener.StreamFilters)
...

所以，filters 的配置主要是来源于配置文件。

运行

filters 的配置是在 listener 之下的，配置解析会将每个 listener 配置声明要用到的 filters 初始化到 listener 实例里，在连接 accept 以及处理过程中，调用上文的函数初始化 filters 并调用。

MOSN 会将连接的上下文信息放在 context 内传给 filter，并将 stream 传给 filter。下面是代码流程：

(1) 连接 accept：

https://github.com/mosn/mosn/blob/0.9.0/pkg/server/handler.go#L394

func (al *activeListener) OnAccept(rawc net.Conn, useOriginalDst bool, oriRemoteAddr net.Addr, ch chan types.Connection, buf []byte) {
...
arc.ContinueFilterChain(ctx, true)

(2) 将连接上下文放入 context，并用以创建 filter chain，并初始化 filter manager，执行 filters 的 OnNewConnection 函数。 filter manager 是 filters 的代理，外部会在不同阶段调用 filter manager 的不同函数，filter manager 管理 filters 的执行逻辑：

https://github.com/mosn/mosn/blob/0.9.0/pkg/server/handler.go#L394

func (al *activeListener) OnAccept(rawc net.Conn, useOriginalDst bool, oriRemoteAddr net.Addr, ch chan types.Connection, buf []byte) {
    ...
   
    ctx := mosnctx.WithValue(context.Background(), types.ContextKeyListenerPort, al.listenPort)
    ctx = mosnctx.WithValue(ctx, types.ContextKeyListenerType, al.listener.Config().Type)
    ctx = mosnctx.WithValue(ctx, types.ContextKeyListenerName, al.listener.Name())
    ctx = mosnctx.WithValue(ctx, types.ContextKeyNetworkFilterChainFactories, al.networkFiltersFactories)
    ctx = mosnctx.WithValue(ctx, types.ContextKeyStreamFilterChainFactories, &al.streamFiltersFactoriesStore)
    ctx = mosnctx.WithValue(ctx, types.ContextKeyAccessLogs, al.accessLogs)
    if rawf != nil {
       ctx = mosnctx.WithValue(ctx, types.ContextKeyConnectionFd, rawf)
    }
    if ch != nil {
       ctx = mosnctx.WithValue(ctx, types.ContextKeyAcceptChan, ch)
       ctx = mosnctx.WithValue(ctx, types.ContextKeyAcceptBuffer, buf)
    }
    if oriRemoteAddr != nil {
       ctx = mosnctx.WithValue(ctx, types.ContextOriRemoteAddr, oriRemoteAddr)
    }
    ...

↓

https://github.com/mosn/mosn/blob/0.9.0/pkg/server/handler.go#L454

func (al *activeListener) OnNewConnection(ctx context.Context, conn types.Connection) {
    //Register Proxy's Filter
    filterManager := conn.FilterManager()
    for _, nfcf := range al.networkFiltersFactories {
    nfcf.CreateFilterChain(ctx, al.handler.clusterManager, filterManager)
    }
    filterManager.InitializeReadFilters()
...

(3) 执行 filter 的 OnData 方法

https://github.com/mosn/mosn/blob/0.9.0/pkg/network/connection.go#L428 ->

https://github.com/mosn/mosn/blob/0.9.0/pkg/network/connection.go#L484

func (c *connection) doRead() (err error) {
    ...
    c.onRead()
    ...

func (c *connection) onRead() {
    ...
    c.filterManager.OnRead()

至此，filter 就实现了对连接的干预，filter 就像中间件，可以返回 type.Continue 控制连接继续进行，也可以返回 type.Stop 停止连接继续处理。即可以对连接内容进行干预，比如在 static response 的场景，返回既定的 response 内容；也可以对连接处理流程进行干预，比如在 fault injection 的场景，增加连接延时，等等。

MOSN 实现了的 filters

根据文件目录我们可以看出 MOSN 目前实现了哪些 filter：


➜  mosn git:(2c6f58c5) ✗ ll pkg/filter/network
total 0
drwxr-xr-x   7 mac  staff  224 Aug 28 22:37 .
drwxr-xr-x   8 mac  staff  256 Feb  9 15:49 ..
drwxr-xr-x  3 mac  staff   96 Feb  8 10:35 connectionmanager // 连接管理
drwxr-xr-x  4 mac  staff  128 Feb  5 08:52 faultinject // 错误注入相关
drwxr-xr-x  3 mac  staff   96 Feb  9 12:37 proxy // 代理逻辑, 这个 filter 目前是 MONS 里的逻辑一部分, 负责将 stream 发送到 serverStream, 开启流量的代理
drwxr-xr-x  6 mac  staff  192 Feb  5 08:52 tcpproxy // tcp 代理逻辑

➜  mosn git:(2c6f58c5) ✗ ll pkg/filter/stream
total 0
drwxr-xr-x   7 mac  staff  224 Aug 28 22:37 .
drwxr-xr-x   8 mac  staff  256 Feb  9 15:49 ..
drwxr-xr-x  11 mac  staff  352 Feb  5 08:52 commonrule // stream filter 逻辑公共部分, rule engine 等等
drwxr-xr-x   6 mac  staff  192 Feb  5 08:52 faultinject // 错误注入相关
drwxr-xr-x   3 mac  staff   96 Aug 28 22:37 healthcheck // upstream 健康检查相关
drwxr-xr-x   3 mac  staff   96 Feb  5 08:52 mixer // mixer 逻辑相关
drwxr-xr-x   4 mac  staff  128 Feb  5 08:52 payloadlimit // 限流相关

具体每个 filter 的逻辑都可以根据下述的 filter 结构，进行代码跟读和调试，分别理解每个 filter 的作用。

filter 包含的内容 & 如何扩展 MOSN filters

一个 filter 包含以下内容：

init 函数，register 创建 filter manager 的回调函数
回调函数需要返回一个实现了 types.NetworkFilterChainFactory 接口的 struct
该 struct 的 CreateFilterChain 方法创建具体逻辑的实例，并调用 callback 参数的 addReadFilter | addWriteFilter 函数，进行 filter 注入到 filter manager
具体的业务逻辑

由此可见，通过 filter 机制扩展 MOSN，我们只需实现上述 4 样东西，与 MOSN 一同编译。再通过适当的 config 内容配置，或者与 XDS server 协作并生成含有你扩展的 filter 名及配置（这部分需要修改 MOSN 源码，MOSN 与 XDS server 交互并生成 config，选用哪些 filter 目前是写死在代码里的），MOSN 就会在适当时候加载并运行你的 filter，对代理流量进行干预。

总结

本文通过分析 MOSN 源码，简述了 MOSN 的filter扩展机制，并简述了实现自己的 filter 需要做的东西。大家可以通过该机制，使用 MONS 轻松 cover 自己具体的使用场景。

参考资料:

MOSN 源码

Blog: MOSN 源码浅析

Sun, 02 Feb 2020 00:00:00 +0000

前言

MOSN是基于Go开发的sidecar，用于service mesh中的数据面代理，建议先看下一个sidecar的自我修养对sidecar 的基本概念、原理有所了解。

手感

使用 MOSN 作为 HTTP 代理。

通过设置 log level 为debug，代码中加更多日志来辅助分析代码。本文主要以http-example 为例来分析。

基本使用

MOSN源码解析—配置详解。

mosn
    examples
        codes
            http-example
                // mosn start -c config.json 即可启动mosn
                config.json
                // golang 实现的一个简单的http server，直接go run server.go 即可启动
                server.go

使用http://localhost:8080 和 http://localhost:2345 都可以拿到数据。

配置理解

对应config.json 的内容如下。

{
    "servers": [
        {
            "default_log_path": "stdout", 
            "listeners": [
                {
                    "name": "serverListener", 
                    "address": "127.0.0.1:2046", 
                    "bind_port": true, 
                    "log_path": "stdout", 
                    "filter_chains": [
                        {}
                    ]
                }, 
                {
                    "name": "clientListener", 
                    "address": "127.0.0.1:2045", 
                    "bind_port": true, 
                    "log_path": "stdout", 
                    "filter_chains": [
                        {}
                    ]
                }
            ]
        }
    ], 
    "cluster_manager": {}, 
    "admin": {}
}

单拎出来 admin 部分， MOSN 监听34901 端口。

"admin": {
  "address": {
    "socket_address": {
      "address": "0.0.0.0",
      "port_value": 34901
    }
  }
}

访问http://localhost:34901/的返回结果。

support apis:
/api/v1/update_loglevel
/api/v1/enable_log
/api/v1/disbale_log
/api/v1/states
/api/v1/config_dump
/api/v1/stats

代码结构

几乎所有的 interface 定义在 pkg/types 中，MOSN 基于四层架构实现（见下文），每一个 layer 在 types 中有一个 go 文件，在pkg 下有一个专门的文件夹。

分层架构

一般的服务端编程，二级制数据经过协议解析为协议对应的model（比如HttpServletRequest）进而交给上层业务方处理，对于 MOSN：

协议上数据统一划分为 header/data/Trailers 三个部分，转发也是以这三个子部分为基本单位。
借鉴了http2 的stream 的理念（所以Stream interface 上有一个方法是ID()），Stream 可以理解为一个子Connection，Stream 之间可以并行请求和响应，通过StreamId关联，用来实现在一个Connection 之上的“多路复用”。PS：为了连接数量与请求数量解耦。

代码的组织（pkg/stream，pkg/protocol，pkg/proxy）跟上述架构是一致的。

pkg/types/connection.go Connection.
pkg/types/stream.go StreamConnection is a connection runs multiple streams.
pkg/types/stream.go Stream is a generic protocol stream
一堆listener 和filter 比较好理解：Method in listener will be called on event occur, but not effect the control flow.Filters are called on event occurs, it also returns a status to effect control flow. Currently 2 states are used: Continue to let it go, Stop to stop the control flow.
protocol 和 stream 两个layer 因和协议有关，不同协议之间实现差异很大，层次不是很清晰。
跨层次调用/数据传输通过跨层次struct 的“组合”来实现。也有一些特别的，比如http net/io 和 stream 分别启动goroutine read/write loop，通过共享数据来变相的实现跨层调用。

MOSN的核心概念解析。

MOSN 在 IO 层读取数据，通过 read filter 将数据发送到 Protocol 层进行 Decode。
Decode 出来的数据，根据不同的协议，回调到 stream 层，进行 stream 的创建和封装。
stream 创建完毕后，会回调到 Proxy 层做路由和转发，Proxy 层会关联上下游（upstream,downstream）间的转发关系。
Proxy 挑选到后端后，会根据后端使用的协议，将数据发送到对应协议的 Protocol 层，对数据重新做 Encode。
Encode 后的数据会经过 write filter 并最终使用 IO 的 write 发送出去。

一个请求可能会触发多次读取操作，因此单个请求可能会多次调用插件的onData 函数。

连接管理

该图主要说的连接管理部分。

不同颜色表示所处的 package 不同。
因为MOSN主要是的用途是“代理”，所以笔者一开始一直在找代理如何实现，但其实呢，MOSN 首先是一个tcp server，像tomcat一样，MOSN 主要分为连接管理和业务处理两个部分。
业务处理的入口就是filterManager，主要由filterManager.onRead 和 filterManager.onWrite 来实现。filterManager 聚合ReadFilter 链和WriterFilter链，构成对数据的处理。

Envoy 对应逻辑深入解读Service Mesh的数据面Envoy。

数据处理

一些细节：

SOFAMesh中的多协议通用解决方案x-protocol介绍系列(1)-DNS通用寻址方案

iptables在劫持流量时，除了将请求转发到localhost的Sidecar处外，还额外的在请求报文的TCP options 中将 ClusterIP 保存为 original dest。在 Sidecar （Istio默认是Envoy）中，从请求报文 TCP options 的 original dest 处获取 ClusterIP。
SOFAMesh中的多协议通用解决方案x-protocol介绍系列(2)-快速解码转发
1. 转发请求时，由于涉及到负载均衡，我们需要将请求发送给多个服务器端实例。因此，有一个非常明确的要求：就是必须以单个请求为单位进行转发。即单个请求必须完整的转发给某台服务器端实例，负载均衡需要以请求为单位，不能将一个请求的多个报文包分别转发到不同的服务器端实例。所以，拆包是请求转发的必备基础。
2. 多路复用的关键参数：RequestId。RequestId用来关联request和对应的response，请求报文中携带一个唯一的id值，应答报文中原值返回，以便在处理response时可以找到对应的request。当然在不同协议中，这个参数的名字可能不同（如streamid等）。严格说，RequestId对于请求转发是可选的，也有很多通讯协议不提供支持，比如经典的HTTP1.1就没有支持。但是如果有这个参数，则可以实现多路复用，从而可以大幅度提高TCP连接的使用效率，避免出现大量连接。稍微新一点的通讯协议，基本都会原生支持这个特性，比如SOFARPC，Dubbo，HSF，还有HTTP/2就直接內建了多路复用的支持。

我们可以总结到，对于Sidecar，要正确转发请求：

必须获取到destination信息，得到转发的目的地，才能进行服务发现类的寻址。
必须要能够正确的拆包，然后以请求为单位进行转发，这是负载均衡的基础。
可选的RequestId，这是开启多路复用的基础。

深入解读Service Mesh的数据面Envoy下文以Envoy 实现做一下类比用来辅助理解MOSN 相关代码的理念：

对于每一个Filter，都调用onData函数，咱们上面解析过，其中HTTP对应的ReadFilter是ConnectionManagerImpl，因而调用ConnectionManagerImpl::onData函数。ConnectionManager 是协议插件的处理入口，同时也负责对整个处理过程的流程编排。

数据“上传”

一次http1协议请求的处理过程。

绿色部分表示另起一个协程。

转发流程

Downstream stream, as a controller to handle downstream and upstream proxy flow downStream.OnReceive 逻辑。

func (s *downStream) OnReceive(ctx context.Context,..., data types.IoBuffer, ...) {
    ...
    pool.ScheduleAuto(func() {
        phase := types.InitPhase
        for i := 0; i < 10; i++ {
            s.cleanNotify()
            phase = s.receive(ctx, id, phase)
            switch phase {
            case types.End:
                return
            case types.MatchRoute:
                log.Proxy.Debugf(s.context, "[proxy] [downstream] redo match route %+v", s)
            case types.Retry:
                log.Proxy.Debugf(s.context, "[proxy] [downstream] retry %+v", s)
            case types.UpFilter:
                log.Proxy.Debugf(s.context, "[proxy] [downstream] directResponse %+v", s)
            }
        }
    }
}

downStream.receive 会根据当前所处的phase 进行对应的处理。

func (s *downStream) receive(ctx context.Context, id uint32, phase types.Phase) types.Phase {
    for i := 0; i <= int(types.End-types.InitPhase); i++ {
        switch phase {
        // init phase
        case types.InitPhase:
            phase++
        // downstream filter before route
        case types.DownFilter:
            s.runReceiveFilters(phase, s.downstreamReqHeaders, s.downstreamReqDataBuf, s.downstreamReqTrailers)
            phase++
        // match route
        case types.MatchRoute:
            s.matchRoute()
            phase++
        // downstream filter after route
        case types.DownFilterAfterRoute:
            s.runReceiveFilters(phase, s.downstreamReqHeaders, s.downstreamReqDataBuf, s.downstreamReqTrailers)
            phase++
        // downstream receive header
        case types.DownRecvHeader:
            //check not null
            s.receiveHeaders(s.downstreamReqDataBuf == nil && s.downstreamReqTrailers == nil)
            phase++
        // downstream receive data
        case types.DownRecvData:
            //check not null
            s.receiveData(s.downstreamReqTrailers == nil)
            phase++
        // downstream receive trailer
        case types.DownRecvTrailer:
            // check not null
            s.receiveTrailers()
            phase++
        // downstream oneway
        case types.Oneway:
            ...
        case types.Retry:
            ...
        case types.WaitNofity:
            ...
        // upstream filter
        case types.UpFilter:
            s.runAppendFilters(phase, s.downstreamRespHeaders, s.downstreamRespDataBuf, s.downstreamRespTrailers)
            // maybe direct response
            phase++
        // upstream receive header
        case types.UpRecvHeader:
            // send downstream response
            // check not null
            s.upstreamRequest.receiveHeaders(s.downstreamRespDataBuf == nil && s.downstreamRespTrailers == nil)
            phase++
        // upstream receive data
        case types.UpRecvData:
            // check not null
            s.upstreamRequest.receiveData(s.downstreamRespTrailers == nil)
            phase++
        // upstream receive triler
        case types.UpRecvTrailer:
            //check not null
            s.upstreamRequest.receiveTrailers()
            phase++
        // process end
        case types.End:
            return types.End
        default:
            return types.End
        }
    }
    return types.End
}

pkg/types/proxy.go 有phase 的定义。

phase	对应方法	执行逻辑（部分）
InitPhase
DownFilter	runReceiveFilters
MatchRoute	matchRoute
DownFilterAfterRoute	runReceiveFilters
DownRecvHeader	receiveHeaders	==> upstreamRequest.appendHeaders
DownRecvData	receiveData	==> upstreamRequest.appendData
DownRecvTrailer	receiveTrailers	==> upstreamRequest.appendTrailers()
Oneway/Retry/WaitNofity
UpFilter	runAppendFilters
UpRecvHeader	upstreamRequest.receiveHeaders	==> downStream.onUpstreamData
UpRecvData	upstreamRequest.receiveData	==> downStream.onUpstreamData
UpRecvTrailer	upstreamRequest.receiveTrailers	==> downStream.onUpstreamTrailers
End

上述流程才像是一个 proxy 层的活儿，请求转发到 upstream，从upstream 拿到响应，再转回给downStream。

与control plan 的交互

pkg/xds/v2/adssubscriber.go 启动发送线程和接收线程

func (adsClient *ADSClient) Start() {
    adsClient.StreamClient = adsClient.AdsConfig.GetStreamClient()
    utils.GoWithRecover(func() {
        adsClient.sendThread()
    }, nil)
    utils.GoWithRecover(func() {
        adsClient.receiveThread()
    }, nil)
}

定时发送请求。

func (adsClient *ADSClient) sendThread() {
    refreshDelay := adsClient.AdsConfig.RefreshDelay
    t1 := time.NewTimer(*refreshDelay)
    for {
        select {
        ...
        case <-t1.C:
            err := adsClient.reqClusters(adsClient.StreamClient)
            if err != nil {
                log.DefaultLogger.Infof("[xds] [ads client] send thread request cds fail!auto retry next period")
                adsClient.reconnect()
            }
            t1.Reset(*refreshDelay)
        }
    }
}

接收响应。

func (adsClient *ADSClient) receiveThread() {
    for {
        select {
    
        default:
            adsClient.StreamClientMutex.RLock()
            sc := adsClient.StreamClient
            adsClient.StreamClientMutex.RUnlock()
            ...
            resp, err := sc.Recv()
            ...
            typeURL := resp.TypeUrl
            HandleTypeURL(typeURL, adsClient, resp)
        }
    }
}

处理逻辑是事先注册好的函数。

func HandleTypeURL(url string, client *ADSClient, resp *envoy_api_v2.DiscoveryResponse) {
    if f, ok := typeURLHandleFuncs[url]; ok {
        f(client, resp)
    }
}
func init() {
    RegisterTypeURLHandleFunc(EnvoyListener, HandleEnvoyListener)
    RegisterTypeURLHandleFunc(EnvoyCluster, HandleEnvoyCluster)
    RegisterTypeURLHandleFunc(EnvoyClusterLoadAssignment, HandleEnvoyClusterLoadAssignment)
    RegisterTypeURLHandleFunc(EnvoyRouteConfiguration, HandleEnvoyRouteConfiguration)
}

以cluster 信息为例 HandleEnvoyCluster。

func HandleEnvoyCluster(client *ADSClient, resp *envoy_api_v2.DiscoveryResponse) {
    clusters := client.handleClustersResp(resp)
    ...
    conv.ConvertUpdateClusters(clusters)
    clusterNames := make([]string, 0)
    ...
    for _, cluster := range clusters {
        if cluster.GetType() == envoy_api_v2.Cluster_EDS {
            clusterNames = append(clusterNames, cluster.Name)
        }
    }
    ...
}

会触发ClusterManager 更新cluster。

func ConvertUpdateEndpoints(loadAssignments []*envoy_api_v2.ClusterLoadAssignment) error {
    for _, loadAssignment := range loadAssignments {
        clusterName := loadAssignment.ClusterName
        for _, endpoints := range loadAssignment.Endpoints {
            hosts := ConvertEndpointsConfig(&endpoints)
            clusterMngAdapter := clusterAdapter.GetClusterMngAdapterInstance()
            ...
            clusterAdapter.GetClusterMngAdapterInstance().TriggerClusterHostUpdate(clusterName, hosts); 
            ...
            
        }
    }
    return errGlobal
}

学到的

不要硬看代码，尤其对于多协程程序。

打印日志。
debug.printStack 来查看某一个方法之前的调用栈。
fmt.Printf("==> %T\n",xx) 如果一个interface 有多个“实现类” 可以通过%T 查看struct 的类型。

Blog: MOSN 社区成立

Sat, 28 Dec 2019 00:00:00 +0000

2019 年 12 月 28 日，杭州，在第 9 届 Service Mesh Meetup 上，MOSN 开源负责人肖涵（涵畅）宣布，MOSN 从 SOFAStack 社区中迁移出来，成立独立的 Github 组织 https://github.com/mosn，并作为独立项目运营，并开启 MOSN 开源社区。

同时公布了 MOSN 的 Roadmap，开启新的域名 mosn.io。

Blog: Nginx vs Envoy vs MOSN 平滑升级原理解析

Sat, 28 Dec 2019 00:00:00 +0000

前言

本文是对 Nginx、Envoy 及 MOSN 的平滑升级原理区别的分析，适合对 Nginx 实现原理比较感兴趣的同学阅读，需要具备一定的网络编程知识。

平滑升级的本质就是 listener fd 的迁移，虽然 Nginx、Envoy、MOSN 都提供了平滑升级支持，但是鉴于它们进程模型的差异，反映在实现上还是有些区别的。这里来探讨下它们其中的区别，并着重介绍 Nginx 的实现。

Nginx

相信有很多人认为 Nginx 的 reload 操作就能完成平滑升级，其实这是个典型的理解错误。实际上 reload 操作仅仅是平滑重启，并没有真正的升级新的二进制文件，也就是说其运行的依然是老的二进制文件。

Nginx 自身也并没有提供平滑升级的命令选项，其只能靠手动触发信号来完成。具体正确的操作步骤可以参考这里：Upgrading Executable on the Fly，这里只分析下其实现原理。

Nginx 的平滑升级是通过 fork + execve 这种经典的处理方式来实现的。准备升级时，Old Master 进程收到信号然后 fork 出一个子进程，注意此时这个子进程运行的依然是老的镜像文件。紧接着这个子进程会通过 execve 调用执行新的二进制文件来替换掉自己，成为 New Master。

那么问题来了：New Master 启动时按理说会执行 bind + listen 等操作来初始化监听，而这时候 Old Master 还没有退出，端口未释放，执行 execve 时理论上应该会报：Address already in use 错误，但是实际上这里却没有任何问题，这是为什么？

因为 Nginx 在 execve 的时候压根就没有重新 bind + listen，而是直接把 listener fd 添加到 epoll 的事件表。因为这个 New Master 本来就是从 Old Master 继承而来，自然就继承了 Old Master 的 listener fd，但是这里依然有一个问题：该怎么通知 New Master 呢？

环境变量。execve 在执行的时候可以传入环境变量。实际上 Old Master 在 fork 之前会将所有 listener fd 添加到 NGINX 环境变量：

ngx_pid_t
ngx_exec_new_binary(ngx_cycle_t *cycle, char *const *argv)
{
...
    ctx.path = argv[0];
    ctx.name = "new binary process";
    ctx.argv = argv;

    n = 2;
    env = ngx_set_environment(cycle, &n);
...
    env[n++] = var;
    env[n] = NULL;
...
    ctx.envp = (char *const *) env;

    ccf = (ngx_core_conf_t *) ngx_get_conf(cycle->conf_ctx, ngx_core_module);

    if (ngx_rename_file(ccf->pid.data, ccf->oldpid.data) == NGX_FILE_ERROR) {
       ...
        return NGX_INVALID_PID;
    }

    pid = ngx_execute(cycle, &ctx);

    return pid;
}

Nginx 在启动的时候，会解析 NGINX 环境变量：

static ngx_int_t
ngx_add_inherited_sockets(ngx_cycle_t *cycle)
{
...
    inherited = (u_char *) getenv(NGINX_VAR);
    if (inherited == NULL) {
        return NGX_OK;
    }
    if (ngx_array_init(&cycle->listening, cycle->pool, 10,
                       sizeof(ngx_listening_t))
        != NGX_OK)
    {
        return NGX_ERROR;
    }

    for (p = inherited, v = p; *p; p++) {
        if (*p == ':' || *p == ';') {
            s = ngx_atoi(v, p - v);
            ...
            v = p + 1;

            ls = ngx_array_push(&cycle->listening);
            if (ls == NULL) {
                return NGX_ERROR;
            }

            ngx_memzero(ls, sizeof(ngx_listening_t));

            ls->fd = (ngx_socket_t) s;
        }
    }
    ...
    ngx_inherited = 1;

    return ngx_set_inherited_sockets(cycle);
}

一旦检测到是继承而来的 socket，那就说明已经打开了，不会再继续 bind + listen 了：

ngx_int_t
ngx_open_listening_sockets(ngx_cycle_t *cycle)
{
    ...
    /* TODO: configurable try number */

    for (tries = 5; tries; tries--) {
        failed = 0;

        /* for each listening socket */

        ls = cycle->listening.elts;
        for (i = 0; i < cycle->listening.nelts; i++) {
        ...
            if (ls[i].inherited) {

                /* TODO: close on exit */
                /* TODO: nonblocking */
                /* TODO: deferred accept */

                continue;
            }
            ...

            ngx_log_debug2(NGX_LOG_DEBUG_CORE, log, 0,
                           "bind() %V #%d ", &ls[i].addr_text, s);

            if (bind(s, ls[i].sockaddr, ls[i].socklen) == -1) {
                ...
            }
            ...
        }
    }

    if (failed) {
        ngx_log_error(NGX_LOG_EMERG, log, 0, "still could not bind()");
        return NGX_ERROR;
    }

    return NGX_OK;
}

Envoy

Envoy 使用的是单进程多线程模型，其局限就是无法通过环境变量来传递 listener fd。因此 Envoy 采用的是 UDS（unix domain sockets）方案。当 New Envoy 启动完成后，会通过 UDS 向 Old Envoy 请求 listener fd 副本，拿到 listener fd 之后开始接管新来的连接，并通知 Old Envoy 终止运行。

file descriptor 是可以通过 sendmsg/recvmsg 来传递的。

MOSN

MOSN 的方案和 Envoy 类似，都是通过 UDS 来传递 listener fd。但是其比 Envoy 更厉害的地方在于它可以把老的连接从 Old MOSN 上迁移到 New MOSN 上。也就是说把一个连接从进程 A 迁移到进程 B，而保持连接不断！！！厉不厉害？听起来很简单，但是实现起来却没那么容易，比如数据已经被拷贝到了应用层，但是还没有被处理，怎么办？这里面有很多细节需要处理。它子所以能做到这种层面，靠的也是内核的 sendmsg/recvmsg 技术。

SCM_RIGHTS - Send or receive a set of open file descriptors from another process. The data portion contains an integer array of the file descriptors. The passed file descriptors behave as though they have been created with dup(2). http://linux.die.net/man/7/unix

这里有一个 Go 实现的小 Demo: tcp链接迁移。

对比

Nginx 的实现是兼容性最强的，因为 Envoy 和 MOSN 都依赖 sendmsg/recvmsg 系统调用，需要内核 3.5+ 支持。MOSN 的难度最高，算得上是真正的无损升级，而 Nginx 和 Envoy 对于老的连接，仅仅是实现 graceful shutdown，严格来说是有损的。这对于 HTTP(通过 Connection: close) 和 gRPC(GoAway Frame) 协议支持很友好，但是遇到自定义的 TCP 协议就抓瞎了。如果遇到客户端没有处理 close 异常，很容易发生 socket fd 泄露问题。

本文作者 ms2008，转载自Nginx vs Envoy vs Mosn 平滑升级原理解析。

Blog: MOSN 源码解析 - reconfig 机制

Sun, 24 Nov 2019 00:00:00 +0000

本文记录了对 MOSN 的源码研究，研究 MOSN 是如何做到平滑重启的。

本文的内容基于 MOSN v0.8.1。

我们先将被重启的 MOSN 进程称为 旧 MOSN，将重启并接管流量的进程成为 新 MOSN。

机制

MOSN 没有使用重新读取 config 文件的方法来实现 reconfig，而是通过 unix socket 作为进程间通信，并将旧进程的监听 fd 通过 socket 传过去，新 MOSN 接管 fd 并且重新读取 config，旧 MOSN 进行 gracefully shutdown，以达到 reconfig 和平滑重启的功能。

旧 MOSN

我们先从一个启动着的 MOSN 进程看起，看看它是如何被重启的。

MOSN 的 reconfig 逻辑在 server 包的 reconfigure.go 内。

MOSN 进程启动后，会创建一个叫 reconfig.sock 的 unix socket，创建一个协程，开始监听并往里面写入一个字节的内容，这时会出现写阻塞。一旦有另一个进程从 reconfig.sock 读取到这一个字节，旧 MOSN 便开始 reconfig 逻辑。

reconfig 逻辑:

当写阻塞结束，协程会尝试链接另一个 unix socket ：listen.sock
一旦链接上，负责 reconfig 的协程会将已经存在的 fd 从 listen.sock 发送，发送是通过 out-of-band 数据进行的。很显然，这个 listen.sock 是新的 MOSN 进程创建的，用来接收正在服务的 fd，接管并用以继续服务。

这里的 已经存在的 fd 包括两种:
- server listener fd，负责监听业务的 tcp 连接，对应 config.json 里的 servers 数组里的 listeners 数组里的 ip +端口
- service listener fd，控制相关的端口，比如 pprof、prometheus metrics export、admin 端口
发送完fd之后，旧 MOSN 会接收 listen.sock 的数据（由新 mosn 写入的数据，代表 fd 已接管完毕），并进入 gracefully shutdown 状态，不再接收新的链接，等已有请求处理完再关闭
旧 MOSN 有30秒时间处理完现存请求
30秒后，旧 mosn 关闭，链接由新 mosn 接管

新 MOSN

接下来是新 MOSN 的启动。有两个问题:

新 MOSN 是如何将旧 MOSN 的fd据为己有，并且接受数据的呢？
- 新 MOSN 通过 net.FileListener 方法对接受到的 fd 进行处理，该函数会返回 fd 的一个 network listener 副本，改副本可以用来接收数据，新 MOSN 就是通过这个操作来从旧 MOSN 做 fd 的接管
- 新 MOSN 会重新解析一遍 config.json 进行解析，而在上一部处理过的 network listener 副本也能查找到对应的地址和端口。通过比对两者相同之处，就能在创建新的 server listener 和 service listener 时，接管旧 MOSN 的 fd，用来初始化新的 listener。
新 MOSN 接收到 fd 信息后，会做些什么呢？
- 接管 server listener fd
- 接管 service listener fd
- 给 listen.sock 发送一个字节数据，通知旧 MOSN：可以关闭了
- 至此，MOSN reconfig 结束

后续疑问

新 MOSN 通过 net.FileListener 方法处理完 fd 并初始化了 listener，由于处理后的 fd 是一个副本，如果这个时候来了一个连接，那这个连接是会被旧 MOSN 处理到，还是新 MOSN，还是两者都会通知到呢? 关于这方面，可以做一个实验验证一下。

MOSN – MOSN 博客

Blog: MOSN 源码解析 - 启动流程（v0.4.0）

MOSN 简介

MOSN 启动流程

MOSN 的初始化

MOSN 的启动

beforeStart(): MOSN 启动前的最后一步

Start(): MOSN 正式启动

基本术语参考

参考资料

Blog: 以一次 RPC 请求为例探索 MOSN的 工作流程

1. 前言

2. RPC 场景下 MOSN 的工作机制

3. 全局视野下的 MOSN 工作流程

3.1 建立连接

3.2 Protocol 处理

3.3 Proxy 层处理

3.3.1 downStream 部分

3.3.2 upStream 部分

3.4 准备将响应写回客户端

4. 总结

Blog: MOSN 源码解析 - 启动流程

MOSN 启动入口

场景管理器

Application

阶段小结

详细分析

场景管理器的启动

启动逻辑详解

ParamsParsed 阶段

InitStage阶段

PreStartStage阶段

StartStage阶段

AfterStopStage阶段

Blog: MoE 系列[七] - Envoy Go 扩展之沙箱安全

沙箱安全

实现机制

未来

Blog: mosn基于延迟负载均衡算法 -- 走得更快，期待走得更稳

前言

什么是负载均衡

走得更快

延迟来自哪里

如何减少延迟

性能问题是局部的

PeakEWMA

P2C（Power of Two Choice）

模拟流量验证

期待走得更稳

快速失败的挑战

Blog: MoE 系列[六] - Envoy Go 扩展之并发安全

并发的原因

并发安全的实现

写 header 操作

读 header 操作

读写 data 操作

请求生命周期

最后

Blog: MoE 系列 [五] - Envoy Go 扩展之内存安全

三种安全

内存安全实现机制

复制时机

复制方式

最后

Blog: MoE 系列 [四] - Go 扩展的异步模式

异步模式

为什么需要

实现

测试

总结

Blog: MoE 系列 [三] - 使用 Istio 动态更新 Go 扩展配置

前提准备

安装 Istio

Istio 配置 Ingress

挂载 Golang so

开启 Basic auth 认证

测试

总结

Blog: MoE 系列 [二] - Golang 扩展从 Envoy 接收配置

Basic Auth

Blog: 以一次 RPC 请求为例探索 MOSN的工作流程

根据`CollectInterval`周期采集

根据`GC`周期采集