1.Koa洋葱模型 从理解到实现
2.Spark-Submit 源码剖析
3.Golang-gin框架中间件原理
4.Koa 洋葱模型
Koa洋葱模型 从理解到实现
当使用Koa框架时,Middleware(中间件)的码查概念想必大家已不陌生。让我们从实例出发,询洋通过自定义两个中间件——logTime用于打印时间戳,葱溯logUrl负责打印路由——来探索Koa的洋葱源码洋葱模型。 在index.js中,码查游戏账号仓库源码我们按顺序使用这两个中间件。询洋启动服务并访问路由如/test,葱溯你会观察到两个现象:首先,洋葱源码你可能会疑惑:Koa的码查设计为何不按顺序从头到尾执行中间件?
其次,当中间件存在依赖关系时,询洋如何确保前面的葱溯中间件能利用后续中间件的操作结果?比如,logUrl可能处理了url并添加了时间戳,洋葱源码logTime需要获取并打印这个时间戳。码查
这些现象揭示了Koa洋葱模型的询洋设计原理:中间件的执行顺序是关键。外层(上游)中间件先执行,处理完后通过next函数传递控制权给内层(下游)中间件。github镜像源码这样可以确保每个中间件在适当的时机获取和操作数据,避免了单次链式调用时的依赖问题。 通过源码分析,我们发现Koa的实现依赖于`koa-compose`库,它负责管理中间件的执行流程。我们需要对中间件数组进行包装,以便在调用next时传递必要的上下文信息。通过`bind`方法,我们得以保留和传递必要的参数,实现洋葱模型的逻辑。 总结来说,我们从现象出发,通过实例和源码理解了Koa洋葱模型的必要性和工作方式。通过自定义实现,我们加深了对这一模型的理解。Spark-Submit 源码剖析
直奔主题吧:
常规Spark提交任务脚本如下:
其中几个关键的github测试源码参数:
再看下cluster.conf配置参数,如下:
spark-submit提交一个job到spark集群中,大致的经历三个过程:
代码总Main入口如下:
Main支持两种模式CLI:SparkSubmit;SparkClass
首先是checkArgument做参数校验
而sparksubmit则是通过buildCommand来创建
buildCommand核心是AbstractCommandBuilder类
继续往下剥洋葱AbstractCommandBuilder如下:
定义Spark命令创建的方法一个抽象类,SparkSubmitCommandBuilder刚好是实现类如下
SparkSubmit种类可以分为以上6种。SparkSubmitCommandBuilder有两个构造方法有参数和无参数:
有参数中根据参数传入拆分三种方式,然后通过OptionParser解析Args,构造参数创建对象后核心方法是通过buildCommand,而buildCommand又是通过buildSparkSubmitCommand来生成具体提交。
buildSparkSubmitCommand会返回List的命令集合,分为两个部分去创建此List,
第一个如下加入Driver_memory参数
第二个是通过buildSparkSubmitArgs方法构建的具体参数是MASTER,DEPLOY_MODE,FILES,CLASS等等,这些就和我们上面截图中是对应上的。是通过OptionParser方式获取到。
那么到这里的话buildCommand就生成了一个完成sparksubmit参数的命令List
而生成命令之后执行的任务开启点在org.apache.spark.deploy.SparkSubmit.scala
继续往下剥洋葱SparkSubmit.scala代码入口如下:
SparkSubmit,kill,request都支持,keil源码输出后两个方法知识支持standalone和Mesos集群方式下。dosubmit作为函数入口,其中第一步是初始化LOG,然后初始化解析参数涉及到类
SparkSubmitArguments作为参数初始化类,继承SparkSubmitArgumentsParser类
其中env是测试用的,参数解析如下,parse方法继承了SparkSubmitArgumentsParser解析函数查找 args 中设置的--选项和值并解析为 name 和 value ,如 --master yarn-client 会被解析为值为 --master 的 name 和值为 yarn-client 的 value 。
这之后调用SparkSubmitArguments#handle(MASTER, "yarn-client")进行处理。
这个函数也很简单,根据参数 opt 及 value,设置各个成员的值。接上例,parse 中调用 handle("--master", "yarn-client")后,在 handle 函数中,master 成员将被赋值为 yarn-client。
回到SparkSubmit.scala通过SparkSubmitArguments生成了args,案例推理源码然后调用action来匹配动作是submit,kill,request_status,print_version。
直接看submit的action,doRunMain执行入口
其中prepareSubmitEnvironment初始化环境变量该方法返回一个四元 Tuple ,分别表示子进程参数、子进程 classpath 列表、系统属性 map 、子进程 main 方法。完成了提交环境的准备工作之后,接下来就将启动子进程。
runMain则是执行入口,入参则是执行参数SparkSubmitArguments
Main执行非常的简单:几个核心步骤
先是打印一串日志(可忽略),然后是创建了loader是把依赖包jar全部导入到项目中
然后是MainClass的生成,异常处理是ClassNotFoundException和NoClassDeffoundError
再者是生成Application,根据MainClass生成APP,最后调用start执行
具体执行是SparkApplication.scala,那么继续往下剥~
仔细阅读下SparkApplication还是挺深的,所以打算另外写篇继续深入研读~
Golang-gin框架中间件原理
什么是中间件
中间件是一个广泛的概念,其含义在不同领域有所不同。在bs/cs软件编程框架中,中间件可以理解为用于解耦业务和非业务代码的钩子函数,这些函数适用于所有或部分请求。
中间件的原理与钩子函数类似。在框架层面,程序运行到某个阶段会自动执行预设的函数,执行完毕后再回到跳出的那个阶段继续执行原函数。
在bs/cs开发中,为了在主体函数前后执行一些通用操作,常见的写法会预设一些钩子,如beforeXxxFunc、afterXxxFunc。但这只有两个函数,且是针对全局请求的。若要实现部分钩子函数针对某些请求,则需要做额外的业务外操作以达到目的。gin框架的中间件就解决了这些痛点。
中间件原理
原理1:每一条请求都处理自己所挂载的所有中间件和唯一主体函数。
普通的钩子函数如图所示:
优点:解耦了业务和非业务代码,非业务代码实现了统一封装使用。
缺点:若想针对某些主体函数不执行或执行其他beforeFunction,需要额外修改框架逻辑。
gin框架中间件如图:
优点:
原理2:洋葱模型。
洋葱模型,如图所示:
beforeFunc1和afterFunc1即是中间件1;afterFunc2和afterFunc2即是中间件2。
请求到来时从最外层开始执行中间件1,然后进入第二层,依次执行完所有中间件最后到达主体函数,接着再一层层往外走再次执行中间件2...中间件1...最后返回,有点像栈的概念。
gin中中间件的实现步骤1
首先,gin把中间件和主体函数统一定义为一个handleFunc。
源码:gin.go
不管是用use()方法注册中间件,还是用restful注册主体函数,类型都是HandlerFunc。
源码:routergroup.go
步骤2
把所有handleFunc装入一个数组或叫handleChain的东西。
步骤3
从handleChain的第一个元素开始执行,中间使用c.next、c.Abort等函数进行流程控制。
手动实现一个简单版本的中间件
运行结果:
Koa 洋葱模型
Koa 是一个轻量级的 web 框架,由 Express 的团队打造,旨在简化 web 应用与 API 开发。它利用 async 函数改进错误处理,没有固定中间件,而是提供便利方法构建服务端应用。
“洋葱模型”概念,通过一个简单的实例展示。输入 localhost:,控制台显示结果,中间件的执行顺序体现。Koa 中间件通过 next 函数分割,上半部分先执行,下半部分在后续中间件调用后执行。
实现洋葱模型的核心在于函数调用方法,自顶向下嵌套函数,形成类似结构。借助 JavaScript 事件循环机制,先执行同步代码,异步代码入队等待。调用父函数时,按序执行嵌套函数。
简版实现步骤:从第一个函数开始,依次将下个函数作为参数传入。这样,自底向上递归调用,最终只执行一次 next(),实现中间件链式调用。
Koa 洋葱模型的源码展示了核心逻辑,包括两关键点。另一种实现方式是逆序封装中间件,每次都将当前执行函数作为 next 参数传给前一个中间件,最终顺序执行所有中间件。