Knative 實戰：基于 Knative Serverless 技術實作天氣服務

提到天氣預報服務，我們第一反應是很簡單的一個服務啊，目前網上有大把的天氣預報 API 可以直接使用，有必要去使用 Knative 搞一套嗎？殺雞用牛刀？先不要着急，我們先看一下實際的幾個場景需求：

• 場景需求1：根據當地曆年的天氣資訊，預測明年大緻的高溫到來的時間
• 場景需求2：近來天氣多變，如果明天下雨，能否在早上上班前，給我一個帶傘提醒通知
• 場景需求3：上司發話：最近經濟不景氣，公司财務緊張，那個伺服器，你們提供天氣、路況等服務的那幾個小程式一起用吧，但要保證正常提供服務。

從上面的需求，我們其實發現，要做好一個天氣預報的服務，也面臨内憂（資源緊缺）外患（需求增加），并不是那麼簡單的。不過現在更不要着急，我們可以使用 Knative 幫你解決上面的問題。

關鍵詞：天氣查詢、表格存儲，通道服務，事件通知

場景需求

首先我們來描述一下我們要做的天氣服務場景需求：

1. 提供對外的天氣預報 RESTful API

• 根據城市、日期查詢（支援未來 3 天）國内城市天氣資訊
• 不限制查詢次數，支援較大并發查詢（1000）

2. 天氣訂閱提醒

• 訂閱國内城市天氣資訊，根據實際訂閱城市區域，提醒明天下雨帶傘
• 使用釘釘進行通知

整體架構

有了需求，那我們就開始如何基于 Knative 實作天氣服務。我們先看一下整體架構：

• 通過 CronJob 事件源，每隔 3個 小時定時發送定時事件，将國内城市未來3天的天氣資訊，存儲更新到表格存儲
• 提供 RESTful API 查詢天氣資訊
• 通過表格存儲提供的通道服務，實作 TableStore 事件源
• 通過 Borker/Trigger 事件驅動模型，訂閱目标城市天氣資訊
• 根據訂閱收到的天氣資訊進行釘釘消息通知。如明天下雨，提示帶傘等

提供對外的天氣預報 RESTful API

對接高德開放平台天氣預報 API

查詢天氣的 API 有很多，這裡我們選擇高德開放平台提供的天氣查詢 API，使用簡單、服務穩定，并且該天氣預報 API 每天提供 100000 免費的調用量，支援國内 3500 多個區域的天氣資訊查詢。另外高德開放平台，除了天氣預報，還可以提供 ip 定位、搜尋服務、路徑規劃等，感興趣的也可以研究一下玩法。

登入高德開放平台:

https://lbs.amap.com

， 建立應用，擷取 Key 即可：

擷取Key之後，可以直接通過url通路：

https://restapi.amap.com/v3/weather/weatherInfo?city=110101&extensions=all&key=<

使用者key>，傳回天氣資訊資料如下：

{
    "status":"1",
    "count":"1",
    "info":"OK",
    "infocode":"10000",
    "forecasts":[
        {
            "city":"杭州市",
            "adcode":"330100",
            "province":"浙江",
            "reporttime":"2019-09-24 20:49:27",
            "casts":[
                {
                    "date":"2019-09-24",
                    "week":"2",
                    "dayweather":"晴",
                    "nightweather":"多雲",
                    "daytemp":"29",
                    "nighttemp":"17",
                    "daywind":"無風向",
                    "nightwind":"無風向",
                    "daypower":"≤3",
                    "nightpower":"≤3"
                },
                ...
            ]
        }
    ]
}           

定時同步并更新天氣資訊

同步并更新天氣資訊

該功能主要實作對接高德開放平台天氣預報 API， 擷取天氣預報資訊，同時對接阿裡雲表格存儲服務（TableStore），用于天氣預報資料存儲。具體操作如下：

• 接收 CloudEvent 定時事件
• 查詢各個區域天氣資訊
• 将天氣資訊存儲或者更新到表格存儲

在 Knative 中，我們可以直接建立服務如下：

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: weather-store
  namespace: default
spec:
  template:
    metadata:
      labels:
        app: weather-store
      annotations:
        autoscaling.knative.dev/maxScale: "20"
        autoscaling.knative.dev/target: "100"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/weather-store:1.2
          ports:
            - name: http1
              containerPort: 8080
          env:
          - name: OTS_TEST_ENDPOINT
            value: http://xxx.cn-hangzhou.ots.aliyuncs.com
          - name: TABLE_NAME
            value: weather
          - name: OTS_TEST_INSTANCENAME
            value: ${xxx} 
          - name: OTS_TEST_KEYID
            value: ${yyy}
          - name: OTS_TEST_SECRET
            value: ${Pxxx}
          - name: WEATHER_API_KEY
            value: xxx           

關于服務具體實作參見 GitHub 源代碼：

