上一期我們介紹了如何基于 Knative Serverless 技術(shù)實(shí)現(xiàn)天氣服務(wù)-上篇，首先我們先來(lái)回顧一下上篇介紹的內(nèi)容：

• 通過(guò)高德天氣 API 接口，每隔 3 個(gè)小時(shí)定時(shí)發(fā)送定時(shí)事件，將國(guó)內(nèi)城市未來(lái) 3 天的天氣信息，存儲(chǔ)更新到表格存儲(chǔ)
• 提供 RESTful API 查詢天氣信息

接下來(lái)我們介紹如何通過(guò)表格存儲(chǔ)提供的通道服務(wù)，實(shí)現(xiàn) Knative 對(duì)接表格存儲(chǔ)事件源，訂閱并通過(guò)釘釘發(fā)送天氣提醒通知。

整體架構(gòu)

回顧一下整體架構(gòu)：

• 通過(guò) CronJob 事件源，每隔 3 個(gè)小時(shí)定時(shí)發(fā)送定時(shí)事件，將國(guó)內(nèi)城市未來(lái) 3 天的天氣信息，存儲(chǔ)更新到表格存儲(chǔ)
• 提供 RESTful API 查詢天氣信息
• 通過(guò)表格存儲(chǔ)提供的通道服務(wù)，實(shí)現(xiàn) TableStore 事件源
• 通過(guò) Borker/Trigger 事件驅(qū)動(dòng)模型，訂閱天氣信息
• 根據(jù)訂閱收到的天氣信息進(jìn)行釘釘消息通知。如明天下雨，提示帶傘等

基于 Knative 實(shí)現(xiàn)天氣服務(wù)-下篇

首先我們介紹一下表格存儲(chǔ)提供的通道服務(wù)。通道服務(wù)（Tunnel Service）是基于表格存儲(chǔ)數(shù)據(jù)接口之上的全增量一體化服務(wù)。通道服務(wù)為您提供了增量、全量、增量加全量三種類型的分布式數(shù)據(jù)實(shí)時(shí)消費(fèi)通道。通過(guò)為數(shù)據(jù)表建立數(shù)據(jù)通道，您可以簡(jiǎn)單地實(shí)現(xiàn)對(duì)表中歷史存量和新增數(shù)據(jù)的消費(fèi)處理。通過(guò)數(shù)據(jù)通道可以進(jìn)行數(shù)據(jù)同步、事件驅(qū)動(dòng)、流式數(shù)據(jù)處理以及數(shù)據(jù)搬遷。這里事件驅(qū)動(dòng)正好契合我們的場(chǎng)景。

先看一下處理流程圖：

• 定義 TableStore 事件源，用于接收通道服務(wù)數(shù)據(jù)
• 通過(guò) Borker/Trigger 事件驅(qū)動(dòng)模型，訂閱天氣信息
• 訂閱接收到的天氣信息發(fā)送給天氣提醒服務(wù)，進(jìn)行釘釘消息通知

下面我們來(lái)詳細(xì)介紹一下。

自定義 TableStore 事件源

在 Knative 中自定義事件源其實(shí)很容易，可以參考官方提供的自定義事件源的實(shí)例：https://github.com/knative/docs/tree/master/docs/eventing/samples/writing-a-source。

我們這里定義數(shù)據(jù)源為 AliTablestoreSource。代碼實(shí)現(xiàn)主要分為兩部分：

資源控制器-Controller：接收 AliTablestoreSource 資源，在通道服務(wù)中創(chuàng)建 Tunnel

