Shulou(Shulou.com)06/01 Report--

This article shows you how to implement weather services based on Knative Serverless technology, the content is concise and easy to understand, it will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

When it comes to weather forecasting service, our first reaction is a very simple service. At present, there are a lot of weather forecast API on the Internet that can be used directly. Is it necessary to use Knative to set up a set? Break a butterfly on the wheel? Don't worry, let's take a look at the actual scenario requirements:

Scene demand 1: according to the local weather information over the years, predict the approximate time of high temperature next year.

Scene requirement 2: the weather is changeable recently. If it rains tomorrow, could you give me a reminder with an umbrella before going to work in the morning?

Scenario requirement 3: the leader said: the recent economic downturn, the company's financial constraints, the server, you provide weather, road conditions and other services with the Mini Program bar, but to ensure that normal services.

From the above demand, we actually find that in order to do a good weather forecasting service, it is not so simple to face internal worries (resource shortage) and external problems (increased demand). But don't worry now, we can use Knative to help you solve the above problems.

Keywords: weather query, table storage, channel service, event notification

Scene requirement

First of all, let's describe the weather service scenario we are going to do:

1. Provide external weather forecast RESTful API

Query the weather information of domestic cities according to city and date (support for the next 3 days)

No limit on the number of queries, supporting larger concurrent queries (1000)

two。 Weather subscription reminder

Subscribe to domestic city weather information, according to the actual subscription to the urban area, remind you to bring an umbrella when it rains tomorrow

Use nails to notify

Overall architecture

When there is a demand, then we begin to implement weather services based on Knative. Let's first take a look at the overall architecture:

Through the CronJob event source, regular events are sent every 3 hours, and the weather information of domestic cities in the next 3 days is stored and updated to the table.

Provide RESTful API to query weather information

Realize the TableStore event source through the channel service provided by table storage.

Subscribe the weather information of the target city through the Borker/Trigger event-driven model

The nailing message notification is made according to the weather information received by the subscription. If it rains tomorrow, remind you to bring an umbrella, etc.

Provide external weather forecast RESTful API

Docking with Gaode open platform weather forecast API

There are many API for weather query. Here we choose the weather query API provided by Gaode Open platform, which is easy to use and stable. The weather forecast API provides 100000 free calls every day to support weather information query in more than 3500 regions of China. In addition, Gaode open platform, in addition to weather forecast, can also provide ip positioning, search services, path planning, etc., interested can also study how to play. Log in to Gaode Open platform: https://lbs.amap.com, create an application, and obtain Key:

After obtaining the Key, you can access it directly through url: https://restapi.amap.com/v3/weather/weatherInfo?city=110101&extensions=all&key=. The weather information is returned as follows:

{"status": "1", "count": "1", "info": "OK", "infocode": "10000", "forecasts": [{"city": "Hangzhou", "adcode": "330100", "province": "Zhejiang", "reporttime": "2019-09-24 20:49:27" "casts": [{"date": "2019-09-24", "week": "2", "dayweather": "Qing", "nightweather": "cloudy", "daytemp": "29" "nighttemp": "17", "daywind": "No wind direction", "nightwind": "no wind direction", "daypower": "≤ 3", "nightpower": "≤ 3"},...]}]}

Synchronize and update weather information regularly

Synchronize and update weather information

This function mainly realizes the docking of Gaode open platform weather forecast API to obtain weather forecast information, and the docking of Aliyun Table Storage Service (TableStore) for weather forecast data storage. The specific operations are as follows:

Receive CloudEvent timing events

Query the weather information of each region

Store or update weather information to table storage

In Knative, we can directly create services as follows:

ApiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata: name: weather-store namespace: defaultspec: 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

For more information about the specific implementation of the service, see GitHub source code: https://github.com/knative-sample/weather-store

Create a scheduled event

There may be a question here: why not do a timed poll directly in the service, instead of making a timed event trigger execution call through Knative Eventing? So let's make it clear that this is how it should be played in the Serverless era-on demand. Never run these scheduled tasks in the traditional way in the service, dear, this is a continuous waste of computing resources. To get to the point, let's use the timing task data source (CronJobSource) that comes with Knative Eventing to trigger timing synchronization events. Create a CronJobSource resource to trigger synchronous Weather Service (weather-store) every 3 hours. The WeatherCronJob.yaml is as follows:

ApiVersion: sources.eventing.knative.dev/v1alpha1kind: CronJobSourcemetadata: name: weather-cronjobspec: schedule: "0 * / 3 *" data:'{"message": "sync"} 'sink: apiVersion: serving.knative.dev/v1alpha1 kind: Service name: weather-store

Execute the command:

Kubectl apply-f WeatherCronJob.yaml

Now when we log in to Aliyun's table storage service, we can see that the weather forecast data has been synchronized according to the format of city and date.

Provide weather forecast query RESTful API

With these weather data, we can provide our own weather forecasting service at will (it feels like we have contracted a piece of land and we will be the landlords). There is no difficulty here. Query the corresponding weather data from the table storage and encapsulate it according to the returned data format. In Knative, we can deploy the RESTful API service as follows:

ApiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata: name: weather-service namespace: defaultspec: 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}

Specific implementation source code GitHub address: https://github.com/knative-sample/weather-service query weather RESTful API:

Request URL GET / api/weather/query

Parameter: cityCode: city area code. For example, Beijing area code: 110000date: query date. Such as format: 2019-09-26

Return the result