https://github.com/knative-sample/weather-store

建立定時事件

這裡或許有疑問：為什麼不在服務中直接進行定時輪詢，非要通過 Knative Eventing 搞一個定時事件觸發執行調用？那我們要說明一下，Serverless 時代下就該這樣玩-按需使用。千萬不要在服務中按照傳統的方式空跑這些定時任務，親，這是在持續浪費計算資源。

言歸正傳，下面我們使用 Knative Eventing 自帶的定時任務資料源（CronJobSource），觸發定時同步事件。

建立 CronJobSource 資源，實作每 3 個小時定時觸發同步天氣服務（weather-store），WeatherCronJob.yaml 如下：

apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
  name: weather-cronjob
spec:
  schedule: "0 */3 * * *"
  data: '{"message": "sync"}'
  sink:
    apiVersion: serving.knative.dev/v1alpha1
    kind: Service
    name: weather-store           

執行指令：

kubectl apply -f WeatherCronJob.yaml           

現在我們登入阿裡雲表格存儲服務，可以看到天氣預報資料已經按照城市、日期的格式同步進來了。

提供天氣預報查詢 RESTful API

有了這些天氣資料，可以随心所欲的提供屬于我們自己的天氣預報服務了（感覺像是承包了一塊地，我們來當地主），這裡沒什麼難點，從表格存儲中查詢對應的天氣資料，按照傳回的資料格式進行封裝即可。

在 Knative 中，我們可以部署 RESTful API 服務如下：

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: weather-service
  namespace: default
spec:
  template:
    metadata:
      labels:
        app: weather-service
      annotations:
        autoscaling.knative.dev/maxScale: "20"
        autoscaling.knative.dev/target: "100"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/weather-service:1.1
          ports:
            - name: http1
              containerPort: 8080
          env:
          - name: OTS_TEST_ENDPOINT
            value: http://xxx.cn-hangzhou.ots.aliyuncs.com
          - name: TABLE_NAME
            value: weather
          - name: OTS_TEST_INSTANCENAME
            value: ${xxx} 
          - name: OTS_TEST_KEYID
            value: ${yyy}
          - name: OTS_TEST_SECRET
            value: ${Pxxx}           

具體實作源代碼 GitHub 位址：

https://github.com/knative-sample/weather-service

查詢天氣 RESTful API:

• 請求URL

  GET /api/weather/query

參數:
cityCode：城市區域代碼。如北京市區域代碼：110000
date：查詢日期。如格式：2019-09-26           

• 傳回結果

{
    "code":200,
    "message":"",
    "data":{
        "adcode":"110000",
        "city":"北京市",
        "date":"2019-09-26",
        "daypower":"≤3",
        "daytemp":"30",
        "dayweather":"晴",
        "daywind":"東南",
        "nightpower":"≤3",
        "nighttemp":"15",
        "nightweather":"晴",
        "nightwind":"東南",
        "province":"北京",
        "reporttime":"2019-09-25 14:50:46",
        "week":"4"
    }
}           

查詢：杭州，2019-09-26天氣預報資訊示例

測試位址：

http://weather-service.default.knative.kuberun.com/api/weather/query?cityCode=330100&date=2019-11-06

另外城市區域代碼表可以在上面提供的源代碼 GitHub 中可以檢視，也可以到高德開放平台中下載下傳：

https://lbs.amap.com/api/webservice/download

天氣訂閱提醒

首先我們介紹一下表格存儲提供的通道服務。通道服務（Tunnel Service）是基于表格存儲資料接口之上的全增量一體化服務。通道服務為您提供了增量、全量、增量加全量三種類型的分布式資料實時消費通道。通過為資料表建立資料通道，您可以簡單地實作對表中曆史存量和新增資料的消費處理。通過資料通道可以進行資料同步、事件驅動、流式資料處理以及資料搬遷。這裡事件驅動正好契合我們的場景。

自定義 TableStore 事件源

在 Knative 中自定義事件源其實很容易，可以參考官方提供的自定義事件源的執行個體：

https://github.com/knative/docs/tree/master/docs/eventing/samples/writing-a-source

。

我們這裡定義資料源為 AliTablestoreSource。代碼實作主要分為兩部分：

