程寶平，王兆輝，汪勝，陳進利

（中移（杭州）信息技術有限公司/中國移動杭州研發(fā)中心，杭州 310000）

面向企業(yè)協(xié)作服務的新型業(yè)務架構探索與實踐＊

程寶平，王兆輝，汪勝，陳進利

（中移（杭州）信息技術有限公司/中國移動杭州研發(fā)中心，杭州 310000）

系統(tǒng)基于自研自容器微服務架構，通過自定義輕量化協(xié)議實現(xiàn)終端兩省一低（省電、省流量、低功耗）平臺三高一低（高擴展性、高負載、高可用、低資源消耗），以辦公型即時通訊錄、企業(yè)融合通信、企業(yè)辦公協(xié)同為基礎，實現(xiàn)辦公的移動化、平臺化、社交化、業(yè)務化，全面提升員工效率，充分釋放組織潛能。

智慧政企；融合通信；協(xié)作辦公；微服務

1 企業(yè)協(xié)作服務架構現(xiàn)狀

1.1 現(xiàn)狀概述

傳統(tǒng)企業(yè)協(xié)作服務多采用單體式架構設計，應用核心是業(yè)務邏輯，由定義服務、域、對象和事件等模塊完成，圍繞著核心的是與外界交互的適配器，適配器包括數(shù)據(jù)庫訪問組件、生產(chǎn)和處理消息的組件，以及提供API或者UI訪問支持的Web模塊等。

雖然采用的多是模塊化邏輯，模塊之間虛擬隔離，但是最終它還是會打包并部署為單體式應用。例如許多Java應用會被打包為WAR格式，部署在Tomcat或者Jetty上，而另外一些Java應用會被打包成自包含的JAR格式，同樣，Rails和Node.js會被打包成層級目錄。

這種傳統(tǒng)的應用開發(fā)風格被大規(guī)模應用在企業(yè)平臺開發(fā)，因為IDE和其它工具都擅長開發(fā)一個簡單應用，這類應用也很易于調(diào)試，只需要簡單運行此應用，用簡單UI測試方式就可以完成端到端測試。單體式應用也易于部署，只需要把打包應用拷貝到服務器端，通過在負載均衡器后端運行多個拷貝就可以輕松實現(xiàn)應用擴展。

1.2 存在的問題

傳統(tǒng)單體式系統(tǒng)架構在用戶體驗、研發(fā)運維、可靠性等多方面存在問題，隨著系統(tǒng)不斷迭代，開發(fā)和運維團隊的效率將受到極大挑戰(zhàn)。

（1）從用戶體驗角度，應用的發(fā)布與更新都會造成業(yè)務的中斷和暫停，導致用戶會有間歇性的服務不可用體驗。

（2）從研發(fā)運維角度，簡單的應用會隨著時間推移逐漸變大，敏捷開發(fā)和部署舉步維艱，復雜而巨大的單體式應用也不利于持續(xù)性開發(fā)，如今，SaaS應用常態(tài)就是每天會改變很多次，而這對于單體式應用模式非常困難。另外，這種變化帶來的影響并沒有很好的被理解，所以不得不做很多手工測試，持續(xù)部署也會很艱難。

（3）從性能的可擴容的角度，當單體應用的某一個模塊遇到性能瓶頸需要擴容，會導致整體應用的擴展和擴容，導致了不必要系統(tǒng)資源的浪費。

（4）從穩(wěn)定性的角度，因為所有模塊都運行在一個進程中，任何一個模塊中的一個bug，比如內(nèi)存泄露，將會有可能弄垮整個進程。除此之外，因為所有應用實例都是唯一的，這個bug將會影響到整個應用的可靠性。

2 企業(yè)協(xié)作服務新架構方案

2.1 方案概述

單體服務架構通過服務內(nèi)模塊化實現(xiàn)模塊間低耦合，模塊內(nèi)高內(nèi)聚，單體服務架構通常表現(xiàn)為六邊形架構，一個典型的企業(yè)辦公類產(chǎn)品架構通常設計如圖1所示。

