對於DevOps的理解大家眾說紛紜，就連維基百科（Wikipedia）都沒有給出一個統一的定義。一般的解釋都是從字面上來理解，就是把開發（Development）和運維(Operations)整合到一起，來加速產品從啟動到上線的過程，並使之自動化。這個是對DevOps的廣義解釋，而且大多數人都是認可的。但這個解釋太寬泛了，幾乎包括了IT的所有內容，使之沒有太大意義。 而DevOps是近幾年才興起的（2014年才開始流行），它是對某種項目模式的描述，是有着其特定內涵的。任何項目都可以分成開發和運維兩個部分，而開發的一整套流程和工具在DevOps之前早就有了，並沒有改變。

DevOps真正改變的是運維。因此從運維的角度去理解DevOps，才能抓住它的本質。你可以把它理解為用開發的方式做運維（Operation as Development），這就是對它的狹義的理解。 開發的方式就是寫代碼，換句話說DevOps就是通過寫代碼來做運維。運維里一個非常流行的概念叫“Iac（）” 基礎設施即代碼，也就是把運行環境的創建用代碼的形式來描述出來，通過運行代碼來創建環境。它是運維領域的一場革命，開創了現代運維技術，它也是DevOps的基石。但基礎設施創建只是運維的一部分，如果我們把這場革命繼續延伸到運維的各個領域，讓代碼覆蓋整個運維，那時就是代碼即運維（Operation as Code），這才是DevOps的精髓。

那麼從一個應用程序項目的角度看，什麼是DevOps呢？它就是把應用程序的代碼和運維的代碼都放到一個源程序庫中，並對它進行版本管理，這樣你就擁有了關於這個項目的所有信息，隨時可以部署這個程序（包括程序本身和它的運行環境），而且可以保證每次創建出來的程序的運行結果是一樣的（因為它的運行環境也是一樣的）。

運維即代碼（Operation as Code）：

下面我們就把運維所做的事情一件一件拆分開，看看他們是怎麼用代碼來實現的。

運維的工作通常包括下面幾個方面：

• 基礎設施：即程序運行環境的創建和維護。
• 持續部署：部署應用程序，並使整個過程自動化。
• 服務的健壯性：是指當服務的的運行環境出現了問題，例如網絡故障或服務過載或某些微服務宕機的情況下，程序仍能夠提供部分或大部分服務。
• 運行監測：它既包含對程序的監測也包含對運行環境的監測。

基礎設施即代碼 (Infrastructure as code)

我們通過一個Go（別的語言也大同小異）微服務程序做例子來展示如何用代碼來創建基礎設施。程序本身的功能非常簡單，只是用SQL語句訪問數據庫中的數據，並寫入日誌。你可以簡單地把它分成兩層，後端數據訪問層和數據庫層。程序的部署環境是基於k8s的容器環境。在k8s中它被分成兩個服務。一個是後端程序服務，另一個是數據庫（用MySQL）服務。後端程序要調用數據庫服務，然後會把一些數據寫入日誌。

在這種新的模式下，運行環境的代碼和應用程序的代碼是存在一個源碼庫中的，這樣當你下載了源碼庫之後，你不但擁有了程序的所有源碼，而且也擁有了運行環境的源碼。這樣當要創建新的運行環境時，只要運行一遍代碼就能創建出整套的運行環境，而且每次創建出來的環境都是一致的。

上面就是這個Go程序的目錄結構，它裏面有一個目錄“script”是專門存放與運行環境相關的文件的，裏面的“kuburnetes”子目錄就是整個運行環境的代碼。除了“script”之外的其它目錄存有應用程序的代碼。這樣，與這個應用程序有關的信息都以代碼的方式保存在了一個源代碼庫。有了它之後，你可以隨時部署出一個相同的程序的運行環境，而且保證是一模一樣的。

“kubernetes”目錄下有兩個子目錄“backend”和“database”分別存放後端程序和數據庫的配置文件。它們內部的結構是類似的，都有三個“yaml”文件：

• backend-deployment.yaml：部署配置文件,
• backend-service.yaml：服務配置文件
• backend-volume.yaml：持久卷配置文件.

另外還有一個“.sh”文件是它的運行命令，當你運行這個shell文件時，它就調用上面三個k8s配置文件來創建運行環境。

kubernetes目錄的最外層有兩個“yaml”文件“k8sdemo-config.yaml”和”k8sdemo-secret.yaml”，它們是用來創建k8s運行環境參數的，因為它們是被不同服務共享的，因此放在最外層。另外還有一個”k8sdemo.sh”文件是k8s命令文件，用來創建k8s對象。

這種源程序結構的一個好處就是使應用程序和它的運行環境能夠更好地集成。舉個例子，當你要修改服務的端口時，以前，你需要在運行環境和源碼里分別修改，但它是分別由開發和運維完成的，這很容易造成修改的不同步。當你把它們放在同一個源碼庫中，只需要修改一個地方，這樣就保證了應用程序和運行環境的一致性。

下面就是後端服務的k8s配置代碼：

apiVersion: v1
kind: Service
metadata:
  name: k8sdemo-backend-service
  labels:
    app: k8sdemo-backend
spec:
  type: NodePort
  selector:
    app: k8sdemo-backend
  ports:
    - protocol : TCP
      nodePort: 32080
      port: 80
      targetPort: 8080

由於篇幅的關係，這裏就不詳細解釋程序了，有興趣的請參見.

基礎設施可以分成兩個層面，一個就是上面講到的k8s層面，也就是容器層面，這個是跟應用程序緊密相關的。還有一個層面就是容器下面的支持層，也就是虛機層面，當然還包括網絡，負載均衡等設備或軟件。當你在阿里雲或華為雲上創建k8s之前，先要把這些構建好才行。它的部署也可以用代碼來完成。Terraform就是一款非常流行的用來完成創建的工具，它是被ThoughtWorks推薦的（詳見 ），它支持用代碼來創建虛機。

代碼如下：

resource "aws_instance" "example" {
  count         = 10
  ami           = "ami-v1"
  instance_type = "t2.micro"
}

但在這一層面，基礎設施的工作與應用程序的關聯並沒有那麼緊密，因此這部分的代碼沒有放在應用程序里，你可以單獨創建一個基礎設施的源碼項目，用來存放這部分代碼。

持續部署（Continuous Deployment）

部署應用程序是運維的一項重要工作。隨着商業競爭的加劇，要求更快的程序更新，從原來的的幾周部署一次，到後來的一天部署十幾次甚至幾十次。這樣手工部署就完全不能滿足需要，於是就要把整個流程自動化，這就是持續部署。

管線（pipeline）是一個很重要的概念，它用來描述持續部署的整個步驟和流程。Jenkin是一款非常流行的持續集成和部署工具，它提出了“管線即代碼”（“Pipeline as code”，詳見）。就是把持續部署的管線也作為程序源碼的一部分，和應用程序一起管理起來，讓它有着和應用程序一樣的版本和複審流程。

下面我們就通過一個具體例子來說明他是怎樣實現的。這個例子用的是和上面一樣的程序。先來看一下程序的目錄結構。

