为什么我要放弃 go-micro 框架?

后续:目前已通过传统grpc和grpc-gateway构建的差不多了,都很顺利,有空的时候会总结下gateway的搭建经验


English @Medium

为了快速上手微服务使用了 github 上比较火的框架 go-micro,但渐渐使用下来,到了必须摒弃的地步。

定位

  • 服务自动发现,不需要配置死 ip:port,直接通过 service-name 连接服务,期间支持负载均衡
  • 服务发现、协议编码、消息订阅,可以通过启动参数自由切换不同组件,如通过环境变量MICRO_REGISTRY切换MDNS/Consul/NATS

不爽

  • 要支持的服务,必须在 micro-plugin 已实现,无法跟随这些第三方库同步更新。每个库都有自己的特性,这样的强制统一,是以牺牲一部分可用性为代价的。
  • 然而随意切换插件,这个定位简直就是鸡肋,谁还会待着没事换不同插件玩?
  • 每个 Topic 都需要实例化一个 Broker,而希望的是直接一个函数,Topic 作为枚举类型的参数传递
  • micro-api 把所有的 RPC 方法都转换为了开放的 HTTP API,无法限制权限,比如发邮件,只是内部服务会调用的接口,不应该公开给用户。
  • 希望是 GRPC 接口只对内,额外配置 HTTP 的接口才对外,grpc-gateway 满足我的需求,但 micro 并不兼容(需要重复定义proto,见官方实例)

结论

所以 go-micro 用来练练手还可以,真是开发实际项目,简直像被捆绑了手脚,举步维艰。


现在我从原始的 grpc 开始搭建,再按照实际需求植入第三方插件,开发起来简直舒服多了~

你可能感兴趣的:(为什么我要放弃 go-micro 框架?)