隨著時間的推移，應用系統(tǒng)會變得越來越龐大，沒有人能夠對系統(tǒng)整體了如指掌，同時敏捷迭代和部署變得舉步維艱，修正bug和正確的添加新功能變的非常困難和耗時。

以云企信為例：未進行架構改造之前，核心服務代碼超過2G，編譯部署一次需要5 min以上，應用運行對服務器配置要求高，擴展困難，可靠性原來越差。

在我們實際的研發(fā)中也發(fā)現(xiàn)，業(yè)務在往復雜化發(fā)展，用戶的需求越來越個性化，甚至各個省的客戶由于地域差異也會出現(xiàn)需求沖突。

解決好如上問題成為架構師最大的挑戰(zhàn)，因此在新架構設計的時候創(chuàng)新性引入了“分而治之”的思想，對業(yè)務進行獨立分拆，相似業(yè)務獨立為一個小服務，即方興未艾的微服務理念，服務之間互聯(lián)互通，自由伸縮，系統(tǒng)具備良好擴展性。

同時，引入擴展性良好的業(yè)務協(xié)議，降低終端的資源消耗，降低終端開發(fā)和平臺開發(fā)的溝通難度。

對系統(tǒng)整體而言，可以保障系統(tǒng)在未來可見的生命周期內(nèi)滿足用戶增長、運營活動的支撐要求。

2.2 架構總體設計

如圖2所示，系統(tǒng)架構設計方面在企業(yè)服務行業(yè)首創(chuàng)地引入分層設計原則，自上而下分為負載均衡層、連接層、服務層、數(shù)據(jù)層4層， 4層架構清晰明了，邏輯清晰，每一層均獨立可擴展。

負載均衡層摒棄原F5硬負載均衡方案，采用軟負載的方式降低運維成本，提高系統(tǒng)擴展性。

連接層負責所有終端、管理系統(tǒng)的接入，通過移動終端長連接保持、前后端分離設計的管理系統(tǒng)、自研輕量化業(yè)務協(xié)議，實現(xiàn)終端良好用戶體驗。

服務層是整體系統(tǒng)的核心，為系統(tǒng)的業(yè)務承載層，服務之間可自由通信，通過引入服務治理概念，實現(xiàn)服務間自動負載均衡，有效提高服務的擴展性和靈活性；同時，服務層采用嵌入式監(jiān)控，對服務的健康狀況進行實時監(jiān)控。

數(shù)據(jù)層為系統(tǒng)的文件、數(shù)據(jù)、緩存、通知——訂閱、消息的集中存儲，方便運維進行管理。

2.3 關鍵技術特征

2.3.1 微服務架構設計與服務治理

圖1 企業(yè)服務平臺六邊形架構體系

圖2 企業(yè)服務平臺新型架構體系

在本系統(tǒng)的設計實現(xiàn)過程中，微服務更多的是一種理念，代表靈活可自由拼裝的軟件設計，通常一類業(yè)務會組裝成一個獨立的服務，微服務架構有以下幾個好處。

（1）通過分解巨大單體式應用為多個服務方法解決了復雜性問題，在功能不變的情況下，應用被分解為多個可管理的分支或服務，每個服務都有一個用RPC——或者消息驅動API定義清楚的邊界，微服務架構模式給采用單體式編碼方式很難實現(xiàn)的功能提供了模塊化的解決方案，由此，單個服務很容易開發(fā)、理解和維護。

（2）這種架構使得每個服務都可以有專門開發(fā)團隊來開發(fā)，開發(fā)者可以自由選擇開發(fā)技術，提供API服務。當然，許多公司試圖避免混亂，只提供某些技術選擇。然后，這種自由意味著開發(fā)者不需要被迫使用某項目開始時采用的過時技術，他們可以選擇現(xiàn)在的技術。甚至于，因為服務都是相對簡單，即使用現(xiàn)在技術重寫以前代碼也不是很困難的事情。

