#boot
一直想把这个框架开源,今天日子比较特别,正好也没事,整理一下代码,把一些陈年烂代码该删的都删了,然后从私有库转到github
Boot的核心服务启动器,最早的时候是作为微服务框架而设计的,但随着不同项目的应用和框架设计思想的影响下,不断不断的重构成为今天这样子。
首先这个框架比较简陋,以至于啥都没有,就只管启动服务,这有点类似IOC,但是又不太一样,因为boot把服务看成插件,每个插件提供自己独特的服务,很多插件组装起来对外就是一个独立的微服务。
当然,既然是微服务,有一些东西必须是标准化的,比如传输协议,服务发现,监控等
######关于服务协议
boot使用的是GRPC作为服务协议,当然,您也可以换别的协议,毕竟,RPC也只是一个插件而已。
######关于服务注册与发现
在plugin的两个包里面可以看到有discovery和register两个包,分别是发现和注册的实现
第一版使用了Etcd来支撑服务注册和服务发现,
第二版改为consul作为服务中心,同时兼容etcd作为服务发现中心,其实里面问题挺多的,只是没时间去改,好比熔断等,直到最近整体要迁移到kubernetes中,所以做了第三版改进
第三版为了适应k8s+service mash,所以回归了最原始的dns方式,由service Mash来控制服务的访问,熔断等,其实这一版我是最满意的一版,因为结构最简单了。 (ps:在做架构的时候我习惯把流程设计得复杂一些,但是实现要求一定要简单,不要绕,毕竟开发人员在代码实现与沟通过程中还那么绕的话,代码就别想写好。) 其实serviceMash就是要消灭代码中的服务发现与注册,从系统层面来保证服务的动态变更与调用,正好我也就顺其自然的没有使用服务注册,但是服务发现还有的,不过也只是对dns的简单封装,当然如果有谁有兴趣优化一下k8s的服务发现组件,欢迎提交rp
######关于插件化
各种通用的数据库处理,队列处理等可以实现plugin.Plugin,然后作为一个插件注入到服务中。可以套用以下模版来生成服务:
import (
"context"
"github.com/coffeehc/base/log"
"github.com/coffeehc/boot/plugin"
"go.uber.org/zap"
"sync"
)
var service Service
var mutex = new(sync.RWMutex)
var name = ""
var scope = zap.String("scope",name)
func GetService()Service {
if service == nil{
log.Panic("Service没有初始化",scope)
}
return service
}
func EnablePlugin(ctx context.Context) {
if name == ""{
log.Panic("插件名称没有初始化")
}
mutex.Lock()
defer mutex.Unlock()
if service!=nil{
return
}
service = newService(ctx)
plugin.RegisterPluginByFast(name,nil,nil)
}
type Service interface {
}
func newService(ctx context.Context)Service {
xxx.EnablePlugin(ctx)
impl := &serviceImpl{
xxxService: xxx.GetService()
}
return impl
}
type serviceImpl struct {
xxxService xxx.Service
}
框架已经处理好了插件调用依赖,所以不会重复创建插件,但实际为了保证不重复创建插件是以上模版来保证的,之所为没有集成到Plugin里面去,主要是因为这里的服务都是单例模式,如果有的插件遇到不能使用单例的场景,或者更个性化的需求的时候,就可以通过修改模版创建的代码来实现自定义,这样灵活度更高。
那么基本上这个框架就这样,已经算比较稳定的一个版本,既然开源了,以后就尽量向下兼容来升级框架,代码很简单也很容易看懂,如果大家有兴趣的话,可以开issus提建议或者直接点rp丢过来。
说实话,我倒是很希望有一天boot能被精简成百来行代码,服务被更细粒度化,一切插件都被服务化,被弱化成less Service或者镜像化,或者成为低代码平台的组件等其他形态,那boot将会真正成为一个启动器,它将是应用组装的最后那一公里。
README写的很粗糙,慢慢改善