【51CTO.com原創稿件】2014年前后，微服務架構理念慢慢流行開來，加之Amazon、Netflix等著名互聯網公司的應用實踐，開發者們更加認定微服務能夠打破架構層面的瓶頸。時至今日，無論是新開發系統、還是有十多年光景的遺留系統，不談微服務團隊實屬罕見。那么，微服務架構當前應用現狀如何？弊端有哪些？AI技術落地又帶來哪些挑戰？

近日，2018WOT全球軟件與運維技術峰會重量級嘉賓，轉轉公司架構算法部負責人孫玄接受了我們專訪，核心圍繞微服務架構的優勢、應用場景與轉轉微服務架構演進，及AI技術應用必然要面對的挑戰展開。

[[227143]]

孫玄·轉轉公司***架構師／架構算法部負責人

微服務架構的優勢、應用場景與弊端

微服務架構的特點

談微服務架構之前我們必要先說說單體架構。單體架構是指業務功能的實現全部在一個進程（process）內完成，優勢有二：

其一，在于請求響應延遲低，接收客戶端請求，經過一次網絡交互從數據庫批量獲取數據，其余的功能全部在進程內完成，避免了多次的網絡交互；

其二，第二僅一個進程，部署和運維成本小。

但業務功能單元間耦合嚴重、擴展性差、技術選型單一（在一個進程內是否可以采用多種開發語言？）等缺點也很明顯。其中架構顆粒過粗，嚴重影響系統迭代速度是***的問題。

單體架構很難滿足持續高速發展的互聯網業務，故按照某些維度進行拆分：

• 按照系統水平方向進行拆分（水平分層架構）。
• 按照業務功能垂直拆分（SOA架構）。
• 按照業務功能垂直拆分又按照系統水平方向進行拆分（微服務架構）。

如下圖所示，微服務架構是Martin Fowler 在2014年提出的架構模式。

微服務架構一般是按照業務領域拆分服務、一系列小服務構成、服務獨立部署、獨立運行、服務間去中心化管理（任何一個服務都可以采用任何開發語言 C/PHP/Go/Java等。

運行于任何的平臺Linux/Windows等，理想是豐滿的，現實相對骨感）。

孫玄老師表示，微服務首先按照業務領域模型垂直拆分，即根據不同的業務功能單元進行垂直拆分。之后，對垂直拆分后的服務，在水平方向繼續進行拆分。

微服務架構的優勢與現狀

當問及微服務架構的優勢，孫玄這樣這樣說，采用微服務架構后，項目能夠做到快速迭代，持續交付。服務架構的出現，解決了水平分層架構以及SOA架構拆分不徹底的問題。

• 從業務角度看，微服務架構本質上一個業務架構，對業務了解越深刻，微服務拆分越合理；
• 從系統角度看，微服務架構是水平分層架構和SOA架構的結合體。

提到微服務架構，就不得不提到Netflix公司。Netflix是一家成功實踐微服務架構的互聯網公司，幾年前，Netflix就把它的幾乎整個微服務框架棧開源貢獻給了社區。

Netflix公司的開源框架組件已經在Netflix的大規模分布式微服務環境中經過多年的生產實戰驗證，正逐步被社區接受為構造微服務框架的標準組件。Pivotal去年推出的Spring Cloud開源產品，主要是基于對Netflix開源組件的進一步封裝，方便Spring開發人員構建微服務基礎框架。

微服務架構的應用場景

當前，國內有很多系統在擁抱微服務架構，轉轉二手交易平臺也是之一。除內部積極實施微服務架構外，一些公司還會把框架開源出來，比如百度的ppc，阿里的Dubbo等。

微服務架構不適用的應用場景有三：內部系統、系統要求低延遲和數據要求強一致性。

內部系統

這些系統包括企業內部OA系統（比如工作匯報等）、財務審計系統（比如報銷系統等）、HR系統（比如考勤系統等）、行政系統（比如會議室預定等）、運維自動化系統（工單系統、發布系統、CMDB系統等）。這類系統的特點是功能相對簡單、需求固定，變化頻率不高、使用人數較少、平均訪問次數不高。對這類的系統使用微服務架構的必要性不大。

系統要求低延遲

按照微服務架構拆分服務后，服務數量變多，服務間的調用關系也會變的錯綜復雜，導致請求的鏈條變長，使得請求的平均耗時增加。因此對請求耗時極其敏感的場景，微服務架構不是合理的選擇。比如量化交易場景，一個請求會到達多個服務提供方，哪家服務方的響應被接受取決于服務方的響應速度，在這個業務場景下，哪怕響應速度慢1ms，也就無效了。

