在诸如广告、推荐等系统中，我们往往会涉及过滤、召回和排序等过程。随着系统业务变得复杂，代码的耦合和交错会让项目跌入难以维护的深渊。于是模块化设计是复杂系统的必备基础。这篇文章介绍的业务框架脱胎于线上多人协作开发、高并发的竞价广告系统，在实践中不停被优化，直到易于理解和应用。

基础组件

Handler

在系统中，我们定义一个独立的业务逻辑为一个Handler。
比如过滤“机型”信息的逻辑可以叫做DeviceFilterHandler，排序的逻辑叫SortHandler。
Handler的实现也很简单，只要实现frame.HandlerBaseInterface接口和它对应的方法即可（见github）：

package main

import (
	"fmt"
	"ghgroups/frame"
	ghgroupscontext "ghgroups/frame/ghgroups_context"
	"reflect"
)

type ExampleHandler struct {
	frame.HandlerBaseInterface
}

func NewExampleHandler() *ExampleHandler {
	return &ExampleHandler{}
}

// ///
// ConcreteInterface
func (e *ExampleHandler) Name() string {
	return reflect.TypeOf(*e).Name()
}

// ///
// HandlerBaseInterface
func (e *ExampleHandler) Handle(*ghgroupscontext.GhGroupsContext) bool {
	fmt.Printf("run %s", e.Name())
	return true
}

ConcreteInterface

在系统中，我们要求每个组件都要有名字。这样我们可以在配置文件中指定它在流程中的具体位置。
组件通过继承接口ConcreteInterface，并实现其Name方法来暴露自己的名称。它可以被写死（如上例），也可以通过配置文件来指定（见后续案例）。

type ConcreteInterface interface {
	Name() string
}

HandlerBaseInterface

处理业务逻辑的代码需要在Handle(context *ghgroupscontext.GhGroupsContext) bool中实现的。上例中，我们只让其输出一行文本。
这个方法来源于HandlerBaseInterface接口。

type HandlerBaseInterface interface {
	ConcreteInterface
	Handle(context *ghgroupscontext.GhGroupsContext) bool
}

因为HandlerBaseInterface 继承自ConcreteInterface ，所以我们只要让自己构建的Handler继承自HandlerBaseInterface，并实现相应方法即可。

应用

一般一个复杂的业务不能只有一个Handler，但是为了便于方便讲解，我们看下怎么运行只有一个Handler的框架（见github）。

package main

import (
	"fmt"
	"ghgroups/frame"
	"ghgroups/frame/constructor"
	ghgroupscontext "ghgroups/frame/ghgroups_context"
	"ghgroups/frame/utils"
	"reflect"
)

func main() {
	constructor := utils.BuildConstructor("")
	constructor.Register(reflect.TypeOf(ExampleHandler{}))
	mainProcess := reflect.TypeOf(ExampleHandler{}).Name()
	run(constructor, mainProcess)
}

func run(constructor *constructor.Constructor, mainProcess string) {
	if err := constructor.CreateConcrete(mainProcess); err != nil {
		fmt.Printf("%v", err)
	}
	if someInterfaced, err := constructor.GetConcrete(mainProcess); err != nil {
		fmt.Printf("%v", err)
	} else {
		if mainHandlerGroup, ok := someInterfaced.(frame.HandlerBaseInterface); !ok {
			fmt.Printf("mainHandlerGroup %s is not frame.HandlerBaseInterface", mainProcess)
		} else {
			context := ghgroupscontext.NewGhGroupsContext(nil)
			// context.ShowDuration = true
			mainHandlerGroup.Handle(context)
		}
	}
}

在main函数中，我们需要向对象构建器constructor注册我们写的Handler。然后调用run方法，传入构建器和需要启动的组件名（mainProcess）即可。运行结果如下

ExampleHandler
run ExampleHandler

第一行是框架打印的流程图（目前只有一个），第二行是运行时ExampleHandler的Handle方法的执行结果。

HandlerGroup

HandlerGroup是一组串行执行的Handler。

框架底层已经实现好了HandlerGroup的代码，我们只要把每个Handler实现即可（Handler的代码可以前面的例子）。
然后在配置文件中，配置好Handler的执行顺序：

name: handler_group_a
type: HandlerGroup
handlers: 
  - ExampleAHandler
  - ExampleBHandler

应用

部分代码如下（完整见github）

package main

