Address of this project : https://github.com/Mikaelemmmm/go-zero-looklook
travel-api (B&B api) depends on travel-rpc (B&B rpc), usercenter-rpc (user-center rpc)
travel is divided into several businesses
- homestay :room listings
@server(
prefix: travel/v1
group: homestay
)
service travel {
@doc "room-list(for your preference)"
@handler homestayList
post /homestay/homestayList (HomestayListReq) returns (HomestayListResp)
@doc "Landlord's list of all rooms"
@handler businessList
post /homestay/businessList (BusinessListReq) returns (BusinessListResp)
@doc "Guess your favorite room list"
@handler guessList
post /homestay/guessList (GuessListReq) returns (GuessListResp)
@doc "Room Details"
@handler homestayDetail
post /homestay/homestayDetail (HomestayDetailReq) returns (HomestayDetailResp)
}
- homestayBusiness : travel bisuness
@server(
prefix: travel/v1
group: homestayBussiness
)
service travel {
@doc "Best Landlord"
@handler goodBoss
post /homestayBussiness/goodBoss (GoodBossReq) returns (GoodBossResp)
@doc "Store List"
@handler homestayBussinessList
post /homestayBussiness/homestayBussinessList (HomestayBussinessListReq) returns (HomestayBussinessListResp)
@doc "Landlord Information"
@handler homestayBussinessDetail
post /homestayBussiness/homestayBussinessDetail (HomestayBussinessDetailReq) returns (HomestayBussinessDetailResp)
}
- homestayComment : travel-comment
@server(
prefix: travel/v1
group: homestayComment
)
service travel {
@doc "travel comment list"
@handler commentList
post /homestayComment/commentList (CommentListReq) returns (CommentListResp)
}
1.Writing api interface files
app/travel/cmd/api/desc/homestay/homestay.api
type (
HomestayListReq {
LastId int64 `json:"lastId"`
PageSize int64 `json:"pageSize"`
RowType string `json:"rowType"` //preferredHomestay:Preferred
}
HomestayListResp {
List []Homestay `json:"list"`
}
)
app/travel/cmd/api/desc/travel.api
import (
"homestay/homestay.api"
....
)
@server(
prefix: travel/v1
group: homestay
)
service travel {
@doc "room list(Preferred)"
@handler homestayList
post /homestay/homestayList (HomestayListReq) returns (HomestayListResp)
......
}
2.goctl generate api code
1)Go to app/travel/cmd/api/desc directory in the command line.
- Go to deploy/script/gencode/gen.sh in the project directory, copy the following command and execute it in the command line (the command line should switch to app/travel/cmd directory)
goctl api go -api *.api -dir ../ -style=goZero
3.Open app/travel/cmd/api/internal/logic/homestay/homestayListLogic.go
Because our recommendations are configured in the background, we created an activity table (here you can also choose to configure to redis), in short, we just get the configured recommended bed and breakfast id from the activity table first, and then go through the id to get the corresponding bed and breakfast information list.
Here you can see, I got the id collection, not the ordinary foreach one by one to get, but the use of go-zero for us to encapsulate a good mapreduce to get the data, so you can concurrently go to get the data, rather than to go to get a finish in the next one, the time greatly shortened, here just want to build to show such a function, some students have to be serious, you can pass an id slice or id arr to the rpc, and then in the rpc to concurrently get each, so there is nothing wrong, I just show you this function
Define the protobuf file
app/travel/cmd/rpc/pb/travel.proto
//model
message Homestay {
int64 id = 1;
string title = 2;
string subTitle = 3;
string banner = 4;
string info = 5;
int64 peopleNum = 6;
int64 homestayBusinessId = 7; //business id
int64 userId = 8; //Landlord id
int64 rowState = 9; //0:down 1:up
int64 rowType = 10; //Selling type 0: Sold by room 1: Sold by person
string foodInfo = 11; //Meal standard
int64 foodPrice = 12; //Meal price (cents)
int64 homestayPrice = 13; //room prices (cents)
int64 marketHomestayPrice = 14; //market room price (cent)
}
//req .resp
message HomestayDetailReq {
int64 id = 1;
}
message HomestayDetailResp {
Homestay homestay = 1;
}
//service
service travel {
//info
rpc homestayDetail(HomestayDetailReq) returns(HomestayDetailResp);
}
-
Use goctl to generate the code, here you do not need to manually knock
-
Command line into the app/travel/cmd/rpc/pb directory.
-
Go to deploy/script/gencode/gen.sh in the project directory, copy the following two commands and execute them on the command line (the command line should switch to the app/travel/cmd directory)
goctl rpc protoc *.proto --go_out=../ --go-grpc_out=../ --zrpc_out=../ sed -i "" 's/,omitempty//g' *.pb.go
-
-
Open app/travel/cmd/rpc/internal/logic/homestayDetailLogic.go to write the logic code
There is little logic here, query Findone, and then return to the api, because the api side is passed through the id, and then you can see that our side once again used the previous sheet mentioned the gorm authors provide another magic tool copier, the last section is used in the api, the rpc proto file data copy to the api file , here you can see that we copy the data returned by the model to the proto data can also be used, how is it very convenient.
Here why we do not go to findlist, because we have a cache in the findone method, we query data one by one according to the id, only the first time will hit the db, the other time is basically hit the redis cache, so not only fast, even when the traffic surge, will not all hit the db, but all in the redis, so will greatly improve the speed of our system access and db support capabilities.
Generally we maintain our own db cache will be written piecemeal, but go-zero uses the built-in tool goctl generated mod, comes with sqlc + sqlx implementation of the code to achieve automatic cache management, we do not need to manage the cache, just use sqlx to write sql data, sqlc will automatically help us manage the cache, and is through singleflight , which means that even if the cache is invalidated at a certain time, at the moment of invalidation there are a lot of concurrent requests coming in, go-zero will only let one thread in when querying the db, the other threads are waiting, when this thread gets the data back from the database, the data will be cached to redis while all the previous waiting threads share this data When this thread comes back from the database, it will cache the data in redis and share the data among all the waiting threads, so that the subsequent threads that come in to look up the same data will only go to redis and not to the db.
So that once the rpc has all the data, it can be returned to the front-end for display
Several other services without business what logical here will not be explained one by one, see api documentation basically know what is, according to the above example code to see for themselves, later there are involved in the business of complex places will be explained one by one