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

近日，2018WOT全球軟件與運維技術(shù)峰會重量級嘉賓，轉(zhuǎn)轉(zhuǎn)公司架構(gòu)算法部負責(zé)人孫玄接受了我們專訪，核心圍繞微服務(wù)架構(gòu)的優(yōu)勢、應(yīng)用場景與轉(zhuǎn)轉(zhuǎn)微服務(wù)架構(gòu)演進，及AI技術(shù)應(yīng)用必然要面對的挑戰(zhàn)展開。

[[227143]]

孫玄·轉(zhuǎn)轉(zhuǎn)公司***架構(gòu)師／架構(gòu)算法部負責(zé)人

微服務(wù)架構(gòu)的優(yōu)勢、應(yīng)用場景與弊端

微服務(wù)架構(gòu)的特點

談微服務(wù)架構(gòu)之前我們必要先說說單體架構(gòu)。單體架構(gòu)是指業(yè)務(wù)功能的實現(xiàn)全部在一個進程（process）內(nèi)完成，優(yōu)勢有二：

其一，在于請求響應(yīng)延遲低，接收客戶端請求，經(jīng)過一次網(wǎng)絡(luò)交互從數(shù)據(jù)庫批量獲取數(shù)據(jù)，其余的功能全部在進程內(nèi)完成，避免了多次的網(wǎng)絡(luò)交互；

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

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

單體架構(gòu)很難滿足持續(xù)高速發(fā)展的互聯(lián)網(wǎng)業(yè)務(wù)，故按照某些維度進行拆分：

• 按照系統(tǒng)水平方向進行拆分（水平分層架構(gòu)）。
• 按照業(yè)務(wù)功能垂直拆分（SOA架構(gòu)）。
• 按照業(yè)務(wù)功能垂直拆分又按照系統(tǒng)水平方向進行拆分（微服務(wù)架構(gòu)）。

如下圖所示，微服務(wù)架構(gòu)是Martin Fowler 在2014年提出的架構(gòu)模式。

微服務(wù)架構(gòu)一般是按照業(yè)務(wù)領(lǐng)域拆分服務(wù)、一系列小服務(wù)構(gòu)成、服務(wù)獨立部署、獨立運行、服務(wù)間去中心化管理（任何一個服務(wù)都可以采用任何開發(fā)語言 C/PHP/Go/Java等。

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

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

微服務(wù)架構(gòu)的優(yōu)勢與現(xiàn)狀

當(dāng)問及微服務(wù)架構(gòu)的優(yōu)勢，孫玄這樣這樣說，采用微服務(wù)架構(gòu)后，項目能夠做到快速迭代，持續(xù)交付。服務(wù)架構(gòu)的出現(xiàn)，解決了水平分層架構(gòu)以及SOA架構(gòu)拆分不徹底的問題。

• 從業(yè)務(wù)角度看，微服務(wù)架構(gòu)本質(zhì)上一個業(yè)務(wù)架構(gòu)，對業(yè)務(wù)了解越深刻，微服務(wù)拆分越合理；
• 從系統(tǒng)角度看，微服務(wù)架構(gòu)是水平分層架構(gòu)和SOA架構(gòu)的結(jié)合體。

提到微服務(wù)架構(gòu)，就不得不提到Netflix公司。Netflix是一家成功實踐微服務(wù)架構(gòu)的互聯(lián)網(wǎng)公司，幾年前，Netflix就把它的幾乎整個微服務(wù)框架棧開源貢獻給了社區(qū)。

Netflix公司的開源框架組件已經(jīng)在Netflix的大規(guī)模分布式微服務(wù)環(huán)境中經(jīng)過多年的生產(chǎn)實戰(zhàn)驗證，正逐步被社區(qū)接受為構(gòu)造微服務(wù)框架的標準組件。Pivotal去年推出的Spring Cloud開源產(chǎn)品，主要是基于對Netflix開源組件的進一步封裝，方便Spring開發(fā)人員構(gòu)建微服務(wù)基礎(chǔ)框架。

微服務(wù)架構(gòu)的應(yīng)用場景

當(dāng)前，國內(nèi)有很多系統(tǒng)在擁抱微服務(wù)架構(gòu)，轉(zhuǎn)轉(zhuǎn)二手交易平臺也是之一。除內(nèi)部積極實施微服務(wù)架構(gòu)外，一些公司還會把框架開源出來，比如百度的ppc，阿里的Dubbo等。

