golang微服务框架Kratos使用

最新推荐文章于 2024-11-08 23:30:01 发布

luslin1711

最新推荐文章于 2024-11-08 23:30:01 发布

阅读量6.3k

点赞数 3

分类专栏：后端 go 分布式文章标签：分布式 go

本文链接：https://blog.csdn.net/luslin1711/article/details/106192095

版权

本文介绍了Go语言的微服务框架Kratos，它提供了完整的微服务研发体验，包括Quick start、HTTP Blademaster、gRPC Warden、Config、错误码处理和日志管理等。Blademaster旨在解决服务安全性、日志记录等问题，而Warden则集成trace、log、prom组件，实现服务发现和负载均衡。Kratos还提供了错误码注册和Log库，以支持高性能的日志记录。

摘要由CSDN通过智能技术生成

简介

项目地址：https://github.com/go-kratos/kratos
项目致力于提供完整的微服务研发体验，整合相关框架及工具后，微服务治理相关部分可对整体业务开发周期无感，从而更加聚焦于业务交付。对每位开发者而言，整套Kratos框架也是不错的学习仓库，可以了解和参考到bilibili在微服务方面的技术积累和经验。

Quick start

Requirments

Go version>=1.13

Installation

GO111MODULE=on && go get -u github.com/go-kratos/kratos/tool/kratos
cd $GOPATH/src
kratos new kratos-demo

通过 kratos new 会快速生成基于kratos库的脚手架代码，如生成 kratos-demo
Build & Run

cd kratos-demo/cmd
go build
./cmd -conf ../configs

打开浏览器访问：http://localhost:8000/kratos-demo/start，你会看到输出了Golang 大法好！！！
项目结构

├── api
│   ├── api.bm.go
│   ├── api.pb.go
│   ├── api.proto
│   └── client.go
├── CHANGELOG.md
├── cmd
│   └── main.go
├── configs
│   ├── application.toml
│   ├── db.toml
│   ├── grpc.toml
│   ├── http.toml
│   ├── memcache.toml
│   └── redis.toml
├── internal
│   ├── dao
│   │   ├── dao.bts.go
│   │   ├── dao.go
│   │   ├── dao_test.go
│   │   ├── db.go
│   │   ├── mc.cache.go
│   │   ├── mc.go
│   │   ├── redis.go
│   │   ├── wire_gen.go
│   │   └── wire.go
│   ├── di
│   │   ├── app.go
│   │   ├── wire_gen.go
│   │   └── wire.go
│   ├── model
│   │   └── model.go
│   ├── server
│   │   ├── grpc
│   │   │   └── server.go
│   │   └── http
│   │       └── server.go
│   └── service
│       └── service.go
├── OWNERS
├── README.md
└── test
    ├── 0_db.sql
    ├── 1_data.sql
    ├── application.toml
    ├── db.toml
    ├── docker-compose.yaml
    ├── grpc.toml
    ├── http.toml
    ├── memcache.toml
    └── redis.toml

参考：

在test中docker-compose.yaml可在本机创建mysql，redis， memcached 数据库

docker-compose up -d

http blademaster

在像微服务这样的分布式架构中，经常会有一些需求需要你调用多个服务，但是还需要确保服务的安全性、统一化每次的请求日志或者追踪用户完整的行为等等。要实现这些功能，你可能需要在所有服务中都设置一些相同的属性，虽然这个可以通过一些明确的接入文档来描述或者准入规范来界定，但是这么做的话还是有可能会有一些问题：

你很难让每一个服务都实现上述功能。因为对于开发者而言，他们应当注重的是实现功能。很多项目的开发者经常在一些日常开发中遗漏了这些关键点，经常有人会忘记去打日志或者去记录调用链。但是对于一些大流量的互联网服务而言，一个线上服务一旦发生故障时，即使故障时间很小，其影响面会非常大。一旦有人在关键路径上忘记路记录日志，那么故障的排除成本会非常高，那样会导致影响面进一步扩大。
事实上实现之前叙述的这些功能的成本也非常高。比如说对于鉴权（Identify）这个功能，你要是去一个服务一个服务地去实现，那样的成本也是非常高的。如果说把这个确保认证的责任分担在每个开发者身上，那样其实也会增加大家遗忘或者忽略的概率。

为了解决这样的问题，你可能需要一个框架来帮助你实现这些功能。比如说帮你在一些关键路径的请求上配置必要的鉴权或超时策略。那样服务间的调用会被多层中间件所过滤并检查，确保整体服务的稳定性