與持續部署相關的文件都在“script”目錄下，他被分成兩部分，一個是“cd”子目錄，它存有Jenkins的管線，另一個是“Kubernetes”下的“jenkins”子目錄，它存有Jenkinsde的k8s配置文件。你如果仔細看一下的話會發現它裏面的文件和前面講到的後端程序和數據庫的k8s配置文件很相似，有了它，你就可以在k8s里創建出Jenkins的運行環境。

這裏我把Jenkins的k8s配置文件也放在應用程序里了，但實際上它是應該放在前面提到的基礎設施項目源碼里。因為Jenkins是被應用程序共享的，而不是屬於單獨的一個應用。這裏為了說明方便放在一起了，真正用的時候要把它抽取出來。

下面就是管線的代碼：

def POD_LABEL = "k8sdemopod-${UUID.randomUUID().toString()}"
podTemplate(label: POD_LABEL, cloud: 'kubernetes', containers: [
    containerTemplate(name: 'modified-jenkins', image: 'jfeng45/modified-jenkins:1.0', ttyEnabled: true, command: 'cat')
  ],
  volumes: [
     hostPathVolume(mountPath: '/var/run/docker.sock', hostPath: '/var/run/docker.sock')
  ]) {

    node(POD_LABEL) {
       def kubBackendDirectory = "/script/kubernetes/backend"
       stage('Checkout') {
            container('modified-jenkins') {
                sh 'echo get source from github'
                git 'https://github.com/jfeng45/k8sdemo'
            }
          }
       stage('Build image') {
            def imageName = "jfeng45/jenkins-k8sdemo:${env.BUILD_NUMBER}"
            def dockerDirectory = "${kubBackendDirectory}/docker/Dockerfile-k8sdemo-backend"
             container('modified-jenkins') {
               withCredentials([[$class: 'UsernamePasswordMultiBinding',
                 credentialsId: 'dockerhub',
                 usernameVariable: 'DOCKER_HUB_USER',
                 passwordVariable: 'DOCKER_HUB_PASSWORD']]) {
                 sh """
                   docker login -u ${DOCKER_HUB_USER} -p ${DOCKER_HUB_PASSWORD}
                   docker build -f ${WORKSPACE}${dockerDirectory} -t ${imageName} .
                   docker push ${imageName}
                   """
               }
             }
           }
       stage('Deploy') {
           container('modified-jenkins') {
               sh "kubectl apply -f ${WORKSPACE}${kubBackendDirectory}/backend-deployment.yaml"
               sh "kubectl apply -f ${WORKSPACE}${kubBackendDirectory}/backend-service.yaml"
             }
       }
    }
}

由於篇幅的關係，這裏不詳細解釋。如果有興趣並想了解如何運行Jenkins來完成持續部署，請參閱 .

這裏我用的是Jenkins軟件，它另外還有一個子項目叫Jenkins-x，是專門為k8s環境量身打造的，它的主要功能是能夠幫助你自動生成管線代碼（你需要回答他的一些問題）。如果你不想自己寫代碼，那麼你可以試一下它，詳情請見。

服務的韌性（Service Resilience as Code）

又叫服務的健壯性，這部分不像前面兩個部分有着公認的名字，英文叫“Service Resilience”，翻譯成中文就五花八門了，我覺得叫服務的韌性比較合適。

“Service Resilience”是指當服務的的運行環境出現了問題，例如網絡故障或服務過載或某些微服務宕機的情況下，程序仍能夠提供部分或大部分服務，這時我們就說服務的韌性很強。它是衡量服務質量的一個重要指標。

這部分的功能包括下面幾個部分：

• 服務超時 （Timeout）
• 服務重試 （Retry）
• 服務限流（Rate Limiting）
• 熔斷器 （Circuit Breaker）
• 故障注入（Fault Injection）
• 艙壁隔離技術（Bulkhead）

這部分與前面兩個部分略有不同，前面兩個部分都是典型的運維任務，而這部分以前是應用程序的一部分，只是這些年才慢慢開始轉移到運維的。

最開始的時候，這些功能都是和程序的業務邏輯混在一起，對業務邏輯的侵入很大，後來，大家開始把這部分邏輯抽取出來，劃分成單獨的一部分。下面通過一個具體的例子（Go微服務程序）來講解：

上圖是程序的目錄結構，它分為客戶端（client）和服務端（server），它們的內部結構是類似的。“middleware”包是實現服務韌性功能的包。 “service”包是業務邏輯包，在服務端就是微服務的實現函數，在客戶端就是調用服務端的函數。在客戶端（client）下的“middleware”包中包含四個文件並實現了三個功能：服務超時，服務重試和熔斷器。“clientMiddleware.go”是總入口。在服務端（server）下的“middleware”包中包含了兩個文件並實現了一個功能，服務限流。“serverMiddleware.go”是總入口。

注意，這裏的服務韌性的功能是完全從業務邏輯中抽出來了，對業務邏輯沒有任何侵入，它是在一個單獨的包（middleware）里實現的。這裏用的是修飾模式。有關程序實現的詳情，請參閱。

上面講的是用程序來實現這些功能，但從本質上來講這些功能不應該屬於應用程序，而是應該由基礎設施來完成。現在公認的看法是，服務網格（Service Mesh）是完成這些功能的最佳方案。使用服務網格的方式和k8s類似，也是創建配置文件，然後通過運行配置文件來建立服務網格的運行環境。我們這裏用Istio來舉例說明，Istio是一款非常流行的服務網格軟件。

上圖就是下載的Istio軟件的目錄，“bookinfo”是它的一個示例程序，在這個例子里，它展示了多種使用Istio的方式，其中就有如何實現服務韌性的方法。詳情請參見.

運行監測 (Monitoring or Observability)

運行監測是運維的一項重要內容，它通常包含如下幾個方面的內容：

• 日誌（logging）: 記錄的是程序運行過程中的信息
• 跟蹤（tracing）: 記錄的是與一條請求相關的信息，特別是請求的與時間有關的信息。
• 指標（metrics）: 與上面的離散的信息不同，這裏記錄的是可累加的信息，一般是按照時間軸進行累加。

我們經常稱之為觀測的三個支柱（Three Pillars of Observabilty）,有一篇很不錯的講解它們之間關係的文章，詳情請見””。

這部分的內容可能會有些爭議。因為前幾個部分都是清清楚楚的運維工作，即使服務韌性, 雖然以前是開發的工作，但現在也已經一直公認是運維的事，而且它們的代碼都能很乾凈的摘出來。但運行監測不一樣，雖然主要工作還是由運維來完成，但它的代碼與業務邏輯代碼混在一起，很難摘得清楚。

日誌:

這部分的代碼都是在應用程序里，但日誌的採集，匯總，分析和展示都是由運維來完成。它的代表就是著名的ELK系列。採用DevOps之後，這裏面的變化不大，頂多就是採集代理（Agent）更好地和服務網格或k8s進行集成，使之變得更為容易。

分佈式跟蹤：

這部分有點像服務韌性，開始的時候是由程序完成，慢慢地把它變成單獨的部分與應用程序隔離開，最終大部分的工作交由服務網格來完成。但它又與服務韌性不太相同。服務韌性可以和應用程序做一個非常乾淨的切割，而分佈式跟蹤取決於跟蹤的顆粒度。如果僅是服務之間的跟蹤，就一點問題都沒有，完全可以由服務網格來完成。但如果是服務內部的跟蹤，服務網格就無能為力了，還是要由程序代碼來完成，就像日誌一樣。但我覺得服務之間的跟蹤是投入產出比最高的，大多數情況下有它就足夠了，不必需要服務內部的跟蹤。

