Micro Api vs GateWay Api库

Micro Api

常用到的功能

  • Serve securely by default using ACME via Let’s Encrypt,Set TLS Certificate
  • 服务发现,负载平衡,热插拔后端的服务
  • 固定路由规则,对API的请求通过HTTP提供,并通过RPC进行内部路由
  • 鉴权,限流、熔断
  • 支持各种插件,但需要二次开发micro

问题

  • api网关:micro api --namespace=com.xinyan.beenest --type=debug PS:新版本问题:使用protobuf格式时,空数据会报错
  • go.micro.api 是通过 grpc+json 访问rpc服务,编码效率不高
  • 额外性能开销,多了一层服务,负载平衡 已经有阿里云SLB保证
  • 固定路由,不灵活,不支持自定义路由(我们的webhook就要用到自定义路由)
  • 只支持protobuf和json,处理文件上传比较麻烦
  • 鉴权,文档少,其中鉴权在 micro v2.6以上版本 强制加入,使用一脸懵逼。
  • 限流、熔断,文档少,还不知道用法,感觉不好针对服务定制策略
  • Micro Api层的错误,后端服务完全不知道,延时情况,日志不好追踪

Gateway Api库

优化思路

原架构:

graph LR browse(客户端) -- /customer/orders -->SLB("阿里云 SLB") SLB --> K8s("K8s Traefik") K8s --> micro("Micro API【Http+proto】") micro -- Customer.Orders --> A("Customer API【grpc+json】") A -- Get Customer --> AS("Customer Service【grpc+proto】") A -- Get Orders --> BS("Order Service【grpc+proto】") micro .-> B("Order API【grpc+json】") B .-> BS

SLB:高可用,负载均衡

SLB参考资料:https://www.cnblogs.com/qiujz/p/13265371.html img

LVS+keepalived实现高可用: https://blog.51cto.com/atong/1351709
img

角色 IP地址 备注
主LVS调度器(MASTER) 192.168.41.181 使用keepalived配置
备LVS调度器(BACKUP) 192.168.41.251
HTTP服务器(RS1) 192.168.41.31 apache服务器(一般生产环境需要外网 IP地址,这里用内网IP地址替代)
HTTP服务器(RS2) 192.168.41.33
虚拟IP地址(VIP) 192.168.41.249 虚拟IP地址

LVS负载均衡原理:https://blog.51cto.com/blief/1745134
wKiom1bTrTXCPxZFAACgh-_xgho912

Traefik:K8s对外暴露内部服务,负载均衡 调用内部服务

img

优化方案:

将Micro API分别合并到Customer API、Order API、Message API。

graph LR browse(客户端) -- /customer/orders -->SLB("阿里云 SLB") SLB --> K8s("K8s Traefik") K8s -- /customer/orders --> A("Customer API【Http+proto】") K8s .-> B("Order API【Http+proto】") A -- Get Customer --> AS("Customer Service【grpc+proto】") A -- Get Orders --> BS("Order Service【grpc+proto】") B .-> BS

好处:

  • api网关:micro api --namespace=com.xinyan.beenest --type=debug PS:新版本问题:使用protobuf格式时,空数据会报错 (自己实现的,没这个问题)

  • 额外性能开销,多了一层服务,负载平衡 已经有阿里云SLB保证(不用Micro Api,自然就少了一层)

  • 改动少量代码,GRpc => Http,优先匹配自定义路由,然后再匹配固定路由:

    func main() {
        xconfig.AddModule("data", "file")
    
        // New Service
        service := micro.NewService(
            micro.Name(meet.Name.ApiGeneral()),
            micro.Version("latest"),
        )
    
        excludeList := []string{"General.UploadCallback", "General.HandlerWebHook", "General.CheckVersion", "General.TestApi", "General.ReportErr", "General.FileScanCallback"}
        // Initialise service
        service.Init(
            micro.WrapHandler(auth.AuthWrapper(excludeList)),
            micro.WrapHandler(xvalidator.ValidatorWrapper()),
        )
    
        // global 要放在最后面
        global.InitMicroService(service)
        defer global.OnExit(recover())
    
        h := handler.NewGeneral()
        _ = general.RegisterGeneralHandler(service.Server(), h)
      // general.IService().SetRecoverHandler(global.LogErrorInState) // 绕过server grpc的recover
        //if err := service.Run(); err != nil {
        //    log.Fatal(err.Error())
        //}
    
        ws := gateway.InitWeb(service, h, general.IService())
      // 自定义路由 /webhook/token_xxxxxxx/
        ws.HandleFunc("/webhook/", func(writer http.ResponseWriter, request *http.Request) {})
        if err := ws.Run(); err != nil {
            log.Fatal(err.Error())
        }
    }
    
  • 除了支持protobuf和json,也方便处理文件上传

  • 限流、鉴权,使用自己最熟悉的micro.WrapHandler自定义实现

  • 熔断,可以用micro.WrapClient自定义实现

  • Micro Api层的错误,后端服务完全不知道,延时情况,日志不好追踪

不足之处:

每增加一个Api服务,需要配置多一个Nginx反向代理规则; 而Micro Api可以只配置一次Micro Api的反向代理,后续通过服务发现找到Api服务。

Copyright © xinyan all right reserved,powered by Gitbook该文件修订时间: 2020-08-03 20:48:42

results matching ""

    No results matching ""