提到天氣預報服務，我們第一反應是很簡單的一個服務啊，目前網上有大把的天氣預報 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。代碼實現主要分為兩部分：

資源控制器-Controller：接收 AliTablestoreSource 資源，在通道服務中創建 Tunnel。

事件接收器-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:?""

創建 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 可以幫你做到資源利用游刃有余。歡迎持續關注。