![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/9c598dd5edf542e793fce7c90e15c9f0.png)

作者 | 計緣
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/pF3yj6LPD5m7WpP6CT8kOA)

眾所周知，遊戲行業在當今的網際網路行業中算是一棵常青樹。在疫情之前的 2019 年，中國遊戲市場營收規模約 2884.8 億元，同比增長 17.1%。2020 年因為疫情，遊戲行業更是突飛猛進。玩遊戲本就是中國網民最普遍的娛樂方式之一，疫情期間更甚。據不完全統計，截至 2019 年，中國移動遊戲使用者規模約 6.6 億人，佔中國總網民規模 8.47 億的 77.92%，可見遊戲作為一種低門檻、低成本的娛樂手段，已成為大部分人生活中習以為常的一部分。

對於玩家而言，市面上的遊戲數量多如牛毛，那麼玩家如何能發現和認知到一款遊戲，並且持續的玩下去恐怕是所有遊戲廠商需要思考的問題。加之 2018 年遊戲版號停發事件，遊戲廠商更加珍惜每一個已獲得版號的遊戲產品，所以這也使得“深度打磨產品質量”和“提高運營精細程度”這兩個遊戲產業發展方向成為廣大遊戲廠商的發展思路，無論是新遊戲還是老遊戲都在努力落實這兩點：

- **新遊戲**：面向玩家需要提供更充足的推廣資源和更完整的遊戲內容。

- **老遊戲**：透過使用者行為分析，投入更多的精力和成本，製作更優質的版本內容。

這裡我們重點來看新遊戲。一家遊戲企業辛辛苦苦研發三年，等著新遊戲發售時一飛沖天。那麼問題來了，新遊戲如何被廣大玩家看到？

首先來看看遊戲行業公司的分類：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/392171703fba4114815a327df92d91c0.png)

- 遊戲研發商：研發遊戲的公司，生產和製作遊戲內容。比如王者榮耀的所有英雄設計、遊戲戰鬥場景、戰鬥邏輯等，全部由遊戲研發公司提供。

- 遊戲發行商：遊戲發行商的主要工作分三大塊：市場工作、運營工作、客服工作。遊戲發行商把控遊戲命脈，市場工作核心是匯入玩家，運營工作核心是將使用者價值最大化、賺取更多利益。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/355564bc954448549240a0e9848287f3.png)

- 遊戲平臺/渠道商：遊戲平臺和渠道商的核心目的就是曝光遊戲，讓儘量多的人能發現你的遊戲。

這三種型別的業務，有專注於其中某一領域的獨立公司，也有能承接全部業務的公司，但無論那一種，這三者之間的關係是不會變的：