詳細情況請參見

Metrics:

這部分觀測的是累加信息。大多數情況下，只要安裝好工具，就能採集數據進行分析。最流行的工具是Prometheus. 你不需要寫代碼來獲取數據，不過你如果想要快速地找到需要的信息，k8s的配置還是要和Prometheus的設置相匹配，因此你需要做一些詳細的設計。詳細情況請參見。

當然你如果有一些更細緻的監測需求，Prometheus不能直接滿足。這時需要在應用程序里插入一些Prometheus的監測代碼來滿足你的需要。

其他工作

是不是還有其他運維工作被漏掉了？

持續集成（Continious Integration）

很多人都把持續集成（CI）算作DevOps的重要組成部分，那是因為他用的是廣義的定義。按照狹義的理解，DevOps只包括運維的內容。持續集成（CI）與持續部署（CD）有着明顯的不同，持續集成是開發的工作，而持續部署是運維的工作，下圖展示了它們的差異。

如圖所示，整個流程是這樣的：
程序員從源碼庫（Source Control）中下載源代碼，編寫程序，完成后提交代碼到源碼庫，持續集成（Continuous Integration）工具從源碼庫中下載源代碼，編譯源代碼，然後提交到運行庫（Repository），然後持續交付（Continuous Delivery）工具從運行庫（Repository）中下載代碼，生成發布版本，併發布到不同的運行環境（例如DEV，QA，UAT， PROD）。

圖中，左邊的部分是持續集成，它主要跟開發和程序員有關；右邊的部分是持續部署，它主要跟測試和運維有關。持續交付（Continuous Delivery）又叫持續部署（Continuous Deployment），它們如果細分的話還是有一點區別的，但我們這裏不分得那麼細，統稱為持續部署

我並沒有把持續集成放到DevOps裏面，因為本文用的是狹義的解釋，也就是只包含運維的部分。

結論

本文從代碼的視角詮釋了對DevOps的理解，DevOps的精髓就是用寫代碼的方式來做運維，並對運維的各個部分給出了具體的實例，希望能對想採用DevOps的朋友有所幫助。DevOps對開發和運維的改變都是巨大的，尤其是對運維。在不久的將來，就沒有開發和運維之分了，只有一個工作，就是寫代碼，當然也許會細分成開發碼農和運維碼農。運維的工作都是通過寫代碼來完成。應用程序里不但包括業務邏輯的代碼，也包括運維的代碼，它們會被同時存儲在一個源碼庫中。

源碼庫

完整源碼的github鏈接：

索引：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

本文由 JavaGuide 翻譯自 https://www.baeldung.com/java-performance-mapping-frameworks 。轉載請註明原文地址以及翻譯作者。

1. 介紹

創建由多個層組成的大型 Java 應用程序需要使用多種領域模型，如持久化模型、領域模型或者所謂的 DTO。為不同的應用程序層使用多個模型將要求我們提供 bean 之間的映射方法。手動執行此操作可以快速創建大量樣板代碼並消耗大量時間。幸運的是，Java 有多個對象映射框架。在本教程中，我們將比較最流行的 Java 映射框架的性能。

綜合日常使用情況和相關測試數據，個人感覺 MapStruct、ModelMapper 這兩個 Bean 映射框架是最佳選擇。

2. 常見 Bean 映射框架概覽

2.1. Dozer

Dozer 是一個映射框架，它使用遞歸將數據從一個對象複製到另一個對象。框架不僅能夠在 bean 之間複製屬性，還能夠在不同類型之間自動轉換。

要使用 Dozer 框架，我們需要添加這樣的依賴到我們的項目:

<dependency>
    <groupId>net.sf.dozer</groupId>
    <artifactId>dozer</artifactId>
    <version>5.5.1</version>
</dependency>

更多關於 Dozer 的內容可以在官方文檔中找到： http://dozer.sourceforge.net/documentation/gettingstarted.html ，或者你也可以閱讀這篇文章：https://www.baeldung.com/dozer 。

2.2. Orika

Orika 是一個 bean 到 bean 的映射框架，它遞歸地將數據從一個對象複製到另一個對象。

Orika 的工作原理與 Dozer 相似。兩者之間的主要區別是 Orika 使用字節碼生成。這允許以最小的開銷生成更快的映射器。

要使用 Orika 框架，我們需要添加這樣的依賴到我們的項目:

<dependency>
    <groupId>ma.glasnost.orika</groupId>
    <artifactId>orika-core</artifactId>
    <version>1.5.2</version>
</dependency>

更多關於 Orika 的內容可以在官方文檔中找到：https://orika-mapper.github.io/orika-docs/，或者你也可以閱讀這篇文章：https://www.baeldung.com/orika-mapping。

2.3. MapStruct

MapStruct 是一個自動生成 bean mapper 類的代碼生成器。MapStruct 還能夠在不同的數據類型之間進行轉換。Github 地址：https://github.com/mapstruct/mapstruct。

要使用 MapStruct 框架，我們需要添加這樣的依賴到我們的項目:

<dependency>
    <groupId>org.mapstruct</groupId>
    <artifactId>mapstruct-processor</artifactId>
    <version>1.2.0.Final</version>
</dependency>

更多關於 MapStruct 的內容可以在官方文檔中找到：https://mapstruct.org/，或者你也可以閱讀這篇文章：https://www.baeldung.com/mapstruct。

要使用 MapStruct 框架，我們需要添加這樣的依賴到我們的項目:

<dependency>
    <groupId>org.mapstruct</groupId>
    <artifactId>mapstruct-processor</artifactId>
    <version>1.2.0.Final</version>
</dependency>

2.4. ModelMapper

ModelMapper 是一個旨在簡化對象映射的框架，它根據約定確定對象之間的映射方式。它提供了類型安全的和重構安全的 API。

更多關於 ModelMapper 的內容可以在官方文檔中找到：http://modelmapper.org/ 。

要使用 ModelMapper 框架，我們需要添加這樣的依賴到我們的項目:

<dependency>
  <groupId>org.modelmapper</groupId>
  <artifactId>modelmapper</artifactId>
  <version>1.1.0</version>
</dependency>

2.5. JMapper

JMapper 是一個映射框架，旨在提供易於使用的、高性能的 Java bean 之間的映射。該框架旨在使用註釋和關係映射應用 DRY 原則。該框架允許不同的配置方式:基於註釋、XML 或基於 api。

更多關於 JMapper 的內容可以在官方文檔中找到：https://github.com/jmapper-framework/jmapper-core/wiki。

要使用 JMapper 框架，我們需要添加這樣的依賴到我們的項目:

<dependency>
    <groupId>com.googlecode.jmapper-framework</groupId>
    <artifactId>jmapper-core</artifactId>
    <version>1.6.0.1</version>
</dependency>

3.測試模型

為了能夠正確地測試映射，我們需要有一個源和目標模型。我們已經創建了兩個測試模型。

第一個是一個只有一個字符串字段的簡單 POJO，它允許我們在更簡單的情況下比較框架，並檢查如果我們使用更複雜的 bean 是否會發生任何變化。

