自己写的云原生微服务框架欢迎 star

[gl3081]

moke-kit

一个用于构建微服务/单体应用的基础框架。可以按照单体应用开发，生产环境部署为微服务模式。像玩 LEGO 积木一样，你可以按需灵活拼接不同类型的服务。

项目地址：

https://github.com/GStones/moke-kit

特性

• 使用 uber/fx 实现 IOC(依赖注入控制反转)，可以按需组装不同类型服务。
• 内置 TLS ，mTLS ，快速构建 Zero Trust 安全模型。
• 内置基于 Token 的认证，支持 JWT token 。
• 内置中间件(rate limit, open telemetry, auth middleware,logging, panic recovery 等)。
• 内置 Cache-Aside 模式数据缓存机制。
• 内置 Compare-and-swap 保证数据库操作的一致性。
• 内置交互式命令行客户端，方便独立测试服务接口。
• 基于 buf 一键生成 proto, grpc, gateway, swagger 和客户端的协议文件。

[awalkingman]

对 golnag 各种版本的依赖注入 PDST 了

[artiga033]

@awalkingman “java 开发者想在所有其他语言里面写 java“

golang,尤其是微服务场景 99%的情况根本就不需要什么 IoC 和 DI

[Kumo31]

"单体应用开发，微服务部署"，感觉想法有点像 Google 的 Service Weaver

[onion83]

PHP 就被 javaer 转行的拉死了 。。。

[129duckflew]

@onion83 我孤陋寡闻了，听说过 Java 转 Go 的 没听说过 Java 转 PHP 的

[gl3081]

@artiga033 微服务的每个服务抽象成一个 component ，可以被任何容器 inject ，那样微服务就可以自己拼接组合，方便复用，还是非常有用的

[RedisMasterNode]

简单问题复杂化...项目模块化做得够好就可以了，而且 Go 里面的 Interface 本身就是用于抽象实现的，不认为需要做什么依赖注入控制反转，如果觉得 Go 不适配这套玩法，为什么不直接用 Java 去实现呢

[gl3081]

@RedisMasterNode 这里说的是微服务中的每个服务，因为在微服务中服务数量比较多，管理起来太麻烦，如果有 IOC ，可以更好的分类组合，比较灵活适用用户规模：
* 本地开发所有服务注入到一个 monolith 容器中
* 测试环境可以按类型封装多个容器部署
* 生产环境部署拆分成多个 micro 容器打包 docker 镜像实现集群部署

[ZSeptember]

话说，不用依赖注入的，服务间调用咋搞的
全局变量吗还是一个一个手动传入构建 service

[gl3081]

@ZSeptember 是的，服务间互相调用用 IOC 也特别方便

[sophos]

已 star ，看上去还是要自己手动组合，感觉和我这个项目有点类似呀 :-)

https://github.com/go-kod/kod
https://github.com/go-kod/kod-mono

顺便说一句，依赖注入或者 IOC 并不是 java 专属
Go 用依赖注入其实相比 Java 其实舒服，因为编译和启动速度更快，更轻量
对于大型项目尤其是多人参与的业务项目，几乎是必备的，否则大概率就会慢慢沦为屎山

[gl3081]

@sophos 感谢大佬，同道中人

[bv]

可能是 Java 八股文把依赖注入问烂了，导致很多人听到依赖注入就不辨是非的厌恶。

宽泛来说：构造方法传参就是一种依赖注入的行为，无论是否用到依赖注入框架。

希望依赖注入框架自身保持最小依赖，少整花里胡哨超纲的功能，保持 KISS 原则。

[twogoods]

先点赞，service weaver 那一套吧，贡献给社区啊 最大做强；接下来可以写一套 java 的实现了这样 ioc 就没人喷了🤣

[gl3081]

@twogoods 感谢支持！ service weaver 之前没有听过，我研究下，请教下如何贡献给社区？

[twogoods]

@gl3081 #15 你没听过怎么会有 “可以按照单体应用开发，生产环境部署为微服务模式”这种想法的，这个最早不是 google 提的吗 然后开源了 service weaver

[gl3081]

@twogoods 确实没有听过，所有服务都是基于 IOC 思想，自然也就可以创建不同粒度的 main 容器来注入这些服务，也就实现了“可以按照单体应用开发，生产环境部署为微服务模式” 这种 feature ，moke-kit 还有更多的 feature ，欢迎体验

[GeekGao]

使用 Dapr 就行了，没必要造轮子了。

[gl3081]

@GeekGao 看了下 Dapr,确实很厉害，这是一个 sever mesh 的插件，应该类似于 istio 吧，moke-kit 更多的是提供了面向当前服务本身的一些解决方案

[RedisMasterNode]

@gl3081 这个东西对比单仓库维护多个微服务有什么好处呢...?不同微服务也可以有公共的包放在这个仓库里

[gl3081]

@RedisMasterNode git 仓库管理可以按照类型去分组，每个组一个仓库，每个仓库可以包含多个服务： https://juejin.cn/post/7384419675072856103

[RedisMasterNode]

@gl3081 对呀所以要依赖注入有什么好处呢

[gl3081]

@RedisMasterNode 多个仓库的多个服务，本地开发是否需要每个服务都启动？ moke-kit 可以将所有仓库的所有服务注入到一个 main 容器里面，执行一个 main 容器就会把所有服务启动，参考： https://github.com/moke-game/game/blob/main/cmd/game/main.go#L50 ，这是聚合了所有服务的一个 main 容器