淺談微服務(wù)的來龍去脈

作者：王清培(Plen wang)

滬江 公共業(yè)務(wù)平臺(tái) 應(yīng)用架構(gòu)師

轉(zhuǎn)載至滬江技術(shù)學(xué)院微信公眾號(hào)

背景介紹

最近一段時(shí)間公共業(yè)務(wù)平臺(tái)在進(jìn)行大面積的重構(gòu)，對(duì)原來的技術(shù)棧進(jìn)行遷移，逐漸往Java、Go、Node.js等開源、自由為主的技術(shù)體系中過度。

雖然這主要是替換技術(shù)框架，但也是我們應(yīng)用系統(tǒng)進(jìn)行重新設(shè)計(jì)、業(yè)務(wù)流程重新梳理的一個(gè)好機(jī)會(huì)，我們將利用這次機(jī)會(huì)來重構(gòu)之前發(fā)現(xiàn)的一些問題。

Martin Fowler大師《重構(gòu)》一書中有說過一句話，大概意思就是，“每次對(duì)原有系統(tǒng)進(jìn)行修改調(diào)整的時(shí)候是一個(gè)非常好的重構(gòu)契機(jī)?！?/p>

對(duì)一個(gè)正在運(yùn)行良好的系統(tǒng)進(jìn)行重構(gòu)機(jī)會(huì)不多，這種需要對(duì)系統(tǒng)進(jìn)行適當(dāng)?shù)男薷幕蛘哒{(diào)整的時(shí)候，可以借機(jī)重構(gòu)。如果總是不抓住這樣難得的重構(gòu)機(jī)會(huì)，就意味著積累的技術(shù)債務(wù)永遠(yuǎn)償還不了，最后頻繁的破窗效應(yīng)、墨菲定律。我們正視前行的道路上欠下的技術(shù)債務(wù)，把握恰當(dāng)?shù)臅r(shí)機(jī)及時(shí)償還，這樣才有可能不會(huì)因?yàn)榧夹g(shù)包袱影響系統(tǒng)建設(shè)，影響業(yè)務(wù)發(fā)展。這些在George Fairbanks 大師的《恰如其分的軟件架構(gòu)》一書中講解的很深刻，最重要的一條就是“風(fēng)險(xiǎn)驅(qū)動(dòng)”的架構(gòu)設(shè)計(jì)原則，一定要先識(shí)別出風(fēng)險(xiǎn)，針對(duì)風(fēng)險(xiǎn)排好優(yōu)先級(jí)及時(shí)重構(gòu)解決。

我們還面臨著一個(gè)最大的問題就是，需要一邊支持業(yè)務(wù)高速發(fā)展一邊進(jìn)行系統(tǒng)重構(gòu)，更要命的是還需要支持各業(yè)務(wù)線進(jìn)行各種大促活動(dòng)，配合進(jìn)行核心交易系統(tǒng)壓測(cè)等等，可想而知這種壓力還是不小。

而且我們是滬江集團(tuán)的公共業(yè)務(wù)平臺(tái)，我們是服務(wù)于滬江集團(tuán)所有業(yè)務(wù)線，包括B2C業(yè)務(wù)（滬江網(wǎng)校）、直播業(yè)務(wù)（CCtalk）、外部訂單業(yè)務(wù)（開放平臺(tái)）、UGC（滬江問答）、批量導(dǎo)入訂單（TPS峰值較高）等核心業(yè)務(wù)。

大家可能對(duì)傳統(tǒng)電商的業(yè)務(wù)比較了解，但是對(duì)教育行業(yè)的類電商業(yè)務(wù)可能不是很了解，兩者之間最大的一個(gè)區(qū)別就是在商品的標(biāo)準(zhǔn)化上。教育是以服務(wù)為主，不是一個(gè)簡(jiǎn)單的買賣商品的過程，而是一個(gè)智能推薦的過程，所有的商品都是需要基于用戶之前的學(xué)習(xí)數(shù)據(jù)來動(dòng)態(tài)生成，也就是說，公共業(yè)務(wù)平臺(tái)的商品系統(tǒng)中的商品是動(dòng)態(tài)變化的，沒有固定屬性的商品，商品的屬性一直隨著數(shù)據(jù)積累在進(jìn)化。

