基于PaaS平臺的電信CRM系統開發運營方案研究與實踐

王倩， 施志銘， 陳泳， 劉曉蓬, 代武成

(中國電信股份有限公司 上海分公司, 上海 200122)

0 引言

隨著云平臺的發展和PaaS平臺組件技術的逐漸成熟， PaaS平臺自身性能日益健壯、運維體系比較合理，且有良好的彈性縮擴容的工作機制。因此，越來越多的企業級互聯網應用直接構建在了PaaS平臺上。

這樣做的好處是各應用系統不再需要過多關注分布式組件本身的工作原理和機制，包括分布式數據、分布式緩存、分布式消息中間件等，而是可以把更多精力投入到業務應用本身的業務研發和運營推廣之上。

但有利也有弊，同時會使用應用運營人員對分布式組件和平臺本身缺乏了解，導致過分相信平臺提供的性能保障而減少應用本身的性能考慮和性能優化的動力，也會導致在出現故障時應用側過多依賴平臺解決問題或應用與平臺之間出現維護職責的相互推諉。

如何充分利用平臺優勢抓住機遇發展業務？又如何解決新型平臺架構之下帶來的新問題？

1 PaaS平臺對傳統應用開發及運營帶給的變化分析

1.1 舉一個可能的傳統的IT系統應用開發及運營的場景：

當完成各種前置工作(如商務、技術招投標、預算申請下達等)，進行一個企業內IT系統的實際開發階段，大致需要以下步驟：

① 了解業務需求(盡量細致而明確);

② 根據需求確定應用技術架構和具體技術選型;

③ 申請開發、測試及生產硬件環境資源;

④ 確立開發團隊和開發流程;

⑤ 完成開發并在測試環境中部署;

⑥ 內部測試和業務測試;

⑦ 完成生產環境部署;

⑧ 業務正式上線運營;

⑨ 發現問題或產生新的需求;

⑩ 重復1、3、5、6、7、8、9的動作(可能需求的變化導致技術選型需要進行，或開發團隊結構調整，則2、4的動作也需要重復)。

1.2 在PaaS平臺和新型開發理念下應用開發及運營的場景

如圖1所示。

圖1 PaaS平臺與應用、基礎設施的關系

前置工作完成后，在實際開發階段步驟將有很大不同：

① 了解整體需求后直接進行需求分解和開發；

② 開發測試和業務測試完成后上線部署

③ 業務正式運營；

④ 產品問題或新需求后直接在分解后的任務項上改動或快速迭代產生新的任務項后快速開發部署(受技術選型和開發團隊結構影響很小)。

1.3 傳統與新型IT開發的變化分析

根據上述兩類開發模式的步驟列舉，不難看出差別。基于PaaS的新型開發理念下，開發步驟變得不再像傳統意義上的開發步驟那么冗長、那么中規中矩。原因何在？

首先， PaaS平臺身處應用層(SaaS)和基礎設施(IaaS)層之間，起到了緩沖、橋梁的作用(見圖1)時，由于PaaS可以事先根據應用的近期、中期、遠期規劃提前向基礎設施申請資源，保證提前量，再向應用層提供封裝后的資源服務，使得原本應用構建的一個基礎步驟——硬件資源申請的過程變得不再繁瑣而苛刻。

第二，PaaS上提供的公共組件如分布式數據、緩存、消息中間件、應用服務框架[1]都有一定之規，從根本上約束了應用側的技術架構和技術工具選型都在一個可控范圍內，不允許應用側天馬行空。這在一定意義上當然也可以說是限制了應用的發揮，但在更多場景下，是提高了工作效率、減少了多應用之間的技術壁壘。

第三、多數PaaS平臺還會對應用部署有規范要求，例如采用容器技術，要求開發的服務有一定限量，如，要求一個容器鏡像上部署不超過20個服務、對服務報文處理時延最大要求等，每一個容器鏡像所占用cpu、內存都可以大致量化，這一舉措從根本上保障了資源使用可以真正切片，這一點與第一點基礎設施的申請息息相關。同時，也使得需求變化導致的服務增加、服務增加導致容器鏡像增加、容器鏡像增加導致資源動態擴容[2]，這一條連鎖反應鏈變成順理成章。

