Knative 實戰:基於 Knative Serverless 技術實現天氣服務-下篇
上一期我們介紹瞭如何 基於 Knative Serverless 技術實現天氣服務-上篇,首先我們先來回顧一下上篇介紹的內容:
- 透過高德天氣 API 介面,每隔 3 個小時定時傳送定時事件,將國內城市未來 3 天的天氣資訊,儲存更新到表格儲存
- 提供 RESTful API 查詢天氣資訊
接下來我們介紹如何透過表格儲存提供的通道服務,實現 Knative 對接表格儲存事件源,訂閱並透過釘釘傳送天氣提醒通知。
整體架構
回顧一下整體架構:
- 透過 CronJob 事件源,每隔 3 個小時定時傳送定時事件,將國內城市未來 3 天的天氣資訊,儲存更新到表格儲存
- 提供 RESTful API 查詢天氣資訊
- 透過表格儲存提供的通道服務,實現 TableStore 事件源
- 透過 Borker/Trigger 事件驅動模型,訂閱天氣資訊
- 根據訂閱收到的天氣資訊進行釘釘訊息通知。如明天下雨,提示帶傘等
基於 Knative 實現天氣服務-下篇
首先我們介紹一下表格儲存提供的通道服務。通道服務(Tunnel Service)是基於表格儲存資料介面之上的全增量一體化服務。通道服務為您提供了增量、全量、增量加全量三種型別的分散式資料實時消費通道。透過為資料表建立資料通道,您可以簡單地實現對錶中歷史存量和新增資料的消費處理。透過資料通道可以進行資料同步、事件驅動、流式資料處理以及資料搬遷。這裡事件驅動正好契合我們的場景。
先看一下處理流程圖:
- 定義 TableStore 事件源,用於接收通道服務資料
- 透過 Borker/Trigger 事件驅動模型,訂閱天氣資訊
- 訂閱接收到的天氣資訊傳送給天氣提醒服務,進行釘釘訊息通知
下面我們來詳細介紹一下。
自定義 TableStore 事件源
在 Knative 中自定義事件源其實很容易,可以參考官方提供的自定義事件源的例項: 。
我們這裡定義資料來源為 AliTablestoreSource。程式碼實現主要分為兩部分:
- 資源控制器-Controller:接收 AliTablestoreSource 資源,在通道服務中建立 Tunnel
- 事件接收器-Receiver:透過 Tunnel Client 監聽事件,並將接收到的事件傳送到目標服務( Broker)
關於自定義 TableStore 事件源實現參見 GitHub 原始碼:
部署自定義事件源服務如下:
從 /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":" "accessKeyId":"xxxx","accessKeySecret":"xxxx" }
設定並進行 base64 編碼。將結果設定到如下 Secret 配置檔案
alitablestore
屬性中:
apiVersion: v1
kind: Secret
metadata:
name: alitablestore-secret
type: Opaque
data:
# { "url":" "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=
- --adcode=110000
- --date=2019-10-13
- --dayweather=雨
image: registry.cn-hangzhou.aliyuncs.com/knative-sample/dingtalk-weather-service:1.2
建立訂閱
最後我們建立 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。
本文為雲棲社群原創內容,未經允許不得轉載。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69949601/viewspace-2660052/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Knative 實戰:基於 Kafka 實現訊息推送Kafka
- Knative:重新定義 Serverless | GIAC 實錄Server
- Serverless 工程實踐 | 零基礎上手 Knative 應用Server
- 使用Knative基於構建、部署、管理serverless應用Server
- Knative 實戰:一個微服務應用的部署微服務
- K8s 原生 Serverless 實踐:ASK 與 KnativeK8SServer
- Knative Serverless 之道:如何 0 運維、低成本實現應用託管?Server運維
- 實戰CXF呼叫Webxml天氣預報服務WebXML
- 基於Kubernetes和Istio的Serverless框架Knative解析之AutoscalerServer框架
- GitHub - knative/eventing-contrib: 基於knative的Event Sources事件溯源Github事件
- Knative 入門系列1:knative 概述
- 基於Netty實現海量接入的推送服務技術要點Netty
- Google釋出跨雲Serverless管理平臺KnativeGoServer
- 開源 Serverless 里程碑:Knative 1.0 來了Server
- Knative 助力 XTransfer 加速應用雲原生 Serverless 化Server
- 從零入門 Serverless | Knative 帶來的極致 Serverless 體驗Server
- 跟我一起學Knative(6)--部署gRPC服務RPC
- 跟我一起學Knative(1)--Knative 簡介
- Knative 簡介
- 開箱即用,Knative 給您極致的容器 Serverless 體驗Server
- 介紹基於OpenFaaS函式的knative Build教程 - alexellis函式UI
- React服務端渲染實現(基於Dva)React服務端
- Go實現基於WebSocket的彈幕服務GoWeb
- 基於lua協程的AI服務實現AI
- 實戰與原理:如何基於RocketMQ實現分散式事務?MQ分散式
- Serverless:基於個性化服務畫像的彈性伸縮實踐Server
- 基於cJSON及心知天氣模組化實現獲取城市氣象資訊(現在、未來)JSON
- Flutter Weather天氣模組實現Flutter
- 基於 swoole 的 websocket 服務實現狀態同步Web
- 專案實戰(連載):基於Angular2+Mongodb+Node技術實AngularMongoDB
- 微信小程式-基於高德地圖API實現天氣元件(動態效果)微信小程式地圖API元件
- 基於微服務架構的技術實踐(附PPT)微服務架構
- Kubernetes基於haproxy實現ingress服務暴露
- Knative = Kubernetes網路++
- 【深入淺出Sentinel原理及實戰】「基礎實戰專題」零基礎實現服務流量控制實戰開發指南(2)
- IPv6技術詳解:基本概念、應用現狀、技術實踐(下篇)
- 微服務實戰:服務發現的可行方案以及實踐案例微服務
- 【Serverless】Unity快速整合認證服務實現郵件登入ServerUnity