微服務(wù)架構(gòu)不適用的應(yīng)用場景有三：內(nèi)部系統(tǒng)、系統(tǒng)要求低延遲和數(shù)據(jù)要求強一致性。

內(nèi)部系統(tǒng)

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

系統(tǒng)要求低延遲

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

數(shù)據(jù)要求強一致性

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

除了上述三大場景外，在互聯(lián)網(wǎng)的其他場景中，都能夠使用微服務(wù)架構(gòu)。

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

轉(zhuǎn)轉(zhuǎn)二手較易平臺的微服務(wù)架構(gòu)演進

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

如下圖，是轉(zhuǎn)轉(zhuǎn)二手較易平臺最終微服務(wù)架構(gòu)。

轉(zhuǎn)轉(zhuǎn)二手較易平臺還包括了服務(wù)治理功能：注冊中心、配置中心。網(wǎng)關(guān)負責(zé)請求接入，業(yè)務(wù)邏輯層用于各種業(yè)務(wù)邏輯的處理；數(shù)據(jù)訪問層用做數(shù)據(jù)訪問代理，提供ORM、數(shù)據(jù)Sharding以及屏蔽底層存儲的差異性等功能；注冊中心負責(zé)服務(wù)的注冊和發(fā)現(xiàn)；配置中心負責(zé)服務(wù)個性化配置的讀取。

隨著產(chǎn)品功能越來越多，業(yè)務(wù)復(fù)雜度也越來越高，在業(yè)務(wù)邏輯層會有一些功能重復(fù)出現(xiàn)（比如業(yè)務(wù)邏輯層都需要用戶登錄邏輯功能），解決功能重復(fù)的問題，轉(zhuǎn)轉(zhuǎn)在業(yè)務(wù)邏輯層之下，抽象提取出公共業(yè)務(wù)邏輯層。用戶的請求鏈路變?yōu)榫W(wǎng)關(guān)、業(yè)務(wù)邏輯層、公共邏輯層、數(shù)據(jù)訪問層。

AI下的微服務(wù)架構(gòu)

轉(zhuǎn)轉(zhuǎn)二手交易平臺，在搜索、個性化推薦、風(fēng)控等領(lǐng)域都有使用AI技術(shù)。從AI方向講，轉(zhuǎn)轉(zhuǎn)使用較多的是機器學(xué)習(xí)，特別是有監(jiān)督學(xué)習(xí)。深度學(xué)習(xí)方面也在嘗試，在風(fēng)控等領(lǐng)域已經(jīng)在使用，取得不錯的效果。

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

• 召回層，涉及到大規(guī)模商品數(shù)據(jù)，如何使商品召回更精確，如何使用復(fù)雜模型，無論是在工程還是在算法應(yīng)用層面，都會面對較大的挑戰(zhàn)。
• 排序?qū)?，使用更多的特征并?yīng)用復(fù)雜的排序模型，使得最終序更能符合用戶的期望。

孫玄表示，商品召回量越來越大，機器學(xué)習(xí)模型越來越復(fù)雜，如何合理使用分布式并行計算技術(shù)，使得用戶的請求能夠盡快返回，對微服務(wù)工程架構(gòu)的挑戰(zhàn)會越來越大。

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

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

【被訪者簡介】

孫玄，現(xiàn)任轉(zhuǎn)轉(zhuǎn)公司***架構(gòu)師／架構(gòu)算法部負責(zé)人，前58集團技術(shù)委員會主席，高級系統(tǒng)架構(gòu)師，“架構(gòu)之美”公眾號作者。擅長系統(tǒng)架構(gòu)設(shè)計，大數(shù)據(jù)，機器學(xué)習(xí)等技術(shù)領(lǐng)域。代表公司多次參加 Artificial Intelligence Conference、QCon、ArchSummit、SDCC、CCTC、DTCC、Top100、Strata + Hadoop World、WOT 等大會嘉賓演講，并為《程序員》雜志撰稿 2 篇。 前百度高級工程師，參與百度社區(qū)搜索部多個基礎(chǔ)系統(tǒng)的設(shè)計與實現(xiàn)。畢業(yè)于浙江大學(xué)。

【本月排行***0】

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

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】