簡單的源模型如下:

public class SourceCode {
    String code;
    // getter and setter
}

它的目標也很相似:

public class DestinationCode {
    String code;
    // getter and setter
}

源 bean 的實際示例如下:

public class SourceOrder {
    private String orderFinishDate;
    private PaymentType paymentType;
    private Discount discount;
    private DeliveryData deliveryData;
    private User orderingUser;
    private List<Product> orderedProducts;
    private Shop offeringShop;
    private int orderId;
    private OrderStatus status;
    private LocalDate orderDate;
    // standard getters and setters
}

目標類如下圖所示:

public class Order {
    private User orderingUser;
    private List<Product> orderedProducts;
    private OrderStatus orderStatus;
    private LocalDate orderDate;
    private LocalDate orderFinishDate;
    private PaymentType paymentType;
    private Discount discount;
    private int shopId;
    private DeliveryData deliveryData;
    private Shop offeringShop;
    // standard getters and setters
}

整個模型結構可以在這裏找到:https://github.com/eugenp/tutorials/tree/master/performance-tests/src/main/java/com/baeldung/performancetests/model/source。

4. 轉換器

為了簡化測試設置的設計，我們創建了如下所示的轉換器接口:

public interface Converter {
    Order convert(SourceOrder sourceOrder);
    DestinationCode convert(SourceCode sourceCode);
}

我們所有的自定義映射器都將實現這個接口。

4.1. OrikaConverter

Orika 支持完整的 API 實現，這大大簡化了 mapper 的創建:

public class OrikaConverter implements Converter{
    private MapperFacade mapperFacade;

    public OrikaConverter() {
        MapperFactory mapperFactory = new DefaultMapperFactory
          .Builder().build();

        mapperFactory.classMap(Order.class, SourceOrder.class)
          .field("orderStatus", "status").byDefault().register();
        mapperFacade = mapperFactory.getMapperFacade();
    }

    @Override
    public Order convert(SourceOrder sourceOrder) {
        return mapperFacade.map(sourceOrder, Order.class);
    }

    @Override
    public DestinationCode convert(SourceCode sourceCode) {
        return mapperFacade.map(sourceCode, DestinationCode.class);
    }
}

4.2. DozerConverter

Dozer 需要 XML 映射文件，有以下幾個部分:

<mappings xmlns="http://dozer.sourceforge.net"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://dozer.sourceforge.net
  http://dozer.sourceforge.net/schema/beanmapping.xsd">

    <mapping>
        <class-a>com.baeldung.performancetests.model.source.SourceOrder</class-a>
        <class-b>com.baeldung.performancetests.model.destination.Order</class-b>
        <field>
            <a>status</a>
            <b>orderStatus</b>
        </field>
    </mapping>
    <mapping>
        <class-a>com.baeldung.performancetests.model.source.SourceCode</class-a>
        <class-b>com.baeldung.performancetests.model.destination.DestinationCode</class-b>
    </mapping>
</mappings>

定義了 XML 映射后，我們可以從代碼中使用它:

public class DozerConverter implements Converter {
    private final Mapper mapper;

    public DozerConverter() {
        DozerBeanMapper mapper = new DozerBeanMapper();
        mapper.addMapping(
          DozerConverter.class.getResourceAsStream("/dozer-mapping.xml"));
        this.mapper = mapper;
    }

    @Override
    public Order convert(SourceOrder sourceOrder) {
        return mapper.map(sourceOrder,Order.class);
    }

    @Override
    public DestinationCode convert(SourceCode sourceCode) {
        return mapper.map(sourceCode, DestinationCode.class);
    }
}

4.3. MapStructConverter

Map 結構的定義非常簡單，因為它完全基於代碼生成:

@Mapper
public interface MapStructConverter extends Converter {
    MapStructConverter MAPPER = Mappers.getMapper(MapStructConverter.class);

    @Mapping(source = "status", target = "orderStatus")
    @Override
    Order convert(SourceOrder sourceOrder);

    @Override
    DestinationCode convert(SourceCode sourceCode);
}

4.4. JMapperConverter

JMapperConverter 需要做更多的工作。接口實現后:

public class JMapperConverter implements Converter {
    JMapper realLifeMapper;
    JMapper simpleMapper;

    public JMapperConverter() {
        JMapperAPI api = new JMapperAPI()
          .add(JMapperAPI.mappedClass(Order.class));
        realLifeMapper = new JMapper(Order.class, SourceOrder.class, api);
        JMapperAPI simpleApi = new JMapperAPI()
          .add(JMapperAPI.mappedClass(DestinationCode.class));
        simpleMapper = new JMapper(
          DestinationCode.class, SourceCode.class, simpleApi);
    }

    @Override
    public Order convert(SourceOrder sourceOrder) {
        return (Order) realLifeMapper.getDestination(sourceOrder);
    }

    @Override
    public DestinationCode convert(SourceCode sourceCode) {
        return (DestinationCode) simpleMapper.getDestination(sourceCode);
    }
}

我們還需要向目標類的每個字段添加@JMap註釋。此外，JMapper 不能在 enum 類型之間轉換，它需要我們創建自定義映射函數:

@JMapConversion(from = "paymentType", to = "paymentType")
public PaymentType conversion(com.baeldung.performancetests.model.source.PaymentType type) {
    PaymentType paymentType = null;
    switch(type) {
        case CARD:
            paymentType = PaymentType.CARD;
            break;

        case CASH:
            paymentType = PaymentType.CASH;
            break;

        case TRANSFER:
            paymentType = PaymentType.TRANSFER;
            break;
    }
    return paymentType;
}

4.5. ModelMapperConverter

ModelMapperConverter 只需要提供我們想要映射的類:

public class ModelMapperConverter implements Converter {
    private ModelMapper modelMapper;

    public ModelMapperConverter() {
        modelMapper = new ModelMapper();
    }

    @Override
    public Order convert(SourceOrder sourceOrder) {
       return modelMapper.map(sourceOrder, Order.class);
    }

    @Override
    public DestinationCode convert(SourceCode sourceCode) {
        return modelMapper.map(sourceCode, DestinationCode.class);
    }
}

5. 簡單的模型測試

對於性能測試，我們可以使用 Java Microbenchmark Harness，關於如何使用它的更多信息可以在 這篇文章：https://www.baeldung.com/java-microbenchmark-harness 中找到。

我們為每個轉換器創建了一個單獨的基準測試，並將基準測試模式指定為 Mode.All。

5.1. 平均時間

對於平均運行時間，JMH 返回以下結果(越少越好):

這個基準測試清楚地表明，MapStruct 和 JMapper 都有最佳的平均工作時間。

5.2. 吞吐量

在這種模式下，基準測試返回每秒的操作數。我們收到以下結果(越多越好):

在吞吐量模式中，MapStruct 是測試框架中最快的，JMapper 緊隨其後。

5.3. SingleShotTime

這種模式允許測量單個操作從開始到結束的時間。基準給出了以下結果(越少越好):

這裏，我們看到 JMapper 返回的結果比 MapStruct 好得多。

5.4. 採樣時間

這種模式允許對每個操作的時間進行採樣。三個不同百分位數的結果如下:

