Knative 实战:基于 Knative Serverless 技术实现天气服务-下篇

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
应用实时监控服务-用户体验监控,每月100OCU免费额度
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 上一期我们介绍了如何基于 Knative Serverless 技术实现天气服务-上篇,首先我们先来回顾一下上篇介绍的内容:通过高德天气 API 接口,每隔 3 个小时定时发送定时事件,将国内城市未来 3 天的天气信息,存储更新到表格存储提供 RESTful API 查询天气信息接下来我们介绍如何通过表格存储提供的通道服务,实现 Knative 对接表格存储事件源,订阅并通过钉钉发送天气提醒通知。

上一期我们介绍了如何基于 Knative Serverless 技术实现天气服务-上篇,首先我们先来回顾一下上篇介绍的内容:

  • 通过高德天气 API 接口,每隔 3 个小时定时发送定时事件,将国内城市未来 3 天的天气信息,存储更新到表格存储
  • 提供 RESTful API 查询天气信息

接下来我们介绍如何通过表格存储提供的通道服务,实现 Knative 对接表格存储事件源,订阅并通过钉钉发送天气提醒通知。

整体架构

回顾一下整体架构:

o1

  • 通过 CronJob 事件源,每隔 3 个小时定时发送定时事件,将国内城市未来 3 天的天气信息,存储更新到表格存储
  • 提供 RESTful API 查询天气信息
  • 通过表格存储提供的通道服务,实现 TableStore 事件源
  • 通过 Borker/Trigger 事件驱动模型,订阅天气信息
  • 根据订阅收到的天气信息进行钉钉消息通知。如明天下雨,提示带伞等

基于 Knative 实现天气服务-下篇

首先我们介绍一下表格存储提供的通道服务。通道服务(Tunnel Service)是基于表格存储数据接口之上的全增量一体化服务。通道服务为您提供了增量、全量、增量加全量三种类型的分布式数据实时消费通道。通过为数据表建立数据通道,您可以简单地实现对表中历史存量和新增数据的消费处理。通过数据通道可以进行数据同步、事件驱动、流式数据处理以及数据搬迁。这里事件驱动正好契合我们的场景。

先看一下处理流程图:

o2

  • 定义 TableStore 事件源,用于接收通道服务数据
  • 通过 Borker/Trigger 事件驱动模型,订阅天气信息
  • 订阅接收到的天气信息发送给天气提醒服务,进行钉钉消息通知

下面我们来详细介绍一下。

自定义 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
AI 代码解读

部署完成之后,我们可以看到资源控制器已经开始运行:

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

创建事件源

由于我们是通过 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
AI 代码解读

创建事件源实例

这里需要说明一下,创建事件源实例其实就是在表格存储中创建通道服务,那么就需要配置访问通道服务的地址、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>"
AI 代码解读

创建 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
AI 代码解读

创建 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
AI 代码解读

创建完成之后,我们可以看到运行中的事件源:

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

订阅事件和通知提醒

创建天气提醒服务

如何进行钉钉通知呢,我们可以创建一个钉钉的群组(可以把家里人组成一个钉钉群,天气异常时,给家人一个提醒),添加群机器人:

o3

获取 webhook :

o4

