Knative Actual Warfare: Implementing Weather Service Based on Knative Serverless Technology - Part II

Keywords: github encoding

How did we describe in the last issue? Implementation of Weather Service Based on Knative Serverless Technology First of all, let's review what we introduced in the previous part.

  • Through the Gaud Weather API interface, regular events are sent every three hours, and the weather information of the domestic cities in the next three days is stored and updated to table storage.
  • Provide RESTful API to query weather information

Next, we introduce how to store event source by Knative docking table through the channel service provided by table storage, subscribe and send weather reminder notification through nails.

Overall framework

Review the overall architecture:

  • Through CronJob Event Source, timed events are sent every three hours regularly, and the weather information of domestic cities in the next three days is stored and updated to table storage.
  • Provide RESTful API to query weather information
  • Implementation of TableStore Event Source through Channel Service Provided by Table Storage
  • Subscribe to weather information through Borker/Trigger event-driven model
  • Nail message notification based on weather information received by subscription. If it rains tomorrow, bring an umbrella, etc.

Implementation of Weather Service Based on Knative

Let's first introduce the channel services provided by table storage. Tunnel Service is a fully incremental integrated service based on table storage data interface. Channel services provide you with three types of distributed data real-time consumption channels: incremental, full and incremental. By establishing data channels for the tables, you can simply consume the historical stock and new data in the tables. Data synchronization, event-driven, streaming data processing and data relocation can be achieved through data channels. Event-driven here fits our scenario.

First look at the processing flow chart:

  • Define the TableStore event source for receiving channel service data
  • Subscribe to weather information through Borker/Trigger event driven model
  • Subscribe the received weather information and send it to the weather alert service for nail message notification

Now let's go into details.

Customize TableStore Event Source

It's easy to customize event sources in Knative. You can refer to an official example of a custom event source: https://github.com/knative/docs/tree/master/docs/eventing/samples/writing-a-source.

We define the data source here as AliTableStorSource. Code implementation is mainly divided into two parts:

  1. Resource Controller: Receives AliTableStorSource resources and creates Tunnel in channel services
  2. Event Receiver: listens for events through Tunnel Client and sends the received events to the target service (Broker)

See GitHub source code for custom TableStore event source implementations: https://github.com/knative-sample/tablestore-source

Deploy custom event source services as follows:

from https://github.com/knative-sample/tablestore-source/tree/master/config The event source deployment file can be retrieved and the following operations can be performed:

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 deployment, we can see that the resource controller has started to run:

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

Create event sources

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

Create Broker

apiVersion: eventing.knative.dev/v1alpha1
kind: Broker
metadata:
  name: weather
spec:
  channelTemplateSpec:
    apiVersion: messaging.knative.dev/v1alpha1
    kind: InMemoryChannel

Create event source instances

It needs to be explained here that creating an event source instance is actually creating a channel service in a table store. Then you need to configure the address of the access channel service, accessKeyId and accessKeySecret, with reference to the format: {"url": "https://xxx.cn-beijing.ots.aliyuncs.com/", "access KeyId", "xxx", "access KeySecret", "xxxxxx"} settings and E64 encoding. Set the results to the following Secret configuration file alitablestore property:

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

Create RBAC permissions:

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

Create an instance of AliTablestoreSource, where we set sink to receive events as the Broker service created above.

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

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

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

Subscription events and notification reminders

Create weather alert service

How to make nail notification? We can create a nail group (we can make the family into a nail group, when the weather is abnormal, give a reminder to the family), add a group of robots:

Get webhook:

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

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=rain
        image: registry.cn-hangzhou.aliyuncs.com/knative-sample/dingtalk-weather-service:1.2

Refer to the GitHub source code for the implementation of the nail reminder service: https://github.com/knative-sample/dingtalk-weather-service

Create subscription

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

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

After subscription, if Beijing (110000), Date: 2019-10-13, Rainy weather, will receive the following nail reminders:

In fact, there is still room for improvement:

  • Is it possible to subscribe based on the city (subscribe only to the target city)?
  • Can you send a message reminder at a specified time (the weather reminder for the second day will be pushed on time at 8 p.m. that day)?

Interested parties can continue to improve the current weather service functions.

Summary

This paper introduces how to customize event source in Knative, receive weather change information through event-driven, subscribe and push notifications through nails. In this way, the overall implementation of weather service based on the knowledge serverless technology is introduced. Interested students can continue to study the shortcomings mentioned above. Still, it's not easy to do a good job of weather service, but fortunately I have Knative.

Welcome to Knative Exchange Group

"Alibaba Cloud Primary Wechat Public Number (ID: Alicloudnative) focuses on micro-services, Serverless, containers, Service Mesh and other technical areas, focuses on the trend of cloud primitive popular technology, cloud primitive large-scale landing practices, and makes the technical public number that knows the most about cloud primitive developers."

This article by the blog article multiple platform OpenWrite Release!

Posted by Albright on Fri, 11 Oct 2019 23:55:11 -0700