{"code": 200," message ":"," data ": {" adcode ":" 110000 "," city ":" Beijing "," date ":" 2019-09-26 "," daypower ":" ≤ 3 "," daytemp ":" 30 "," dayweather ":" Qing "," daywind ":" Southeast "," nightpower ":" ≤ 3 " "nighttemp": "15", "nightweather": "Qing", "nightwind": "Southeast", "province": "Beijing", "reporttime": "2019-09-25 14:50:46", "week": "4"}}

Query: Hangzhou, 2019-09-26 Weather Forecast sample Test address: http://weather-service.default.knative.kuberun.com/api/weather/query?cityCode=330100&date=2019-11-06 additional city area code table can be viewed in the source code GitHub provided above, or you can download it from Gaode Open platform: https://lbs.amap.com/api/webservice/download

Weather subscription reminder

First of all, let's introduce the channel services provided by table storage. Channel Service (Tunnel Service) is a fully incremental integrated service based on table storage data interface. Channel service provides you with three types of distributed real-time data consumption channels: incremental, full, incremental plus full. By establishing a data channel for the data table, you can simply realize the consumption of the historical stock and new data in the table. Data synchronization, event-driven, streaming data processing and data relocation can be carried out through the data channel. The event-driven here fits our scene.

Customize the TableStore event source

It's actually easy to customize event sources in Knative. You can refer to the official example of custom event sources: https://github.com/knative/docs/tree/master/docs/eventing/samples/writing-a-source. Here we define the data source as AliTablestoreSource. The code implementation is mainly divided into two parts:

Resource controller-Controller: receives the AliTablestoreSource resource and creates the Tunnel in the channel service.

Event receiver-Receiver: listens for events through Tunnel Client and sends received events to the target service (Broker)

For custom TableStore event source implementation, see GitHub source code: https://github.com/knative-sample/tablestore-source

Deploy the custom event source service as follows: you can get the event source deployment file from https://github.com/knative-sample/tablestore-source/tree/master/config and do the following

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

After the deployment is complete, we can see that the resource controller is already running:

[root@iZ8vb5wa3qv1gwrgb3lxqpZ config] # kubectl-n knative-sources get podsNAME READY STATUS RESTARTS AGEalitablestore-controller-manager-0 1 + 1 Running 0 4h22m

Create an event source

Because we deal with weather events through the Broker/Trigger event-driven model in Knative Eventing. First, we create a Broker service for data reception.

Create Broker

ApiVersion: eventing.knative.dev/v1alpha1kind: Brokermetadata: name: weatherspec: channelTemplateSpec: apiVersion: messaging.knative.dev/v1alpha1 kind: InMemoryChannel

Create an event source instance

It needs to be explained here that to create an event source instance is to create a channel service in the table store, so you need to configure the address, accessKeyId and accessKeySecret to access the channel service. Here, refer to the format: {"url": "https://xxx.cn-beijing.ots.aliyuncs.com/"," accessKeyId ":" xxxx "," accessKeySecret ":" xxxx "} and base64 encoding. Set the result to the following Secret profile alitablestore property:

ApiVersion: v1kind: Secretmetadata: name: alitablestore-secrettype: Opaquedata: # {"url": "https://xxx.cn-beijing.ots.aliyuncs.com/"," accessKeyId ":" xxxx "," accessKeySecret ":" xxxx "} alitablestore:"

Create RBAC permissions

ApiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: eventing-sources-alitablestoresubjects:- kind: ServiceAccount name: alitablestore-sa namespace: defaultroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: eventing-sources-alitablestore-controller---apiVersion: v1kind: ServiceAccountmetadata: name: alitablestore-sasecrets:- name: alitablestore-secret

Create an AliTablestoreSource instance, where we set the sink that receives the event to the Broker service created above.

-apiVersion: sources.eventing.knative.dev/v1alpha1kind: AliTablestoreSourcemetadata: labels: controller-tools.k8s.io: "1.0" name: alitablestoresourcespec: # Add fields here serviceAccountName: alitablestore-sa accessToken: secretKeyRef: name: alitablestore-secret key: alitablestore tableName: weather instance: knative-weather sink: apiVersion: eventing.knative.dev/v1alpha1kind: Broker name: weather

After the creation is complete, we can see the running event source:

[root@iZ8vb5wa3qv1gwrgb3lxqpZ config] # kubectl get podsNAME READY STATUS RESTARTS AGEtablestore-alitablestoresource-9sjqx-656c5bf84b-pbhvw 1/1 Running 0 4h9m

Subscribe to event and notification reminders

Create a weather reminder service

How to notify the nailing? we can create a nailing group (we can group the family into a nailing group and give the family a reminder when the weather is abnormal) and add a group of robots:

Get webhook:

Here we assume that Beijing (110000), date: 2019-10-13, if the weather is rainy, send a notification reminder through nails, then the service configuration is as follows:

ApiVersion: serving.knative.dev/v1beta1kind: Servicemetadata: name: day-weatherspec: template: spec: containers:-args:-dingtalkurl= https://oapi.dingtalk.com/robot/send?access_token=xxxxxx-adcode=110000-date=2019-10-13-dayweather= Rain image: registry.cn-hangzhou.aliyuncs.com/knative-sample/dingtalk-weather-service:1.2

For more information about the implementation of nail reminder service, please see GitHub source code: https://github.com/knative-sample/dingtalk-weather-service

Create a subscription

Finally, we create a Trigger to subscribe to weather events and trigger the weather reminder service:

ApiVersion: eventing.knative.dev/v1alpha1kind: Triggermetadata: name: weather-triggerspec: broker: weather subscriber: ref: apiVersion: serving.knative.dev/v1alpha1 kind: Service name: day-weather

After subscription, if Beijing (110000), date: 2019-10-13, the weather is rainy, you will receive the following nail reminder:

In fact, there is still room for improvement:

Can I subscribe based on the city (subscribe to the target city only)?

Can I send a message reminder at a specified time (the weather reminder for day 2 will be pushed at 8: 00 p. M. that day)?

The above content is how to implement weather services based on Knative Serverless technology. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.