https://github.com/TarsCloud/TarsGo

  • Tarsgo是基于Golang编程语言使用Tars协议的高性能RPC框架。随着docker,k8s,etcd等容器化技术的兴起，Go语言变得流行起来。Go的goroutine并发机制使Go非常适合用于大规模高并发后端服务程序的开发。 Go语言具有接近C/C++的性能和接近python的生产力。在腾讯，一部分现有的C++开发人员正逐渐向Go转型，Tars作为广泛使用的RPC框架，现已支持C++/Java/Nodejs/Php，其与Go语言的结合已成为大势所趋。因此，在广大用户的呼声中我们推出了Tarsgo,并且已经将它应用于腾讯地图、应用宝、互联网+以及其他项目中。

  • 关于tars的整体架构和设计理念，请阅读 Tars文档

    功能特性

  • Tars2go工具: tars文件自动生成并转换为go语言，包含用go语言实现的RPC服务端/客户端代码

  • go语言版本的tars的序列化和反序列化包
  • 服务端支持心跳上报，统计监控上报，自定义命令处理，基础日志
  • 客户端支持直接连接和路由访问，自动重新连接，定期刷新节点状态以及支持UDP/TCP协议
  • 提供远程日志
  • 提供特性监控上报
  • 提供set分组
  • 提供 protocol buffers 支持， 详见 pb2tarsgo

https://github.com/go-kratos/kratos

https://github.com/lesismal/arpc

cmux is a generic Go library to multiplex connections based on their payload. Using cmux, you can serve gRPC, SSH, HTTPS, HTTP, Go RPC, and pretty much any other protocol on the same TCP listener.
GoLang 的连接多路复用器：在同一端口上提供不同的服务！
cmux是一个通用的Go库，基于其有效载荷的多路复用连接。使用 cmux，您可以在同一 TCP 侦听器上使用 gRPC、SSH、HTTPS、HTTP、Go RPC 和几乎任何其他协议。
https://github.com/soheilhy/cmux

A standard library for microservices.
https://github.com/go-kit/kit

https://github.com/rsocket/rsocket-go
https://github.com/twitchtv/twirp
https://github.com/vaporz/turbo
https://github.com/smallnest/rpcx
https://github.com/asim/go-micro

一个用于构建分布式系统的工具集或者轻框架，支持 grpc 和 http ，支持多种注册中心 consul ，etcd , mdns 等。
https://github.com/Allenxuxu/stark

https://github.com/twitchtv/twirp
https://github.com/nats-rpc/nrpc

A Go framework for microservices
Kratos 一套轻量级 Go 微服务框架，包含大量微服务相关框架及工具。
https://github.com/go-kratos/kratos
https://go-kratos.dev

Principles

  • 简单：不过度设计，代码平实简单；
  • 通用：通用业务开发所需要的基础库的功能；
  • 高效：提高业务迭代的效率；
  • 稳定：基础库可测试性高，覆盖率高，有线上实践安全可靠；
  • 健壮：通过良好的基础库设计，减少错用；
  • 高性能：性能高，但不特定为了性能做 hack 优化，引入 unsafe ；
  • 扩展性：良好的接口设计，来扩展实现，或者通过新增基础库目录来扩展功能；
  • 容错性：为失败设计，大量引入对 SRE 的理解，鲁棒性高；

  • 工具链：包含大量工具链，比如 cache 代码生成，lint 工具等等；

    Features

  • APIs：协议通信以 HTTP/gRPC 为基础，通过 Protobuf 进行定义；

  • Errors：通过 Protobuf 的 Enum 作为错误码定义，以及工具生成判定接口；
  • Metadata：在协议通信 HTTP/gRPC 中，通过 Middleware 规范化服务元信息传递；
  • Config：支持多数据源方式，进行配置合并铺平，通过 Atomic 方式支持动态配置；
  • Logger：标准日志接口，可方便集成三方 log 库，并可通过 fluentd 收集日志；
  • Metrics：统一指标接口，可以实现各种指标系统，默认集成 Prometheus；
  • Tracing：遵循 OpenTracing 规范定义，以实现微服务链路追踪；
  • Encoding：支持 Accept 和 Content-Type 进行自动选择内容编码；
  • Transport：通用的 HTTP/gRPC 传输层，实现统一的 Middleware 插件支持；
  • Registry：实现统一注册中心接口，可插件化对接各种注册中心；

https://github.com/nats-rpc/nrpc
与 GRPC 模型相比，在 NATS的请求响应模型上执行 RPC 具有一些优势：

  • 最小的服务发现：客户端和服务器只需要知道NATS集群的终点。客户不需要发现他们依赖的单个服务的终点。
  • 负载平衡无需负载平衡器：无状态微服务可以多余托管并连接到相同的 NATS 聚类。然后，通过 NATS队列在这些请求中随机路由传入的请求。无需在每个微服务中设置（高可用性）负载平衡器。
  • 然而，午餐并不总是免费的。从规模上看，NATS集群本身可能成为瓶颈。无法提供流式处理和高级身份验证等 gRPC 功能。

https://github.com/TarsCloud/TarsGo