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

本文涉及的产品
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
函数计算FC,每月15万CU 3个月
简介: 提到天气预报服务,我们第一反应是很简单的一个服务,但实际做好天气预报服务其实并没有那么简单,本文通过 Knative Serverless 角度出发,给你介绍如何基于新一代 Serverless 技术玩转天气服务

提到天气预报服务,我们第一反应是很简单的一个服务啊,目前网上有大把的天气预报 API 可以直接使用,有必要去使用 Knative 搞一套吗?杀鸡用牛刀?先不要着急,我们先看一下实际的几个场景需求:

  • 场景需求1:根据当地历年的天气信息,预测明年大致的高温到来的时间
  • 场景需求2:近来天气多变,如果明天下雨,能否在早上上班前,给我一个带伞提醒通知
  • 场景需求3:领导发话:最近经济不景气,公司财务紧张,那个服务器,你们提供天气、路况等服务的那几个小程序一起用吧,但要保证正常提供服务。

从上面的需求,我们其实发现,要做好一个天气预报的服务,也面临内忧(资源紧缺)外患(需求增加),并不是那么简单的。不过现在更不要着急,我们可以使用 Knative 帮你解决上面的问题。

关键词:天气查询、表格存储,通道服务,事件通知

场景需求

首先我们来描述一下我们要做的天气服务场景需求:

1. 提供对外的天气预报 RESTful API

  • 根据城市、日期查询(支持未来 3 天)国内城市天气信息
  • 不限制查询次数,支持较大并发查询(1000)

2. 天气提醒

  • 订阅国内城市天气信息,根据实际订阅城市区域,提醒明天下雨带伞
  • 使用钉钉进行通知

整体架构

有了需求,那我们就开始如何基于 Knative 实现天气服务。我们先看一下整体架构:
image

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

基于内容较多,我们分上、下两篇分别进行介绍:

  • 上篇我们会主要介绍如何对接第三方的天气预报API、定时同步并更新天气信息以及提供RESTful API。
  • 下篇我们会主要介绍如何实现 TableStore 事件源、订阅天气信息并通过钉钉发送提醒通知。

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

对接高德开放平台天气预报 API

查询天气的 API 有很多,这里我们选择高德开放平台提供的天气查询 API,使用简单、服务稳定,并且该天气预报 API 每天提供 100000 免费的调用量,支持国内 3500 多个区域的天气信息查询。另外高德开放平台,除了天气预报,还可以提供 ip 定位、搜索服务、路径规划等,感兴趣的也可以研究一下玩法。
登录高德开放平台: https://lbs.amap.com, 创建应用,获取 Key 即可:
image

获取Key之后,可以直接通过url访问:https://restapi.amap.com/v3/weather/weatherInfo?city=110101&extensions=all&key=<用户key>,返回天气信息数据如下:

{
    "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

现在我们登录阿里云表格存储服务,可以看到天气预报数据已经按照城市、日期的格式同步进来了。
image

提供天气预报查询 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.serverless.kuberun.com/api/weather/query?cityCode=330100&date=2019-09-26
另外城市区域代码表可以在上面提供的源代码 GitHub 中可以查看,也可以到高德开放平台中下载:https://lbs.amap.com/api/webservice/download

小结

通过上面的介绍,大家对如何通过 Knative 提供天气预报实现应该有了更多的体感,其实类似的场景我们有理由相信通过 Knative Serverless 可以帮你做到资源利用游刃有余。下一篇会继续我们要实现的内容:通过 Knative 事件驱动,订阅天气信息,钉钉推送通知提醒,欢迎持续关注。

欢迎加入 Knative 交流群

image

相关实践学习
【AI破次元壁合照】少年白马醉春风,函数计算一键部署AI绘画平台
本次实验基于阿里云函数计算产品能力开发AI绘画平台,可让您实现“破次元壁”与角色合照,为角色换背景效果,用AI绘图技术绘出属于自己的少年江湖。
从 0 入门函数计算
在函数计算的架构中,开发者只需要编写业务代码,并监控业务运行情况就可以了。这将开发者从繁重的运维工作中解放出来,将精力投入到更有意义的开发任务上。
目录
相关文章
|
6月前
|
关系型数据库 MySQL Shell
MySQL 备份 Shell 脚本:支持远程同步与阿里云 OSS 备份
一款自动化 MySQL 备份 Shell 脚本,支持本地存储、远程服务器同步(SSH+rsync)、阿里云 OSS 备份,并自动清理过期备份。适用于数据库管理员和开发者,帮助确保数据安全。
|
9月前
|
消息中间件 缓存 监控
go高并发之路——消息中间件kafka
本文介绍了高并发业务中的流量高峰应对措施,重点讲解了Kafka消息中间件的使用,包括常用的Go语言库sarama及其版本问题,以及Kafka的版本选择建议。文中还详细解释了Kafka生产者的四种分区策略:轮询、随机、按Key和指定分区,并提供了相应的代码示例。
210 1
go高并发之路——消息中间件kafka
|
10月前
|
缓存 监控 数据挖掘
C# 一分钟浅谈:性能测试与压力测试
【10月更文挑战第20天】本文介绍了性能测试和压力测试的基础概念、目的、方法及常见问题与解决策略。性能测试关注系统在正常条件下的响应时间和资源利用率,而压力测试则在超出正常条件的情况下测试系统的极限和潜在瓶颈。文章通过具体的C#代码示例,详细探讨了忽视预热阶段、不合理测试数据和缺乏详细监控等常见问题及其解决方案,并提供了如何避免这些问题的建议。
219 7
|
人工智能 运维 Serverless
【云故事探索】NO1:看森马服饰,在阿里云上如何用AI实现创新?
在数字化转型中,云计算成为企业创新的关键驱动力。森马服饰借助阿里云函数计算,应对新零售挑战,实现业务模式重塑和效率提升。面对AI技术落地的困难,如高成本、长决策周期和复杂运维,森马通过阿里云的Serverless解决方案,快速将AI融入核心业务,优化了从设计到营销的全链条流程。通过函数计算,森马降低了AI项目初期的硬件投入和运维难题,提升了设计师的工作效率,将设计时间从3天缩短到30秒,实现了服装设计和营销的智能化升级。
|
Linux 应用服务中间件 Shell
在CentOS 7上安装和使用Docker Compose的方法
在CentOS 7上安装和使用Docker Compose的方法
1047 0
|
存储 应用服务中间件 nginx
Elasticsearch-Alias别名的2个核心场景
了解Elasticsearch的Alias别名之后,可以在业务上很方便的实现复杂需求,快速解决问题,本文从3个方面介绍:官方定义、使用场景、使用方法。
|
前端开发 Java 开发者
【Spring】Spring 6 新特性一一HTTP Interface
Spring 6 的第一个 GA 版本发布了,其中带来了一个新的特性——HTTP Interface。 这个新特性,可以让开发者将 HTTP 服务,定义成一个包含特定注解标记的方法的 Java 接口,然后通过对接口方法的调用,完成 HTTP 请求。下面我们参考官方文档来完成一个 Demo。
490 1
【Spring】Spring 6 新特性一一HTTP Interface
|
Web App开发 Java Windows
WebDriver多线程并发
要想多线程并发的运行WebDriver,必须同时满足2个条件,首先你的测试程序是多线程,其次需要用到Selenium Server。下载位置如下图:   下载下来后是一个jar包,需要在命令行中运行。
2043 0
|
缓存 NoSQL Java
Shiro整合EhCache缓存(九)
Shiro整合EhCache缓存(九)
611 0
Shiro整合EhCache缓存(九)

相关产品

  • 函数计算