微服務從程式碼到k8s部署應有盡有系列（六、訂單服務）

kevinwan發表於2022-02-23
微服務K8S
系列文章：
微服務從程式碼到k8s部署應有盡有系列（一） 微服務從程式碼到k8s部署應有盡有系列（二、閘道器） 微服務從程式碼到k8s部署應有盡有系列（三、鑑權） 微服務從程式碼到k8s部署應有盡有系列（四、使用者中心） 微服務從程式碼到k8s部署應有盡有系列（五、民宿服務） 微服務從程式碼到k8s部署應有盡有系列（六、訂單服務）

我們用一個系列來講解從需求到上線、從程式碼到k8s部署、從日誌到監控等各個方面的微服務完整實踐。

整個專案使用了go-zero開發的微服務，基本包含了go-zero以及相關go-zero作者開發的一些中介軟體，所用到的技術棧基本是go-zero專案組的自研元件，基本是go-zero全家桶了。

實戰專案地址：github.com/Mikaelemmmm/go-zero-loo...

1、訂單服務業務架構圖

2、依賴關係

order-api（訂單api）

  • order-rpc（訂單rpc）
  • payment-rpc（支付rpc）

payment-rpc（支付rpc）

  • mqueue-rpc(訊息佇列)

order-rpc（訂單rpc）

  • mqueue-rpc(訊息佇列)
  • travel-rpc（民宿rpc）

3、訂單舉例

3.1 下訂單

1、使用者在去瀏覽travel服務中的民宿homestay看中選擇日期之後要下單，呼叫下單api介面

app/order/cmd/api/desc/order.api

// 訂單模組v1版本的介面
@server(
   prefix: order/v1
   group: homestayOrder
)
service order {
   @doc "建立民宿訂單"
   @handler createHomestayOrder
   post /homestayOrder/createHomestayOrder (CreateHomestayOrderReq) returns (CreateHomestayOrderResp)

   .....
}

2、order-api中呼叫order-rpc

3、rpc中校驗條件建立訂單之後 ，會呼叫mqueue-rpc建立一個延遲關閉訂單的訊息佇列

4、mqueue-rpc 延遲佇列

延遲佇列是用的asynq，asynq是基於redis的高效能佇列，同時支援訊息佇列、定時佇列、固定週期佇列，但是我們這個專案為了演示go-zero官方的訊息佇列go-queue（go-queue是基於kafka的），所以訊息佇列用的go-queue，延遲佇列、定時任務用asynq。這裡注意，這裡只是往延遲佇列新增延遲任務，具體執行不在這裡，那我們去看看20分鐘之後具體執行的程式碼，在app/order/cmd/mq

5、延遲20分鐘執行的任務佇列

在app/order/cmd/mq，這裡我要說明一下，go-zero官方goctl支援生成的服務目前是api、rpc，目前暫時還沒有支援console、mq等，但是go-zero提供了ServiceGroup，方便我們管理我們自己任何的服務，所以在mq中我是用了ServiceGroup管理了服務，這也是官方推薦的使用方式，程式碼如下:

1）app/order/cmd/mq/order.go 首先我們看main.go

func main() {
    flag.Parse()
    var c config.Config

    conf.MustLoad(*configFile, &c)
    prometheus.StartAgent(c.Prometheus)

    serviceGroup := service.NewServiceGroup()
    defer serviceGroup.Stop()

    for _, mq := range listen.Mqs(c) {
        serviceGroup.Add(mq)
    }
    serviceGroup.Start()
}

ServiceGroup 可以新增任何service進去，但是如何成為一個service呢？ 那你就要實現兩個方法一個Starter、一個Stoper

2）我們在main中可以看到迴圈listen.Mqs(c) ，那我們看看listen.Mqs(c) 都有哪些

我們不止要監聽asynq的延遲佇列、定時佇列，後面我們還想監聽go-queue的kafka訊息佇列，在程式碼上我們考慮不想把go-queue的kafka訊息佇列跟asynq的延遲佇列、定時佇列放到一起去，所以這裡做了個分類

3）asyny的延遲訊息佇列

定義asynq

定義路由

具體實現邏輯（關閉訂單邏輯）

所以我們啟動這個order-mq的時候，asynq就會被載入、定義路由，當我們之前新增的延遲佇列到了20分鐘，就會自動執行關閉訂單邏輯，如果訂單沒有被支付，這裡就會關閉掉訂單，支付了就忽略掉了，這樣就可以不用使用定時任務輪訓關閉訂單了，哈哈

3.2 訂單列表

沒啥邏輯，就是查出來顯示罷了，自己看一下就好了

// 訂單模組v1版本的介面
@server(
   prefix: order/v1
   group: homestayOrder
)
service order {

   @doc "使用者訂單列表"
   @handler userHomestayOrderList
   post /homestayOrder/userHomestayOrderList (UserHomestayOrderListReq) returns (UserHomestayOrderListResp)

}

3.3 訂單明細

沒啥邏輯，就是查出來顯示罷了，自己看一下就好了

// 訂單模組v1版本的介面
@server(
    prefix: order/v1
    group: homestayOrder
)
service order {

    @doc "使用者訂單明細"
    @handler userHomestayOrderDetail
    post /homestayOrder/userHomestayOrderDetail (UserHomestayOrderDetailReq) returns (UserHomestayOrderDetailResp)
}

4、結尾

下了訂單，當然我們要支付了，那就看下一篇支付服務吧

專案地址

github.com/zeromicro/go-zero

歡迎使用 go-zero 並 star 支援我們！

微信交流群

關注『微服務實踐』公眾號並點選 交流群 獲取社群群二維碼。

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章