這就帶來一個(gè)巨大的挑戰(zhàn)，因?yàn)橐坏┎皇腔谝粋€(gè)固定標(biāo)準(zhǔn)的商品來進(jìn)行交易系統(tǒng)、商品系統(tǒng)、營(yíng)銷系統(tǒng)、商戶清結(jié)算系統(tǒng)等核心系統(tǒng)設(shè)計(jì)時(shí)會(huì)面臨著一個(gè)極大的抽象難度，必須建立起一套龐大且可以落地的抽象模型出來，足以容納那些變化萬千的業(yè)務(wù)模式。這方面的系統(tǒng)建設(shè)還沒有太多成熟的模式可以參考，這是一個(gè)考驗(yàn)?zāi)憔C合技術(shù)能力的時(shí)候，光有一個(gè)“具體”的技術(shù)是解決不了這種問題域的。

這個(gè)背景介紹主要是為了能夠與讀者達(dá)成一個(gè)基本技術(shù)討論的上下文環(huán)境，目的是為了在講解本文主題的時(shí)候大家在一個(gè)頻道上，這樣才不會(huì)浪費(fèi)大家寶貴的時(shí)間。

通過背景介紹，至少我們達(dá)成以下共識(shí)，我們正在做系統(tǒng)重構(gòu)，業(yè)務(wù)主要是提供服務(wù)型商品，背后需要很多智能化的支持，同時(shí)我們是平臺(tái)型的系統(tǒng)，所以我們會(huì)陸續(xù)面臨平臺(tái)型系統(tǒng)所碰到的所有問題。

本文僅僅代表個(gè)人對(duì)應(yīng)用架構(gòu)、軟件工程的一些獨(dú)立思考的總結(jié)。

微服務(wù)怎么來的

把一個(gè)業(yè)務(wù)系統(tǒng)設(shè)計(jì)好，這本身所面對(duì)的問題域就是偏業(yè)務(wù)分析、業(yè)務(wù)設(shè)計(jì)。大部分的時(shí)間都是在根據(jù)對(duì)業(yè)務(wù)的理解來進(jìn)行抽象建模，搞清楚邊界，站在一個(gè)較高的角度看待問題。（這在架構(gòu)設(shè)計(jì)領(lǐng)域常被稱為“上帝視角”）

受當(dāng)下比較熱的技術(shù)之一微服務(wù)影響，大家都在談?wù)撐覀円蛟煳⒎?wù)架構(gòu)。當(dāng)我們都沉迷在微服務(wù)的技術(shù)中時(shí)，會(huì)主觀的傾向性的用微服務(wù)來輔助你的系統(tǒng)建模，也就是將微服務(wù)的方法論提升到了系統(tǒng)分析的戰(zhàn)略層面，這將直接決定了系統(tǒng)架構(gòu)建設(shè)的方向。

所以由此我花了點(diǎn)時(shí)間反思了微服務(wù)，我們必須徹底的看清楚它的來龍去脈，這樣才能把它用在合適的地方。要想搞清楚微服務(wù)是什么并不簡(jiǎn)單，需要很多證據(jù)和線索，來幫助你辯證、推理你的判斷。

微服務(wù)的提出者是本章前面提到的Martin Fowler，他是世界軟件大師，Thoughtworks首席科學(xué)家，著作頗多。如果你讀過他的一系列經(jīng)典書籍的話，你應(yīng)該知道他是“軟件”大師，他不是類似“JAVA并發(fā)”大師Doug Lea，他們是不同領(lǐng)域的大師，所解決的問題域是不同的。確定這一點(diǎn)很重要，這可以讓你明白微服務(wù)是由誰提出的，提出來用來解決什么類型問題域，這是重要的線索之一。

Martin Fowler與太多東西有關(guān)系，他與Robert C.Martin是我們?cè)趹?yīng)用系統(tǒng)建設(shè)領(lǐng)域接觸最多的大師，Robert C.Martin《敏捷軟件開發(fā)-原則、模式與實(shí)踐》榮獲Jolt大獎(jiǎng)。還有一位大師不得不提，《UML與模式應(yīng)用》作者Craig Larman，他的GRASP也是經(jīng)典中的經(jīng)典，不可錯(cuò)過，絕對(duì)是武裝你應(yīng)用架構(gòu)能力的重要武器。

