chinesefreesexvideos高潮,欧美极品少妇性运交,久久久国产一区二区三区,99久久婷婷国产综合精品,成人国产一区二区三区

就營(yíng)銷活動(dòng)搭建的發(fā)展過(guò)程而言：最初的營(yíng)銷活動(dòng)的搭建通常是“定制化”的，面臨一個(gè)需求、一個(gè)場(chǎng)景寫一個(gè)活動(dòng)，慢慢地重復(fù)性活動(dòng)越來(lái)越多，開(kāi)始借鑒模板的思想，制作幾套活動(dòng)開(kāi)始每次換膚，但是次次換膚限定了玩法套路，容易導(dǎo)致用戶疲勞，效果開(kāi)始衰退。

這時(shí)候活動(dòng)的訴求已經(jīng)變成在現(xiàn)有的模版思想上靈活串聯(lián)現(xiàn)有玩法，并不斷新增玩法，所以開(kāi)始沉淀一個(gè)又一個(gè)的標(biāo)準(zhǔn)“玩法”，比如說(shuō)任務(wù)、簽到、抽獎(jiǎng)、投票、答題、助力、組團(tuán)、打榜等等若干玩法，然后每次有新的活動(dòng)我們只需要手動(dòng)開(kāi)發(fā)串聯(lián)即可。

整個(gè)的對(duì)于玩法的串聯(lián)，可以通過(guò)定制開(kāi)發(fā)解決，也可以通過(guò)研發(fā)配置解決，最終可以完全脫離研發(fā)運(yùn)營(yíng)配置解決，本篇要描述的就是營(yíng)銷活動(dòng)中，用戶參與流程或者說(shuō)玩法串聯(lián)的流程編排問(wèn)題。

一、分析現(xiàn)狀

正如前面所提到的，我們對(duì)于常用的玩法進(jìn)行沉淀之后，我們獲得了各類形式的抽獎(jiǎng)、答題、任務(wù)、簽到等玩法，在使用的過(guò)程中，通常是玩法A的某個(gè)動(dòng)作在某種場(chǎng)景下關(guān)聯(lián)玩法B的某個(gè)動(dòng)作，比如用戶第一次參與答題獲得一次抽獎(jiǎng)機(jī)會(huì)，用戶任務(wù)完成獲得現(xiàn)金等等。

如果純研發(fā)開(kāi)發(fā)定制關(guān)聯(lián)的話，每次面臨開(kāi)發(fā)的關(guān)系是相對(duì)復(fù)雜的，按照量級(jí)來(lái)算基本是：m*n*s （輸出事件、輸入動(dòng)作、場(chǎng)景），即使每次都有沉淀，玩法和玩法的交互關(guān)系基本是過(guò)度復(fù)雜、難以維護(hù)的，所以我們需要一個(gè)“總線”工具來(lái)集中管理這些交互，降低復(fù)雜度。

二、整體設(shè)計(jì)思路

對(duì)于這些易變且復(fù)雜的邏輯，最直觀的思路是剝離業(yè)務(wù)決策邏輯與代碼決策邏輯。在活動(dòng)編排的場(chǎng)景下，業(yè)務(wù)邏輯是玩法事件之間的關(guān)聯(lián)關(guān)系及決策關(guān)系，代碼關(guān)聯(lián)就是各類事件的接受、各類事件的call。

1. 事件驅(qū)動(dòng)設(shè)計(jì)

所以需要規(guī)范下玩法的輸入輸出，然后有一個(gè)地方能夠?qū)@些事件配置關(guān)聯(lián)，對(duì)于關(guān)聯(lián)之間的業(yè)務(wù)決策邏輯，只需要借鑒一下決策引擎就可以了。整個(gè)抽象完成后活動(dòng)串聯(lián)的成本已經(jīng)從m*n*s降低到m+n，并且直接進(jìn)入到研發(fā)配置關(guān)聯(lián)階段，成本至少能縮減80%以上，并為后續(xù)的運(yùn)營(yíng)可直接手動(dòng)配置提供了功能開(kāi)發(fā)的切入口。

