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

　　愛奇藝海外App是一個重運營的應用。對于App里的頂導航、我的頁面、彈窗等，需要根據(jù)模式、版本、平臺、語言、渠道等不同的維度進行運營管理。隨著業(yè)務(wù)快速發(fā)展，版本快速迭代，如何保持運營資源能夠被高效、穩(wěn)定和靈活地配置，如何高效穩(wěn)定的為新的運營需求提供支持，是我們需要解決的問題。

　　在這種背景下，愛奇藝海外Phone后端研發(fā)組通過打造一個穩(wěn)定、靈活、高效的運營配置平臺來解決前面遇到的問題。本文主要分享我們在建設(shè)高效的運營配置平臺過程中積累的一些經(jīng)驗以及面臨的挑戰(zhàn)和思考。

　　1.配置資源拆解

　　運營類配置可以分為兩塊，運營資源和基礎(chǔ)數(shù)據(jù)的配置。

　　運營資源范例：彈窗

　　基礎(chǔ)數(shù)據(jù)：底部導航

　　1.1 運營資源

　　簡單而言，運營資源可以理解為App中經(jīng)常變動的一些廣告、運營活動等。比如上圖中彈窗廣告，就是一個典型的運營資源。對于這類運營資源，它們一般有如下特征：

　　時效性強：只在一定時間范圍內(nèi)顯示在C端固定位置。

　　模式強相關(guān)：每個活動、廣告都只會出現(xiàn)在固定的某些模式。

　　數(shù)據(jù)變動頻繁：特別是活動類數(shù)據(jù)，展示的圖片文案等變動較為頻繁。

　　支持多語言展示：基于愛奇藝海外站面向全球用戶的情況，不同模式下需要展示不同的語言文案。

　　1.2 基礎(chǔ)數(shù)據(jù)配置

　　基礎(chǔ)數(shù)據(jù)配置相對于運營資源來說其變更的頻率相對較低，與時間、版本的關(guān)系也沒那么強。譬如下面愛奇藝海外App-底部導航欄（樣式如上圖所示）。這類配置有如下幾個特征：多維度：需要針對不同的模式、語言做不同的配置。長期有效：這種類型的配置一般長期存在，過期場景較少。

　　2.實踐中的痛點：運營效率低、重復工作多

　　面對接二連三的運營配置需求，我們最初通過實現(xiàn)不同的配置界面來對接各類運營產(chǎn)品需求。但這必然會遇到很大的問題，這主要體現(xiàn)為以下方面：

　　運營效率低

　　對于新的運營配置需求，研發(fā)同學需要開發(fā)對應的配置頁面，然后轉(zhuǎn)給運營同學進行配置的管理，最后運營人員對資源進行配置上線，其流程圖如下：

　　對于每個運營配置需求都要經(jīng)過需求評審、頁面開發(fā)、配置管理、上線的流程。同時，對于配置頁面的開發(fā)，少則需要1到2天的開發(fā)工時，研發(fā)成本高。問題總結(jié)如下：1. 研發(fā)成本高，每個需求要開發(fā)新的配置管理頁面。2. 研發(fā)周期長，運營效率低，從需求的提出到運營上線周期長。3. 靈活性差，對不同的運營維度（模式、版本、時間等）都需要事先確定好，無法動態(tài)調(diào)整。

　　重復開發(fā)工作多對于通用型的運營配置后臺，某些特有的功能特別對于前后端來說重復開發(fā)工作明顯。如操作記錄，審核機制，根據(jù)不同的模式版本語言過濾數(shù)據(jù)等功能，在每次出現(xiàn)的配置需求中都需要重復的開發(fā)。

　　3.實踐中的思考：明確三個原則

　　針對以上問題，我們希望通過設(shè)計一個通用的解決方案，去解決上文闡述的各種運營資源管理的問題。我們把這個項目稱為IQ運營位。通過調(diào)研我們確認項目設(shè)計的原則主要有以下三個：一切數(shù)據(jù)皆可配置運營數(shù)據(jù)高可用接口性能高效通過不斷的實踐和總結(jié)，我們希望能從以下三個方面實現(xiàn)上述原則：

　　3.1 數(shù)據(jù)JSON化

　　隨著業(yè)務(wù)的不斷迭代，無論采用怎樣的數(shù)據(jù)字段組成，都很難滿足業(yè)務(wù)變化的字段（這里是指像標題、副標題、圖片、跳轉(zhuǎn)鏈接等）要求。對底層數(shù)據(jù)進行JSON化，其對應的數(shù)據(jù)字段即可實現(xiàn)可動態(tài)擴展，從而滿足業(yè)務(wù)不斷迭代的需求。JSON化隨之也會帶來運營位字段管理的問題，我們通過在運營后臺提供了相應的字段管理功能來解決這個問題。