如果你是一名應(yīng)用系統(tǒng)領(lǐng)域建設(shè)從業(yè)者，你應(yīng)該不會(huì)錯(cuò)過大師們的經(jīng)典。他們?nèi)齻€(gè)大師都會(huì)經(jīng)常性的出現(xiàn)在一些經(jīng)典書籍的推薦序中，如，在Craig Larman的《UML與模式應(yīng)用》的推薦序中，第一個(gè)就是Martin Fowler。

《UML和模式應(yīng)用（原書第3版）》的結(jié)構(gòu)和重點(diǎn)建立在作者多年教授和培訓(xùn)成千上萬學(xué)生掌握OOA/D的經(jīng)驗(yàn)之上，它提供了一個(gè)精煉的、已證明的和高效率的掌握OOA/D的學(xué)習(xí)方法。

　　“人們經(jīng)常問我，介紹OO設(shè)計(jì)的圖書是哪一本。讀過《UML和模式應(yīng)用（原書第3版）》之后，我毫無保留地選擇了它?！薄?/p>

　　——Martin Fowler，《UML Distilled》和《Refactoring》的作者

還有很多為了解決軟件復(fù)雜性而作出努力的大師，像Peter code建模大師，他發(fā)明了彩色建模，讓我們能夠用不變的方式勾勒、描繪出任何復(fù)雜的領(lǐng)域，像“實(shí)體”、“角色”、“描述”、“時(shí)刻時(shí)段”，他的著作《彩色UML建?！贩浅＝?jīng)典。此書里的一個(gè)經(jīng)典分析方法就是：“某個(gè)角色的對(duì)象，在某個(gè)時(shí)間里、某個(gè)場(chǎng)景下做了某件事情，觸發(fā)了某種事件（event）”。

比如：會(huì)員等級(jí)Level1的用戶plen，2017年5月10號(hào)上午10:30分、在滬江網(wǎng)校的商城里購(gòu)買了新版雅思7分沖刺【5月班】課程，觸發(fā)了創(chuàng)建訂單事件。

當(dāng)你掌握了這種巧妙的方法之后你會(huì)喜歡上業(yè)務(wù)分析。一般人不會(huì)意識(shí)到“行為”是跟著角色走的，而是下意識(shí)的認(rèn)為行為是跟著對(duì)象走的。請(qǐng)仔細(xì)揣摩這句話，看你能否搞清楚，這是系統(tǒng)分析中典型的問題，“職責(zé)分配”，這也是應(yīng)用系統(tǒng)架構(gòu)中的致命環(huán)節(jié)。

提示：你只有在公司才具有打開公司商業(yè)文件的權(quán)利，你只有在家里才可以和家人很親密。

這里面隱含的意思就是，“角色”賦予你的行為，你只有是公司的“員工”角色的時(shí)候才可以進(jìn)行公司商業(yè)文件的瀏覽權(quán)限。你只有是“爸爸”或者“老公”又或者“兒子”的時(shí)候才可以和家人親密無間。在大街上摟摟抱抱的總是不太和諧，問題就在這里。你在大街上所扮演的角色是一個(gè)國(guó)家的公民，是有具體的行為準(zhǔn)則的。所以角色決定了你的行為。

還有DDD（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）之父Eric Evans，DDD基本上是現(xiàn)代應(yīng)用系統(tǒng)架構(gòu)中必不可少的技術(shù)之一，包括阿里巴巴都在越來越多的運(yùn)用DDD設(shè)計(jì)復(fù)雜的業(yè)務(wù)系統(tǒng)（你可以通過他們的招聘JD中發(fā)現(xiàn)）。DDD通過將問題域進(jìn)行了設(shè)計(jì)抽象、通過將一個(gè)龐大的問題域如何進(jìn)行子域的劃分，又如何識(shí)別出這些子域的立體關(guān)系，而不是上下關(guān)系，識(shí)別出落地的限界上下文，上下文的邊界交互模式，領(lǐng)域事件的影響、事件追溯（Event sourcing）等等。DDD里面明確了幾個(gè)重要的東西，“戰(zhàn)略模式”、“戰(zhàn)術(shù)模式”、“問題域”，當(dāng)我們進(jìn)行系統(tǒng)分析和建模的時(shí)候是運(yùn)用戰(zhàn)略模式的時(shí)候。大多數(shù)時(shí)候我們錯(cuò)誤的使用了戰(zhàn)術(shù)模式來解決戰(zhàn)略問題，你無法用戰(zhàn)術(shù)層面的技術(shù)解決戰(zhàn)略層面的問題。

