Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Serverless Application Programming Model in Cloud-Native Scenarios

Serverless Application Programming Model in Cloud-Native Scenarios

This article discusses Serverless application and various tools, including ASK, ECI, and Knative.

By Yuanyi

Background

Alibaba Cloud Serverless Kubernetes (ASK) is a serverless Kubernetes container service. The underlying layer is based on Elastic Container Instance (ECI) and allows you to create secure and isolated container applications without purchasing ECS nodes. ASK has passed the conformance test of Kubernetes, providing a fully compatible community-based Kubernetes experience.

Knative is an open-source serverless application orchestration framework based on Kubernetes. Its goal is to formulate cloud-native and cross-platform serverless application orchestration standards. Based on ASK, Alibaba Cloud Knative is fully compatible with the community Knaitve. It orchestrates Function Compute (FC) and ECI workloads, supports event-driven and automatic elasticity, and provides a unified serverless application programming model.

Architecture

Next, we will introduce the architecture through a barrage service demo. The demo includes HomePage, event-driven, and message processing.

HomePage is mainly used to send and receive barrage. Event drivers are used to receive, filter, and forward events. Message processing is used to process barrage messages. HomePage and message processing are deployed to FC and ECI respectively through Knative Serving, and event drivers are deployed to ECI through Knative Eventing.

The main flow of the pop-up service demo is shown in the figure below. The user sends the pop-up message to HomePage through the frontend, and HomePage sends the pop-up message to Kafka. Then, the event driver receives the pop-up message and routes it to message processing for processing. After the pop-up is processed, the pop-up result is sent to the Tablestore, and the frontend obtains the pop-up result and displays it on the page.

1

Next, we begin to deploy the barrage service demo. The operations include the following:

Deploy message processing, deploy event-driven, deploy HomePage, and perform pop-up service access after deployment is completed.

Step 1: Deploy Message Processing

This service is used to receive pop-up requests sent by the event driver and scale out the request automatically based on the number of requests. After the pop-up message is processed, the results are sent to the Tablestore. Before deployment, confirm there are no workloads to observe the results after deployment.

  • Select ask cluster
  • In the left-side navigation pane, choose Workloads > Deployments. Select the default namespace and confirm there is no current workload.

2

Then, use Knative to deploy message processing to ECI workloads. Here, we use the yaml method to deploy. The content of yaml is listed below:

code_1

Parameter Description:

  • minScale and maxScale indicate the minimum and maximum number of pods configured for the service.
  • containerConcurrency indicates the maximum request parallelism of the configured pods.
  • OTS_ENDPOINT indicates the configured Tablestore endpoint.
  • TRACING indicates the configured call connection address.

Then, deploy the service:

text_1

Step 2: Deploy Event-Driven

text_2

apiVersion: sources.knative.dev/v1alpha1
kind: KafkaSource
metadata:
  annotations:
    k8s.aliyun.com/req-timeout: "60"
    k8s.aliyun.com/retry-count: "5"
    k8s.aliyun.com/retry-interval: "2"
  name: barrage
  namespace: default
spec:
  bootstrapServers: 192.168.42.205:9092,192.168.42.204:9092,192.168.42.203:9092
  consumerGroup: barrage-info-consumer
  sink:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: test-barrage-process
      namespace: default
  topics: barrage-info

Parameter Description:

  • The Kafka configuration includes the Kafka service address, pop-up message topics, and consumerGroup.
  • Target Message Processing for Routing: test-barrage-process

Then, deploy the service:

text_3

The message above says the processing and event driver have been deployed. Let's verify it.

On the left-side navigation pane of the cluster management page, choose Workloads > Pods

In the container group, you can see that the message processing and Kafka event source instances are running.

3

Step 3: Deploy HomePage

text_4

  • Log on to the FC console
  • In the top navigation bar, select a region (Shanghai)

Open the Services and Functions page and confirm there are no pop-up services and functions.

4

  • On the left-side navigation pane, click Custom Domain Name

Open the Custom Domain Name page and confirm that no custom domain name is available:

5

Next, we use Knative to deploy HomePage to FC type workloads. Here, we use yaml to deploy. The content of yaml is listed below:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: demo-barrage
  annotations:
    workload.serving.knative.aliyun.com/class: "fc"