（3）微服務架構模式是每個微服務獨立的部署，開發(fā)者不再需要協(xié)調(diào)其它服務部署對本服務的影響，這種改變可以加快部署速度，UI團隊可以采用AB測試，快速的部署變化。微服務架構模式使得持續(xù)化部署成為可能。

（4）微服務架構模式使得每個服務獨立擴展，你可以根據(jù)每個服務的規(guī)模來部署滿足需求的規(guī)模。甚至于，你可以使用更適合于服務資源需求的硬件。

微服務給我們的系統(tǒng)開發(fā)帶來諸多好處的同時，也給系統(tǒng)的運維帶來了諸多挑戰(zhàn)，諸如服務治理、服務保障、服務間通信保障、服務監(jiān)控等系統(tǒng)運行問題，考慮到盡量降低系統(tǒng)運行風險，在系統(tǒng)設計之初便引入了服務治理與嵌入式監(jiān)控，以保障服務的高可用和良好擴展性。

圖3 企業(yè)服務平臺服務治理示意圖

圖4 序列化反序列化性能對比圖

如圖3所示，服務治理是為了解決服務間調(diào)度及自動化運維問題而設計的，通過引入統(tǒng)一服務注冊中心，所有服務啟動時完成注冊中心登記才可標記服務成功啟動，服務調(diào)用方通過訂閱該服務名稱來獲知服務的變更信息（服務啟動、停止、擴展）。

2.3.2 接入層透明代理設計

本系統(tǒng)架構設計中，創(chuàng)新性設計了透明代理機制，即統(tǒng)一所有終端連接管理到一個connector服務，該服務負責終端的鏈接管理、服務調(diào)用和消息推送，這為研發(fā)過程和用戶體驗帶來了如下好處。

（1）在研發(fā)過程中，終端與平臺服務間之間進行協(xié)議協(xié)商，連接器對協(xié)議過程不關心。

（2）在平臺業(yè)務上下架過程，連接器服務會一直保持正常運行，終端不會有掉線的體驗。

（3）運維可隨時發(fā)布、更新服務，不需要選擇服務器閑時。

2.3.3 自研輕量化協(xié)議

行業(yè)內(nèi)領先的協(xié)議設計，基于protobuffer3.0，自研全套業(yè)務協(xié)議，實現(xiàn)信令私有化，實現(xiàn)終端通信的兩省一低（省電、省流量、低功耗），同時保障系統(tǒng)的通信安全，與其它通用協(xié)議自研輕量化協(xié)議具備如下優(yōu)勢。

（1）性能高，基于二進制序列化框架，提高序列化性能，經(jīng)過實際測試，反序列化性能提升4倍（xmpp:0.86μs V pb:0.22μs)，序列化性能提升20倍（xmpp:2.37μs VS pb:0.12μs），如圖4所示。

（2）流量低，通過協(xié)議本身的合理制定和流量壓縮技術，可以實現(xiàn)80%的流量降低，實際對比測試數(shù)據(jù)如圖5所示。

圖5 流量消耗對比圖

（3）開發(fā)效率高，自研協(xié)議代碼生成器，開發(fā)者只需要關心業(yè)務本身如何設計。

（4）兼容性好，是完美的前后兼容方案。向前兼容，模塊A升級后，模塊B可以正常識別A發(fā)出的新版本協(xié)議，此時，新增的屬性會被忽略；向后兼容，模塊B升級后，能夠正常識別A發(fā)出的老版本協(xié)議，由于老版本沒有新增的屬性，在擴充協(xié)議時，一般設置為非必填或定義默認值。

3 開發(fā)實踐

移動互聯(lián)網(wǎng)時代，一個新的業(yè)務點從思路產(chǎn)生到產(chǎn)品上線，軟件的研發(fā)效率是十分重要的指標，對于一個大型軟件系統(tǒng)來說，如何能夠在既有體系架構下，以最低的侵入性將一個全新的業(yè)務無縫構建出來，是這套架構需要重點解決的問題。