說(shuō)到這里大家應(yīng)該發(fā)現(xiàn)本質(zhì)上就是一個(gè)業(yè)務(wù)事件總線，如果看過(guò)SOA事件交互總線的定義，本質(zhì)上思想是一樣的，只不過(guò)我們不需要SOA這么強(qiáng)的定義。不光是SOA架構(gòu)設(shè)計(jì)中會(huì)有相關(guān)描述，如果熟知微服務(wù)架構(gòu)、事件驅(qū)動(dòng)架構(gòu)還有DDD設(shè)計(jì)思想等，也存在大量對(duì)于事件總線設(shè)計(jì)的描述。

這里的業(yè)務(wù)事件總線不過(guò)是在這些思想之上，根據(jù)活動(dòng)業(yè)務(wù)場(chǎng)景進(jìn)行本地化處理，增加了一些動(dòng)態(tài)決策、配置關(guān)聯(lián)的能力。

2. 上下文共享問(wèn)題

在把各種玩法解耦，然后通過(guò)業(yè)務(wù)事件總線進(jìn)行玩法關(guān)聯(lián)，每個(gè)玩法內(nèi)部基本形成一個(gè)信息孤島，只關(guān)心自己內(nèi)部的變化，其實(shí)是不利于活動(dòng)邏輯的。高門檻任務(wù)加的抽獎(jiǎng)機(jī)會(huì)面向的獎(jiǎng)品集合往往價(jià)值更高，不同的組團(tuán)（不同身份團(tuán)隊(duì)成員）面向的獎(jiǎng)勵(lì)價(jià)值也是不同，很多時(shí)候需要依賴用戶參與的上下文信息，如果打破信息孤島，通常有兩種處理思路：

1）把獎(jiǎng)勵(lì)這些需要上下文的玩法做成一種基礎(chǔ)能力，感知所有玩法的上下文，獎(jiǎng)勵(lì)作為一種微內(nèi)核的存在，每個(gè)玩法直接帶著上下文調(diào)用。

2）進(jìn)一步抽象這些感知上下文的應(yīng)用，將業(yè)務(wù)規(guī)則進(jìn)一步剝離，僅有業(yè)務(wù)規(guī)則（規(guī)則引擎）感知上下文信息，其他玩法的上下文對(duì)于一個(gè)玩法來(lái)說(shuō)只是普通 key-value 而已，具體使用在持有業(yè)務(wù)規(guī)則的表達(dá)式中執(zhí)行。

整體來(lái)看兩種思路本質(zhì)上都是可以的，適用于不同的系統(tǒng)發(fā)展階段，活動(dòng)相對(duì)較多，第一種就足夠了，復(fù)雜活動(dòng)較多，第二種就相對(duì)適合。

整體比較來(lái)看：

• 第一種：實(shí)現(xiàn)相對(duì)簡(jiǎn)單，對(duì)玩法的要求相對(duì)較低，但是如果一個(gè)操作，同時(shí)涉及多個(gè)玩法的上下文，處理相對(duì)費(fèi)勁。并且需要上下文的操作如果變多且關(guān)聯(lián)，架構(gòu)就逐漸退化到手動(dòng)強(qiáng)關(guān)聯(lián)。

• 第二種：實(shí)現(xiàn)相對(duì)復(fù)雜，對(duì)于玩法可配置要求較高，但擴(kuò)展性較好，對(duì)于復(fù)雜活動(dòng)的處理更加輕松。

3. 上下文的設(shè)計(jì)

上下文的設(shè)計(jì)相對(duì)簡(jiǎn)單，可以粗暴地理解為一個(gè) get 的路由分發(fā)，大家可以理解為一個(gè)具有業(yè)務(wù)特性的 dataSource，可以根據(jù)一個(gè) key 來(lái)找到我們所需要的用戶參與的上下文信息。

具體的實(shí)現(xiàn)方案可以是一個(gè)集中存儲(chǔ)，用來(lái)存放活動(dòng)的上下文，也可以是邏輯上的集中存儲(chǔ)，做一層代理透過(guò)玩法注入的 method 活動(dòng)上下文。

上下文 + 動(dòng)態(tài)決策編排 = 活動(dòng)編排引擎

三、性能保證

由于需要處理一個(gè)業(yè)務(wù)或者幾個(gè)業(yè)務(wù)下的事件流轉(zhuǎn)，業(yè)務(wù)事件總線是一個(gè)對(duì)性能要求相對(duì)較高“系統(tǒng)節(jié)點(diǎn)”，需要盡可能保證它的性能極佳的特點(diǎn)，這里就來(lái)說(shuō)一下對(duì)于事件總線的整體優(yōu)化過(guò)程（按照老套路，先優(yōu)化點(diǎn)、再優(yōu)化分布式場(chǎng)景下“量”），先看結(jié)果：