spec:
  template:
    metadata:
      annotations:
        fc.revision.serving.knative.aliyun.com/code-space: "image"
        fc.revision.serving.knative.aliyun.com/role-arm: "acs:ram::xxxx:role/knative-fc"
        fc.revision.serving.knative.aliyun.com/domain: '{"domain":"barrage.demo.knative.top","path":"/*"}'
    spec:
      containers:
        - image: registry.cn-shanghai.aliyuncs.com/knative-sample/barrage-main:forrester-yuanyi_4cd77c84-20210618214527
          env:
            - name: OTS_ENDPOINT
              value: https://barrage.cn-hangzhou.ots.aliyuncs.com
            - name: TABLE_NAME
              value: barrage
            - name: OTS_INSTANCENAME
              value: barrage
            - name: OTS_KEYID
              value: xxx
            - name: OTS_SECRET
              value: xxx
            - name: KAFKA_SERVER
              value: "106.15.11.179:9093,47.100.131.71:9093,47.102.44.91:9093"
            - name: KAFKA_USER
              value: "alikafka_pre-cn-xxx"
            - name: KAFKA_PWD
              value: "xxx"
            - name: KAFKA_TOPIC
              value: "barrage-info"
            - name: TRACING
              value: "http://tracing-analysis-dc-sh.aliyuncs.com/adapt_g2it2kg78n@5cf06035aec2eb9_g2it2kg78n@53df7ad2afe8301/api/traces"
            - name: TRACE_NAME1
              value: "sender"
            - name: TRACE_NAME2
              value: "receiver"
            - name: TRACE_NAME3
              value: "result"
            - name: PARENT_SPAN
              value: "barrage-sender"
            - name: SUB_SPAN1
              value: "sender"
            - name: SUB_SPAN2
              value: "result"

Parameter Description:

  • The configuration of FC-related parameters: deploy fc-type workloads, deploy them by mirroring, and specify the access domain name as barrage.demo.knative.top
  • Configure the Tablestore access address: OTS_ENDPOINT
  • Configuration of kafka-related parameters: Kafka service address and bullet message topic
  • Call Address Configuration: TRACING

Then, deploy the service:

text_5

After the deployment is complete, let's verify it in the Function Compute console:

  • Log on to the Function Compute console
  • On the top navigation bar, select a region
  • On the left-side navigation pane, click Services and Functions

Open the Services and Functions page, and you can see that HomePage has been deployed:

6

  • On the left-side navigation pane, click Custom Domain Name

On the Custom Domain Name page, you can see that the domain name you have configured is created automatically:

7

Step 4: Service Access

All the services above have been deployed. Now, we can access the services through a custom domain name. http://barrage.demo.knative.top

Next, we will send the barrage. Here, we can customize the message, parallelism, and duration of the barrage to be sent. We use the default configuration to send it.

Set Message, Concurrency, and Duration, and click Send.

8

We can see that barrage messages are constantly on display.

9

Summary

On top of Serverless Kubernetes, Alibaba Cloud Knative provides a unified programming model for containers and functions, bringing you a unified Serverless application programming model. You are welcome to communicate together.

Programming Computing Container Service Serverless Kubernetes cloud native ECI Knative Serverless Kubernetes ask
0 0 0
Share on

Read previous post:

The Flexvolume Scenario Disk Migration Solution

Read next post:

Serverless Containers and Automatic Scaling Based on Traffic Patterns

Alibaba Container Service

177 posts | 31 followers

You may also like

Comments

Alibaba Container Service

177 posts | 31 followers

Related Products

  • Function Compute

    Alibaba Cloud Function Compute is a fully-managed event-driven compute service. It allows you to focus on writing and uploading code without the need to manage infrastructure such as servers.

    Learn More

  • Container Service for Kubernetes

    Alibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.

    Learn More

  • Serverless Workflow

    Visualization, O&M-free orchestration, and Coordination of Stateful Application Scenarios

    Learn More

  • Serverless Application Engine

    Serverless Application Engine (SAE) is the world's first application-oriented serverless PaaS, providing a cost-effective and highly efficient one-stop application hosting solution.

    Learn More

More Posts by Alibaba Container Service

See All