　　3.2 運營數(shù)據(jù)多點存儲

　　通過持久化存儲，分布式緩存，以及接入業(yè)務(wù)方的本地緩存，運營數(shù)據(jù)的多方存儲，保證極端情況下都有降級數(shù)據(jù)獲取，降低系統(tǒng)異常的損失。

　　3.3 接口SDK化

　　對于運營數(shù)據(jù)，無論是通過數(shù)據(jù)庫的落地方案、還是通過分布式緩存的方案，都無法徹底解決服務(wù)中心化和服務(wù)抖動的問題。通過接入的SDK化，可以做到數(shù)據(jù)的本地緩存更新機制，解除對中心化服務(wù)的依賴，大大提升服務(wù)的穩(wěn)定性和性能。同時整個IQ運營位服務(wù)變成可水平擴展，在擴展過程中也不會影響中心服務(wù)的穩(wěn)定性。調(diào)用方請求流程圖如下：

　　4.IQ運營位架構(gòu)

　　IQ運營位配置系統(tǒng)整體框架圖。從功能角度，大體上分為四層：數(shù)據(jù)層、服務(wù)層、接入層和監(jiān)控層。IQ運營位架構(gòu)圖如下：

　　4.1 數(shù)據(jù)層

　　數(shù)據(jù)層主要是存儲接入IQ運營位的各類運營數(shù)據(jù)。數(shù)據(jù)層主要面臨以下難點。難點1，數(shù)據(jù)量大；難點2，QPS高?；谝陨蟽纱箅y點，我們通過redis集群做中間緩存，通過SDK使各業(yè)務(wù)方接入本地緩存、通過消息監(jiān)聽異步更新的方式來解決中心服務(wù)的流量壓力。

　　4.2 服務(wù)層

　　服務(wù)層向下對底層數(shù)據(jù)進行操作；向上為接入層獲取數(shù)據(jù)提供接入能力。其提供四個服務(wù)能力：運營后臺、開放平臺、數(shù)據(jù)服務(wù)、IQKIT-SDK。其中運營后臺主要面向運營人員和產(chǎn)品，提供數(shù)據(jù)的配置后臺。開放平臺收歸于開發(fā)技術(shù)人員，提供一個增加運營位配置的后臺。數(shù)據(jù)服務(wù)主要是為調(diào)用數(shù)據(jù)的開發(fā)提供一個統(tǒng)一的、高可用的、高性能的api接口。SDK為數(shù)據(jù)服務(wù)服務(wù)。主要目前是簡化開發(fā)人員的接入成本，提供數(shù)據(jù)服務(wù)性能和可用性。

　　4.3 接入層

　　C端接入如何更方便？為了簡化開發(fā)人員的接入成本，調(diào)用邏輯在SDK內(nèi)實現(xiàn)，用戶只需要引入maven包，注入OppkitClient，封裝OppkitRequest，通過OppkitClient直接調(diào)用即可返回過濾并且翻譯后的數(shù)據(jù)。B端配置如何更便捷？在設(shè)計項目的時候后臺配置秉持的原則有且只有一個：一切皆可配置。通過開放后臺來配置IQ運營位，每個IQ運營位相當于一個業(yè)務(wù)形態(tài)，比如導航欄，而運營位內(nèi)包含多個數(shù)據(jù)，比如title，link等，而title包含多種語言，需要配置多語言key。開放平臺的作用就是創(chuàng)建IQ運營位，為IQ運營位配置字段。運營后臺則用于配置開放平臺創(chuàng)建的IQ運營位數(shù)據(jù)。

　　4.4 監(jiān)控層

　　除了數(shù)據(jù)存儲層的監(jiān)控以及烽火臺對數(shù)據(jù)層與服務(wù)層的監(jiān)控外，我們還對SDK內(nèi)實現(xiàn)的本地緩存進行了監(jiān)控。C端的接入即數(shù)據(jù)的獲取在SDK內(nèi)部實現(xiàn)，SDK內(nèi)部我們做了以下功能：1. 如果請求包含某些特定離散字段如設(shè)備id，因為包含的數(shù)據(jù)量極大，存入本地緩存會給業(yè)務(wù)方的機器內(nèi)存帶來很大壓力，則避開緩存直接請求服務(wù)。2. 為了滿足數(shù)據(jù)實時性要求較高的業(yè)務(wù)方，新增不接入本地緩存的邏輯。3. 如果只包含某些聚合度高的字段如平臺字段，版本，模式，語言等，則把請求的數(shù)據(jù)存入本地緩存。本地緩存通過監(jiān)聽運營平臺的方式進行異步更新，當異步更新獲取數(shù)據(jù)失敗，則保持之前的數(shù)據(jù)返回，避免極端情況運營數(shù)據(jù)全部為空，將業(yè)務(wù)損失降至最低。4. SDK內(nèi)部通過異步線程，將本地緩存的使用情況通過定時線程存入，通過后臺界面展示各緩存使用情況，對各類緩存的使用情況實時監(jiān)控。

