王海霞+朱海云
【摘 要】為了解決目前存在的公眾賬號功能單一,無法通過公眾賬號完成在線業(yè)務(wù)辦理等功能,沒有實質(zhì)性的服務(wù)內(nèi)容等問題,首先從統(tǒng)一公眾號管理平臺的現(xiàn)狀和業(yè)務(wù)目標(biāo)著手,分析了統(tǒng)一公眾號管理平臺的功能架構(gòu),研究了系統(tǒng)的關(guān)鍵技術(shù),提出了為各類公眾賬號提供統(tǒng)一管控平臺的思路,旨在能為用戶提供一站式電信服務(wù)方案。
【關(guān)鍵詞】統(tǒng)一公眾號管理平臺 J2EE SOA 去IOE技術(shù)
Research on Key Techniques of the United Official Account
Management Platform
[Abstract]At present, current official accounts suffer from single functions and unsubstantial contents, and some online services cannot be handled by official accounts. In order to deal with these problems, the functional architecture of the united official account management platform was analyzed according to the status and the service objective of the united official account management platform. Then, key techniques of the system were investigated. Finally, the idea of presented the united management platform to official accounts was put forward to provide the solution to the one-stop telecommunication service to users.
[Key words]united official account management platform J2EE SOA take off IOE
1 引言
中國電信與網(wǎng)易于2013年8月19日發(fā)布一款新一代移動即時通訊社交產(chǎn)品“易信”。這是全球電信運營商與互聯(lián)網(wǎng)公司首次成立合資公司并合作打造移動即時通訊社交產(chǎn)品。2015年易信用戶發(fā)展目標(biāo)是4個億,其中電信新增用戶1個億,中國電信各省公司通過直銷、實體、電子等三大渠道及所有可能的用戶觸點來加大易信用戶客戶端、易信公眾賬號和易信群的營銷和推廣。中國電信廣東公司和各市分公司已經(jīng)為營業(yè)廳開通微信/易信公眾賬號近2000個,經(jīng)過近兩年的運營,發(fā)展粉絲10多萬,有了一定的用戶基礎(chǔ),培養(yǎng)了用戶的使用習(xí)慣,各公眾賬號運營者已經(jīng)積累了基礎(chǔ)運營經(jīng)驗,此時迫切需要建設(shè)一個統(tǒng)一的支撐和運營平臺,利用更多的創(chuàng)新移動互聯(lián)網(wǎng)營銷手段,努力加大粉絲拉升和業(yè)務(wù)轉(zhuǎn)化的力度,帶動業(yè)務(wù)收入的增長。中國電信廣東公司為了實現(xiàn)對微信/易信公眾賬號的統(tǒng)一管理,建設(shè)了一套省集中的統(tǒng)一公眾號管理平臺。
2 統(tǒng)一公眾號管理平臺系統(tǒng)總體設(shè)計
2.1 現(xiàn)狀分析
中國電信廣東公司是擴大易信市場的一線陣地,已經(jīng)在陸續(xù)推進易信客戶端尤其是公眾賬號建設(shè)和營銷推廣的工作,目前來看仍存在以下問題:
用戶角度
推薦給用戶的公眾賬號普遍存在功能比較單一,甚至無人打理和維護的問題,推薦用戶關(guān)注公眾賬號后,由于沒有實質(zhì)性的服務(wù)內(nèi)容,用戶很容易取消關(guān)注。客戶希望能夠通過營業(yè)廳的公眾賬號辦理電信業(yè)務(wù)和參加電信營銷活動,享受到中國電信一致的服務(wù)。
公眾賬號的運營者角度
公眾賬號目前主要通過微信/易信公眾號支撐,但微信/易信公眾號提供的功能相對比較單一,只有一些簡單的靜態(tài)圖文消息配置和消息群發(fā)功能,用戶無法通過公眾號完成類似在線業(yè)務(wù)辦理、促銷抽獎等業(yè)務(wù),也沒有實現(xiàn)智能客服以及與O2O結(jié)合的營銷工作。公眾賬號運營負(fù)責(zé)人的工作重心在市場和營銷,IT的支撐能力參差不齊,故希望有一個平臺能提供更多可配置的工具模板,支持用極簡的方式進行操作,在最短的時間內(nèi)上線發(fā)布,適應(yīng)瞬息萬變的市場變化。
省公司角度
希望各類公眾賬號既能發(fā)揮其主動性和靈活性,又能實現(xiàn)渠道引流、資源共享。目前全省部署的活動只能由省公司提供基礎(chǔ)的文字圖片材料,由公眾賬號負(fù)責(zé)人自己配置維護,風(fēng)格、關(guān)鍵字和界面布局不統(tǒng)一,嚴(yán)重影響用戶感知。同時缺乏對全省各類公眾賬號的有效管控,無法及時匯總各公眾賬號的運營數(shù)據(jù),包括每天新增的用戶數(shù)、用戶參與活動的情況,群發(fā)消息的點擊率和轉(zhuǎn)發(fā)次數(shù)等,故而無法給予及時有效的指導(dǎo)。
2.2 業(yè)務(wù)目標(biāo)
建立中國電信廣東公司統(tǒng)一公眾號管理平臺旨在為各類公眾賬號提供統(tǒng)一的管控平臺,通過公眾賬號多級管理、一對一客服以及O2O等手段實現(xiàn)全省公眾賬號協(xié)同工作,為用戶提供一站式電信服務(wù)。
(1)建設(shè)面向營業(yè)廳公眾賬號的營銷管控平臺,為運營人員提供方便快捷的標(biāo)準(zhǔn)活動模版,滿足各渠道營銷、服務(wù)、用戶維系等能力提升的迫切需求,促進業(yè)務(wù)量的增長。
(2)在各類公眾賬號下加載積分兌換、套餐查詢、自助話費查詢、充值繳費等線上功能,為用戶提供一站式延伸服務(wù)。
(3)在各類公眾賬號下加載與線下活動相結(jié)合的營銷活動的線上提前預(yù)約、線下優(yōu)先辦理等功能,創(chuàng)新公眾賬號服務(wù)新模式。
(4)建設(shè)“省公司→市分公司→區(qū)縣分公司→具體營業(yè)廳”的四級統(tǒng)一管理、內(nèi)容發(fā)布和協(xié)同運營支撐的公眾號體系平臺,支持由省公司、市分公司、區(qū)縣分公司、營銷中心、營業(yè)廳等角色共同參與的協(xié)同支撐體系,這既能實現(xiàn)省公司對各級各公眾賬號的統(tǒng)一管理,還能充分發(fā)揮各級各公眾賬號的自主性。
(5)實現(xiàn)與中國電信廣東公司營業(yè)廳管理門戶系統(tǒng)的對接。
2.3 系統(tǒng)功能架構(gòu)
中國電信廣東公司統(tǒng)一公眾號管理平臺核心功能包括公眾號基礎(chǔ)管理、公眾號運營管理、應(yīng)用組件管理和接口管理等關(guān)鍵功能,平臺功能架構(gòu)如圖1所示。
(1)公眾號基礎(chǔ)管理:主要功能包括粉絲管理、內(nèi)容管理、消息管理和菜單管理。
粉絲管理:自動從微信/易信公眾號同步關(guān)注其粉絲列表,包括粉絲的昵稱、頭像等。支持粉絲擴展屬性:姓名、性別、所屬組織、職務(wù)、工號、手機號碼、郵箱、用戶類型等;支持粉絲擴展屬性的自定義,不同的公眾賬號屬性模板可不同。支持按照粉絲的昵稱、手機號碼、用戶類型等屬性進行快速的檢索。支持粉絲列表以Excel格式導(dǎo)出和備份。
內(nèi)容管理:實現(xiàn)多級內(nèi)容管理,能從上級向下級發(fā)布內(nèi)容。支持單圖文、多圖文、圖片、語音、視頻、文字、公眾賬號卡片等素材的制作和發(fā)布;支持根據(jù)素材主題、素材類型、素材作者進行檢索的功能。
消息管理:包括對用戶上傳的各種數(shù)據(jù)進行采集和集中管理,對用戶消息進行即時回復(fù),給用戶推送/群發(fā)各種消息等。支持獲取用戶在易信/微信用戶端上行的各種問題咨詢、關(guān)鍵字、語音留言、圖片、視頻、位置消息等進行集中管理。消息至少保留6個月。支持對用戶上行消息的即時回復(fù)。支持根據(jù)粉絲昵稱或注冊的手機號碼、名稱等信息進行快速消息檢索的功能。支持按照消息類型、關(guān)鍵字、時間等維度進行消息檢索。支持消息的導(dǎo)出和備份。
菜單管理:維護微營銷服務(wù)平臺所有的菜單。
(2)公眾號運營管理:微營銷服務(wù)平臺用戶可以進行創(chuàng)建易信/微信公眾號并綁定的操作,創(chuàng)建的公眾號與組織機構(gòu)進行關(guān)聯(lián),一個賬戶至少支持綁定一個微信公眾賬號和一個易信公眾賬號。支持通過公眾賬號的名稱、賬號、開通時間、服務(wù)組織等信息進行快速檢索。用戶綁定后可對綁定的公眾號進行管理,主要包括用戶管理、權(quán)限管理、積分管理和日志管理等功能。
用戶管理:用戶管理的對象是建立在組織機構(gòu)下的微營銷服務(wù)平臺用戶,用戶根據(jù)組織機構(gòu)的關(guān)系也具有層級關(guān)系,可以與公眾號進行綁定,實現(xiàn)對公眾號的管理,可根據(jù)工號分配崗位,獲得崗位的權(quán)限。平臺用戶需要區(qū)分系統(tǒng)超級管理員、公眾賬號管理員、運營人員(可區(qū)分為營銷活動專崗、素材編輯專崗、客服專崗和數(shù)據(jù)統(tǒng)計專崗),不同賬戶類型按照角色進行區(qū)分,設(shè)置不同的權(quán)限。
權(quán)限管理:通過角色管理分配和控制系統(tǒng)的權(quán)限,需要給后臺的功能菜單的操作權(quán)限、關(guān)鍵字的發(fā)布范圍、能夠統(tǒng)計和查詢的公眾賬號的范圍等權(quán)限分配不同的角色進行控制。分級授權(quán)是指按照四級管理架構(gòu)自上而下進行分級授權(quán)管理,即上一級機構(gòu)的管理員創(chuàng)建下一級機構(gòu)的管理員賬號,并通過角色給他們設(shè)定范圍權(quán)限。
數(shù)據(jù)統(tǒng)計:支持一次統(tǒng)計全省、部分地市、部分區(qū)縣、部分營業(yè)廳的公眾賬號的運營數(shù)據(jù)。可對各指標(biāo)做橫向、縱向之間的同比或環(huán)比,包括粉絲統(tǒng)計分析、消息統(tǒng)計分析,統(tǒng)計結(jié)果支持以Excel報表形式導(dǎo)出。
積分管理:每個營業(yè)廳都可以建立自己獨立的積分體系。至少支持用戶閱讀消息、轉(zhuǎn)發(fā)消息,推薦好友關(guān)注公眾賬號、參與各種營銷活動給予積分獎勵等。各種動作產(chǎn)生的積分分值可由運營人員自定義,支持用戶在線查詢積分的總分和詳情。支持通過實物獎勵、參加地面活動、提供特色服務(wù)等方式消費積分。支持積分兌代金券、兌換流量、享受優(yōu)惠購機等。
分級發(fā)布:內(nèi)容及統(tǒng)計結(jié)果按照四級管理架構(gòu)自上而下進行分級發(fā)布。
日志管理:記錄及保存系統(tǒng)的操作日志。
(3)應(yīng)用組件管理:分別對活動類、功能類和業(yè)務(wù)辦理類的組件進行管理。
活動類管理:針對各公眾賬號開展的營銷活動(砸蛋、刮刮卡、抽獎等),為運營人員提供各種簡單易用、可快速配置的模板化活動組件,支持營銷活動統(tǒng)一發(fā)布,支持運營數(shù)據(jù)的自動匯總統(tǒng)計。
功能類管理:支持微信調(diào)查、留言、投票、定位、論壇、答題、報名、簽到、社區(qū)等常用功能。
業(yè)務(wù)辦理類管理:通過與CRM、BOSS、翼支付系統(tǒng)對接,實現(xiàn)用戶認(rèn)證、業(yè)務(wù)訂購、自助服務(wù)、訂單支付等電信業(yè)務(wù)辦理功能組件。支持用戶通過公眾賬號預(yù)約辦理各種電信業(yè)務(wù),主要圍繞用戶話費、流量、套餐、賬單、積分的查詢。支持通過充值卡購買流量包、短信包,具體流量包和短信包的規(guī)格以網(wǎng)廳發(fā)布的為準(zhǔn)。提供充值卡向用戶賬號充值的功能,用戶需要先進行天翼賬號和手機號碼的綁定,然后選擇需要充值的金額,進入充值界面進行充值。支持寬帶續(xù)約。
3 系統(tǒng)的關(guān)鍵技術(shù)
3.1 J2EE的B/S三層架構(gòu)
整體架構(gòu)采用了J2EE的B/S三層架構(gòu)模式,將表現(xiàn)層、業(yè)務(wù)應(yīng)用層、數(shù)據(jù)層分開。
J2EE是一個方便于服務(wù)器方應(yīng)用程序開發(fā)的中間件服務(wù)集,它利用Java2技術(shù)的平臺無關(guān)性、安全性等特點,適度解決了企業(yè)解決方案的一些復(fù)雜問題。此外,J2EE還提供了一整套核心企業(yè)應(yīng)用程序編程界面,其中包括Servlets、JSP、JDBC等。
表現(xiàn)層用于向用戶以Web網(wǎng)頁或者APP應(yīng)用界面的方式展示信息。一般可采用jsp/php/asp/js等前端技術(shù)實現(xiàn),需要考慮數(shù)據(jù)與前端UI布局分離,主要包括頁面提交的數(shù)據(jù)有效性驗證、數(shù)據(jù)格式轉(zhuǎn)換等。邏輯控制,同時控制Web或者APP頁面邏輯跳轉(zhuǎn),根據(jù)不同的業(yè)務(wù)場景需要進行相關(guān)的頁面控制權(quán)限控制,當(dāng)出現(xiàn)錯誤時,提示錯誤信息,當(dāng)沒有足夠權(quán)限時,禁止訪問等。
業(yè)務(wù)應(yīng)用層基于下層進行服務(wù)封裝,實現(xiàn)相關(guān)的業(yè)務(wù)層邏輯代碼功能。服務(wù)層能夠?qū)?shù)據(jù)庫表級業(yè)務(wù)重用到服務(wù)級別。面向業(yè)務(wù)的開發(fā)得以服務(wù)為開發(fā)基礎(chǔ),而不用關(guān)心底層數(shù)據(jù)庫表如何實現(xiàn),更不用關(guān)心數(shù)據(jù)庫是MySQL還是Oracel等。服務(wù)層將數(shù)據(jù)隔離,也增加了對數(shù)據(jù)層安全性的要求。業(yè)務(wù)應(yīng)用層的服務(wù)調(diào)用引擎內(nèi)部需經(jīng)過三環(huán)節(jié)處理,如下:
(1)服務(wù)接入
分布式高并發(fā)接入使用者消費平臺服務(wù)的場景需采用非阻塞方式實現(xiàn)服務(wù)請求的接入與轉(zhuǎn)發(fā),此層關(guān)注服務(wù)安全控制、業(yè)務(wù)驗證等入口控制。
(2)服務(wù)交換
分布式高并發(fā)處理經(jīng)過服務(wù)接入層轉(zhuǎn)發(fā)的消息服務(wù)請求,由于服務(wù)請求傳輸?shù)南笪幕蛘邊f(xié)議與目標(biāo)服務(wù)不同,交換層在此層處理業(yè)務(wù)邏輯,并向下層轉(zhuǎn)發(fā)。
(3)服務(wù)訪問
分布式高并發(fā)服務(wù)訪問,接收服務(wù)交換層處理的業(yè)務(wù)請求,并向目標(biāo)服務(wù)發(fā)送請求,繼而返回結(jié)果。
數(shù)據(jù)層用于直接從數(shù)據(jù)庫中取得業(yè)務(wù)相關(guān)信息。數(shù)據(jù)層將用戶與數(shù)據(jù)庫分離,實現(xiàn)數(shù)據(jù)與展示層隔離的目的,同時也提高了系統(tǒng)的松耦合性。數(shù)據(jù)層實現(xiàn)主要資源的有效管理與釋放,包括數(shù)據(jù)庫資源、文件IO資源等。
這種結(jié)構(gòu)使整個系統(tǒng)的每套業(yè)務(wù)組件之間相對獨立、組件相互間調(diào)用流程清晰、業(yè)務(wù)功能明確,并且具有較強的穩(wěn)定性、安全性和可維護性。采用組件化設(shè)計便于滿足不斷擴展的業(yè)務(wù)需求,而且各子業(yè)務(wù)系統(tǒng)通過統(tǒng)一接口來獲取數(shù)據(jù),統(tǒng)一接口可以通過多種方式實現(xiàn)與外部系統(tǒng)互聯(lián),并向各業(yè)務(wù)子系統(tǒng)提供xml格式的數(shù)據(jù)包,不直接與外部系統(tǒng)接口打交道,可有效地將外部系統(tǒng)隔離在業(yè)務(wù)系統(tǒng)之外。
3.2 去IOE技術(shù)
隨著業(yè)務(wù)的不斷發(fā)展,數(shù)據(jù)量和業(yè)務(wù)量呈爆發(fā)性增長,傳統(tǒng)的集中式Oracle數(shù)據(jù)庫架構(gòu)在擴展性方面遭遇瓶頸。傳統(tǒng)的商業(yè)數(shù)據(jù)庫軟件多以集中式架構(gòu)為主,主要特點是將所有的數(shù)據(jù)都集中在一個數(shù)據(jù)庫中,依靠大型高端設(shè)備來提高業(yè)務(wù)處理能力。集中式數(shù)據(jù)庫通過增加CPU、內(nèi)存、磁盤等方式提高處理能力,從而實現(xiàn)向上擴展(Scale Up)。采用這種集中式數(shù)據(jù)庫的架構(gòu),數(shù)據(jù)庫必然成為了整個系統(tǒng)的瓶頸,將越來越難以滿足海量數(shù)據(jù)對計算能力的巨大需求。
去IOE技術(shù)已經(jīng)在互聯(lián)網(wǎng)中得到了很好的實踐落地,它大大降低了企業(yè)的軟/硬件成本。統(tǒng)一公眾號管理平臺實現(xiàn)了用開源的MySQL數(shù)據(jù)庫替換Oracle數(shù)據(jù)庫,并且MySQL數(shù)據(jù)庫均采用PC-Server承載,支撐高并發(fā)大數(shù)據(jù)量的核心業(yè)務(wù)系統(tǒng)。去IOE技術(shù)在統(tǒng)一公眾號管理平臺的運用主要體現(xiàn)在以下方面:
舍棄IBM、Oracle等中間件,采用高性能中間件開源產(chǎn)品,例如采用開源ESB、開源Web容器,來替換IBM服務(wù)總線產(chǎn)品和Oracle weblogic產(chǎn)品;數(shù)據(jù)庫存儲引入NoSQL技術(shù),進行類似平臺服務(wù)調(diào)用日志等非核心數(shù)據(jù)存儲與分析;存儲方面,采用廉價的存儲設(shè)備。
3.3 緩存技術(shù)
采用緩存技術(shù)能夠有效解決業(yè)務(wù)系統(tǒng)對數(shù)據(jù)庫的壓力。統(tǒng)一公眾號管理平臺具體采用了OSCache的緩存框架,設(shè)計特點主要體現(xiàn)在:
(1)通過采用一致性Hash,避免了動態(tài)增減結(jié)點帶來的緩存結(jié)點失效問題。
(2)緩存同步策略,參照場景設(shè)置主動與被動緩存失效。
(3)采用epoll網(wǎng)絡(luò)事件模型,主要優(yōu)勢是在相同的硬件環(huán)境下較其它網(wǎng)絡(luò)模型可支持更多的并發(fā)連接。
(4)通過緩存加載實現(xiàn)緩存數(shù)據(jù)初始加載與增量插入。
(5)接口服務(wù)可緩存、服務(wù)配置數(shù)據(jù)可緩存等。
(6)當(dāng)結(jié)點失效后,會出現(xiàn)緩存空窗現(xiàn)象,如果有大量數(shù)據(jù)庫操作則將出現(xiàn)雪崩效應(yīng),采用緩存HA集群可實現(xiàn)失效傳移。
(7)采用分布式技術(shù),實現(xiàn)數(shù)據(jù)緩存的同步刷新。
(8)分布式緩存與本地緩存結(jié)合。
(9)采用個性化緩存刷新策略。
緩存技術(shù)用于減輕由于數(shù)據(jù)模型層過多的訪問對數(shù)據(jù)庫造成的壓力,數(shù)據(jù)庫連接池資源畢竟是有限的,在高并發(fā)場景中,連接池資源緊張甚至?xí)?dǎo)致拒絕數(shù)據(jù)庫服務(wù)。緩存能夠有效解決以上問題,通過將已經(jīng)訪問過的數(shù)據(jù)庫數(shù)據(jù)存儲到內(nèi)存中,下次訪問可以直接從緩存中提取。緩存層提供了更多的技術(shù)策略,例如通過緩存刷新可有效解決數(shù)據(jù)不一致的問題。
4 結(jié)束語
為了應(yīng)對公眾號的發(fā)展趨勢,分析了統(tǒng)一公眾號管理平臺的現(xiàn)狀及存在的主要問題,結(jié)合管理平臺的業(yè)務(wù)目標(biāo),提出了統(tǒng)一公眾號管理平臺的功能框架,闡述了管理平臺的公眾號基礎(chǔ)管理、公眾號運營管理、應(yīng)用組件管理和接口管理等核心功能,重點研究了平臺的三層架構(gòu)模式、去IOE技術(shù)和緩存技術(shù)及具體應(yīng)用,旨在為中國電信廣東公司統(tǒng)一公眾號管理平臺后續(xù)的發(fā)展建設(shè)提供一些指導(dǎo)建議。
參考文獻:
[1] 中國電信股份有限公司. 中國電信CTG-MBOSS系列規(guī)范集[Z]. 2011.
[2] 陸衛(wèi)忠,趙玉雪,朱云祥,等. 基于微信公眾平臺架構(gòu)的應(yīng)用系統(tǒng)開發(fā)[J]. 蘇州科技學(xué)院學(xué)報: 自然科學(xué)版, 2015(3): 47-51.
[3] 楊毅宇. 基于微信公眾平臺開發(fā)模式的高校教學(xué)管
理服務(wù)系統(tǒng)的設(shè)計與實現(xiàn)[J]. 信息與電腦: 理論版, 2016(7): 85-86.
[4] 朱智星,白鵬飛,羅智杰,等. 基于微信公眾平臺的云智能采集系統(tǒng)的設(shè)計[J]. 電子技術(shù)應(yīng)用, 2015,41(8): 17-19.
[5] 李松輝,侯志江. 圖書館微信公眾號服務(wù)平臺的設(shè)計與開發(fā)[J]. 信息系統(tǒng)工程, 2015(2): 32-33.
[6] 夏雨,孫炯寧,鮑建成. 基于微信公眾平臺開發(fā)的高校學(xué)生助手系統(tǒng)[J]. 電腦與電信, 2013(11): 30-32.
[7] 黃海彬. 微信公眾平臺運營的實踐與思考——以溫州市圖書館為例[J]. 圖書館研究與工作, 2015(1): 42-45.
[8] 蔣紅軍. 基于服務(wù)調(diào)度的微信公眾平臺開發(fā)架構(gòu)設(shè)計與實現(xiàn)[J]. 電腦知識與技術(shù): 學(xué)術(shù)交流, 2014,31(11): 7543-7546.
[9] 謝寶良,習(xí)聰玲. 微信公眾號開發(fā)與使用技術(shù)研究[J]. 電腦編程技巧與維護, 2015(9): 53.
[10] 帥忻征. 微信公眾平臺與接口開發(fā)[J]. 計算機與網(wǎng)絡(luò), 2015,41(24): 46-47.
[11] 李家健,王海霞. 電子渠道標(biāo)準(zhǔn)服務(wù)提供平臺的設(shè)計與實現(xiàn)[J]. 移動通信, 2015,39(20): 81-82.