天天看點

Knative 實戰:基于 Knative Serverless 技術實作天氣服務-下篇

上一期我們介紹了如何 基于 Knative Serverless 技術實作天氣服務-上篇 ,首先我們先來回顧一下上篇介紹的内容:

  • 通過高德天氣 API 接口,每隔 3 個小時定時發送定時事件,将國内城市未來 3 天的天氣資訊,存儲更新到表格存儲
  • 提供 RESTful API 查詢天氣資訊

接下來我們介紹如何通過表格存儲提供的通道服務,實作 Knative 對接表格存儲事件源,訂閱并通過釘釘發送天氣提醒通知。

整體架構

回顧一下整體架構:

Knative 實戰:基于 Knative Serverless 技術實作天氣服務-下篇
  • 通過 CronJob 事件源,每隔 3 個小時定時發送定時事件,将國内城市未來 3 天的天氣資訊,存儲更新到表格存儲
  • 通過表格存儲提供的通道服務,實作 TableStore 事件源
  • 通過 Borker/Trigger 事件驅動模型,訂閱天氣資訊
  • 根據訂閱收到的天氣資訊進行釘釘消息通知。如明天下雨,提示帶傘等

基于 Knative 實作天氣服務-下篇

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

先看一下處理流程圖:

Knative 實戰:基于 Knative Serverless 技術實作天氣服務-下篇
  • 定義 TableStore 事件源,用于接收通道服務資料
  • 訂閱接收到的天氣資訊發送給天氣提醒服務,進行釘釘消息通知

下面我們來詳細介紹一下。

自定義 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           

訂閱事件和通知提醒

建立天氣提醒服務

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

Knative 實戰:基于 Knative Serverless 技術實作天氣服務-下篇

擷取 webhook :

Knative 實戰:基于 Knative Serverless 技術實作天氣服務-下篇

這裡我們假設北京 (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, 天氣有雨,會收到如下的釘釘提醒:

Knative 實戰:基于 Knative Serverless 技術實作天氣服務-下篇

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

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

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

小結

本文介紹了如何在 Knative 中自定義事件源,并通過事件驅動接收天氣變化資訊,訂閱并通過釘釘推送通知提醒。這樣基于 Knative Serverless 技術實作天氣服務整體實作就介紹完了。有興趣的同學可以針對上面提到的不足繼續研究。還是那句話,做好天氣服務不容易,但還好我有 Knative。

歡迎加入 Knative 交流群

Knative 實戰:基于 Knative Serverless 技術實作天氣服務-下篇
“ 阿裡巴巴雲原生微信公衆号(ID:Alicloudnative)關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐,做最懂雲原生開發者的技術公衆号。”

繼續閱讀