　　5.穩(wěn)定性與性能保障

　　如上文所說在運營后臺的設(shè)計考慮中，我們秉持了以下幾個原則：

　　一切數(shù)據(jù)皆可配置運營數(shù)據(jù)高可用接口性能高效下面我們介紹下運營后臺穩(wěn)定性與性能保障所作出的解決方案。

　　整體請求流程圖如下：

　　5.1 穩(wěn)定性保障

　　作為各類運營數(shù)據(jù)配置的運營后臺，穩(wěn)定性尤為重要。除了在操作機制上即運營流程化數(shù)據(jù)配置機制、多級數(shù)據(jù)存儲使用分布式緩存以及分布式數(shù)據(jù)庫以外，我們還提供了一個SDK方案來對服務(wù)的故障進行降級。下面我們將詳細介紹該方案的落地過程。

　　SDK本地緩存方案

　　我們考慮到在實現(xiàn)本地緩存，有這樣幾個好處：

　　1. 緩解中心服務(wù)的流量壓力，更多的流量將會請求到本地服務(wù)的內(nèi)存中。

　　2. 基于愛奇藝海外站業(yè)務(wù)的特點，國外網(wǎng)絡(luò)環(huán)境不可預測，環(huán)境差等情況，盡可能的減少網(wǎng)絡(luò)請求鏈路。

　　3. 一旦中心服務(wù)故障，周知各業(yè)務(wù)方不要重新部署，以本地緩存實現(xiàn)數(shù)據(jù)降級。

　　但是本地緩存的方案缺點也非常明顯，即一旦有運營后臺數(shù)據(jù)更新，各業(yè)務(wù)方無法實時獲取到最新的數(shù)據(jù)?；诖耍覀儗DK進行了以下幾個版本迭代工作。具體見下圖：

　　SDK內(nèi)部技術(shù)的演進過程

　　技術(shù)架構(gòu)演進到第三版，可以較好的解決中心服務(wù)流量問題，使得運營后臺的流量由用戶請求量決定改為后臺的數(shù)據(jù)更新頻率決定，從而解決流量過載問題。但是該版實現(xiàn)也需要解決以下幾個難點：

　　1. 各業(yè)務(wù)方本地緩存的使用情況種類繁多，如何進行提供系統(tǒng)監(jiān)控？

　　2. MQ的方案該如何設(shè)計？

　　針對問題1，我們在SDK內(nèi)部實現(xiàn)一套這樣的機制，通過scheduledexecutorservice定時任務(wù)，周期性的將緩存使用情況拉取到庫內(nèi)，這樣在通過后臺界面就可以根據(jù)時間展示本地緩存的使用情況。這樣，可以系統(tǒng)的掌握各個不同的業(yè)務(wù)方緩存的使用情況，供業(yè)務(wù)方的內(nèi)存申請和分配提供數(shù)據(jù)支撐。

　　針對問題2，涉及到的難點主要有兩個：(1)業(yè)務(wù)服務(wù)機器一般都是一個服務(wù)有多臺機器，所以一個消息的更新需要被多臺部署相同代碼的服務(wù)器同時消費，這樣確保每臺機器都獲取到最新的數(shù)據(jù)。(2)運營位有多個，但對于業(yè)務(wù)方來說沒有必要在沒有接入的運營位更新數(shù)據(jù)時去異步地請求運營后臺中心服務(wù)更新數(shù)據(jù)（因為這些數(shù)據(jù)這個業(yè)務(wù)方壓根沒接入）。針對(1)，明確的是消息的生產(chǎn)者是運營后臺服務(wù)，而一個消息需要被所有業(yè)務(wù)方監(jiān)聽，具體的說是所有業(yè)務(wù)方的每臺機器。所以，每臺機器應該屬于不同的消費組。所以我們需要找到一個每臺機器都不一樣的標識節(jié)點，以這個節(jié)點做為消費組。顯然，這個節(jié)點最好的就是機器地址，可以保證每臺機器所在分組都不一樣。針對(2)，我們提供一個配置文件，各業(yè)務(wù)方需要在配置文件內(nèi)寫入各自業(yè)務(wù)方使用的IQ運營位名稱，當一個消息來臨時，首先需要判斷這個消息中的運營位名稱是否包含在配置文件內(nèi)，如果不在，則這條消息被忽略（空消費），如果在，則請求響應的運營位更新本地數(shù)據(jù)。