所有的基準測試都表明，根據場景的不同，MapStruct 和 JMapper 都是不錯的選擇，儘管 MapStruct 對 SingleShotTime 給出的結果要差得多。

6. 真實模型測試

對於性能測試，我們可以使用 Java Microbenchmark Harness，關於如何使用它的更多信息可以在 這篇文章：https://www.baeldung.com/java-microbenchmark-harness 中找到。

我們為每個轉換器創建了一個單獨的基準測試，並將基準測試模式指定為 Mode.All。

6.1. 平均時間

JMH 返回以下平均運行時間結果（越少越好）：

該基準清楚地表明，MapStruct 和 JMapper 均具有最佳的平均工作時間。

6.2. 吞吐量

在這種模式下，基準測試返回每秒的操作數。我們收到以下結果(越多越好):

在吞吐量模式中，MapStruct 是測試框架中最快的，JMapper 緊隨其後。

6.3. SingleShotTime

這種模式允許測量單個操作從開始到結束的時間。基準給出了以下結果(越少越好):

6.4. 採樣時間

這種模式允許對每個操作的時間進行採樣。三個不同百分位數的結果如下:

儘管簡單示例和實際示例的確切結果明顯不同，但是它們的趨勢相同。在哪種算法最快和哪種算法最慢方面，兩個示例都給出了相似的結果。

6.5. 結論

根據我們在本節中執行的真實模型測試，我們可以看出，最佳性能顯然屬於 MapStruct。在相同的測試中，我們看到 Dozer 始終位於結果表的底部。

7. 總結

在這篇文章中，我們已經進行了五個流行的 Java Bean 映射框架性能測試：ModelMapper ， MapStruct ， Orika ，Dozer， JMapper。

示例代碼地址：https://github.com/eugenp/tutorials/tree/master/performance-tests。

開源項目推薦

作者的其他開源項目推薦：

1. ：【Java學習+面試指南】 一份涵蓋大部分Java程序員所需要掌握的核心知識。
2. : 適合新手入門以及有經驗的開發人員查閱的 Spring Boot 教程（業餘時間維護中，歡迎一起維護）。
3. : 我覺得技術人員應該有的一些好習慣！
4. :從零入門 ！Spring Security With JWT（含權限驗證）後端部分代碼。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

未來一年內，通用汽車（General Motors，GM）將與 Lyft 合作，在一般道路上測試無人駕駛的最新款電動車  Chevrolet Bolt，並計畫以此車款成為叫車服務的車隊主力。通用汽車近期正試圖整合幾筆投資，以迎接矽谷科技巨頭對傳統汽車行業的挑戰，包含 Tesla 的電動車、Google 的自動駕駛以及 Uber 的分享出租服務。   根據《華爾街日報》報導，今年 1 月通用汽車曾投資 Lyft 高達 5 億美元，並以 10 億美元價格收購了位於舊金山的自動駕駛技術開發商 Cruise Automation，預期接下來的服務將仰賴該公司技術。   通用汽車與 Lyft 的合作主要針對 Google 和 Uber 而來。Google 的自動駕駛汽車技術目前遙遙領先，即便與福特汽車合作告吹，他們也順利另外和飛雅特─克萊斯勒（Fiat Chrysler）成功聯手。而作為 Lyft 難以撼動的競爭對手，Uber 也在匹茲堡成立了無人駕駛研究中心，並計劃於 2020 年將無人駕駛車投入車隊營運。   Lyft 高層表示，關於無人計程車測試的細節仍在研究當中，不過這一項測試將在某些城市供用戶參與。Lyft 目前擁有一款原型的智慧型手機應用，用戶藉此透過 Lyft 叫車，可以選擇是否由無人駕駛車前來接送。在發生問題時，用戶也可以聯繫通用汽車 OnStar 系統助理請求協助。這款應用還支援讓用戶指示車輛何時出發，以及車輛是否已達到目的地可以離開。   目前有加州、密西根州、內華達州、佛羅里達州與華盛頓特區等地通過無人駕駛車上路測試的相關法案，Google 則已經在這些地區以外的其他城市，包含奧斯汀、鳳凰城與華盛頓州的柯克蘭進行他們的自動駕駛車測試。這也意味著通用汽車和 Lyft 同樣可以選擇在某些立法未詳的州以實行他們的計畫。Lyft 和 Uber 高層之前都曾表示，無人駕駛車的主要障礙來自於監管法規如何適用於這類車輛，以及責任歸屬如何界定。為了解決監管問題，Lyft 最初仍會在無人駕駛車上配備司機，以在必要情況下進行人工介入。   除了無人駕駛車外，通用汽車最重要的如意算盤，就是讓 Lyft 及其司機團隊成為 Chevrolet Bolt 的主要客戶。這款電動車將於 2016 年底上市。目前通用汽車和 Lyft 在芝加哥將 Chevrolet Equinox 租給有需要的司機駕駛，而未來的主力車型將會是 Bolt，而不是作為 SUV 的 Equinox。   Bolt 比上一款 Chevrolet Volt 能儲存更多電力，續航力更強；電池位於車身底盤，因此車輛前半部多出了空間，讓後排乘客的腿部空間更大。通用汽車表示，這款車型非常適合需要更多空間，同時希望降低運營成本的司機。

（首圖來源： CC BY 2.0）   （本文授權轉載自《》─〈〉）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

先上張圖整體了解Flink中的異步io

 

阿里貢獻給flink的，優點就不說了嘛，官網上都有，就是寫庫不會柱塞性能更好

然後來看一下， Flink 中異步io主要分為兩種

　　一種是有序Ordered

　　一種是無序UNordered

主要區別是往下游output的順序（注意這裏順序不是寫庫的順序既然都異步了寫庫的順序自然是無法保證的），有序的會按接收的順序繼續往下游output發送，無序就是誰先處理完誰就先往下游發送

兩張圖了解這兩種模式的實現

 

有序：record數據會通過異步線程寫庫，Emitter是一個守護進程，會不停的拉取queue頭部的數據，如果頭部的數據異步寫庫完成，Emitter將頭數據往下游發送，如果頭元素還沒有異步寫庫完成，柱塞      

無序：record數據會通過異步線程寫庫，這裡有兩個queue,一開始放在uncompleteedQueue，當哪個record異步寫庫成功后就直接放到completedQueue中，Emitter是一個守護進程，completedQueue只要有數據，會不停的拉取queue數據往下游發送 

    

可以看到原理還是很簡單的，兩句話就總結完了，就是利用queue和java的異步線程，現在來看下源碼

這裏AsyncIO在Flink中被設計成operator中的一種，自然去OneInputStreamOperator的實現類中去找

於是來看一下AsyncWaitOperator.java

　　

看到它的open方法（open方法會在taskmanager啟動job的時候全部統一調用，可以翻一下以前的文章）

這裏啟動了一個守護線程Emitter,來看下線程具體做了什麼

 

 1處拉取數據，2處就是常規的將拉取到的數據往下游emit，Emitter拉取數據，這裏先不講因為分為有序的和無序的

 這裏已經知道了這個Emitter的作用是循環的拉取數據往下游發送

 回到AsyncWaitOperator.java在它的open方法初始化了Emitter,那它是如何處理接收到的數據的呢，看它的ProcessElement（）方法

 

    

 

 其實主要就是三個個方法