这里我们假设北京 (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
AI 代码解读

关于钉钉提醒服务具体实现参见 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
AI 代码解读

订阅之后,如果北京 (110000),日期:2019-10-13, 天气有雨,会收到如下的钉钉提醒:

o5

这里其实还有待完善的地方:

  • 是否可以基于城市进行订阅(只订阅目标城市)?
  • 是否可以指定时间发送消息提醒(当天晚上 8 点准时推送第 2 天的天气提醒信息)?

有兴趣的可以继续完善当前的天气服务功能。

小结

本文介绍了如何在 Knative 中自定义事件源,并通过事件驱动接收天气变化信息,订阅并通过钉钉推送通知提醒。这样基于 Knative Serverless 技术实现天气服务整体实现就介绍完了。有兴趣的同学可以针对上面提到的不足继续研究。还是那句话,做好天气服务不容易,但还好我有 Knative。

欢迎加入 Knative 交流群

o6

“ 阿里巴巴云原生微信公众号(ID:Alicloudnative)关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术公众号。”

相关实践学习
【文生图】一键部署Stable Diffusion基于函数计算
本实验教你如何在函数计算FC上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。函数计算提供一定的免费额度供用户使用。本实验答疑钉钉群:29290019867
建立 Serverless 思维
本课程包括: Serverless 应用引擎的概念, 为开发者带来的实际价值, 以及让您了解常见的 Serverless 架构模式
目录
打赏
0
0
0
0
12697
分享
相关文章
科普文:云计算服务类型IaaS, PaaS, SaaS, BaaS, Faas说明
本文介绍了云计算服务的几种主要类型,包括IaaS(基础设施即服务)、PaaS(平台即服务)、SaaS(软件即服务)、BaaS(后端即服务)和FaaS(函数即服务)。每种服务模式提供了不同的服务层次和功能,从基础设施的提供到应用的开发和运行,再到软件的交付使用,满足了企业和个人用户在不同场景下的需求。文章详细阐述了每种服务模式的特点、优势和缺点,并列举了相应的示例。云计算服务的发展始于21世纪初,随着互联网技术的普及,这些服务模式不断演进,为企业和个人带来了高效、灵活的解决方案。然而,使用这些服务时也需要注意服务的稳定性、数据安全性和成本等问题。
3753 5
云原生应用实战:基于阿里云Serverless的API服务开发与部署
随着云计算的发展,Serverless架构日益流行。阿里云函数计算(Function Compute)作为Serverless服务,让开发者无需管理服务器即可运行代码,按需付费,简化开发运维流程。本文从零开始,介绍如何使用阿里云函数计算开发简单的API服务,并探讨其核心优势与最佳实践。通过Python示例,演示创建、部署及优化API的过程,涵盖环境准备、代码实现、性能优化和安全管理等内容,帮助读者快速上手Serverless开发。
Serverless Argo Workflows大规模计算工作流平台荣获信通院“云原生技术创新标杆案例”
2024年12月24日,阿里云Serverless Argo Workflows大规模计算工作流平台荣获由中国信息通信研究院颁发的「云原生技术创新案例」奖。
Elasticsearch Serverless高性价比智能时序分析关键技术解读
本篇演讲由阿里云1s团队的贾新寓讲解,主题为高性价比、智能日志更新关键技术。内容分为四部分:回顾日志场景痛点、介绍四大关键能力(开箱即用、高性能低成本、按量付费、智能调度免运维)、解读关键技术(如读写分离架构、ES内核优化等),并演示如何快速接入Serverless产品。通过这些技术,显著提升性能、降低成本,帮助用户实现高效日志管理。
PolarDB Serverless 模式通过自动扩缩容技术,根据实际工作负载动态调整资源,提高系统灵活性与成本效益
PolarDB Serverless 模式通过自动扩缩容技术,根据实际工作负载动态调整资源,提高系统灵活性与成本效益。用户无需预配高固定资源,仅需为实际使用付费,有效应对流量突变,降低总体成本。示例代码展示了基本数据库操作,强调了合理规划、监控评估及结合其他云服务的重要性,助力企业数字化转型。
109 6
Elasticsearch Serverless 高性价比智能日志分析关键技术解读
本文解析了Elasticsearch Serverless在智能日志分析领域的关键技术、优势及应用价值。
300 8
Elasticsearch Serverless 高性价比智能日志分析关键技术解读
魔搭社区与函数计算:高效部署开源大模型的文本生成服务体验
在数字化时代,人工智能技术迅速发展,开源大模型成为重要成果。魔搭社区(ModelScope)作为开源大模型的聚集地,结合阿里云函数计算,提供了一种高效、便捷的部署方式。通过按需付费和弹性伸缩,开发者可以快速部署和使用大模型,享受云计算的便利。本文介绍了魔搭社区与函数计算的结合使用体验,包括环境准备、部署应用、体验使用和资源清理等步骤,并提出了改进建议。
"揭秘D2终端大会热点技术:Serverless架构最佳实践全解析,让你的开发效率翻倍,迈向技术新高峰!"
【10月更文挑战第23天】D2终端大会汇聚了众多前沿技术,其中Serverless架构备受瞩目。它让开发者无需关注服务器管理,专注于业务逻辑,提高开发效率。本文介绍了选择合适平台、设计合理函数架构、优化性能及安全监控的最佳实践,助力开发者充分挖掘Serverless潜力,推动技术发展。
246 1
前端技术新趋势:从PWA到Serverless架构
【10月更文挑战第1天】前端技术新趋势:从PWA到Serverless架构
90 3

云原生

+关注

相关产品

  • 函数计算
  • AI助理

    你好,我是AI助理

    可以解答问题、推荐解决方案等