DDD里面有很多突破性的技術(shù)，比較有意思的“事件驅(qū)動(dòng)”、“事件溯源(event sourcing)”。

DDD強(qiáng)化實(shí)體，實(shí)體與實(shí)體之間的協(xié)作是通過event觸發(fā)，這里又與actor模型類似，每個(gè)actor即是一個(gè)獨(dú)立的微對(duì)象。

而在micro service里 服務(wù)盡可能小，服務(wù)之間也在強(qiáng)調(diào)事件驅(qū)動(dòng)，SOA里也在提EDA架構(gòu)。

問題的關(guān)鍵還是event怎么來，event都是特定domain的，event不會(huì)無故產(chǎn)生。所以得用DDD來解決event的抽象問題。

大家可能對(duì)event sourcing不是太了解，但是如果你對(duì)redis的AOF持久化了解的話，就大差不離了，redis也通過對(duì)key的操作形成一系列的event，然后通過key event來追溯數(shù)據(jù)的生命周期。

還有一些建模界的大師，像SOA大師，Thomas Erl，也是著作頗豐，他的書里有很多用SOA來建模企業(yè)整體信息架構(gòu)的思路，所以SOA不純粹是一個(gè)RPC，他是代表一整套技術(shù)落地框架。

到此，你可能會(huì)好奇，這些與微服務(wù)有啥關(guān)系。先別急著下結(jié)論，這些都是用來搞清楚微服務(wù)是什么的重要線索。

我們是什么，工程師，而不是發(fā)明或者科研人員，工程師講究嚴(yán)謹(jǐn)、追溯、分析、看歷史、看未來、找規(guī)律，需要找到證據(jù)來證明我們的推理，而不是人云亦云，要不然沒有說服力，沒有獨(dú)立思考能力，在實(shí)施的時(shí)候要么都對(duì)要么都錯(cuò)，無法進(jìn)行思維的碰撞。

Martin Fowler、Eric Evans 這兩位大師就我個(gè)人而言意味著應(yīng)用軟件開發(fā)界最高領(lǐng)袖和方向盤（這是個(gè)人信仰、和崇拜，誰讓我是他們的粉絲），Martin Fowler 的《企業(yè)應(yīng)用架構(gòu)模式》是軟件分層架構(gòu)的思想最開始的地方。Eric Evans 是個(gè)偉大的突破者，正在征服軟件復(fù)雜性問題，《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)—軟件核心復(fù)雜性應(yīng)對(duì)之道》是我讀過的眾多書籍中感觸最大，最讓人深思的書。

經(jīng)過上面的分析和追溯，我想表達(dá)的是這樣的一個(gè)構(gòu)思導(dǎo)圖：（圖1）

上圖中從最左邊開始，一直到最右邊，是我在學(xué)習(xí)應(yīng)用系統(tǒng)架構(gòu)過程中總結(jié)出的一個(gè)大概技術(shù)發(fā)展或者是相互影響的關(guān)系。這些東西模糊著看，在歷史上發(fā)生的事情邊界并不總是那么明顯清晰，都有互相影響的作用。此圖主要是圍繞著一些本人學(xué)習(xí)過程中收集的一些技術(shù)影響力比較高的人來敘述，并不一定完全正確，能表達(dá)我們分析的思路即可。為了只是能將這些東西串起來推理微服務(wù)的由來。

