5種常見Bean映射工具的性能比對

本文由 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  ?

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

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

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

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

採礦業進駐 污染環境 阿根廷紅酒區爆水資源戰

摘錄自2019年12月25日明報報導

拉丁美洲最大葡萄酒產區、阿根廷門多薩省(Mendoza)爆發當地史上最大規模的示威,抗議省政府為擴大財源,修訂《水資源保護法》,容許使用大量水資源的採礦業進駐當地,並可在開採過程中使用氰化物和硫酸等有害物質,恐令當地水源受污染,並加劇旱情,損害葡萄種植戶、酒廠等的生計。

《水資源保護法》於2007年制定,限制省內的採礦過程中使用危險化學品,並禁止大量用水的採擴項目,以免影響環境。惟門多薩省議會上周五(20日)以大比數通過修例,批准省內的採礦活動使用氰化物、硫酸及其他有害化學物質。

省長蘇亞雷斯周日(22日)宣布已有19個開採鈾、銅、金、鉛、銀、鋅、鐵礦項目等待議會批准,進一步激起民憤。

省環境部長明戈蘭塞聲稱水資源不會因新政策受損,也不會對環境構成任何負面影響,強調環保糾察將規管省內每一個採礦項目對環境的影響,且將在礦場所在地辦公開聽證會。阿根廷新任總統費爾南德斯(Alberto Fernandez)表示支持礦業項目,認為對阿根廷從長期的經濟困境中復蘇至關重要。

千計群眾周一(23日)再次遊行到省府門多薩市的省長辦公室外抗議,高叫「別動水源」和修例違憲等。這場門多薩省史上最大型示威演變成警民衝突。憤怒的示威者向現場防暴警員擲石,遭警方動用橡膠子彈與催淚彈驅散。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

通用汽車與 Lyft 合作,無人計程車上路測試

未來一年內,通用汽車(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中異步AsyncIO的實現 (源碼分析)

先上張圖整體了解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  ?

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

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

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

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

巴西東北岸海灘 再出現原油污染

摘錄自2019年12月31日中央社報導

巴西海軍今天(31日)表示,東北部塞阿拉州(Ceara)部分海灘發現原油油污,快兩個月前,這個地區也曾被另一波浮油侵襲。

那次的污染是原油大規模外洩的一部分,在9月到11月污染了巴西東北岸數百個海灘,威脅海洋生物、觀光業和漁業,源頭至今仍是個謎。

塞阿拉聯邦大學(Federal University of Ceara)海洋研究人員卡瓦坎特(Rivelino Cavalcante)告訴新聞網站G1,和這次污染相同,於今年稍早出現在海灘上的大量油污仍沈積在海床,因為洋流的關係才跑到岸邊。

巴西政府官員曾表示,檢測顯示外洩原油的源頭是委內瑞拉,但委國否認。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

搶入特斯拉自駕電動車供應鏈 英特磊營收看漲

英特磊 8 日公布 6 月營收 7,693 萬元,月增 8.18% 而年增 15.2%,第 2 季營收 2.24 億元,季增 8.21% 年增 46.84%,月、季營收同步創高,公司並將在 9 月洽談車用防撞系統新單,可望打入 Tesla 發展自駕(ADAS)電動車需求,再創營運高峰。    據了解,英特磊收購 Soitec 後,取得全球最大車用防撞 IC 廠 UMS 供應認證,UMS 打入多數歐系高級車,包括 BMW、Audi、賓士等,同時間,UMS 也是與 Tesla 計畫合作自駕車系統 Mobileye 的主要客戶,在此緊密的車用供應鏈關係中,英特磊持續獲得熱賣車款點火。   英特磊看好第 3 季旺季需求,將獲得新布局的車用防撞雷達、Skyworks 物聯網帶動,因此公司先在 5 月進行歲修調整機台,將對全年營收衝刺動能有關鍵性助益。 ]

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

【其他文章推薦】

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

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

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

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

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

支撐馬蜂窩「雙11」營銷大戰背後的技術架構

