怎么基于KnativeServerless技术实现天气服务-创新互联
本篇文章为大家展示了怎么基于 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访问: /tupian/20230522/weatherInfo "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 中可以查看,也可以到高德开放平台中下载: /tupian/20230522/summary class="Editable-styled">
天气订阅提醒
首先我们介绍一下表格存储提供的通道服务。通道服务(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
部署自定义事件源服务如下: 从 /tupian/20230522/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 4h22m
创建事件源
由于我们是通过 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=/tupian/20230522/send - --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 Serverless 技术实现天气服务,你们学到知识或技能了吗?如果还想学到更多技能或者丰富自己的知识储备,欢迎关注创新互联-成都网站建设公司行业资讯频道。
当前名称:怎么基于KnativeServerless技术实现天气服务-创新互联
文章转载:http://ybzwz.com/article/ghoci.html