圖的最右邊是Martin Fowler提出微服務(wù)的時(shí)候，看到這幅圖的時(shí)候你應(yīng)該能大致的明白，其實(shí)微服務(wù)的提出者是用它來解決什么問題的，這里還不能完全對(duì)微服務(wù)的由來下個(gè)結(jié)論，因?yàn)檫€有一部分內(nèi)容我們沒有分析。這里還有一個(gè)有力的證據(jù)可以證明，目前微服務(wù)書籍里評(píng)分最高的就是Thought Works公司技術(shù)專家編寫的《微服務(wù)設(shè)計(jì)》由圖靈出版社引進(jìn)國(guó)內(nèi)出版。在仔細(xì)看下書的目錄你會(huì)驚訝的發(fā)現(xiàn)微服務(wù)的落地需要DDD來輔助的，這起碼在建模階段是需要借助DDD強(qiáng)大的戰(zhàn)略模式來支撐的。所以，這里也證明了，微服務(wù)不是簡(jiǎn)單的指將服務(wù)盡可能的拆小，然后一個(gè)RPC框架搞定了。這太粗糙了，無法落地的，會(huì)有一系列問題出現(xiàn)，比如，分布式事務(wù)問題、數(shù)據(jù)生命周期問題、數(shù)據(jù)延遲問題、抽象混亂問題等。抽象的工作做不好，落地的時(shí)候就會(huì)比較混亂，不易于擴(kuò)展：（圖2）

如果用TOGAF的框架來劃分企業(yè)整體架構(gòu)體系的話，至少微服務(wù)的技術(shù)棧在應(yīng)用架構(gòu)層是有明確的技術(shù)應(yīng)用的，而不是全指系統(tǒng)架構(gòu)層的某個(gè)具體的技術(shù)，如，docker、RabbitMQ、RPC之類的中間件。

如果大家仔細(xì)思考過你所學(xué)的應(yīng)用技術(shù)在整個(gè)軟件工程的生命線上的發(fā)展關(guān)系時(shí)，你應(yīng)該能發(fā)現(xiàn)一個(gè)規(guī)律，就是任何一個(gè)方法論的出現(xiàn)都會(huì)有兩個(gè)層面的東西，“識(shí)別問題域?qū)栴}域進(jìn)行建模”的方法，最后才會(huì)談“如何落地的事情”。這是兩個(gè)大的層面問題需要解決，戰(zhàn)略層面、戰(zhàn)術(shù)層面。

所以技術(shù)都要用兩個(gè)層面來看，具體講就是分析、設(shè)計(jì)、建模，落地實(shí)施方法。這其中包括如下幾個(gè)比較重量級(jí)的技術(shù)體系，TOGAF 企業(yè)信息架構(gòu)框架、DDD 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)、SOA 面向服務(wù)架構(gòu)、GRASP 通用軟件職責(zé)設(shè)計(jì)模式、彩色建?！纳湍Ｊ健RASP主要是輔助職責(zé)設(shè)計(jì)，四色原型主要是捕捉實(shí)體的事件發(fā)生序列，不會(huì)讓你丟失關(guān)鍵業(yè)務(wù)場(chǎng)景。

這些技術(shù)、方法論、模式并不是純粹的理論，而是有很多比較精妙的思想在里面，我們看下上述中他們是怎么劃分兩個(gè)層面來看問題的：（圖3）

學(xué)習(xí)搞懂這些模式，都是希望能夠讓我們不僅正確的做事，還需要做正確的事情。這些軟件大師不是在重復(fù)造輪子，而是軟件工程界一直有太多問題需要解決，而且問題是源源不斷的出現(xiàn)。

那么這些應(yīng)用技術(shù)到底位于整個(gè)技術(shù)棧的什么位置，其實(shí)整個(gè)技術(shù)棧用分層來看，比較好理解：（圖4）

現(xiàn)在技術(shù)體系基本上分為三大類，應(yīng)用架構(gòu)、系統(tǒng)架構(gòu)、中間件架構(gòu)，當(dāng)然還有運(yùn)維架構(gòu)、數(shù)據(jù)架構(gòu)，后兩者跟我們文章主題關(guān)系不是很大，這里暫且先不談。這些在美國(guó)著名的TOGAT架構(gòu)框架技術(shù)體系中講解的比較清楚，可以適當(dāng)參考。 我不打算羅列太多技術(shù)概念，只想表達(dá)微服務(wù)這個(gè)技術(shù)是在應(yīng)用技術(shù)棧范疇，跟其他的應(yīng)用技術(shù)一樣都是具有系統(tǒng)分析、建模的能力，并不是一個(gè)純粹的框架或技術(shù)，而是一個(gè)綜合性的架構(gòu)模式。

微服務(wù)是進(jìn)化出來的