第四、從軟的能力上看，畢竟PaaS所限定的主流應用技術是大多數開發人員的首選，因此當需求的異常變化也好、運營正常迭代的需求變化也好，對開發團隊的技術要求是一致的，那么由于需求變化即使開發團隊人數不足或團隊人員流失，也能較快的擴充或重組團隊，并很快地響應需求。同時，并非必須但常常與PaaS同時出現的微服務開發思路，也使得開發人員可以通過數據和微服務拆分、容器化的部署，對已有應用的數據結構、程序代碼可以最大限度地保護。當需求變更時，開發人員需要做的經常是加、減法，而不是數據結構和代碼的重構，這一點可以從根本上把開發團隊內的溝通和知識經驗的傳遞的成本降低。當然這里并不是說溝通和知識傳遞不重要，而是從快速響應需求、快速迭代的角度，可以最大限度地先快速開發上線。

綜上，PaaS平臺和微服務技術已經為開發運營一體化提供了良好的土壤，如何實施？筆者認為需要分兩部分。第一，是業務運營與開發的一體化，這需要通過面向對象的思想和方案與解決。第二，是開發與系統運營的一體化，需要通過分層的思想去解決。接下來將重點闡述在上海電信CRM系統重構過程中的這一解決方案。

2 PaaS平臺及微服務場景下通過面向對象的思想實現業務運營與開發一體化

根據上一節對傳統應用和新型應用的開發運營的比較分析，我們可以看出，基于PaaS平臺及其延伸開發理念的支撐下，對應用側的業務研發、快速運營迭代而言，可以說是一個前所未有的機遇。如何抓住機遇大力發展業務，如何把平臺帶來的優勢發揮出來并揚長避短？這是目前面臨的一個課題。筆者認為，需要分為兩個方面進行破題：可持續的一體化的業務運營和分層級的系統運營，本節將重點闡述業務運營部分。系統運營部分將在下一節闡述。

2.1 何為可持續的業務運營？

有必要解釋一下本文對業務運營的定義：應用系統上線后的一切由業務發起的變更和實施的全過程，稱之為業務運營。即，業務運營的出發點是為了將應用系統發揚光大、不斷地對內擴展功能、對外擴大使用，不斷地制造需求、實現需求、吸引更多的用戶、提升用戶的體驗。業務運營不僅僅強調業務發展本身，還強調可持續運營的理念。也就是說業務方與開發實現方本為一體，需求提出者就是需求實現者，是真正的DevOps的工作方法。

2.2 如何讓需求提出者去實現需求？

面向對象的核心理念是對事物從具體中進行抽象，抽象的過程中要分析事物有哪些對象，對象有哪些特征(即屬性)，對象間、屬性間有那些關系，針對這些對象、屬性、關系可以有哪些操作，抽象結束后，一個事物的本質就呈現出來了。再進而分析這些對象的共同點，即，從對象引出類的概念，同類對象有相同的屬性、關系、操作。再進而分析這些同類對象在相同部分中的些微不同點，即有了繼承和多態的概念，等等。如見圖2所示。

圖2 面向對象的事物抽象方法

由此而構建了面向對象的完整理論體系。不論是面向對象的各類編程語言還是各類建模分析方法，都在這個理論體系之下。

對于需求提出者而言，往往苦于只會表達具體業務場景，不會抽象為事物本質，使用面向對象的抽象方法可以有效的解決這一問題。以電信行業傳統的產品的CRM需求舉例，每一個產品可以理解為一個對象，例如傳統的直線電話、centrex、pbx、DID、公用電話都可以抽象為固定電話這個產品類，移動電話也是一個類,寬帶也可以視作一個類。產品對象本身可以分層級，即子對象。例如，來電顯示，可以是固定電話的子對象，也可以是移動電話的子對象。同一個子對象在不同的父對象下，操作可以不同。

例如，還是來電顯示這個產品，在固定電話這個父對象下，收費操作可以是6元，而在移動電話這個父對象下，收費操作可以是10元。同理[3]，屬性也可以進行抽象，例如，接入方式可以視作固定電話這個類的屬性，同時也可以作為寬帶這個類的屬性，而光纖接入、銅纜接入都可視作是屬性的具體取值。對于對象、屬性都可以定義相關的操作，例如剛剛談起的對象收費是一種操作，改接入方式這個屬性也可以是一種操作。如圖3所示。