先是！！！將record封裝成了一個包裝類StreamRecordQueueEntry，主要是這個包裝類的構造方法中,創建了一個CompleteableFuture(這個的complete方法其實會等到用戶代碼執行的時候用戶自己決定什麼時候完成）

1處主要就是講元素加入到了對應的queue,這裏也分為兩種有序和無序的

 

這裏也先不講這兩種模式加入數據的區別

接着2處就是調用用戶的代碼了，來看看官網的異步io的例子

 

 給了一個Future作為參數，用戶自己起了一個線程（這裏思考一下就知道了為什麼要新起一個異步線程去執行，因為如果不起線程的話，那processElement方法就柱塞了，無法異步了）去寫庫讀庫等，然後調用了這個參數的complete方法（也就是前面那個包裝類中的CompleteableFuture）並且傳入了一個結果

看下complete方法源碼

 

 這個resultFuture是每個record的包裝類StreamRecordQueueEntry的其中一個屬性是一個CompletableFuture

 那現在就清楚了，用戶代碼在自己新起的線程中當自己的邏輯執行完以後會使這個異步線程結束，並輸入一個結果

 那這個幹嘛用的呢

 

最開始的圖中看到有序和無序實現原理，有序用一個queue,無序用兩個queue分別就對應了

OrderedStreamElementQueue類中

 

 UnorderedStreamElementQueue類中

 

回到前面有兩個地方沒有細講，一是兩種模式的Emitter是如何拉取數據的，二是兩種模式下數據是如何加入OrderedStreamElementQueue的

有序模式：

1.先來看一下有序模式的，Emitter的數據拉取，和數據的加入

　　　　其tryPut（）方法

　　　　  

 　　　  

 　　　　onComplete方法

　　　　　　　

       onCompleteHandler方法

　　　　  　　

　　這裏比較繞，先將接收的數據加入queue中，然後onComplete()中當上一個異步線程getFuture() 其實就是每個元素包裝類裏面的那個CompletableFuture,當他結束時（會在用戶方法用戶調用complete時結束）異步調用傳入的對象的 accept方法，accept方法中調用了onCompleteHandler（）方法，onCompleteHandler方法中會判斷queue是否為空，以及queue的頭元素是否完成了用戶的異步方法，當完成的時候，就會將headIsCompleted這個對象signalAll（）喚醒

 

2.接着看有序模式Emitter的拉取數據

       

   這裡有序方式拉取數據的邏輯很清晰，如果為空或者頭元素沒有完成用戶的異步方法，headIsCompleted這個對象會wait住（上面可以知道，當加入元素的到queue且頭元素完成異步方法的時候會signalAll（））然後將頭數據返回，往下游發送

 

這樣就實現了有序發送，因為Emitter只拉取頭元素且已經完成用戶異步方法的頭元素

 

無序模式： 

　　這裏和有序模式就大同小異了，只是變成了,接收數據后直接加入uncompletedQueue，當數據完成異步方法的時候就，放到completedQueue裏面去並signalAll（），只要completedqueue裏面有數據，Emitter就拉取往下發

 

這樣就實現了無序模式，也就是異步寫入誰先處理完就直接放到完成隊列裏面去，然後往下發，不用管接收數據的順序

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

(馬蜂窩技術原創內容，公眾號 ID: mfwtech)

引言

消費者的狂歡節「雙 11」剛剛過去。在電商競爭環境日益激烈的今天，為了抓住流量紅利，雙 11 打響的已經不僅僅是「促銷戰」，也是「營銷戰」，這對平台的技術支撐能力提出新的要求。

從 2014 年的「318 大促」，到正在進行的 「馬蜂窩雙 11 全球旅行蜂搶節」，馬蜂窩旅遊電商業務的大促已經走過 5 年時間，僅僅是雙 11、暑期、十一黃金周、年終這些關鍵節點的 S 級促銷就張羅了 50 多場，每年上線活動達幾百個。

圖：馬蜂窩11.11全球旅行蜂搶節

 

在這個過程中，馬蜂窩營銷平台也在經歷着優化和改進，不斷探索靈活高效的營銷活動運營開發方式，更好地支撐業務營銷活動的模式創新和投放需求，努力實現平台商家與馬蜂窩旅遊消費者的高效匹配，目前已經形成了一套較為完整的技術體系。

本文將以馬蜂窩營銷活動後台的技術實踐為重點，分享馬蜂窩營銷平台的架構設計思路，希望能讓遇到類似問題的同學有所收穫。

 

一、馬蜂窩營銷平台架構

1. 營銷中心體系

談到大促，大家可能首先會想到的海量數據、高併發、高流量等關鍵詞。其實除了這些，營銷活動數量多、周期短、功能複雜多變等，都是營銷活動運營開發需要應對的挑戰。並且由於我們的很多活動會涉及到一些獎勵或權益的下發，對於安全性的要求也很高。

針對以上問題，馬蜂窩營銷系統的技術架構要具備的核心能力包括：

• 打造靈活、高效的活動開發模式

• 提供高可靠、高可用的活動運營支撐

• 保證營銷活動業務的安全運行

因此，我們本着「平台化、組件化、模塊化」的方法，將營銷體系的架構設計如下：

 

馬蜂窩整體營銷體系分為 B 端和 C 端兩部分。B 端主要面向商家，幫助商家在馬蜂窩招商平台進行大促活動的提報以及商品選取；C 端主要是面向馬蜂窩用戶，平台用戶可以在業務營銷頁面完成活動商品的購買、秒殺、大促紅包贏取等具體的營銷活動參与互動。

2. C 端營銷平台

C 端營銷平台的系統架構主要分為主要分為營銷應用層、中間層、投放平台、搭建平台四個部分。

• 活動開發平台：營銷平台最核心的部分，也是本文重點。包括前端頁面搭建層「魔方」、業務邏輯層「蜂玩樂園」、獎勵規則控制層「獎池」三部分

• 投放平台：是指營銷活動頁的投放，包括投放策略、運營策略和機制等

• 中間件：負責併發處理、分佈式緩存和容災限流等等

• 營銷應用：包括馬蜂窩大促營銷、業務營銷、新人禮包等

下面，我們重點介紹營銷搭建平台的核心部分——活動開發平台，是如何實現高效、靈活的營銷活動開發模式的。

 

二、活動開發平台的實現

2.1 靈活高效的開發模式

通過上圖可以看到，由 MySQL、ElasticSearch、Redis 組成的數據池在底層為活動開發平台提供支撐。其中 MySQL 為最主要的存儲方案，用於會場搭建配置數據、蜂玩樂園的用戶運行數據、獎池配置數據等的存放。ElasticSearch 是搜索引擎，支持活動頁面商家活動報名與篩選過程。Redis 有 2 種用途：1）活動任務併發鎖；2）獎池的獎品數據存放；3）限流和削峰。

之前我們提到，活動開發的挑戰包括數量多、周期短、功能複雜多變。為了降低開發同學的工作量，提升研發效率，我們將前端和後端組件進行了整合，並封裝成功能模塊對提供服務，形成了目前的魔方、蜂玩樂園、獎池三個子系統，使整體結構更加清晰。每個部分解決的問題和主要功能模塊示意如下：

2.1.1 系統分層

魔方

「魔方」系統希望通過組件、工具的方式完成營銷頁面的搭建，實現統一維護和復用，從而減少前端團隊在活動開發中承載的重複性開發工作。目前為止我們已經在「魔方」中開發了 80 多個組件模塊，例如秒殺模塊、貨架模塊、店鋪模塊、導航模塊、領券模塊、遊戲互動模塊等。

現在，小型活動完全可以不用開發人員支持，只需要業務同學操作即可搭建促銷會場上線活動，提升了活動運營效率，也大大解放了前端開發人員。關於「魔方」更多的細節我們會在後續文章單獨介紹，本文不過多展開。

蜂玩樂園

(1) 邏輯功能抽象

營銷活動的核心是創新和吸引力。每次活動開始前，運營同學都會在創意策劃上絞盡腦汁，盡可能創造出與眾不同的新玩法。這些新穎有趣的遊戲玩法，可以在微信，App 等渠道引起用戶的好奇心和興趣，為賣場拉新，進而創造更多的交易。

隨着「花樣」的不斷翻新，活動開發的複雜度也在增加，有時甚至讓技術同學應接不暇，也促使我們探索更加高效的開發方式。

我們開始思考在複雜多變的活動玩法下，是否潛藏着一些不變的模式和規則？通過對不同業務活動模式的分析和抽象，我們將活動的流程和用戶的行為進行了一個有趣的類比：

• 首先，開發活動就創建了一個「樂園」

• 我們會根據不同的「規則」去設計每一個「活動」，激發潛在「參与者」的興趣，或建立他們希望贏得獎勵的期待。

• 進入活動后，我們會驗證參与者「身份」，和需要滿足這次活動的「條件」，來確定他是否可以開始。

• 活動開始時，參与者參与一次活動需要發生的行為，就是在完成「任務」

• 完成「任務」后，為參与者發放相應的「權益」或「獎勵」。

這個類比模型在歷屆促銷活動中進行了推演，結果显示基本是通用的，但完成任務可能伴隨獎勵服務，也可能沒有，由具體業務需求決定。舉個例子，在一場紅包裂變的營銷活動中有一個需求是下紅包雨，用戶可以點擊掉下來的紅包領取相應的紅包獎勵。那麼「領取」這個動作就可以視為活動中的一個任務；另一個需求是每當用戶成功邀請一位好友后就可以在任務中心領取一個邀請紅包獎勵，那麼我們可以把在任務中心領取邀請紅包也看成一個任務。

這兩個任務有一個共同的特點就是觸發后都有紅包獎勵，只是在第二個場景中的任務，本質上是用戶發起了一個請求。

經過進一步的梳理、規整，我們抽象出了「參与者」、「活動」、「任務」、「獎品」等業務邏輯功能。

(2) 技術實現

蜂玩樂園將每一個業務邏輯功能收歸到一個唯一的入口和統一的體系中，形成獨立的功能組件模塊，如數據請求模塊、自定義數據配置模塊、驗證器模塊 、執行器模塊、獎勵服務模塊等。每個活動的任務開發都可以選擇模塊配置，模塊配置信息以 yaml. 的格式進行統一管理，這樣的配置具有靈活性、擴展性和可復用性。

在使用的時候解析配置數據，並向組件註冊中心註冊該任務所需要的組件模塊，再按照定義好的順序執行即可。流程如下圖所示：

為大家介紹幾個關鍵模塊的實現。

• 數據請求模塊

數據請求模塊定義了客戶端與服務端約定好的請求參數規則：

request:
       -
        field:  deviceId
        rule: required  #必填項校驗
        method: post
        message:  deviceId參數錯誤
       -
        field:  sex
        rule: in:[0,1] #範圍校驗
        method: post
        message: 性別範圍錯誤
       -
        field:  phone
        rule:   regex:/^1[3456789]\d{9}$/ #正則校驗
        method: post
        message: 手機號格式錯誤

(i) field – 傳入參數的 key 
(ii) rule – 校驗該參數的規則，目前我們已經實現了一些常用的規則：
(iii) required – 必傳參數

• in：驗證所傳參數必須在指定範圍內

• regex：正則表達式校驗 

• min，max：自定義規則最小和最大長度

• integer：必須是数字

• method：定義 GET、POST 請求方式，

(iv) message – 規則驗證失敗返回的錯誤信息。這一層會讀取配置模塊中的請求參數模塊配置內容，將內容解析出來，按照所配置的字段規則做響應的校驗，如校驗通過繼續向下執行，沒有通過則直接返回規則提示。

• 參數配置模塊

參數配置模塊定義了該任務執行中所需配置的所有靜態數據配置項。營銷活動的特點是多樣性、創新性，所以很難去窮舉各種場景建立一個有針對性的配置中心，因此這裏就為每一個任務單獨開闢了一個沒有結構化的小空間，可根據具體場景的特定需求為任務自由配置，使程序代碼里基本不用再寫各種不合理的硬編碼。

params:
    stockRedPacket:
     amount: 1
     stock: 3
     stockKey:  limit_key
     stockField: limit_key_90
     timeWindow:
       beginTime: "2019-11-06 00:00:00"
       endTime: "2019-11-10 23:59:

以一個用戶開啟紅包的配置信息為例：

(i) stockRedPacket 配置了活動設定的固定庫存與固定金額紅包的業務邏輯

• amount 金額

• stock 庫存

• stockKey、stockField 用來加鎖的字段

(ii) timeWindow 定義了該任務的活動開始和結束時間

 

• 驗證器模塊

驗證器模塊的功能主要是是對業務或者規則的校驗。它定義了該任務要執行的業務驗證規則，特點是具有單一性、普適性，能提供一種適用於大多數場景的方法。這些驗證規則可以拆解得足夠細，越細則越靈活，得以在不同任務中靈活組裝使用。

validator:
   - MCommon_Validator_TimeWindowValidator
   - MCommon_Validator_AuthValidator
   - MCommon_Validator_LockValidator

• 這裏使用了活動時間驗證 TimeWindowValidator，不在活動時間內則返回錯誤提示

• 登陸驗證 AuthValidator，參加活動必須要登錄，前端通過判斷錯誤狀態碼統一跳轉到登陸頁面

• 併發鎖 LockValidator，避免一個用戶同樣的操作多次提交

• 取出所有的驗證器，然後通過反射依次按照順序調用，如果其中一個驗證器失敗，則直接返回錯誤信息，終止向下執行。

 

• 執行器模塊

執行器模塊定義了該任務要執行的一些業務邏輯，比如要執行一段寫日誌的邏輯，要執行一個異步調用的邏輯等，都可以使用此模塊定義一個執行器去執行。

command: MSign_Command
afterCommand: MSign_Command_After

執行器又分為前置 command 和後置 afterComman：

 

• 如果需要執行獎勵模塊，則先執行前置 command，再執行獎勵邏輯，最後執行後置 afterCommand，最終返回結果

• 如果沒有獎勵，則先執行前置 command，接着執行後置 afterCommand

 

• 獎勵服務模塊

獎勵服務模塊決定該任務是否需要執行獎勵發放，如果配置了獎勵，任務在執行時會根據獎勵的配置規則下發獎勵。在我們的實際場景中，主要涉及到的獎勵類型包括獎勵機會、紅包、抽獎、優惠券等：

• 獎勵機會：有 2 種規則，分別是按固定頻次給用戶初始化機會數，和獎勵增量機會數。

• 發送紅包：設定固定紅包和隨機紅包，隨機紅包按需求設置發放的概率與用戶群。

• 抽獎：對接獎池系統，下文詳細介紹。

• 優惠券：與馬蜂窩優惠中心直接打通，只需要配置優惠券 SN 和渠道號，即可把優惠券發送到用戶卡券。

 

獎池

在營銷活動中，許多場景都涉及用戶抽獎或獎品發放。營銷技術平台因此對獎品發放的整個生命周期進行了抽象和封裝，創建了「獎池」。

(1) 主要功能

獎池的主要功能點包括：

• 創建獎品池：為每次活動創建一個或多個獎品池

• 設置獎品：在單一獎品池中均勻放置獎品

• 用戶抽獎：用戶在單一獎池中抽獎，支持按概率抽獎，支持獎品的發放和領取

• 中獎統計：包括獎品已發放數量，已領取數量，剩餘數量

如下圖所示，只需創建好獎池，配置好獎品信息，把對應的獎池 ID 填寫到任務，即可實現抽獎功能：

(2) 方案設計

獎池早期的設計非常簡單，獎品實體僅定義「余量」的概念，利用關係型數據庫中單行記錄存儲一次活動的獎品、總量、發放量、余量等數據。在用戶流量較小且均勻的情況下，發放過程平穩正常。每次進行獎品發放時，在單行記錄上進行 update 操作，扣減余量並增加發放量即可。

然而隨着公司業務的發展，一次營銷活動帶來的效果讓我們不得不立刻改進獎池方案。這次營銷活動帶來的流量遠超預期，但獎品數量的配置卻一如往常。當活動開啟后，獎品消耗很快，並在一段時間后被提前抽光。為了不影響用戶體驗，營銷運營同學不得不持續向獎池中補充獎品。

經歷這次問題開發同學發現，獎池提前抽光的原因在於設計中忽略了時間分佈的因素，使獎品抽光的速度只與訪問量相關。因此，大家開始思考如何讓獎品固定且均勻分佈在活動周期內。

通過學習與比較，最終選擇了業界比較通用的方案，使用 Redis 的有序集合（Sorted Set）創建獎池和設置獎品，從而使獎品在活動時間段內均勻分佈，防止提前抽光的情況出現。

(3) 實現算法

 

1. 時間戳：根據獎品的數量和活動時長，為每 1 份獎品設置一個出獎時間戳，這份獎品僅能在這一時間點及之後被抽出。這一步使出獎時間戳盡量均勻分佈在活動時間範圍內。

2. 創建獎品池：為每一組獎品設置一個獎池，在 Redis 創建一個 zset 數據結構，將其中的每 1 份獎品作為 1 個成員（Member），將時間戳作為分值（score）。
3. 放置獎品：使用ZADD 獎池 出獎時間戳 1 份獎品 語法，在 Redis 中布置一個獎品。

4. 抽獎：使用 Sorted Set 的排序方法，每次排序后查看排名第一的獎品，比較當前時間戳與獎品時間戳的大小。如果當前時間晚於或等於出獎時間，則使用 ZREM 指令出獎，否則不出。

示意圖如下：

2.1.2  體系統一

為了讓開發同學只專註於任務的設計開發，我們抽象出「賬戶」的概念，每個任務產生的數據資源會存儲在所在的「賬戶」體系下，使其支撐多個類似的活動。這種設計的好處在於：

（1）同一用戶在參与不同的活動時得到的獎勵都是相互獨立的，不會出現混淆的情況。

（2）之前每次活動都需要單獨創建數據表，活動下線后表不能復用。時間長了造成系統佔用許多無用的數據表。而把數據庫表以抽象的任務形態創建，不針對具體的某一業務類型，就可以使數據表實現復用。這樣我們只專註任務的設計開發，不用再關心數據表的設計。

在營銷大促的活動中，我們也接入了風控中心、併發鎖和限流服務，以保障整個活動的安全和穩定。

2.2 可用性和可靠性

秒殺模塊是大促流量的最高峰。結合業務實際，我們針對這種場景也做了限流和削峰處理。

限流採用的方案是限制時間窗內最大請求數據，用戶再搶會員權益時，第一步會讀取限流配置 key 和 value，判斷單位時間內是否超過限制的最大請求數 value，如果超過則返回信息提示結束請求；如果沒有超過閾值，則進入下一步操作。目前的限流系統只是在應用層面的實現，為了更好地支撐業務發展，後續我們也會接入網關服務，通過 Sentinel 和 Hystrix 做限流熔斷，避免流量進入應用層，提高服務的高可用性。

削峰部分結合實例說明。

以秒殺金卡會員的場景為例，我們會先用 RabbitMQ 承接瞬時的流量洪峰，再平滑地消費所有請求，並提前把庫存數量對應的 Token 寫入 Redis 緩存（這裏我們針對性的對不同的用戶引入了 Token 機制，以保證我們的秒殺商品在時效和庫存上得以保障）。用戶在秒殺時會順序地從 Redis 中 rPop 對應的 Token，避免庫存超賣的情況；用戶拿到 Token 之後再去收銀台下單開通金卡會員，就可以避免流量同一時刻去下單。

隨着業務和技術的發展，系統的不確定性以及流量的預估都更為困難。我們也在不斷學習業界的先進經驗，來更好地提升系統的可用性和可靠性。目前我們正在調研基於 Noah 的「自適應」限流技術並积極推進，以期針對不同的服務器性能以及當前的流量情況進行針對性的限流控制，相信我們會在後續的優化中會做得更好。

2.3 風險控制

目前是接入公司統一的風控中心。在營銷活動需求確定好后，我們會向風控服務中心提供需要風控的業務場景邏輯。風控中心根據業務配置不同策略，給出不同的場景 key。我們只需要在營銷活動任務中的自定義參數配置模塊配置好風控場景 key，就可在獎勵服務模塊自動調用風控接口去校驗用戶，如果識別出是風險用戶則會被攔截，終止活動參与。

可用性和可靠性、風險控制的實現流程如下圖所示：

 

三、近期規劃

1. 完善監控體系

目前對於活動運行中的數據監控，主要依賴數據組的統計與輸出。線上活動的運行情況並不能通過「蜂玩樂園」與「獎池」系統實時並綜合表現出來。

未來會補齊運行時的活動監控功能，通過活動、任務、獎品的運行時數據指標，指導運營同學第一時間調整活動參數，取得最佳運營效果。

2. 服務化改造

營銷基礎平台依舊搭建在單體架構上，部分功能的邊界與職責並不完全清晰。接下來營銷技術平台會進行技術架構的升級與改造，從單體架構轉向微服務架構，使服務能力與開發能效同步提升。

小結

隨着營銷的逐年發展，活動的趣味性和複雜度會一起上升，這需要我們不斷更新對營銷活動的認識。在這過程中也要反覆嘗試新的抽象和重構，通過不斷改進現有系統，支持更多和更好玩的營銷活動，讓馬蜂窩用戶玩兒得更省心，玩兒得更省錢。

本文作者：馬蜂窩電商研發營銷中心團隊劉遠勻、任浩、唐溶波。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益