1. 資源控制器-Controller：接收 AliTablestoreSource 資源，在通道服務中建立 Tunnel。
2. 事件接收器-Receiver：通過 Tunnel Client 監聽事件，并将接收到的事件發送到目标服務( Broker）

關于自定義 TableStore 事件源實作參見 GitHub 源代碼：

https://github.com/knative-sample/tablestore-source

部署自定義事件源服務如下：

從

https://github.com/knative-sample/tablestore-source/tree/master/config

中可以擷取事件源部署檔案，執行下面的操作

kubectl apply -f 200-serviceaccount.yaml -f 201-clusterrole.yaml -f 202-clusterrolebinding.yaml -f 300-alitablestoresource.yaml -f 400-controller-service.yaml -f 500-controller.yaml -f 600-istioegress.yaml           

部署完成之後，我們可以看資源控制器已經開始運作：

[root@iZ8vb5wa3qv1gwrgb3lxqpZ config]# kubectl -n knative-sources get pods
NAME                                 READY   STATUS    RESTARTS   AGE
alitablestore-controller-manager-0   1/1     Running   0          4h12m           

建立事件源

由于我們是通過 Knative Eventing 中 Broker/Trigger 事件驅動模型對天氣事件進行處理。首先我們建立用于資料接收的 Broker 服務。

建立 Broker

apiVersion: eventing.knative.dev/v1alpha1
kind: Broker
metadata:
  name: weather
spec:
  channelTemplateSpec:
    apiVersion: messaging.knative.dev/v1alpha1
    kind: InMemoryChannel           

建立事件源執行個體

這裡需要說明一下，建立事件源執行個體其實就是在表格存儲中建立通道服務，那麼就需要配置通路通道服務的位址、accessKeyId和accessKeySecret，這裡參照格式：

{ "url":"https://xxx.cn-beijing.ots.aliyuncs.com/", "accessKeyId":"xxxx","accessKeySecret":"xxxx" }

設定并進行base64編碼。将結果設定到如下 Secret 配置檔案

alitablestore

屬性中：

apiVersion: v1
kind: Secret
metadata:
  name: alitablestore-secret
type: Opaque
data:
  # { "url":"https://xxx.cn-beijing.ots.aliyuncs.com/", "accessKeyId":"xxxx","accessKeySecret":"xxxx" }
  alitablestore: "<base64>"           

建立 RBAC 權限

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eventing-sources-alitablestore
subjects:
- kind: ServiceAccount
  name: alitablestore-sa
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eventing-sources-alitablestore-controller

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: alitablestore-sa
secrets:
- name: alitablestore-secret           

建立 AliTablestoreSource 執行個體，這裡我們設定接收事件的

sink

為上面建立的 Broker 服務。

---
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: AliTablestoreSource
metadata:
  labels:
    controller-tools.k8s.io: "1.0"
  name: alitablestoresource
spec:
  # Add fields here
  serviceAccountName: alitablestore-sa
  accessToken:
    secretKeyRef:
      name: alitablestore-secret
      key: alitablestore
  tableName: weather
  instance: knative-weather
  sink:
    apiVersion: eventing.knative.dev/v1alpha1
    kind: Broker
    name: weather           

建立完成之後，我們可以看到運作中的事件源：

[root@iZ8vb5wa3qv1gwrgb3lxqpZ config]# kubectl get pods
NAME                                                              READY   STATUS      RESTARTS   AGE
tablestore-alitablestoresource-9sjqx-656c5bf84b-pbhvw             1/1     Running     0          4h9m           

訂閱事件和通知提醒

建立天氣提醒服務

如何進行釘釘通知呢，我們可以建立一個釘釘的群組（可以把家裡人組成一個釘釘群，天氣異常時，給家人一個提醒），添加群機器人:

擷取 webhook :

這裡我們假設北京(110000)，日期：2019-10-13, 如果天氣有雨，就通過釘釘發送通知提醒，則服務配置如下：

apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
  name: day-weather
spec:
  template:
    spec:
      containers:
      - args:
        - --dingtalkurl=https://oapi.dingtalk.com/robot/send?access_token=xxxxxx
        - --adcode=110000
        - --date=2019-10-13
        - --dayweather=雨
        image: registry.cn-hangzhou.aliyuncs.com/knative-sample/dingtalk-weather-service:1.2           

關于釘釘提醒服務具體實作參見 GitHub 源代碼：

https://github.com/knative-sample/dingtalk-weather-service

建立訂閱

最後我們建立 Trigger訂閱天氣事件，并且觸發天氣提醒服務：

apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
  name: weather-trigger
spec:
  broker: weather
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1alpha1
      kind: Service
      name: day-weather           

訂閱之後，如果北京(110000)，日期：2019-10-13, 天氣有雨，會收到如下的釘釘提醒：

這裡其實還有待完善的地方：

• 是否可以基于城市進行訂閱（隻訂閱目标城市）？
• 是否可以指定時間發送消息提醒（當天晚上 8 點準時推送第 2 天的天氣提醒資訊）？

有興趣的可以繼續完善目前的天氣服務功能。

總結

通過上面的介紹，大家對如何通過 Knative 提供天氣查詢、 訂閱天氣資訊，釘釘推送通知提醒應該有了更多的體感，其實類似的場景我們有理由相信通過 Knative Serverless 可以幫你做到資源利用遊刃有餘。歡迎持續關注。

作者資訊：元毅，阿裡雲容器平台進階開發工程師，負責阿裡雲容器平台 Knative 相關工作