圖3 抽象后的CRM產品需求的業務模型

經過抽象后的產品需求已經可以直接轉化為系統的數據模型設計，如圖4所示。

同理，可以解決更為復雜的商品的業務模型設計。商品的抽象過程中發現，在商品對象、商品屬性、商品關系、商品的業務流程操作、商品的收費操作都可以先繼承產品的內容，再在商品的內容上增加新的對象、屬性、關系、收費。而產品本身并無渠道操作，這是需要商品本身獨有的操作。在服務事件操作上，商品先繼承產品操作然后再根據商品實例的特殊性對服務事件進行覆蓋，即可以停止該服務事件操作，也可以用其他個性化的服務事件操作替代，實現對象內操作的多態性。產品與商品業務模型的對比如下，如表1所示。

圖4 抽象后的CRM產品業務模型可直接轉為系統模型

表1 CRM產品與商品的業務模型對比

商品與產品之間的業務關系模型如圖5所示。

圖5 商品與產品的關系模型

而商品與商品之間的業務關系模型如圖6所示。

圖6 商品之間的關系模型

經過此番業務抽象而形成商品業務模型，也同樣可以直接轉為數據模型，如圖7所示。

圖7 抽象后的CRM商品業務模型可直接轉為數據模型

綜上，業務運營人員通過面向對象方法對電信應用系統例如CRM系統的需求進行抽象，可以直接轉為數據模型。而開發人員基于微服務設計理念，就可以將數據模型直接封裝為數據服務，進而多個數據服務可以封裝在一個容器鏡像內，實現對外提供服務。

以檢查商品之間的關系的對外查詢服務為例，可以直接根據數據模型來設計該服務的入參如表2所示。

表2 商品間關系的查詢服務入參表

并直接通過數據模型設計該服務的出參如表3所示。

這樣，業務運營人員自然而言地參與到了系統開發的過程中。在系統上線運營后，如果有需求變化，業務運營人員可以直接反應到業務模型、數據模型的變化之中，開發人員可以快速通過數據模型來更新對外服務并完成容器鏡像的部署。由此，基于PaaS平臺的高效率、可持續的開發與業務運營一體化的工作就能得以有序開展。

表3 商品間關系的查詢服務出參表

3 PaaS平臺+微服務場景下的通過分層思想實現開發與系統運營一體化

上一節闡述了如何基于PaaS平臺和微服務來實現業務運營與開發的面向對象的一體化，本節來闡述開發與系統運營的一體化。

系統運營與業務運營的差異在于，業務運營團隊關注的是系統的功能豐富、應用推廣、使用感知、快速實現，系統運營團隊關注的是系統的運行總體穩定、風險可控制、手段可預設、故障可快速恢復。即，系統運營團隊既要關注平臺穩定性和應用系統穩定性，而在故障處理、日常巡檢等處理方面，更是需要分層級、自動化地建立系統運營的工作機制。

3.1 基于PaaS平臺的電信業務場景微服務化示例

以電信的業務辦理為例，將一個典型的業務場景來拆分為微服務的調用關系如圖8所示[4]。

圖8 電信業務受理的微服務化示例

將原來的單體應用微服務化的過程大致為：根據業務設計出的業務對象，轉為數據對象后，就可以針對客戶、產品、商品等產品對象，以及業務訂購、算費的對象上的操作提供原子級別的基礎數據服務，進而組裝為分子級的業務共享服務，再進行形成用戶定位、業務受理、費用結算三個應用模塊。

因此，如果從一個業務流程為視角，開發人員將應用模塊逐步拆分，那么調用鏈過程還算清晰，如圖9所示。

圖9 開發視角的服務拆分過程

然而，如果從整個應用系統、乃至整個平臺的西系統運營的角度，關系就復雜得多，可以說已經超出了人腦的掌控范圍，如圖10所示。

3.2 開發與系統運營分層的幾大要素

因此，要進行如此復雜的調用場景的系統運營，解決之道就是進行分層。