數據要求強一致性

微服務架構下數據比較分散，實施數據一致性相對困難，特別是強一致性。因此對數據要求強一致性的場景，微服務架構就變得不在合適。

除了上述三大場景外，在互聯網的其他場景中，都能夠使用微服務架構。

孫玄表示，微服務架構也存在明顯的弊端：開發人員除了關注業務邏輯的實現外，還需要在微服務模塊里處理一系列問題，比如服務注冊、服務發現、服務通訊、負載均衡、服務熔斷、請求超時重試等，這是非常糟糕的。業務開發團隊的強項在于業務理解，而不是技術。能否讓業務開發人員僅關注業務開發，服務間通訊以及請求管理功能不再關心？服務網格架構解決了這個問題，讓業務開發人員真正解脫。

轉轉二手較易平臺的微服務架構演進

轉轉二手較易平臺包括用戶功能、商品功能、交易功能、搜索功能及推薦功能。各個業務單元相對獨立，首先按照業務領域模型垂直拆分成用戶、商品、交易、搜索、推薦微服務。對每一個功能單元（商品等），繼續進行水平拆分，分為商品網關層、商品業務邏輯層、商品數據訪問層、商品DB/Cache，對用戶、交易、搜索、推薦等業務同樣方式進行水平拆分。

如下圖，是轉轉二手較易平臺最終微服務架構。

轉轉二手較易平臺還包括了服務治理功能：注冊中心、配置中心。網關負責請求接入，業務邏輯層用于各種業務邏輯的處理；數據訪問層用做數據訪問代理，提供ORM、數據Sharding以及屏蔽底層存儲的差異性等功能；注冊中心負責服務的注冊和發現；配置中心負責服務個性化配置的讀取。

隨著產品功能越來越多，業務復雜度也越來越高，在業務邏輯層會有一些功能重復出現（比如業務邏輯層都需要用戶登錄邏輯功能），解決功能重復的問題，轉轉在業務邏輯層之下，抽象提取出公共業務邏輯層。用戶的請求鏈路變為網關、業務邏輯層、公共邏輯層、數據訪問層。

AI下的微服務架構

轉轉二手交易平臺，在搜索、個性化推薦、風控等領域都有使用AI技術。從AI方向講，轉轉使用較多的是機器學習，特別是有監督學習。深度學習方面也在嘗試，在風控等領域已經在使用，取得不錯的效果。

就搜索推薦來說，從本質是解決海量商品召回及排序的問題：

• 召回層，涉及到大規模商品數據，如何使商品召回更精確，如何使用復雜模型，無論是在工程還是在算法應用層面，都會面對較大的挑戰。
• 排序層，使用更多的特征并應用復雜的排序模型，使得最終序更能符合用戶的期望。

孫玄表示，商品召回量越來越大，機器學習模型越來越復雜，如何合理使用分布式并行計算技術，使得用戶的請求能夠盡快返回，對微服務工程架構的挑戰會越來越大。

那么，隨著商品量日益增多，機器學習模型越來越復雜，在工程架構體系方面要如何更好地支持，用戶請求要如何盡可能快速返回？

2018年5月18、19日，2018WOT全球軟件與運維技術峰會期間，孫玄將在“容器下的AIOps專場“做主題為”轉轉如何打造AI工程架構體系“的演講。屆時會對工程架構體系石器、鐵器、工業革命各個階段的適用場合、架構特點及進一步演進原因進行詳細闡述。開發者們能夠對轉轉AI工程架構體系演進路線知其然知其所以然，從中借鑒一些實踐經驗，應用于自己的AI工程架構中。

【被訪者簡介】

孫玄，現任轉轉公司***架構師／架構算法部負責人，前58集團技術委員會主席，高級系統架構師，“架構之美”公眾號作者。擅長系統架構設計，大數據，機器學習等技術領域。代表公司多次參加 Artificial Intelligence Conference、QCon、ArchSummit、SDCC、CCTC、DTCC、Top100、Strata + Hadoop World、WOT 等大會嘉賓演講，并為《程序員》雜志撰稿 2 篇。 前百度高級工程師，參與百度社區搜索部多個基礎系統的設計與實現。畢業于浙江大學。

【本月排行***0】

1. 張真：AIOps六大技術難點與宜信運維的重大變革
   
2. 新炬網絡程永新：插上AI翅膀 運維平臺煥發出嶄新生命力
3. 從SIEM&AI到SIEM@AI AI構建下一代企業安全大腦
4. 基于線性網絡的語音合成說話人自適應
5. 轉轉公司架構算法部孫玄：AI下的微服務架構

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】