　　5.2 性能保障

　　以上的SDK提供的本地緩存可以提高后端服務(wù)的性能，除此以外，我們還做了其他一些工作。

　　在運營位的實踐配置中我們發(fā)現(xiàn)，運營數(shù)據(jù)的變化或者說運營人員更改運營數(shù)據(jù)的情形相比網(wǎng)絡(luò)請求來說是非常低頻的，比如之前分析的基礎(chǔ)運營數(shù)據(jù)。因此，數(shù)據(jù)緩存在客戶端可以避免客戶端與后端服務(wù)的網(wǎng)絡(luò)消耗，極大的提高性能。

　　我們的方案是為每個運營位數(shù)據(jù)提供一個版本的概念。通過保存各運營位的操作最新時間，在客戶端開屏時發(fā)起一次請求，將所有的運營位最近的數(shù)據(jù)更新時間返回給客戶端，客戶端將該時間戳緩存在本地，當下次開屏請求時，同樣會獲取到服務(wù)端返回的運營位最近更新時間戳，將本地的與服務(wù)的進行匹配，來確認是否去更新各個運營位的數(shù)據(jù)，如果客戶端緩存的運營數(shù)據(jù)時間與運營后臺返回一致，則直接展示緩存在客戶端的數(shù)據(jù)。

　　這種方案的另一個好處是可以在極端的情況下，如對外暴露的api出現(xiàn)故障，通過禁止運營后臺的數(shù)據(jù)更新，可以使業(yè)務(wù)數(shù)據(jù)正常展示，避免出現(xiàn)運營數(shù)據(jù)消失的嚴重故障。

　　具體的請求流程圖如下：

　　6.總結(jié)與展望

　　本文主要介紹了IQ運營位的設(shè)計與開發(fā)的相關(guān)內(nèi)容，首先根據(jù)遇到的痛點提出了運營后臺的設(shè)計原則:一切數(shù)據(jù)皆可配置，運營數(shù)據(jù)高可用，接口性能高效。針對提出的原則去思考與實現(xiàn)具體的技術(shù)方案。

　　通過配置數(shù)據(jù)的Json化實現(xiàn)業(yè)務(wù)字段的可擴展性。通過設(shè)計的數(shù)據(jù)模型來介紹滿足多語言情況下的各類運營配置數(shù)據(jù)方法。通過提供SDK內(nèi)部實現(xiàn)本地緩存，MQ監(jiān)聽，異步更新的機制解決了服務(wù)中心化的大流量問題和緩存導致的數(shù)據(jù)不一致問題。針對海外的具體情況，提出了客戶端緩存的相關(guān)方案。

　　IQ運營位從今年5月開始規(guī)劃，歷時近半年時間，由于中途穿插了很多的產(chǎn)品需求，所以在自身使用與用戶反饋兩個渠道進行問題收集，前后共經(jīng)過了兩個版本的迭代。目前在運營后臺的界面與使用便利度上在持續(xù)優(yōu)化。

　　IQ運營位上線2個多月以來在愛奇藝海外站得到廣泛使用，在工程效率上更是有質(zhì)的提高，拿最近的錯誤碼配置來舉例，錯誤碼需要給客戶端返回各類錯誤碼以及對應的相關(guān)文案，文案是多語言場景的，通過IQ運營位配置化實現(xiàn)，只需要在分析需求，拆分業(yè)務(wù)字段和數(shù)據(jù)露出的條件后，5min以內(nèi)就可以給出相應的運營后臺。

　　當然，隨著業(yè)務(wù)的迭代與場景更新，IQ運營位仍存在一些不完善的地方，在未來我們將會在工程實踐中的持續(xù)迭代過程中做更進一步的工作，解決各類問題，更好的服務(wù)好IQ運營位的客戶與廣大愛奇藝海外用戶。

　　團隊介紹：

　　愛奇藝海外phone后端團隊：愛奇藝海外事業(yè)部下，負責愛奇藝海外phone后端服務(wù)的開發(fā)和維護，為廣大用戶提供穩(wěn)定、高效、流暢的視頻內(nèi)容服務(wù)。

　　正飛：IQ運營位項目負責人，IQ運營位的設(shè)計與開發(fā)者。