import (
	"fmt"
	"ghgroups/frame"
	"ghgroups/frame/constructor"
	constructorbuilder "ghgroups/frame/constructor_builder"
	"ghgroups/frame/factory"
	ghgroupscontext "ghgroups/frame/ghgroups_context"
	"os"
	"path"
	"reflect"
)

func main() {
	factory := factory.NewFactory()
	factory.Register(reflect.TypeOf(ExampleAHandler{}))
	factory.Register(reflect.TypeOf(ExampleBHandler{}))

	runPath, errGetWd := os.Getwd()
	if errGetWd != nil {
		fmt.Printf("%v", errGetWd)
		return
	}
	concretePath := path.Join(runPath, "conf")
	constructor := constructorbuilder.BuildConstructor(factory, concretePath)
	mainProcess := "handler_group_a"

	run(constructor, mainProcess)
}

这次对象构建器我们需要使用constructorbuilder.BuildConstructor去构建。因为其底层会通过配置文件所在的文件夹路径（concretePath ）构建所有的组件。而在此之前，需要告诉构建器还有两个我们自定义的组件（ExampleAHandler和ExampleBHandler）需要注册到系统中。于是我们暴露出对象工厂（factory ）用于提前注册。
运行结果如下

handler_group_a
        ExampleAHandler
        ExampleBHandler
run ExampleAHandler
run ExampleBHandler

前三行是配置文件描述的执行流程。后两行是实际执行流程中的输出。

AsyncHandlerGroup

AsyncHandlerGroup是一组并行执行的Handler。

和HandlerGroup一样，框架已经实现了AsyncHandlerGroup的底层代码，我们只用实现各个Handler即可。
有别于HandlerGroup，它需要将配置文件中的type设置为AsyncHandlerGroup。

name: async_handler_group_a
type: AsyncHandlerGroup
handlers: 
  - ExampleAHandler
  - ExampleBHandler

应用

使用的代码和HandlerGroup类似，具体见github。
执行结果如下

async_handler_group_a
        ExampleAHandler
        ExampleBHandler
run ExampleBHandler
run ExampleAHandler

Layer

Layer由两部分组成：Divider和Handler。Handler是一组业务逻辑，Divider用于选择执行哪个Handler。

Divider

不同于Handler，Divider需要继承和实现DividerBaseInterface接口。

type DividerBaseInterface interface {
	ConcreteInterface
	Select(context *ghgroupscontext.GhGroupsContext) string
}

Select方法用于填充业务逻辑，选择该Layer需要执行的Handler的名称。下面是Divider具体实现的一个样例（见github）。

package main

import (
	"ghgroups/frame"
	ghgroupscontext "ghgroups/frame/ghgroups_context"
	"reflect"
)

type ExampleDivider struct {
	frame.DividerBaseInterface
}

func NewExampleDivider() *ExampleDivider {
	return &ExampleDivider{}
}

// ///
// ConcreteInterface
func (s *ExampleDivider) Name() string {
	return reflect.TypeOf(*s).Name()
}

// ///
// DividerBaseInterface
func (s *ExampleDivider) Select(context *ghgroupscontext.GhGroupsContext) string {
	return "ExampleBHandler"
}

应用

每个Layer都要通过配置文件来描述其组成。相较于HandlerGroup，由于它不会执行所有的Handler，而是要通过Divider来选择执行哪个Handler，于是主要是新增Divider的配置项。

name: layer_a
type: Layer
divider: ExampleDivider
handlers: 
  - ExampleAHandler
  - ExampleBHandler

具体执行的代码见github。我们看下运行结果

layer_a
        ExampleDivider
        ExampleAHandler
        ExampleBHandler
run ExampleBHandler

可以看到它只是执行了Divider选择的ExampleBHandler。

LayerCenter

LayerCenter是一组串行执行的Layer的组合。

在使用LayerCenter时，我们只要实现好每个Layer，然后通过配置文件配置它们的关系即可。

type: LayerCenter
name: layer_center
layers: 
  - layer_a
  - layer_b

应用

具体代码和前面类似，可以见github。
运行结果如下

layer_center
        layer_a
                ExampleADivider
                ExampleA1Handler
                ExampleA2Handler
        layer_b
                ExampleBDivider
                ExampleB1Handler
                ExampleB2Handler
run ExampleA2Handler
run ExampleB1Handler

可以看到每个Layer选择了一个Handler执行。

源码见github。