(馬蜂窩技術原創內容,公眾號 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  ?

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

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

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

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

回顧2019年極端天氣事件 全球損失超過1000億美元

環境資訊中心綜合外電;姜唯 編譯;林大利 審校

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

騰訊出資!中國版特斯拉 NextEV 先瞄準中國市場

騰訊和高瓴資本在內等多家中國網路巨頭和金融投資機構共同投資的新能源汽車廠商 NextEV,將成為特斯拉(Tesla)的競爭對手。據路透報導,NextEV 發言人劉吉利表示,已聘請福特前高管 Martin Leach 打造一家全球性汽車廠商,他們還招聘了有在特斯拉、寶馬(BMW)、大眾(VW)和其他主要汽車廠商工作經驗的專家。他強調,NextEV 將先瞄準中國市場,然後走向世界。   NextEV 投資方包括數家非汽車廠商的中國科技公司,且其開發電動車的努力得到中國政府的支持,中國政府最近修改相關法規,允許非汽車廠商投資電動汽車產業。目前已宣布或在考慮投資電動汽車產業的中國科技公司包括阿里巴巴、小米和樂視。   劉吉利表示,NextEV 推出的第一款產品將是一款電動超級跑車,預計該車表現將超過世界上所有採用內燃機的跑車。NextEV 並將於明年推出賽車車型,功率超過1000馬力,加速到時速 100 公里僅需 3 秒。之後 NextEV 還會推出一系列高性能車型。

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

【其他文章推薦】

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

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

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

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

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

China .NET Conf 2019-.NET技術架構下的混沌工程實踐

這個月的8號、9號,個人很榮幸參加了China.NET Conf 2019 , 中國.NET開發者峰會,同時分享了技術專題《.NET技術架構下的混沌工程實踐》,給廣大的.NET開發小夥伴介紹混沌工程和高可用性改造實踐。會後大傢伙聚餐的時候,陳計節老師建議大家將各自的議題分享到社區,分享給大家。因此,今天和大家分享我的技術專題《.NET技術架構下的混沌工程實踐》。

先放幾張大會照片:

整個專題主要分為四個部分:

  1. .NET分佈式、微服務架構下的高可用性挑戰
  2. 混沌工程簡介
  3. .NET混沌工程的實踐和成果分享
  4. 展望和規劃

一、.NET分佈式、微服務架構下的高可用性挑戰

目前,我們特來電的技術架構是分佈式、微服務化的,線上超過1000台Server,高可用保障壓力很大:

  • 系統7*24小時運行,不允許宕機,一旦宕機出問題,直接影響全國人民出行;
  • 系統SLA要求99.95% ,全年可宕機時間只有4.38小時;
  • 服務調用鏈路越來越長,依賴越來越複雜,某個環節出問題,都有肯能導致服務雪崩、大規模宕機;
  • 線上遭遇:網絡抖動、內存泄露、線程阻塞、CPU被打爆、 數據庫被打爆、中間件宕機等棘手問題;
  • 每天上百次發布更新,系統高可用性保障壓力非常大;

一張全鏈路監控圖可以反映我們系統的複雜:

 

例如主機CPU被打爆的問題,線上經常會遇到:

經歷了線上各種高可用性問題后,我們做了很多反思和總結:

系統在實現了分佈式、微服務化之後,我們到底有多少把握來保證系統的正常運行?  

如果出現問題,整個分佈式系統會變得非常“混亂”,甚至會引發系統的大規模宕機。

因此,我們有必要在線上事故出現之前,提前識別出系統有哪些弱點和問題,統一管控系統的固有混沌。

這套管控系統固有混沌的方法和體系,就是我們今天要介紹的主角:混沌工程

二、混沌工程簡介

1. 什麼是混沌工程?

通過受控的實驗,掌握系統運行行為的過程,稱為混沌工程。

    混沌工程的典型實踐:Chaos Monkey
     一隻搗亂的猴子,在你的系統裏面上蹦下竄,不停搗亂,直到搞掛你的系統。

    

2. 為什麼需要混沌工程?

   混沌工程可以提升整個系統的彈性。
   通過混沌實驗,可以發現系統脆弱的一面,主動發現這些問題,並解決這些問題

3. 混沌工程怎麼做?

   混沌工程的一般實施步驟:

1 選擇系統正常運行狀態下的可度量指標,作為基準的“穩定狀態” 2 混沌實驗分為實驗組和對照組,都能保持系統的“穩定狀態” 3 對實驗組注入混沌事件,如服務不可用、中間件宕機等混沌事件 4 比較實驗組和對照組“穩定狀態”的差異

   如果混沌實驗前後系統的“穩定狀態”一致,則可以認為系統應對這種混沌事件是彈性的、高可用的。
   相反的,如果打破了系統的穩定狀態,我們就找到了一個系統弱點,然後盡可能地解決它,提升系統的高可用性。

4. 實施混沌工程的推薦原則

  • 明確系統穩定運行的狀態(指標)
  • 混沌事件必須是現實世界可能發生的(合理的)
  • 在生產環境進行混沌實驗 :生產環境可以真實地反映系統的穩定性
  • 持續集成:線上應用每天都在更新,通過持續集成的方式可以不斷髮現問題、解決問題。
  • 最小化影響範圍:線上進行混沌實驗,必須可控,必須確定混沌實驗的最小化影響範圍。

   這裏大家會問:在生產環境上搞混沌實驗,能行嗎?

5. 現實中的混沌工程

  生產環境必須以穩定為前提,因此推薦O2O模式的混沌實驗:即線下演練、線上驗證
  在系統未經過大規模高可用性改造之前,建議首先進行全面的線下演練:

   

   那麼, .NET技術架構下的混沌工程怎麼做?

三、.NET混沌工程的實踐和成果分享

  我們線上系統主要用到了以下.NET技術棧和開源技術:

  • ASP.NET MVC
  • 基於ASP.NET Core的Web運行框架-WRF
  • 基於ASP.NET Web API的分佈式服務網關-SG
  • 基於.NET RPC通訊技術的分佈式微服務平台-HSF
  • 基於RabbitMQ和Kafka的消息應用中心-MAC
  • iBatis.NET & Entity Framework
  • RabbitMQ & RabbitMQ Client for .NET
  • Kafka & Confluent.Kafka
  • Redis
  • Nginx

    在上述.NET 技術架構下,我們梳理了大量的混沌工程事件:

    

    

    

     通過大量的混沌實驗,我們逐步建立了提升系統高可用性的方法論和體系:

     

     .NET技術架構下的高可用性改進-依賴治理、容錯降級     

      業務場景:
      隨着業務複雜度的上升,服務調用鏈路越來越長,鏈路上存在大量不可控的因素:      

    • 網絡抖動,導致服務異常
    • Redis、MQ、DB等中間件不可用,導致服務超時、異常
    • 依賴的服務不可用,直接影響服務調用方  

          

     如何應對:識彆強弱依賴,對弱依賴進行降級,對強依賴有限降級     

    • “用戶有感知” 是強依賴
    • “用戶無感知” 是弱依賴
    • 故障發生時,核心業務有損失的是強依賴,無損失的是弱依賴

           

      .NET技術架構下的高可用性改進-解耦/隔離       

      業務場景:
      核心業務的調用鏈路很長,整個鏈路上包含主流程和輔流程
      輔流程的重要性低,不能因為輔流程的不可用,影響了主流程。

      

       如何應對:

       

       .NET技術架構下的高可用性改進-超時治理        

       業務場景:
       對於服務超時,長時間等待會影響用戶體驗,併發大時還可能造成線程池被打爆。
       同時可能產生服務級聯反應,導致大範圍服務雪崩。

              

        應對方案:
        超時時間設置:服務剛上線時,可以根據壓測情況預估一個值;
        服務上線后再根據實際監控進行修改,比如設置99%的請求響應時間為超時時間。
        超時后的處理策略:
        如果不是核心服務,可直接超時返回失敗。
        如果是核心服務,可以設置相應的重試次數.         

        示例:
        配置服務超時時間
        設置Http請求超時時間
        設置數據庫連接超時、SQL執行超時
        代碼控制超時時間(例如:Polly的Timeout策略)

      .NET技術架構下的高可用性改進-重試補償         

        業務場景:
        實際線上應用中,假如遇到網絡抖動、發布重啟、數據庫阻塞超時等情況,都有可能引起服務調用失敗。         

        應對方案:
        通過失敗重試、異常后的補償,盡可能地保證業務可用。
        重試情況下:業務要保證冪等性、保證最終一致性。        

        示例:
        服務失敗重試策略
        消息發送、消費失敗重試、補償
        代碼層面失敗重試補償(例如:Polly的Retry策略)

      高可用改進還有很多技巧,這裏不一一詳細給大家贅述了。

      通過對系統進行全面的高可用性改進,提升了我們對線上系統的信心!

四、 展望和規劃

    2019年,我們啟動了混沌工程實踐,逐步建立了混沌工程的自有方法論和體系,通過近一年的混沌工程實踐,混沌工程文化逐漸被開發團隊所認可。目前,混沌工程已經逐步過渡到線上生產環境進行(這來自於足夠的信心和把握)。但這隻是一個起步,未來:

  • 正式的混沌工程團隊:通過多團隊配合、保障資源的持續投入
  • 覆蓋所有的關鍵核心應用:讓混沌工程深入到每個產品
  • 堅持O2O混沌工程實踐:線下演練、線上驗證,更可控
  • 混沌事件注入工具:ChaosBlade for .NET,工具讓混沌工程更高效
  • 持續的混沌實驗:持續進行、持續改進

    目標:通過混沌工程揭示問題、解決問題、形成閉環,不斷提升系統高可用性。

以上是本次China.NET Conf 2019的技術專題,分享給大家。

 

周國慶

2019/11/15

 

 

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

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

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

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

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

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