3.1 基礎架構體系分析

我們通常將新型企業(yè)服務平臺分成兩大部分：基礎平臺+擴展模塊，基礎平臺中運轉著系統(tǒng)核心業(yè)務，同時也是擴展業(yè)務得以熱插拔的基石，如圖6所示。

圖6 企業(yè)服務平臺基礎平臺+擴展平臺架構體系

在基礎平臺中，我們根據(jù)企業(yè)服務的特性，梳理出連接器、用戶中心、消息網(wǎng)關、推送服務、短信中心、配置中心、日志分析、服務調(diào)度等核心服務，這些服務所承載的業(yè)務需求較為單一和固定，很少有需求變更的情況。作為基礎平臺，需要在架構之初，設計出供擴展模塊調(diào)用的Base-API，Base-API的特點是業(yè)務無關性，例如用戶中心提供的獲取用戶所在企業(yè)的API，因其業(yè)務無關性可被多個擴展模塊所調(diào)用。

在傳統(tǒng)企業(yè)服務平臺中，新的業(yè)務需求產(chǎn)生后，通常的思路是在既有服務模塊上增加代碼來實現(xiàn)。在新型企業(yè)服務平臺中，我們的做法是全新構建一個微服務，以擴展模塊的形態(tài)，通過服務發(fā)現(xiàn)，與基礎平臺融合在一起。同時在基礎平臺的服務調(diào)度中心，可以快速上架、下架這些擴展模塊，實現(xiàn)服務的熱插拔，業(yè)務靈活性大大提高。

3.2 擴展服務研發(fā)實踐

在新型企業(yè)服務平臺架構體系下，一個新的擴展服務通常按照圖7所示的流程進行研發(fā)推進。

(1) 詳細設計：在新型企業(yè)服務平臺架構下，通常詳細設計階段由平臺研發(fā)人員主導推進，主要內(nèi)容包括技術實現(xiàn)流程設計、交互協(xié)議定義、數(shù)據(jù)庫設計等。交互協(xié)議主要有終端交互協(xié)議和內(nèi)部服務交互協(xié)議，針對移動辦公的業(yè)務特性，我們制定了基于Protobuf+Service接口模式的協(xié)議模型，該技術模型提供了較好的前向兼容性與后向兼容性，大大提升了版本升級迭代的便利性。

(2) 代碼生成：在大型企業(yè)服務平臺中，如何保障眾多微服務模塊的技術框架一致性是重要的課題，因此我們設計了一套代碼生成器。根據(jù)詳細設計階段定義的PB協(xié)議，代碼生成器可生成出除了業(yè)務邏輯外的標準化代碼框架。包括自容器調(diào)試運行框架、接口代理點、全環(huán)境配置等，開發(fā)人員基于這套基礎框架，增加業(yè)務邏輯代碼，能夠在很短的時間內(nèi)完成一個微服務模塊的開發(fā)。

(3) 聯(lián)調(diào)測試：擴展模塊的內(nèi)聚性很強，擴展模塊之間通常沒有耦合性，與Base Platform之間也僅通過Base-API進行單向數(shù)據(jù)交互。同時，通過服務透明代理，Base Platform中的連接器為客戶端和擴展模塊之間架起了一座無形的橋梁，在聯(lián)調(diào)測試過程中，客戶端研發(fā)人員通過調(diào)用擴展模塊提供的終端PB接口，完成端到端的業(yè)務流程。

圖7 擴展服務研發(fā)流程

(4) 質量管控：隨著擴展模塊不斷增多，服務上線的敏捷性要求也越來越高。由于模塊間耦合性很低，新增一個擴展模塊對于系統(tǒng)整體質量不會造成影響，因此我們的質量管控的重點也就落在擴展模塊自身上。我們在模塊代碼框架上限制了模塊必須通過靜態(tài)代碼掃描和單元測試，否則無法編譯通過，也就無法進入集成測試。實踐表明，經(jīng)過這兩項流程，測試一次性通過率提升到了80%以上。

