技術架構統一，應對業務整合
閱文集團成立於2015年，由騰訊文學與原盛大文學整合而成。因為由很多子品牌公司的技術架構組成，所以需要進行技術架構的統一。
傅徐軍說道：“我們面臨的第一個挑戰就要做技術架構的統一，這是我們第一個要解決的問題。”閱文集團後端服務技術棧曾有.Net及Oracle儲存，也存在著幾百臺Windows Server系統的伺服器，當然也存在JAVA和PHP兩種在網路文學行業中應用非常廣泛的語言。所以秉承快速構建、共性開發、持續整合、快速迭代、高效運營的理念，架構統一的工作順理成章地展開了。
技術決策者經驗，微服務架構選型
因為RPC的遠端呼叫特性，針對多系統間的通訊及計算能力橫向擴充套件有著先天優勢。閱文集團早期的架構是單一接入的煙囪式架構，如果發生接入層故障或者資料中心節點故障，都會導致全業務不可用。
針對新技術架構選型，傅徐軍闡述道：“閱文集團需要一個分散式的計算框架，一個高效能的RPC架構以及微服務的治理平臺。在做了很多的技術架構選型之後，最終選擇了騰訊的TARS。經過持續的技術交流和逐步的架構演變，解決了閱文集團在服務發現、智慧排程、負載均衡、容災容錯、立體化監控和視覺化運營管理的問題。閱文集團在技術架構上取得了很好的效果，跟我們的預期非常一致，研發效率得到了極大的提升，運維成本也明顯的減少，整體系統的穩定性也取得了卓越的效果。”
抽象公共元件，提升研發效率
閱文集團這幾年發展很快，針對不同的讀者提供了很多不同的閱讀頻道，針對不同的合作方提供了不同的合作方式。從而形成很多不同的方案，如果為每一個方案做一套獨立的架構，是很有難度的。
傅徐軍表示：“閱文集團一開始有起點讀書、QQ閱讀這類線上網文的內容。後來，做了很多細分，比如說面向女性讀者、面向二次元讀者及海外讀者都提供了不同的閱讀頻道。與正版紙質圖書也有很多合作，如為微信讀書提供內容，像《哈利·波特》、《魔戒》都通過閱文發行。這些方案雖然很不一樣，但是他們有很多的公共元件，是可以抽取出來的。比如說計費、賬戶、稿酬、評論的反作弊等。有大概數百個部分組成，這樣慢慢提取出來，才能做到更好的迭代，才能提高研發效率。”
高效能高併發，服務海量使用者
“閱文集團在近幾年使用者快速增長，現在MAU已經超過1.9億，這樣的一個情況下，春節搞一個紅包活動，QPS大概是十萬級別，核心引擎的資料也達到了十萬級別。為了支援這樣的量級，怎麼樣做一個高效能高併發的架構是一個挑戰。”傅徐軍補充。
閱文集團業務每日呼叫數值巨大。近60種業務服務，對於常規的開發部署方式，必然會花費大量成本進行編碼、部署以及運維的統一。正是採用了騰訊的TARS架構，它在研發和運營方面都有非常優秀的表現，為閱文集團的APP抗住了515書友粉絲節、百萬紅包、除夕手Q線上聯動等過億級使用者量的活動。
技術回饋社群，加速開源發展
傅徐軍在最後說道：“令我印象最深的是，雖然TARS是從原來在騰訊內部使用到後來慢慢變開源的一個平臺，但是它向我們提供的卻是一個企業級的服務。閱文集團技術團隊除了使用開源技術，同時也做了很多對外開源的貢獻。比如在多語言的支援上，原來的TARS欠缺了對PHP語言的支援，而閱文集團在PHP語言開發的積累上是比較透徹的，所以我們幫助TARS做了PHP的語言擴充套件。同時我們去年與TARS的技術團隊也做了深入的分享和交流。未來，閱文將會向開源社群做更多的技術回饋，加速整個開源社群的發展。”