diff --git a/content/zh/blog/code/mosn-overview/index.md b/content/zh/blog/code/mosn-overview/index.md index 2cdab1fb..c3a58a99 100644 --- a/content/zh/blog/code/mosn-overview/index.md +++ b/content/zh/blog/code/mosn-overview/index.md @@ -15,7 +15,7 @@ aliases: "/zh/blog/code/mosn-overview" ## 模块能力 -首先是 MOSN 的 [启动流程](../mosn-startup/)，通过这篇文章，你可以了解 MOSN 的启动过程，包括配置解析，日志初始化，Xds 初始化，各子模块启动，AdminApi 初始化等能力，也介绍了普通启动和热升级启动的区别，对 MOSN 的平滑升级能力有一个初步的了解。 +首先是 MOSN 的 [启动流程](../mosn-startup/v1.6.0/)，通过这篇文章，你可以了解 MOSN 的启动过程，包括配置解析，日志初始化，Xds 初始化，各子模块启动。另外通过 [启动流程（v0.4.0）](../mosn-startup/v0.4.0/) 这篇文章针对 AdminApi 初始化等过程做了分析，同时也介绍了普通启动和热升级启动的区别，对 MOSN 的平滑升级能力有一个初步的了解。 [路由](../mosn-router/) 这个章节，你可以了解路由的配置解析，运行方式和动态路由等能力。 diff --git a/content/zh/blog/code/mosn-startup/_index.md b/content/zh/blog/code/mosn-startup/_index.md new file mode 100644 index 00000000..9549810f --- /dev/null +++ b/content/zh/blog/code/mosn-startup/_index.md @@ -0,0 +1,8 @@ +--- +title: MOSN 源码解析 - 启动流程 +linkTitle: MOSN 源码解析 - 启动流程 +date: 2020-02-26 +aliases: "/blog/posts/mosn-startup" +author: "[江鹏飞（鑫火信息）](https://github.com/joyme123)" +description: MOSN 源码解析之启动流程分析。 +--- \ No newline at end of file diff --git a/content/zh/blog/code/mosn-startup/hot-upgrade-reload-newmosn.svg b/content/zh/blog/code/mosn-startup/v0.4.0/hot-upgrade-reload-newmosn.svg similarity index 100% rename from content/zh/blog/code/mosn-startup/hot-upgrade-reload-newmosn.svg rename to content/zh/blog/code/mosn-startup/v0.4.0/hot-upgrade-reload-newmosn.svg diff --git a/content/zh/blog/code/mosn-startup/index.md b/content/zh/blog/code/mosn-startup/v0.4.0/index.md similarity index 99% rename from content/zh/blog/code/mosn-startup/index.md rename to content/zh/blog/code/mosn-startup/v0.4.0/index.md index 7ef5f232..bf1cc43d 100644 --- a/content/zh/blog/code/mosn-startup/index.md +++ b/content/zh/blog/code/mosn-startup/v0.4.0/index.md @@ -1,10 +1,11 @@ --- -title: MOSN 源码解析 - 启动流程 -linkTitle: MOSN 源码解析 - 启动流程 +title: MOSN 源码解析 - 启动流程（v0.4.0） +linkTitle: MOSN 源码解析 - 启动流程（v0.4.0） date: 2020-02-26 aliases: "/blog/posts/mosn-startup" +weight: 2 author: "[江鹏飞（鑫火信息）](https://github.com/joyme123)" -description: MOSN 源码解析之启动流程分析。 +description: MOSN 源码解析之启动流程分析基于v0.4.0版本。 --- 本文的目的是分析 MOSN 的启动流程。基于 mosn 版本 v0.4.0，commit 为: dc35c8fc95435a47e6393db1c79dd9f60f7eb898 diff --git a/content/zh/blog/code/mosn-startup/normal-newmosn.svg b/content/zh/blog/code/mosn-startup/v0.4.0/normal-newmosn.svg similarity index 100% rename from content/zh/blog/code/mosn-startup/normal-newmosn.svg rename to content/zh/blog/code/mosn-startup/v0.4.0/normal-newmosn.svg diff --git a/content/zh/blog/code/mosn-startup/transfer-conn.svg b/content/zh/blog/code/mosn-startup/v0.4.0/transfer-conn.svg similarity index 100% rename from content/zh/blog/code/mosn-startup/transfer-conn.svg rename to content/zh/blog/code/mosn-startup/v0.4.0/transfer-conn.svg diff --git a/content/zh/blog/code/mosn-startup/v1.6.0/index.md b/content/zh/blog/code/mosn-startup/v1.6.0/index.md new file mode 100644 index 00000000..54be5cca --- /dev/null +++ b/content/zh/blog/code/mosn-startup/v1.6.0/index.md @@ -0,0 +1,295 @@ +--- +title: MOSN 源码解析 - 启动流程 +linkTitle: MOSN 源码解析 - 启动流程 +date: 2023-12-17 +aliases: "/blog/posts/mosn-startup/v1.6.0" +weigth: 1 +author: "[wp500](https://github.com/wang55www)" +description: MOSN 源码解析基于v1.6.0版本 +--- + +本文基于 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_ 应用，该对象定义如下： + +```go +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 的生命周期，后面的逻辑都是围绕着这个对象来编码的，定义如下： + +```go +// 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 根据这些周期的变化，同时回调切换场景的函数。 + +### 阶段小结 + +到这里先不着急往下看启动逻辑，我们先总结一下目前掌握的内容及背后的设计思路，这样后面梳理逻辑会变得很轻松。 +![关联关系图.png](objectRel.png)
+如上图所示，Application 应用（其实就是 _Mosn_ 本身）包含若干方法：初始化、启动、停止。这些方法调用后让应用进入不同的生命周期，同时场景管理器 （StageManager）维护的场景状态也对应发生改变，应用生命周期与场景二者是有关联关系的。 + +那么先不看源码只凭借猜测，到底是应用的生命周期发生变化后触发场景改变状态；还是先触发场景改变状态进而触发应用改变生命周期呢？我的猜测是这样，因为上文提到场景管理器（StageManager）用来管理应用的生命周期，StageManager 结构体中也包含 Application 对象。那么很大的可能是先由场景管理来触发状态改变，再触发应用对应的方法来改变生命周期。 + +其实因为场景的状态有11个粒度要比应用的生命周期粒度更细，从这点上来看也只可能场景状态（细粒度）切换同时调用应用的方法切换生命周期（粗粒度），而反之行不通（粗粒度的一方无法识别什么时候调用细粒度一方）。 + +既然我猜测是 StageManager 场景来控制切换，那么肯定有对应的方法提供场景切换。这个时候我们再来看代码，发现确实存在这样的方法来证明我的猜测。下面是切换场景的方法：
![代码方法.png](methods.png) + +## 详细分析 + +### 场景管理器的启动 + +我们继续看一下 stage_manager.go 的 _Run()_ 方法，可以清楚的看到场景管理器的启动逻辑，就是调用了不同子阶段，每个阶段都会有切换状态的逻辑，在方法的最后逻辑可以看到，启动之后设置场景状态为 Running。 + +```go +// 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()_ 方法执行了参数解析、初始化、启动前处理、启动、启动后处理等方法。我猜测每个方法一定是执行前文说的每个阶段对应的回调函数数组。找其中一个方法看一下逻辑，果然如我猜测一样。 + +```go +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_ 场景。每个过程都会调用若干场景切换。 + +```go +// 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_ 逻辑。 + +```go +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 的默认初始化，这部分逻辑非常的多。里面又细分很多步骤。这里我对每个方法都加上了注释，见下面代码段。 + +```go +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](https://github.com/mosn/holmes) + +### PreStartStage阶段 + +__func (stm *StageManager) AppendPreStartStage(f func(Application)) *StageManager__ + +这个阶段逻辑并不复杂，主要是启动 xds 客户端。 + +```go +// 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 的管理服务，通过配置文件进行启动。 + +```go +// 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 组件。 diff --git a/content/zh/blog/code/mosn-startup/v1.6.0/methods.png b/content/zh/blog/code/mosn-startup/v1.6.0/methods.png new file mode 100644 index 00000000..8e9dd135 Binary files /dev/null and b/content/zh/blog/code/mosn-startup/v1.6.0/methods.png differ diff --git a/content/zh/blog/code/mosn-startup/v1.6.0/objectRel.png b/content/zh/blog/code/mosn-startup/v1.6.0/objectRel.png new file mode 100644 index 00000000..72a6faa4 Binary files /dev/null and b/content/zh/blog/code/mosn-startup/v1.6.0/objectRel.png differ diff --git a/content/zh/blog/posts/_index.md b/content/zh/blog/posts/_index.md index cba9c5ef..ebbdeb73 100644 --- a/content/zh/blog/posts/_index.md +++ b/content/zh/blog/posts/_index.md @@ -2,5 +2,5 @@ title: "分享" linkTitle: "分享" weight: 30 -aliases: “/zh/blog/posts" +aliases: "/zh/blog/posts" --- diff --git a/content/zh/blog/posts/mosn-dubbo-go-hessian2/index.md b/content/zh/blog/posts/mosn-dubbo-go-hessian2/index.md index 4b609a2a..e52f9ad3 100644 --- a/content/zh/blog/posts/mosn-dubbo-go-hessian2/index.md +++ b/content/zh/blog/posts/mosn-dubbo-go-hessian2/index.md @@ -4,7 +4,7 @@ linkTitle: "记一次在 MOSN 对 Dubbo、dubbo-go-hessian2 的性能优化" date: 2020-06-02 author: "[商宗海](https://github.com/zonghaishang)" description: "本文会重点描述在基于 Go 语言库 dubbo-go-hessian2 、Dubbo 协议中对 MOSN 所做的性能优化。" -aliases: “/zh/blog/posts/mosn-dubbo-go-hessian2" +aliases: "/zh/blog/posts/mosn-dubbo-go-hessian2" --- 蚂蚁集团内部对 Service Mesh 的稳定性和性能要求是比较高的，内部 MOSN 广泛用于生产环境。在云上和开源社区，RPC 领域 Dubbo 和 Spring Cloud 同样广泛用于生产环境，我们在 MOSN 基础上，支持了 Dubbo 和 spring cloud 流量代理。我们发现在支持 Dubbo 协议过程中，经过 Mesh 流量代理后，性能有非常大的性能损耗，在大商户落地 Mesh 中也对性能有较高要求，因此本文会重点描述在基于 Go 语言库 [dubbo-go-hessian2](https://github.com/apache/dubbo-go-hessian2) 、Dubbo 协议中对 [MOSN](https://github.com/mosn/mosn) 所做的性能优化。 diff --git a/content/zh/blog/posts/mosn-dubbo-integrate/index.md b/content/zh/blog/posts/mosn-dubbo-integrate/index.md index 9d917ccd..7c393876 100644 --- a/content/zh/blog/posts/mosn-dubbo-integrate/index.md +++ b/content/zh/blog/posts/mosn-dubbo-integrate/index.md @@ -4,7 +4,7 @@ linkTitle: "在 MOSN 中玩转 dubbo-go" date: 2020-06-15 author: "[曹春晖](https://github.com/cch123)" description: "本文主要介绍怎么样在 MOSN 中集成 dubbo-go，来实现 dubbo 的服务发现。" -aliases: “/zh/blog/posts/mosn-dubbo-integrate" +aliases: "/zh/blog/posts/mosn-dubbo-integrate" --- ## Service Mesh 简介 diff --git a/content/zh/blog/posts/mosn-optimize-build-subset/index.md b/content/zh/blog/posts/mosn-optimize-build-subset/index.md index 89b2d5a9..31f2e91f 100644 --- a/content/zh/blog/posts/mosn-optimize-build-subset/index.md +++ b/content/zh/blog/posts/mosn-optimize-build-subset/index.md @@ -4,7 +4,7 @@ linkTitle: "构建 subset 优化" date: 2022-05-12 author: "[李旭东](https://github.com/dzdx)" description: "本文简述 Subset 的原理以及构建优化算法的前后对比" -aliases: “/zh/blog/posts/mosn-optimize-build-subset" +aliases: "/zh/blog/posts/mosn-optimize-build-subset" --- # 前言 diff --git a/content/zh/blog/posts/mosn-wasm-framework/index.md b/content/zh/blog/posts/mosn-wasm-framework/index.md index 864241f5..e98bc83f 100644 --- a/content/zh/blog/posts/mosn-wasm-framework/index.md +++ b/content/zh/blog/posts/mosn-wasm-framework/index.md @@ -4,7 +4,7 @@ linkTitle: "WebAssembly 在 MOSN 中的实践 - 基础框架篇" date: 2021-03-22 author: "[叶永杰](https://github.com/antJack)" description: "本文将着重叙述 MOSN 中的 Wasm 扩展框架，并介绍我们在 Proxy-Wasm 这一开源规范上的贡献。" -aliases: “/zh/blog/posts/mosn-wasm-framework" +aliases: "/zh/blog/posts/mosn-wasm-framework" --- 作为金融级服务网格中的流量代理组件，MOSN 在承载蚂蚁数十万服务容器之间流量的同时，也承载着诸多例如限流、鉴权、路由等中间件基础能力。这些能力以不同的扩展形式与 MOSN 运行于同一进程内。非隔离的运行方式在保障性能的同时，却也给 MOSN 带来了不可预知的安全风险。