![3.png](https://ucc.alicdn.com/pic/developer-ecology/62cc7e048e6541ddb29125aae6c6cb7d.png)

所以不難理解，想讓更多的玩家看到你的遊戲，遊戲發行和運營是關鍵。通俗來講，如果你的遊戲出現在目前所有大家熟知的平臺廣告中，那麼最起碼遊戲的新使用者註冊數量是很可觀的。因此這就引入了一個關鍵詞：**買量**。

根據資料顯示，2019 年月均買量手遊數達 6000+ 款，而 2018 年僅為 4200 款。另一方面，隨著抖音、微博等超級 APP 在遊戲買量市場的資源傾斜，也助推手遊買量的效果和效率有所提升，遊戲廠商更願意使用買量的方式來吸引使用者。

但需要注意的是，在遊戲買量的精準化程度不斷提高的同時，買量的成本也在節節攀升，唯有合理配置買量、渠道與整合營銷之間的關係，才能將宣發資源發揮到最大的效果。

通俗來講，買量其實就是在各大主流平臺投放廣告，廣大使用者看到遊戲廣告後，有可能會點選廣告，然後進入遊戲廠商的宣傳頁面，同時會採集使用者的一些資訊，然後遊戲廠商對採集到的使用者資訊進行大資料分析，進行進一步的定向推廣。

# 遊戲運營核心訴求

遊戲廠商花錢買量，換來的使用者資訊以及新使用者註冊資訊是為持續的遊戲運營服務的，那麼這個場景的核心訴求就是採集使用者資訊的完整性。

比如說，某遊戲廠商一天花 5000w 投放廣告，在某平臺某時段產生了每秒 1w 次的廣告點選率，那麼在這個時段內每一個點選廣告的使用者資訊要完整的被採集到，然後入庫進行後續分析。這就對資料採集系統提出了很高的要求。

這其中，最核心的一點就是系統暴露介面的環節要能夠平穩承載買量期間不定時的流量脈衝。在買量期間，遊戲廠商通常會在多個平臺投放廣告，每個平臺投放廣告的時間是不一樣的，所以就會出現全天不定時的流量脈衝現象。如果這個環節出現問題，那麼相當於買量的錢就打水漂了。

# 資料採集系統傳統架構

![4.png](https://ucc.alicdn.com/pic/developer-ecology/4744efa0ab89407d8484274fa8920da5.png)

上圖是一個相對傳統的資料採集系統架構，最關鍵的就是暴露 HTTP 介面回傳資料這部分，這部分如果出問題，那麼採集資料的鏈路就斷了。但這部分往往會面臨兩個挑戰：

- 當流量脈衝來的時候，這部分是否可以快速擴容以應對流量衝擊。

- 遊戲運營具備潮汐特性，並非天天都在進行，這就需要考慮如何最佳化資源利用率。

通常情況下，在遊戲有運營活動之前，會提前通知運維同學，對這個環節的服務增加節點，但要增加多少其實是無法預估的，只能大概拍一個數字。這是在傳統架構下經常會出現的場景，這就會導致兩個問題：

- 流量太大，節點加少了，導致一部分流量的資料沒有采集到。

- 流量沒有預期那麼大，節點加多了，導致資源浪費。

# 資料採集系統 Serverless 架構

我們可以透過函式計算 FC 來取代傳統架構中暴露 HTTP 回傳資料這部分，從而完美解決傳統架構中存在問題，參考文章：《[資源成本雙最佳化！看 Serverless 顛覆程式設計教育的創新實踐](http://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247491052&idx=3&sn=0238428fd6ef0f812722c4af0736b7ea&chksm=fdeb2f8cca9ca69a352f006ee76669f3d29163becf7d5507e1fcd970fabb5358cd09ecafce54&scene=21#wechat_redirect)》。

先來看架構圖：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/f3417f6b6fbb42e28587071919beb827.png)

傳統架構中的兩個問題均可以透過函式計算百毫秒彈性的特性來解決。我們並不需要去估算營銷活動會帶來多大的流量，也不需要去擔心和考慮對資料採集系統的效能，運維同學更不需要提前預備 ECS。

因為函式計算的極致彈性特性，當沒有買量、沒有營銷活動的時候，函式計算的執行例項是零。有買量活動時，在流量脈衝的情況下，函式計算會快速拉起例項來承載流量壓力；當流量減少時，函式計算會及時釋放沒有請求的例項進行縮容。所以 Serverless 架構帶來的優勢有以下三點：

- 無需運維介入，研發同學就可以很快的搭建出來。

- 無論流量大小，均可以平穩的承接。

- 函式計算拉起的例項數量可以緊貼流量大小的曲線，做到資源利用率最最佳化，再加上按量計費的模式，可以最大程度最佳化成本。

# 架構解析

從上面的架構圖可以看到，整個採集資料階段，分了兩個函式來實現，第一個函式的作用是單純的暴露 HTTP 介面接收資料，第二個函式用於處理資料，然後將資料傳送至訊息佇列 Kafka 和資料庫 RDS。

## 1. 接收資料函式

我們開啟函式計算控制檯，建立一個函式：

- 函式型別：HTTP（即觸發器為 HTTP）

- 函式名稱：receiveData

- 執行環境：Python3

![6.png](https://ucc.alicdn.com/pic/developer-ecology/01463d2957b1412b81e58ae1a995f24d.png)

- 函式例項型別：彈性例項

- 函式執行記憶體：512MB

- 函式執行超時時間：60 秒

- 函式單例項併發度：1

![7.png](https://ucc.alicdn.com/pic/developer-ecology/a6de307a45db42fd904e9def689bfda9.png)

- 觸發器型別：HTTP 觸發器

- 觸發器名稱：defaultTrigger

- 認證方式：anonymous（即無需認證）

- 請求方式：GET，POST

![8.png](https://ucc.alicdn.com/pic/developer-ecology/a2cfd66689604cb9b47457da399adf17.png)

建立好函式之後，我們透過線上編輯器編寫程式碼：

```
# -*- coding: utf-8 -*-
import logging
import json
import urllib.parse
HELLO_WORLD = b'Hello world!\n'
def handler(environ, start_response):
    logger = logging.getLogger() 
    context = environ['fc.context']
    request_uri = environ['fc.request_uri']
    for k, v in environ.items():
      if k.startswith('HTTP_'):
        # process custom request headers
        pass
    try:        
        request_body_size = int(environ.get('CONTENT_LENGTH', 0))    
    except (ValueError):        
        request_body_size = 0   
    # 接收回傳的資料
    request_body = environ['wsgi.input'].read(request_body_size)  
    request_body_str = urllib.parse.unquote(request_body.decode("GBK"))
    request_body_obj = json.loads(request_body_str)
    logger.info(request_body_obj["action"])
    logger.info(request_body_obj["articleAuthorId"])

status = '200 OK'
    response_headers = [('Content-type', 'text/plain')]
    start_response(status, response_headers)
    return [HELLO_WORLD]
```

此時的程式碼非常簡單，就是接收使用者傳來的引數，我們可以呼叫介面進行驗證：

![9.png](https://ucc.alicdn.com/pic/developer-ecology/5e49444b33344a6185c28c894d6e4e02.png)

可以在函式的日誌查詢中看到此次呼叫的日誌：

![10.png](https://ucc.alicdn.com/pic/developer-ecology/e4ba34a52599419482eebe6e97e4cafd.png)

同時，我們也可以檢視函式的鏈路追蹤來分析每一個步驟的呼叫耗時，比如函式接到請求→冷啟動（無活躍例項時）→準備程式碼→執行初始化方法→執行入口函式邏輯這個過程：

![11.png](https://ucc.alicdn.com/pic/developer-ecology/3aff07c2409346a586ea691a2985b0da.png)

![12.png](https://ucc.alicdn.com/pic/developer-ecology/50004c81e17f4da0952d5a443e6a0f58.png)

從呼叫鏈路圖中可以看到，剛才的那次請求包含了冷啟動的時間，因為當時沒有活躍例項，整個過程耗時 418 毫秒，真正執行入口函式程式碼的時間為 8 毫秒。

當再次呼叫介面時，可以看到就直接執行了入口函式的邏輯，因為此時已經有例項在執行，整個耗時只有 2.3 毫秒：

![13.png](https://ucc.alicdn.com/pic/developer-ecology/3568f9c5d1894bc7a121ee8d4f72475e.png)

## 2. 處理資料的函式

第一個函式是透過在函式計算控制檯在介面上建立的，選擇了執行環境是 Python3，我們可以在官方文件中檢視預置的 Python3 執行環境內建了哪些模組，因為第二個函式要操作 Kafka 和 RDS，所以需要我們確認對應的模組。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/29344a99e7424d3785f28197cb5b32a6.png)

從文件中可以看到，內建的模組中包含 RDS 的 SDK 模組，但是沒有 Kafka 的 SDK 模組，此時就需要我們手動安裝 Kafka SDK 模組，並且建立函式也會使用另一種方式。

### 1）Funcraft

Funcraft 是一個用於支援 Serverless 應用部署的命令列工具，能幫助我們便捷地管理函式計算、API 閘道器、日誌服務等資源。它透過一個資源配置檔案（template.yml），協助我們進行開發、構建、部署操作。
所以第二個函式我們需要使用 Fun 來進行操作，整個操作分為四個步驟：

- 安裝 Fun 工具。
- 編寫 template.yml 模板檔案，用來描述函式。
- 安裝我們需要的第三方依賴。
- 上傳部署函式。

### 2）安裝 Fun

Fun 提供了三種安裝方式：

- 透過 npm 包管理安裝 —— 適合所有平臺（Windows/Mac/Linux）且已經預裝了 npm 的開發者。
- 透過下載二進位制安裝 —— 適合所有平臺（Windows/Mac/Linux）。
- 透過 Homebrew 包管理器安裝 —— 適合 Mac 平臺，更符合 MacOS 開發者習慣。

文字示例環境為 Mac，所以使用 npm 方式安裝，非常的簡單，一行命令搞定：

```
sudo npm install @alicloud/fun -g
```

安裝完成之後。在控制終端輸入 fun 命令可以檢視版本資訊：

```
$ fun --version
3.6.20
```

在第一次使用 fun 之前需要先執行 fun config 命令進行配置，按照提示，依次配置 Account ID、Access Key Id、Secret Access Key、 Default Region Name 即可。其中 Account ID、Access Key Id 你可以從函式計算控制檯首頁的右上方獲得：

fun config

? Aliyun Account ID ***01
? Aliyun Access Key ID ***qef6j
? Aliyun Access Key Secret ***UFJG
? Default region name cn-hangzhou
? The timeout in seconds for each SDK client invoking 60
? The maximum number of retries for each SDK client 3

### 3）編寫 template.yml

新建一個目錄，在該目錄下建立一個名為 template.yml 的 YAML 檔案，該檔案主要描述要建立的函式的各項配置，說白了就是將函式計算控制檯上配置的那些配置資訊以 YAML 格式寫在檔案裡：

```
ROSTemplateFormatVersion: '2015-09-01'
Transform: 'Aliyun::Serverless-2018-04-03'
Resources:
FCBigDataDemo:
Type: 'Aliyun::Serverless::Service'
Properties:
Description: 'local invoke demo'
VpcConfig:
VpcId: 'vpc-xxxxxxxxxxx'
VSwitchIds: [ 'vsw-xxxxxxxxxx' ]
SecurityGroupId: 'sg-xxxxxxxxx'
LogConfig:
Project: fcdemo
Logstore: fc_demo_store
dataToKafka:
Type: 'Aliyun::Serverless::Function'
Properties:
Initializer: index.my_initializer
Handler: index.handler
CodeUri: './'
Description: ''
Runtime: python3
```

我們來解析以上檔案的核心內容：

- FCBigDataDemo：自定義的服務名稱。透過下面的 Type 屬性標明是服務，即 Aliyun::Serverless::Service。

- Properties：Properties 下的屬性都是該服務的各配置項。

- VpcConfig：服務的 VPC 配置，包含：
   - VpcId：VPC ID。

- VSwitchIds：交換機 ID，這裡是陣列，可以配置多個交換機。

- SecurityGroupId：安全組 ID。

- LogConfig：服務繫結的日誌服務（SLS）配置，包含：
   - Project：日誌服務專案。

- Logstore：LogStore 名稱。

- dataToKafka：該服務下自定義的函式名稱。透過下面的 Type 屬性標明是函式，即 Aliyun::Serverless::Function。

- Properties：Properties下的屬性都是該函式的各配置項。

- Initializer：配置初始化函式。

- Handler：配置入口函式。

- Runtime：函式執行環境。

目錄結構為：

![15.png](https://ucc.alicdn.com/pic/developer-ecology/4a72b0e347f54dd88926510f1580e43d.png)

### 4）安裝第三方依賴

服務和函式的模板建立好之後，我們來安裝需要使用的第三方依賴。在這個示例的場景中，第二個函式需要使用 Kafka SDK，所以可以透過 fun 工具結合 Python 包管理工具 pip 進行安裝：

```
fun install --runtime python3 --package-type pip kafka-python
```

執行命令後有如下提示資訊：

![16.png](https://ucc.alicdn.com/pic/developer-ecology/59f1caea25334acb906b1580558cbdc6.png)

此時我們會發現在目錄下會生成一個.fun資料夾 ，我們安裝的依賴包就在該目錄下：

![17.png](https://ucc.alicdn.com/pic/developer-ecology/d6ba72542103427e887800b8d9f19937.png)

### 5）部署函式

現在編寫好了模板檔案以及安裝好了我們需要的 Kafka SDK 後，還需要新增我們的程式碼檔案 index.py，程式碼內容如下：

```
# -*- coding: utf-8 -*-
import logging
import json
import urllib.parse
from kafka import KafkaProducer
producer = None
def my_initializer(context):    
    logger = logging.getLogger() 
    logger.info("init kafka producer")
    global producer
    producer = KafkaProducer(bootstrap_servers='XX.XX.XX.XX:9092,XX.XX.XX.XX:9092,XX.XX.XX.XX:9092')
def handler(event, context):
    logger = logging.getLogger()   
    # 接收回傳的資料
    event_str = json.loads(event)
    event_obj = json.loads(event_str)
    logger.info(event_obj["action"])
    logger.info(event_obj["articleAuthorId"])
    # 向Kafka傳送訊息
    global producer
    producer.send('ikf-demo', json.dumps(event_str).encode('utf-8'))
    producer.close()
    return 'hello world'
```

程式碼很簡單，這裡做以簡單的解析：

- my_initializer：函式例項被拉起時會先執行該函式，然後再執行 handler 函式 ，當函式例項在執行時，之後的請求都不會執行 my_initializer 函式 。一般用於各種連線的初始化工作，這裡將初始化 Kafka Producer 的方法放在了這裡，避免反覆初始化 Produer。

-  handler：該函式只有兩個邏輯，接收回傳的資料和將資料傳送至 Kafka 的指定 Topic。

- 下面透過 fun deploy 命令部署函式，該命令會做兩件事：
   - 根據 template.yml 中的配置建立服務和函式。
   - 將 index.py 和 .fun 上傳至函式中。

![18.png](https://ucc.alicdn.com/pic/developer-ecology/e059c1829bb940cebd885b05c602011e.png)

登入函式計算控制檯，可以看到透過 fun 命令部署的服務和函式：

![19.png](https://ucc.alicdn.com/pic/developer-ecology/d446ba6f87984f6493cf3a5dacd5bec0.png)

進入函式，也可以清晰的看到第三方依賴包的目錄結構：

![20.png](https://ucc.alicdn.com/pic/developer-ecology/480893ee01224ce3bcac77a3ffb45b9a.png)

## 3. 函式之間呼叫

目前兩個函式都建立好了，下面的工作就是由第一個函式接收到資料後拉起第二個函式傳送訊息給 Kafka。我們只需要對第一個函式做些許改動即可：

```
# -*- coding: utf-8 -*-
import logging
import json
import urllib.parse
import fc2
HELLO_WORLD = b'Hello world!\n'
client = None
def my_initializer(context):    
    logger = logging.getLogger() 
    logger.info("init fc client")
    global client
    client = fc2.Client(
        endpoint="http://your_account_id.cn-hangzhou-internal.fc.aliyuncs.com",
        accessKeyID="your_ak",
        accessKeySecret="your_sk"
    )
def handler(environ, start_response):
    logger = logging.getLogger() 
    context = environ['fc.context']
    request_uri = environ['fc.request_uri']
    for k, v in environ.items():
      if k.startswith('HTTP_'):
        # process custom request headers
        pass
    try:        
        request_body_size = int(environ.get('CONTENT_LENGTH', 0))    
    except (ValueError):        
        request_body_size = 0   
    # 接收回傳的資料
    request_body = environ['wsgi.input'].read(request_body_size)  
    request_body_str = urllib.parse.unquote(request_body.decode("GBK"))
    request_body_obj = json.loads(request_body_str)
    logger.info(request_body_obj["action"])
    logger.info(request_body_obj["articleAuthorId"])
    global client
    client.invoke_function(
        'FCBigDataDemo',
        'dataToKafka',
        payload=json.dumps(request_body_str),
        headers = {'x-fc-invocation-type': 'Async'}
    )

status = '200 OK'
    response_headers = [('Content-type', 'text/plain')]
    start_response(status, response_headers)
    return [HELLO_WORLD]
```

如上面程式碼所示，對第一個函式的程式碼做了三個地方的改動：

- **匯入函式計算的庫：import fc2**

- **新增初始化方法，用於建立函式計算 Client：**

```
def my_initializer(context):
        logger = logging.getLogger()
        logger.info("init fc client")
        global client
        client = fc2.Client(
            endpoint="http://your_account_id.cn-hangzhou-internal.fc.aliyuncs.com",
            accessKeyID="your_ak",
            accessKeySecret="your_sk"
)
```

這裡需要注意的時，當我們在程式碼裡增加了初始化方法後，需要在函式配置中指定初始化方法的入口：

![21.png](https://ucc.alicdn.com/pic/developer-ecology/1de71bfdc7464b32b89a9862a22895f4.png)

- **透過函式計算 Client 呼叫第二個函式**

```
global client
    client.invoke_function(
            'FCBigDataDemo',
            'dataToKafka',
          payload=json.dumps(request_body_str),
            headers = {'x-fc-invocation-type': 'Async'}
)
```

invoke_function 函式有四個引數：

- **第一個引數**：呼叫函式所在的服務名稱。

- **第二個引數**：呼叫函式的函式名稱。

- **第三個引數**：向呼叫函式傳的資料。

- **第四個引數**：呼叫第二個函式 Request Header 資訊。這裡主要透過 x-fc-invocation-type 這個 Key 來設定是同步呼叫還是非同步呼叫。這裡設定 Async 為非同步呼叫。

如此設定，我們便可以驗證透過第一個函式提供的 HTTP 介面發起請求→採集資料→呼叫第二個函式→將資料作為訊息傳給 Kafka 這個流程了。

### 使用兩個函式的目的

到這裡有些同學可能會有疑問，為什麼需要兩個函式，而不在第一個函式里直接向 Kafka 傳送資料呢？我們先來看這張圖：

![22.png](https://ucc.alicdn.com/pic/developer-ecology/53e44ec6fc7f48cd93ccd427df760b00.png)

當我們使用非同步呼叫函式時，在函式內部會預設先將請求的資料放入訊息佇列進行第一道削峰填谷，然後每一個佇列在對應函式例項，透過函式例項的彈性拉起多個例項進行第二道削峰填谷。所以這也就是為什麼這個架構能穩定承載大併發請求的核心原因之一。

## 4. 配置 Kafka

在遊戲運營這個場景中，資料量是比較大的，所以對 Kafka 的效能要求也是比較高的，相比開源自建，使用雲上的 Kafka 省去很多的運維操作，比如：

- 我們不再需要再維護 Kafka 叢集的各個節點。
- 不需要關心主從節點資料同步問題。
- 可以快速、動態擴充套件 Kafka 叢集規格，動態增加 Topic，動態增加分割槽數。
- 完善的指標監控功能，訊息查詢功能。

總的來說，就是一切 SLA 都有云上兜底，我們只需要關注在訊息傳送和訊息消費即可。

所以我們可以開啟 Kafka 開通介面，根據實際場景的需求一鍵開通 Kafka 例項，開通 Kafka 後登入控制檯，在基本資訊中可以看到 Kafka 的接入點：

- 預設接入點：走 VPC 內網場景的接入點。
- SSL 接入點：走公網場景的接入點。

將預設接入點配置到函式計算的第二個函式中即可。

```
....
producer = KafkaProducer(bootstrap_servers='XX.XX.XX.XX:9092,XX.XX.XX.XX:9092,XX.XX.XX.XX:9092')
....
```

然後點選左側控制檯 Topic 管理，建立 Topic：

![23.png](https://ucc.alicdn.com/pic/developer-ecology/2f1e1a88a8814905af8e373834363019.png)

將建立好的 Topic 配置到函式計算的第二個函式中即可。

```
...
# 第一個引數為Topic名稱
producer.send('ikf-demo', json.dumps(event_str).encode('utf-8'))
...
```

上文已經列舉過雲上 Kafka 的優勢，比如動態增加 Topic 的分割槽數，我們可以在 Topic 列表中，對 Topic 的分割槽數進行動態調整：

![24.png](https://ucc.alicdn.com/pic/developer-ecology/f0b8e9e3808a4f83b7b1b676271f2978.png)

![25.png](https://ucc.alicdn.com/pic/developer-ecology/9eee264296954c4abe4a1d77354622da.png)

單 Topic 最大支援到 360 個分割槽，這是開源自建無法做到的。

接下來點選控制檯左側 Consumer Group 管理，建立 Consumer Group：

![26.png](https://ucc.alicdn.com/pic/developer-ecology/6f77a304162b4d41b8b116658bcead72.png)

至此，雲上的 Kafka 就算配置完畢了，即 Producer 可以往剛剛建立的 Topic 中發訊息了，Consumer 可以設定剛剛建立的 GID 以及訂閱 Topic 進行訊息接受和消費。

### Flink Kafka 消費者

在這個場景中，Kafka 後面往往會跟著 Flink，所以這裡簡要給大家介紹一下在 Flink 中如何建立 Kafka Consumer 並消費資料。程式碼片段如下：

```
final ParameterTool parameterTool = ParameterTool.fromArgs(args);
String kafkaTopic = parameterTool.get("kafka-topic","ikf-demo");
String brokers = parameterTool.get("brokers", "XX.XX.XX.XX:9092,XX.XX.XX.XX:9092,XX.XX.XX.XX:9092");
Properties kafkaProps = new Properties();
kafkaProps.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, brokers);
kafkaProps.put(ConsumerConfig.GROUP_ID_CONFIG, "ikf-demo");
FlinkKafkaConsumer<userbehaviorevent> kafka = new FlinkKafkaConsumer<>(kafkaTopic, new UserBehaviorEventSchema(), kafkaProps);
kafka.setStartFromLatest();
kafka.setCommitOffsetsOnCheckpoints(false);
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
DataStreamSource<userbehaviorevent> dataStreamByEventTime = env.addSource(kafka);
```

以上就是構建 Flink Kafka Consumer 和新增 Kafka Source 的程式碼片段，還是非常簡單的。

# 壓測驗證

至此，整個資料採集的架構就搭建完畢了，下面我們透過壓測來檢驗一下整個架構的效能。這裡使用阿里雲 PTS 來進行壓測。

## 建立壓測場景

開啟 PTS 控制檯，點選左側選單建立壓測/建立 PTS 場景：

![27.png](https://ucc.alicdn.com/pic/developer-ecology/b343593c4550463c80871dddcd1fdc50.png)

在場景配置中，將第一個函式計算函式暴露的 HTTP 介面作為串聯鏈路，配置如下圖所示：

![28.png](https://ucc.alicdn.com/pic/developer-ecology/e5fd0d6f67044674ad3b9b5d0b8ad0a5.png)

![29.png](https://ucc.alicdn.com/pic/developer-ecology/56bbce8132d34747aa69aafe94d4f46e.png)

介面配置完後，我們來配置施壓：

![30.png](https://ucc.alicdn.com/pic/developer-ecology/71d9127cfda040d2afe0f84488248772.png)

- 壓力模式：

- 併發模式：指定有多少併發使用者同時發請求。

- RPS模式：指定每秒有多少請求數。

- 遞增模式：在壓測過程中可以透過手動調節壓力，也可以自動按百分比遞增壓力。

- 最大併發：同時有多少個虛擬使用者發起請求。

- 遞增百分比：如果是自動遞增的話，按這裡的百分比遞增。

- 單量級持續時長：在未完全達到壓力全量的時候，每一級梯度的壓力保持的時長。

- 壓測總時長：一共需要壓測的時長。

這裡因為資源成本原因，併發使用者數設定為 2500 來進行驗證。

![31.png](https://ucc.alicdn.com/pic/developer-ecology/988792bb380a48719d06cc29f74c08b1.png)

![32.png](https://ucc.alicdn.com/pic/developer-ecology/0c165b1f284a4d9b836f2d88286d9dad.png)

從上圖壓測中的情況來看，TPS 達到了 2w 的封頂，549w+ 的請求，99.99% 的請求是成功的，那 369 個異常也可以點選檢視，都是壓測工具請求超時導致的。

# 總結

至此，整個基於 Serverless 搭建的大資料採集傳輸的架構就搭建好了，並且進行了壓測驗證，整體的效能也是不錯的，並且整個架構搭建起來也非常簡單和容易理解。這個架構不光適用於遊戲運營行業，其實任何大資料採集傳輸的場景都是適用的，目前也已經有很多客戶正在基於 Serverless 的架構跑在生產環境，或者正走在改造 Serverless 架構的路上。

基於 Serverless 還有很多其他的應用場景，之後我會一一分享給大家，大家如果有任何疑問也可以加入釘釘群：35712134 來尋找答案，我們不見不散！

### 重磅下載

由 23 位阿里雲技術專家精心打造 222 頁“橙子書”《Serverless 入門與實戰》重磅上線，帶你由表及裡，由淺入深學習 Serverless，助你 2021 年“橙”風而行，心想事“橙”！

**本書亮點**

- 從架構演進開始，介紹 Serverless 架構及技術選型構建 Serverless 思維；
- 瞭解業界流行的 Serverless 架構執行原理；
- 掌握 10 大 Serverless 真實落地案例，活學活用。

[點選即可直接下載！](https://developer.aliyun.com/topic/download?id=1128)</userbehaviorevent></userbehaviorevent>

在遊戲運營行業，Serverless 如何解決資料採集分析痛點？

相關文章