1. 更少&更快的IO

對(duì)于事件總線的使用，盡可能不發(fā)生網(wǎng)絡(luò) IO，首先對(duì)于事件總線調(diào)用的應(yīng)該本地化，第二是事件總線對(duì)于外部事件的調(diào)用盡量本地化，僅作為邏輯上的模塊。

如果因?yàn)閿U(kuò)展性、可用性等若干因素，當(dāng)前的架構(gòu)不允許或者不支持整個(gè)活動(dòng)玩法打包到一起部署，便免不了發(fā)生 IO，那就一句話，盡可能地利用 epoll，這些事作為一個(gè)業(yè)務(wù)開(kāi)發(fā)來(lái)說(shuō)交給基礎(chǔ)架構(gòu)來(lái)處理就好啦。

2. 更快的存儲(chǔ)

硬編碼 > 內(nèi)存 > 本地磁盤 > 網(wǎng)絡(luò)IO，常規(guī)事件之間的關(guān)聯(lián)關(guān)系直接內(nèi)存存儲(chǔ)（可以DB預(yù)加載至進(jìn)程內(nèi)），強(qiáng)關(guān)聯(lián)事件配置直接硬編碼（硬編碼的配置問(wèn)題可以利用一些表達(dá)式），避免發(fā)生網(wǎng)絡(luò)IO、磁盤IO。

3. 合理的優(yōu)化分布式下的量

事件異步化處理&微批處理這類優(yōu)化吞吐的直接拿來(lái)主義，看看 kafka 之類的 mq 的優(yōu)化思路，我相信大家就知道該怎么做了，像這種場(chǎng)景直接就別重復(fù)造輪子了，用 kafka 實(shí)現(xiàn)異步化就足夠了。

平衡一致性、可用性，前面提到了盡可能利用快的存儲(chǔ)，在分布式場(chǎng)景下，如果能接受多節(jié)點(diǎn)不一致可以用這個(gè)思路，如果一致性要求相對(duì)較高可以用單點(diǎn)的 redis 進(jìn)行關(guān)聯(lián)關(guān)系的存儲(chǔ)，如果對(duì)可靠性要求很高再退一步使用 mysql 這些。

通常來(lái)說(shuō)，事件總線總并沒(méi)有顯著的業(yè)務(wù)熱點(diǎn)，橫向擴(kuò)容基本可以解決所有量的問(wèn)題，意義需要注意的就是這個(gè)業(yè)務(wù)上的單點(diǎn)，做好資源隔離就可以啦。

4. 數(shù)據(jù)一致性保證

事件總線并不是一個(gè)強(qiáng)業(yè)務(wù)實(shí)體，屬于一個(gè)純虛構(gòu)的概念，我們只需要使用到事件總線的流程能得到保證即可。

對(duì)于分布式事務(wù)的場(chǎng)景，這個(gè)依賴于分布式事務(wù)的實(shí)現(xiàn)方案，如果是TCC類，只要保證事件能正常參與進(jìn)事務(wù)中即可，對(duì)于依賴于事務(wù)型消息的分布式事務(wù)，可以替換下事件總線的“事件調(diào)用維護(hù)”，在事務(wù)消息隊(duì)列上做封裝即可。

對(duì)于沒(méi)有分布式事務(wù)的處理場(chǎng)景下，最大程度利用冪等重試，做好事件處理的補(bǔ)單極致就好了，順便說(shuō)下，圍繞“事件總線”做冪等重試是一個(gè)不錯(cuò)的處理思路。

四、現(xiàn)有的輪子

打開(kāi)搜索引擎搜一下業(yè)務(wù)事件總線，阿里云、騰訊云都有相似的解決方案，只不是針對(duì)的業(yè)務(wù)場(chǎng)景相對(duì)較少，這東西并不復(fù)雜一個(gè)人兩個(gè)周基本就能開(kāi)發(fā)完成上線了，最重要的是對(duì)應(yīng)思想的本地化實(shí)現(xiàn)，如果現(xiàn)實(shí)工作過(guò)程中遇到了相似的場(chǎng)景，綜合評(píng)估下成本來(lái)落地就好了。