程寶平，王兆輝，汪勝，陳進(jìn)利

（中移（杭州）信息技術(shù)有限公司/中國(guó)移動(dòng)杭州研發(fā)中心，杭州 310000）

面向企業(yè)協(xié)作服務(wù)的新型業(yè)務(wù)架構(gòu)探索與實(shí)踐＊

程寶平，王兆輝，汪勝，陳進(jìn)利

（中移（杭州）信息技術(shù)有限公司/中國(guó)移動(dòng)杭州研發(fā)中心，杭州 310000）

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

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

1 企業(yè)協(xié)作服務(wù)架構(gòu)現(xiàn)狀

1.1 現(xiàn)狀概述

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

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

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

1.2 存在的問題

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

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

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

（3）從性能的可擴(kuò)容的角度，當(dāng)單體應(yīng)用的某一個(gè)模塊遇到性能瓶頸需要擴(kuò)容，會(huì)導(dǎo)致整體應(yīng)用的擴(kuò)展和擴(kuò)容，導(dǎo)致了不必要系統(tǒng)資源的浪費(fèi)。

（4）從穩(wěn)定性的角度，因?yàn)樗心K都運(yùn)行在一個(gè)進(jìn)程中，任何一個(gè)模塊中的一個(gè)bug，比如內(nèi)存泄露，將會(huì)有可能弄垮整個(gè)進(jìn)程。除此之外，因?yàn)樗袘?yīng)用實(shí)例都是唯一的，這個(gè)bug將會(huì)影響到整個(gè)應(yīng)用的可靠性。

2 企業(yè)協(xié)作服務(wù)新架構(gòu)方案

2.1 方案概述

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

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

以云企信為例：未進(jìn)行架構(gòu)改造之前，核心服務(wù)代碼超過2G，編譯部署一次需要5 min以上，應(yīng)用運(yùn)行對(duì)服務(wù)器配置要求高，擴(kuò)展困難，可靠性原來越差。

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

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

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

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

2.2 架構(gòu)總體設(shè)計(jì)

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

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

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

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

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

2.3 關(guān)鍵技術(shù)特征

2.3.1 微服務(wù)架構(gòu)設(shè)計(jì)與服務(wù)治理

圖1 企業(yè)服務(wù)平臺(tái)六邊形架構(gòu)體系

圖2 企業(yè)服務(wù)平臺(tái)新型架構(gòu)體系

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

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

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

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

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

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

圖3 企業(yè)服務(wù)平臺(tái)服務(wù)治理示意圖

圖4 序列化反序列化性能對(duì)比圖

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

2.3.2 接入層透明代理設(shè)計(jì)

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

（1）在研發(fā)過程中，終端與平臺(tái)服務(wù)間之間進(jìn)行協(xié)議協(xié)商，連接器對(duì)協(xié)議過程不關(guān)心。

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

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

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

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

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

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

圖5 流量消耗對(duì)比圖

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

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

3 開發(fā)實(shí)踐

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

3.1 基礎(chǔ)架構(gòu)體系分析

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

圖6 企業(yè)服務(wù)平臺(tái)基礎(chǔ)平臺(tái)+擴(kuò)展平臺(tái)架構(gòu)體系

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

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

3.2 擴(kuò)展服務(wù)研發(fā)實(shí)踐

在新型企業(yè)服務(wù)平臺(tái)架構(gòu)體系下，一個(gè)新的擴(kuò)展服務(wù)通常按照?qǐng)D7所示的流程進(jìn)行研發(fā)推進(jìn)。

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

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

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

圖7 擴(kuò)展服務(wù)研發(fā)流程

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

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

4 總結(jié)與展望

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

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

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

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

（1）服務(wù)器資源使用降低一半，整體平臺(tái)可完全部署在低配虛擬云主機(jī)上，不依賴任何專用硬件設(shè)備。

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

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

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

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

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

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