分層的總體思路為：將系統監控、異常告警、日常關鍵業務巡檢、故障處理和查證解決等系統運營的方方面面，都需要按平臺系統運營與應用開發加以區分，并分層級地部署。

在平臺的系統運營視角下，運營人員的關注界面應該如下，包括平臺總體情況和各應用調用鏈的總體情況和走勢，如圖11所示。

圖10 平臺運營視角的服務調用示意圖

而在應用開發視角下，開發人員關注的調用鏈界面應如下，更多地關注每個環節的具體日志、報錯信息和上下游關系，如圖12所示。

圖12 應用視角調用鏈關注界面

除了系統運營關注要點的分層，在人員組織上，也許進行分層。基于PaaS平臺和微服務的場景，需要大致分為平臺、數據、應用三個層級，而平臺內還可分為一線、二線、高級等多個層級。如圖13所示。

圖13 系統運營的人員組織的分層結構

3.3 應用側與平臺側的系統運營分層與職責分工

根據PaaS平臺的應用發布、日常運營、故障處理的特點，制定應用側與平臺側的系統運營分層與職責分工如表4所示。據此來實現應用與系統運營的協調聯動和應急處置方案。

表4 應用側與平臺側的系統運營分層和職責分工

利用面向對象和分層思想實現基于PaaS平臺的電信CRM系統開發運營方案的研究與實踐

工作項應用側的系統運營平臺側的系統運營日常運輸每日巡檢內容:1、關鍵日志:通過平臺提供的日志查詢界面2、微服務詞用鏈:通過平臺提供的pinpoint調用鏈界面3、接口:通過pinpoint可以查詢到接口的失敗率、時延4、隊列深度:通過平臺監控界面可以查看及要求告警推送。5、接口性能監控6、主動探測的配置和告警7、調用鏈各環節日志分析8、服務調用的報錯處理9、服務性能優化日常監控與巡檢、包括平臺組件健康度、平臺組件負載情況、平臺集群可用性、以及基礎設施、大數據等配套資源可用性等;平臺組件賬號管理應用統一發布平臺故障應急響應與一般性故障處理平臺常規資源的分配與變更配套資源申請平臺構建、包括集群部署、集群擴容、組件升級等平臺組件巡檢質量管控平臺組件負載趨勢分析與資源回收平臺數據備份與清理平臺安全管理、包括安全掃描、安全整改、周期性應急演練平臺高級資源的分配與變更、包括SDK框架批量調整配置、分布式數據庫對象變更等故障處理處理流程:現象分析-故障初判(在用戶的第一接觸界面)-影響范圍分析-故障定位-故障應急預案-故障驗證-故障分析報告應急預案(服務重啟、版本回遇、灰度、資源擴容、TcpSQL的發現和分析、預賣演練等)的策略由應用與平臺共同制定、實際操作可以根據場景進行分工。故障升級與協調平臺組件疑難故障處理平臺故障與組件BUG踴躍管理平臺組件性能調優運維方案各中心制定中心運維方案(監控需求、告警需求、運維流量、運維責任人、故障分析流租、制定應急預案等),由平臺配合。平臺規劃平臺運維流程、規范、操作手冊的編制平臺組件功能需求管理、由應用側配合。配套工作跨應用的故障協助查證、接口類故障協助查證、中心間故障協同查證等配合應用側查證

4 總結

PaaS平臺和微服務技術相對于傳統的IT系統平臺而言，給應用開發帶來的優勢明顯，但問題和挑戰也很多。文中提出的面向對象方法來實現業務運營與開發的一體化、可持續化，以及開發與系統運營的分層的思想和方案，可以最大限度地解決這些問題和挑戰，并且已經在上海電信的CRM系統重構中的得到了驗證。然而，在PaaS平臺和微服務的新環境下，作為電信運營商需要改變工作思路，從搭平臺、搭硬件、搭管道，轉向業務運營、系統運營、用戶運營，這樣才能揚其長、避其短，充分將PaaS平臺及微服務等技術效果發揮到極致，這對每一個電信BOSS系統從業人員而言，還任重道遠，需要不斷積極探索新的方案并加以實踐，在實踐中積累更豐富的經驗。