事件接收器-Receiver：通過(guò) Tunnel Client 監(jiān)聽(tīng)事件，并將接收到的事件發(fā)送到目標(biāo)服務(wù)( Broker）

關(guān)于自定義 TableStore 事件源實(shí)現(xiàn)參見(jiàn) GitHub 源代碼：https://github.com/knative-sample/tablestore-source

部署自定義事件源服務(wù)如下：

從 https://github.com/knative-sample/tablestore-source/tree/master/config 中可以獲取事件源部署文件，執(zhí)行下面的操作：

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

部署完成之后，我們可以看到資源控制器已經(jīng)開(kāi)始運(yùn)行：

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

創(chuàng)建事件源

由于我們是通過(guò) Knative Eventing 中 Broker/Trigger 事件驅(qū)動(dòng)模型對(duì)天氣事件進(jìn)行處理。首先我們創(chuàng)建用于數(shù)據(jù)接收的 Broker 服務(wù)。

創(chuàng)建 Broker

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

創(chuàng)建事件源實(shí)例

這里需要說(shuō)明一下，創(chuàng)建事件源實(shí)例其實(shí)就是在表格存儲(chǔ)中創(chuàng)建通道服務(wù)，那么就需要配置訪問(wèn)通道服務(wù)的地址、accessKeyId 和 accessKeySecret，這里參照格式：{ "url":"https://xxx.cn-beijing.ots.aliyuncs.com/", "accessKeyId":"xxxx","accessKeySecret":"xxxx" } 設(shè)置并進(jìn)行 base64 編碼。將結(jié)果設(shè)置到如下 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>"

創(chuàng)建 RBAC 權(quán)限：

apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata:name: eventing-sources-alitablestore subjects: - kind: ServiceAccountname: alitablestore-sanamespace: default roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: eventing-sources-alitablestore-controller--- apiVersion: v1 kind: ServiceAccount metadata:name: alitablestore-sa secrets: - name: alitablestore-secret

創(chuàng)建 AliTablestoreSource 實(shí)例，這里我們?cè)O(shè)置接收事件的 sink 為上面創(chuàng)建的 Broker 服務(wù)。

--- apiVersion: sources.eventing.knative.dev/v1alpha1 kind: AliTablestoreSource metadata:labels:controller-tools.k8s.io: "1.0"name: alitablestoresource spec:# Add fields hereserviceAccountName: alitablestore-saaccessToken:secretKeyRef:name: alitablestore-secretkey: alitablestoretableName: weatherinstance: knative-weathersink:apiVersion: eventing.knative.dev/v1alpha1kind: Brokername: weather

創(chuàng)建完成之后，我們可以看到運(yùn)行中的事件源：

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

訂閱事件和通知提醒

創(chuàng)建天氣提醒服務(wù)

如何進(jìn)行釘釘通知呢，我們可以創(chuàng)建一個(gè)釘釘?shù)娜航M（可以把家里人組成一個(gè)釘釘群，天氣異常時(shí)，給家人一個(gè)提醒），添加群機(jī)器人:

獲取 webhook :

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

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

關(guān)于釘釘提醒服務(wù)具體實(shí)現(xiàn)參見(jiàn) GitHub 源代碼：https://github.com/knative-sample/dingtalk-weather-service

創(chuàng)建訂閱

最后我們創(chuàng)建 Trigger訂閱天氣事件，并且觸發(fā)天氣提醒服務(wù)：

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

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

這里其實(shí)還有待完善的地方：

• 是否可以基于城市進(jìn)行訂閱（只訂閱目標(biāo)城市）？
• 是否可以指定時(shí)間發(fā)送消息提醒（當(dāng)天晚上 8 點(diǎn)準(zhǔn)時(shí)推送第 2 天的天氣提醒信息）？

有興趣的可以繼續(xù)完善當(dāng)前的天氣服務(wù)功能。

小結(jié)

本文介紹了如何在 Knative 中自定義事件源，并通過(guò)事件驅(qū)動(dòng)接收天氣變化信息，訂閱并通過(guò)釘釘推送通知提醒。這樣基于 Knative Serverless 技術(shù)實(shí)現(xiàn)天氣服務(wù)整體實(shí)現(xiàn)就介紹完了。有興趣的同學(xué)可以針對(duì)上面提到的不足繼續(xù)研究。還是那句話，做好天氣服務(wù)不容易，但還好我有 Knative。

歡迎加入 Knative 交流群

“ 阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的技術(shù)公眾號(hào)。”

總結(jié)

以上是生活随笔為你收集整理的Knative 实战：基于 Knative Serverless 技术实现天气服务-下篇的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。