上一篇文章咱们把整个我的项目的架子搭建实现，服务在本地也曾经能运行起来了，顺利成章的接下来咱们就应该开始写业务逻辑代码了，然而单纯的写业务逻辑代码是比拟干燥的，业务逻辑的代码我会一直地补充到 lerbon 我的项目中去，要害局部我也会加上正文。
那么本篇文章我次要想和大家分享下服务的根本配置和几个典型的代码示例。
日志定义
go-zero的 logx 包提供了日志性能，默认不须要做任何配置就能够在stdout中输入日志。当咱们申请/v1/order/list接口的时候输入日志如下，默认是json格局输入，包含工夫戳，http申请的根本信息，接口耗时，以及链路追踪的span和trace信息。
{"@timestamp":"2022-06-11T08:23:36.342+08:00","caller":"handler/loghandler.go:197","content":"[HTTP] 200 - GET /v1/order/list?uid=123 - 127.0.0.1:59998 - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36","duration":"21.2ms","level":"info","span":"23c4deaa3432fd03","trace":"091ffcb0eafe7818b294e4d8122cf8a1"}程序启动后，框架会默认输入level为stat的统计日志，用于输入以后资源的应用状况，次要为cpu和内存，内容如下：
{"@timestamp":"2022-06-11T08:34:58.402+08:00","caller":"stat/usage.go:61","content":"CPU: 0m, MEMORY: Alloc=3.3Mi, TotalAlloc=7.0Mi, Sys=16.3Mi, NumGC=8","level":"stat"}当咱们不须要这类日志的时候，咱们能够通过如下形式敞开该类日志的输入：
logx.DisableStat()有的时候咱们只须要记录谬误日志，能够通过设置日志等级来勾销level为info级别日志的输入：
logx.SetLevel(logx.ErrorLevel)能够扩大日志输入的字段，增加了uid字段记录申请的用户的uid，日志打印内容如下：
logx.Infow("order list", logx.Field("uid",req.UID)){"@timestamp":"2022-06-11T08:53:50.609+08:00","caller":"logic/orderlistlogic.go:31","content":"order list","level":"info","uid":123}咱们还能够扩大其余第三方日志库，通过logx.SetWriter来进行设置
writer := logrusx.NewLogrusWriter(func(logger *logrus.Logger) { logger.SetFormatter(&logrus.JSONFormatter{})})logx.SetWriter(writer)同时logx还提供了丰盛的配置，能够配置日志输入模式，工夫格局，输入门路，是否压缩，日志保留工夫等
type LogConf struct { ServiceName string `json:",optional"` Mode string `json:",default=console,options=[console,file,volume]"` Encoding string `json:",default=json,options=[json,plain]"` TimeFormat string `json:",optional"` Path string `json:",default=logs"` Level string `json:",default=info,options=[info,error,severe]"` Compress bool `json:",optional"` KeepDays int `json:",optional"` StackCooldownMillis int `json:",default=100"`}能够看到logx提供的日志性能还是十分丰盛的，同时反对了各种自定义的形式。日志是咱们排查线上问题十分重要的依赖，咱们还会依据日志做各种告警，所以这里咱们先做了一些日志应用的介绍。
服务依赖
在BFF服务中会依赖多个RPC服务，默认状况下，如果依赖的RPC服务没有启动，BFF服务也会启动异样，报错如下，通过日志能够晓得是因为order.rpc没有启动，因为order.rpc是整个商城零碎的外围服务，BFF对order.rpc是强依赖，在强依赖的状况下如果被依赖服务异样，那么依赖服务也无奈失常启动。
{"@timestamp":"2022-06-11T10:21:56.711+08:00","caller":"internal/discovbuilder.go:34","content":"bad resolver state","level":"error"}2022/06/11 10:21:59 rpc dial: discov://127.0.0.1:2379/order.rpc, error: context deadline exceeded, make sure rpc service "order.rpc" is already startedexit status 1再看如下的场景，BFF依赖reply.rpc，因为reply.rpc异样导致BFF无奈失常启动，因为reply.rpc并不是商城零碎的外围依赖，就算reply.rpc挂掉也不影响商城的外围流程，所以对于BFF来说reply.rpc是弱依赖，在弱依赖的状况下不应该影响依赖方的启动。
{"@timestamp":"2022-06-11T11:26:51.711+08:00","caller":"internal/discovbuilder.go:34","content":"bad resolver state","level":"error"}2022/06/11 11:26:54 rpc dial: discov://127.0.0.1:2379/reply.rpc, error: context deadline exceeded, make sure rpc service "reply.rpc" is already startedexit status 1在go-zero中提供了弱依赖的配置，配置后BFF即可失常启动，能够看到order.rpc和product.rpc都是强依赖，而reply.rpc配置了NonBlock:true为弱依赖
OrderRPC: Etcd: Hosts: - 127.0.0.1:2379 Key: order.rpcProductRPC: Etcd: Hosts: - 127.0.0.1:2379 Key: product.rpcReplyRPC: Etcd: Hosts: - 127.0.0.1:2379 Key: reply.rpc NonBlock: true并行调用
在高并发的零碎中，接口耗时是咱们十分关注的点，接口疾速响应能够晋升用户体验，长时间的期待会让用户体验很差，用户也就会缓缓的来到咱们。这里咱们介绍简略但很实用的晋升接口响应工夫的办法，那就是并行的依赖调用。
下图展现了串行调用和并行调用的区别，串行调用依赖的话，耗时等于所有依赖耗时的和，并行调用依赖的话，耗时等于所有依赖中耗时最大的一个依赖的耗时。
在获取商品详情的接口中，参数ProductIds为逗号分隔的多个商品id，在这里咱们应用go-zero提供的mapreduce来并行的依据商品id获取商品详情，代码如下，具体代码请参考product-rpc服务：
func (l *ProductsLogic) Products(in *product.ProductRequest) (*product.ProductResponse, error) { products := make(map[int64]*product.ProductItem) pdis := strings.Split(in.ProductIds, ",") ps, err := mr.MapReduce(func(source chan<- interface{}) { for _, pid := range pdis { source <- pid } }, func(item interface{}, writer mr.Writer, cancel func(error)) { pid := item.(int64) p, err := l.svcCtx.ProductModel.FindOne(l.ctx, pid) if err != nil { cancel(err) return } writer.Write(p) }, func(pipe <-chan interface{}, writer mr.Writer, cancel func(error)) { var r []*model.Product for p := range pipe { r = append(r, p.(*model.Product)) } writer.Write(r) }) if err != nil { return nil, err } for _, p := range ps.([]*model.Product) { products[p.Id] = &product.ProductItem{ ProductId: p.Id, Name: p.Name, } } return &product.ProductResponse{Products: products}, nil}在商品详情页，不仅展现了商品的详情，同时页展现了商品评估的第一页，而后点击评估详情能够跳转到评估详情页，为了防止客户端同时申请多个接口，所以咱们在商品详情页把评论首页的内容一并返回，因为评论内容并不是核心内容所以在这里咱们还做了降级，即申请reply.rpc接口报错咱们会疏忽这个谬误，从而能让商品详情失常的展现。因为获取商品详情和商品评估没有前后依赖关系，所以这里咱们应用mr.Finish来并行的申请来升高接口的耗时。
func (l *ProductDetailLogic) ProductDetail(req *types.ProductDetailRequest) (resp *types.ProductDetailResponse, err error) { var ( p *product.ProductItem cs *reply.CommentsResponse ) if err := mr.Finish(func() error { var err error if p, err = l.svcCtx.ProductRPC.Product(l.ctx, &product.ProductItemRequest{ProductId: req.ProductID}); err != nil { return err } return nil }, func() error { var err error if cs, err = l.svcCtx.ReplyRPC.Comments(l.ctx, &reply.CommentsRequest{TargetId: req.ProductID}); err != nil { logx.Errorf("get comments error: %v", err) } return nil }); err != nil { return nil, err } var comments []*types.Comment for _, c := range cs.Comments { comments = append(comments, &types.Comment{ ID: c.Id, Content: c.Content, }) } return &types.ProductDetailResponse{ Product: &types.Product{ ID: p.ProductId, Name: p.Name, }, Comments: comments, }, nil}图片上传
图片上传是十分罕用的性能，咱们在product-admin中须要上传商品图片，这里咱们把商品图片上传到阿里云OSS中，api定义如下
syntax = "v1"type UploadImageResponse { Success bool `json:"success"`}service admin-api { @handler UploadImageHandler post /v1/upload/image() returns (UploadImageResponse)}在admin-api.yaml中增加如下配置
Name: admin-apiHost: 0.0.0.0Port: 8888OSSEndpoint: https://oss-cn-hangzhou.aliyuncs.comAccessKeyID: xxxxxxxxxxxxxxxxxxxxxxxxAccessKeySecret: xxxxxxxxxxxxxxxxxxxxxxxx增加OSS客户端
type ServiceContext struct { Config config.Config OssClient *oss.Client}func NewServiceContext(c config.Config) *ServiceContext { oc, err := oss.New(c.OSSEndpoint, c.AccessKeyID, c.AccessKeySecret) if err != nil { panic(err) } return &ServiceContext{ Config: c, OssClient: oc, }}上传逻辑须要先获取bucket，该bucket为事后定义的bucket，能够通过api调用创立，也能够在阿里云工作台手动创立
func (l *UploadImageLogic) UploadImage() (resp *types.UploadImageResponse, err error) { file, header, err := l.r.FormFile(imageFileName) if err != nil { return nil, err } defer file.Close() bucket, err := l.svcCtx.OssClient.Bucket(bucketName) if err != nil { return nil, err } if err = bucket.PutObject(header.Filename, file); err != nil { return nil, err } return &types.UploadImageResponse{Success: true}, nil}应用Postman上传图片，留神在上传图片前须要先创立bucket
登录阿里云对象存储查看已上传的图片
结束语
本篇文章通过日志定义和服务依赖介绍了服务构建中常见的一些配置，这里并没有把所有配置一一列举而是举例说明了社区中常常有人问到的场景，前面的文章还会持续不断完善服务的相干配置。接着又通过服务依赖的并行调用和图片上传两个案例展现了常见性能的优化伎俩以及编码方式。
这里并没有把所有的性能都列出来，也是想起个头，大家能够把我的项目down下来本人去欠缺这个我的项目，纸上得来终觉浅，绝知此事要躬行，当然我也会持续欠缺我的项目代码和大家一起学习提高。
心愿本篇文章对你有所帮忙，谢谢。
每周一、周四更新
代码仓库: https://github.com/zhoushuguang/lebron
我的项目地址
https://github.com/zeromicro/go-zero
欢送应用 go-zero 并 star 反对咱们！
微信交换群
关注『微服务实际』公众号并点击 交换群 获取社区群二维码。