由此可以得出一個(gè)結(jié)論，微服務(wù)是進(jìn)化出來的。其實(shí)縱觀軟件研發(fā)中的所有技術(shù)，大多都是進(jìn)化出來的，很少突然出現(xiàn)一個(gè)跟之前所有技術(shù)不想關(guān)的技術(shù)。只不過理論性的知識(shí)容易被忽視，大多的技術(shù)人員喜歡直奔主題，動(dòng)手敲敲就是一個(gè)微服務(wù)，其實(shí)只是運(yùn)用了微服務(wù)技術(shù)體系中的部分技術(shù)。

我們一直有這樣的困擾，計(jì)算機(jī)領(lǐng)域的知識(shí)學(xué)習(xí)一直有一個(gè)難點(diǎn)就是：“解釋一個(gè)概念需要用另外幾個(gè)概念來解釋，但是解釋另外幾個(gè)概念還需要其他概念來解釋”，這不就是計(jì)算機(jī)領(lǐng)域的發(fā)展規(guī)律嗎。所以我們都在講究聚焦領(lǐng)域，每個(gè)領(lǐng)域都是深不見底，都有他的知識(shí)體系，都有他的技術(shù)棧。

由于時(shí)間關(guān)系，我并沒有把所有的線索和證據(jù)都羅列出來，其實(shí)還有很多東西都是和微服務(wù)有關(guān)系的，至少說微服務(wù)都是需要借鑒這些東西落地，比如，微服務(wù)中提到了服務(wù)的集成和編排，這些東西在SOA、DDD中都存在，很難說這是微服務(wù)的東西還是SOA、DDD的。所以都是互相借鑒和參考，再進(jìn)一步演化，慢慢的就進(jìn)化出一些具有代表性的技術(shù)概念。

微服務(wù)不是銀彈

當(dāng)我們搞清楚了微服務(wù)是什么之后，就有助于我們進(jìn)行運(yùn)用了。首先可以肯定的是，微服務(wù)不是銀彈，他解決不了所有問題，之前存在的問題依然存在。當(dāng)我們想要盡可能的使用微服務(wù)架構(gòu)時(shí)，那么我們緊接著就要回答別人提出的一系列在SOA架構(gòu)中同樣存在的問題，就要搞清楚如何回答別人提出的服務(wù)邊界怎么劃分問題，如果有GRASP、四色原型等輔助你來分析、設(shè)計(jì)，會(huì)工程化、科學(xué)化很多。

其實(shí)架構(gòu)做了久了大家會(huì)發(fā)現(xiàn)一個(gè)潛規(guī)則，就是有時(shí)候方案沒有明顯的對(duì)與錯(cuò)，而是說服力的問題。你的方案是否經(jīng)得起推敲，經(jīng)得起別人的提問，能否回答別人的疑慮。

所以當(dāng)你將這些應(yīng)用技術(shù)了然于胸之后，你大可不必說出來，而是稍加轉(zhuǎn)換下就可以慢慢影響你的架構(gòu)方向。

總結(jié)

由于時(shí)間關(guān)系，我有很多技術(shù)點(diǎn)沒有展開，主要是為了考慮閱讀時(shí)間問題，我們將不間斷的分享重構(gòu)過程中遇到的一系列問題。這其中會(huì)包括運(yùn)用新技術(shù)，同時(shí)也會(huì)包括對(duì)以往經(jīng)典問題的反思。

希望這篇文章能夠讓你對(duì)微服務(wù)有一個(gè)不一樣的認(rèn)識(shí)，主要是知道他位于整個(gè)技術(shù)棧的什么位置，這有點(diǎn)抽象，但是軟件本身不就是抽象中抽象，設(shè)計(jì)中設(shè)計(jì)嗎，軟件開發(fā)不就是在創(chuàng)造世界嗎。

軟件開發(fā)是一個(gè)綜合性的問題，我們無法用戰(zhàn)術(shù)層面的技術(shù)來解決戰(zhàn)略層面的問題，也無法用戰(zhàn)略層面的技術(shù)來解決戰(zhàn)術(shù)層面的問題。是技術(shù)就一定有適用場(chǎng)景，只有搞清楚某個(gè)技術(shù)的來龍去脈才可能避免濫用。

最后，雖然文章不算太長(zhǎng)，但是文章中包含的技術(shù)面還是比較廣的，要想搞清楚，需要花點(diǎn)時(shí)間逐個(gè)研究一番才能把這些串起來，形成綜合的技術(shù)體系。謝謝。