(5) 服務發(fā)布：在統(tǒng)一框架下研發(fā)微服務，對于需求迭代效率、問題追蹤、團隊人員協(xié)作等都有極大的提升，但隨之也帶來運維的難度。由于微服務模塊非常多，依靠運維人員通過腳本部署很容易造成人為失誤，在生產(chǎn)環(huán)境留下隱患。我們在Base Platform中設計了服務治理中心，融入DevOps的思想，提供可視化運維界面，實現(xiàn)服務的部署與編排。同時建立一套服務&服務器的健康度監(jiān)測模型，進行實時監(jiān)控與預警。

4 總結與展望

面向企業(yè)協(xié)作服務的新型業(yè)務架構通過自研核心技術，提供的不僅僅是一種解決方案，而是一種創(chuàng)新的開發(fā)方式，這種方式將產(chǎn)品、研發(fā)、測試、運維、質量保障等各個角色通過架構設計機密的結合在一起，把研發(fā)角色通過架構設計滲透到各個角色分工中，形成技術主導的DevOps系統(tǒng)研發(fā)模式，保障了良好的分工協(xié)作。

同時，良好架構設計讓開發(fā)人員能夠把更多的精力放在業(yè)務本身，花更多的精力去設計業(yè)務，產(chǎn)出相關設計文檔，從重編碼向重設計轉型，實現(xiàn)研發(fā)人員定位、價值的提升。

當然，新架構需要經(jīng)過實踐的檢驗，不斷完善，才能不斷成熟，目前新架構已經(jīng)應用與小溪云通信、政企云企信、集團版小移人家、山東云企信、政企企業(yè)網(wǎng)關等諸多項目中，滿足PaaS、IaaS等多種部署方式。

以云企信為例，新架構投產(chǎn)之后，相比較老系統(tǒng)而言提升顯著，新架構在商用成熟度快速提高。

（1）服務器資源使用降低一半，整體平臺可完全部署在低配虛擬云主機上，不依賴任何專用硬件設備。

（2） 系統(tǒng)穩(wěn)定性大大提高，基本實現(xiàn)無人值守式運維。

（3） 開發(fā)迭代效率顯著提高，雙周迭代內(nèi)完成需求數(shù)量提高30%。

（4）版本周期內(nèi)，客戶反饋bug數(shù)量下降60%，運營效率大大提高。

在不斷商用過程中，遵循以用促研的原則，滿足基本產(chǎn)品需求之外，未來新型業(yè)務架構將在服務健康度監(jiān)測、自動化運維、分布式消息跟蹤、灰度發(fā)布等方面不斷完善，達到更高的商用標準，打造行業(yè)知名的企業(yè)協(xié)作服務架構技術體系。

Exploration and practice of new business architecture for enterprise collaborative service

CHENG Bao-ping, WANG Zhao-hui, WANG Sheng, CHEN Jin-li
(China Mobile (Hangzhou) Information Technology Co., Ltd./ China Mobile Hangzhou R & D Center, Hangzhou 310000, China)

The system is based on self-porting micro-service architecture, to implements a terminal with low-power, and a platform with high-scalability, high-load, high-availability, low resource consumption, to officetype instant messaging, corporate integration communications, enterprise office collaboration as the basis, to achieve office mobility, platform, socialization, business, and comprehensively enhance staff efficiency, fully release organizational potential.

wisdom government and enterprise; integration communication; cooperative office; micro service

TP311

A

1008-5599（2017）08-00015-06

2017-07-03

* 中國移動集團級一類科技創(chuàng)新成果，原成果名稱為《企業(yè)融合通信產(chǎn)品（云企信、企業(yè)飛信、小移人家、工作機）》。