李忠民+齊占新+周慶虎

摘 要：根據(jù)最近在為某大企業(yè)G做電子商務(wù)平臺（文章稱其為E系統(tǒng)）的微服務(wù)化改造，該平臺為年交易額數(shù)千億的大型招投標(biāo)交易平臺，擁有供應(yīng)商用戶數(shù)十萬，采用微服務(wù)架構(gòu)，基于G企業(yè)的私有云建設(shè)。G公司原有的E系統(tǒng)（后文簡稱E1.0）投產(chǎn)比較早，是一個(gè)典型的單體應(yīng)用，當(dāng)初沒有預(yù)料到會有這么大的交易量，一直處于小馬拉大車的狀態(tài)，且由于架構(gòu)因素導(dǎo)致擴(kuò)展性很差，改進(jìn)困難，故G公司下決心進(jìn)行E系統(tǒng)的徹底改造，而實(shí)施微服務(wù)化改造的新版E系統(tǒng)（后文簡稱E2.0）則是一個(gè)集云計(jì)算、容器化、微服務(wù)架構(gòu)等技術(shù)于一體的系統(tǒng)，這個(gè)轉(zhuǎn)變過程非常具有代表性，故根據(jù)實(shí)踐經(jīng)驗(yàn)總結(jié)出幾個(gè)原則以供探討。

關(guān)鍵詞：大型聯(lián)網(wǎng)平臺；微服務(wù)架構(gòu)；微服務(wù)化；組件化設(shè)計(jì)

中圖分類號：F713.36 文獻(xiàn)標(biāo)志碼：A 文章編號：2095-2945（2017）35-0001-06

1 背景介紹

E系統(tǒng)是一個(gè)大型招投標(biāo)交易平臺，是G公司的核心應(yīng)用之一，該系統(tǒng)的1.0版本已經(jīng)投入運(yùn)營近十年，目前擁有注冊用戶30余萬個(gè)，設(shè)計(jì)目標(biāo)是100萬用戶。目前該系統(tǒng)年處理采購申請80萬份，存儲非結(jié)構(gòu)化數(shù)據(jù)1.7億份，計(jì)30TB左右。

該系統(tǒng)有一種典型的應(yīng)用，即大批次招投標(biāo)業(yè)務(wù)，其對性能提出了較高的要求：

（1）該業(yè)務(wù)要求系統(tǒng)能夠在規(guī)定期限內(nèi)上傳5TB的投標(biāo)文件。

（2）投標(biāo)文件都是加密、壓縮傳輸，要求在2小時(shí)內(nèi)完成2.4TB數(shù)據(jù)的解密、解壓處理。該交易是E系統(tǒng)的關(guān)鍵應(yīng)用，也是特色應(yīng)用，該交易的設(shè)計(jì)指標(biāo)極大地影響著E系統(tǒng)架構(gòu)設(shè)計(jì)的方方面面，如網(wǎng)絡(luò)入口帶寬、存儲設(shè)備性能、應(yīng)用服務(wù)處理性能、內(nèi)網(wǎng)局域網(wǎng)的帶寬要求等等。

E1.0版本有幾根本性的問題：

（1）開發(fā)時(shí)間比較早。由于業(yè)務(wù)發(fā)展比較快，當(dāng)初的架構(gòu)已經(jīng)不適應(yīng)如此大業(yè)務(wù)量的需要，長期處于小馬拉大車的窘境。

（2）架構(gòu)腐化非常嚴(yán)重。系統(tǒng)呈現(xiàn)一團(tuán)面條狀，改動和優(yōu)化非常困難，導(dǎo)致擴(kuò)展性很糟糕。

（3）業(yè)務(wù)特點(diǎn)決定了在某種特殊投標(biāo)業(yè)務(wù)時(shí)，需要在規(guī)定時(shí)間內(nèi)處理非常大量的數(shù)據(jù)（據(jù)測算達(dá)到5TB之多），故而在這些交易上需要非常高的性能，而平時(shí)這些交易又幾乎沒有流量，故性能要求高，且波動幅度非常大。

（4）采用集群化部署，資源配置缺乏彈性。

以上幾個(gè)問題正是微服務(wù)架構(gòu)大顯身手之處，故對于E系統(tǒng)來說，實(shí)現(xiàn)微服務(wù)化是正確的舉措。今年正當(dāng)G公司實(shí)施新的IT信息化戰(zhàn)略的第一年，新戰(zhàn)略以私有云建設(shè)為重頭戲，引入一平臺一系統(tǒng)規(guī)劃理念，E系統(tǒng)作為G公司最大的核心應(yīng)用系統(tǒng)之一，上云發(fā)展、采用分布式架構(gòu)既是公司整體戰(zhàn)略的要求，也是E系統(tǒng)自身的必然選擇，故G公司決定徹底重建E系統(tǒng)，重新分析、設(shè)計(jì)、開發(fā)。E2.0系統(tǒng)采用微服務(wù)架構(gòu)，實(shí)現(xiàn)單體應(yīng)用向微服務(wù)架構(gòu)的轉(zhuǎn)變，實(shí)現(xiàn)傳統(tǒng)集中式集群化系統(tǒng)向分布式、私有云轉(zhuǎn)變。

2 E系統(tǒng)微服務(wù)化面臨的困難

網(wǎng)上有很多對比單體架構(gòu)和微服務(wù)架構(gòu)的文章，其中不乏對微服務(wù)頌揚(yáng)有加的激進(jìn)觀點(diǎn)，但是當(dāng)面臨一個(gè)真實(shí)的大型應(yīng)用，要真正地操刀微服務(wù)化時(shí)，首先要做的是充分考慮到其中的風(fēng)險(xiǎn)，個(gè)人認(rèn)為還是要相對務(wù)實(shí)一些、保守一些，不要被那些純技術(shù)派的觀點(diǎn)誤導(dǎo)。

在實(shí)施E系統(tǒng)的微服務(wù)化改造中，我們主要面臨幾個(gè)問題：

（1）首先微服務(wù)化引入了復(fù)雜性技術(shù)，微服務(wù)架構(gòu)是分布式架構(gòu)，凡是分布式架構(gòu)所具有的復(fù)雜性其都具有，而每個(gè)架構(gòu)師都應(yīng)該努力避免引入無謂的繁雜。

（2）其次微服務(wù)架構(gòu)只有和云計(jì)算、容器化等一系列技術(shù)結(jié)合使用才能發(fā)揮其效果，這附帶著需要整個(gè)技術(shù)生態(tài)發(fā)生變化。

（3）微服務(wù)化必然引起設(shè)計(jì)、開發(fā)、測試、運(yùn)維支持等工作的一系列變化，對于一個(gè)有著很多成熟應(yīng)用、運(yùn)維技術(shù)已經(jīng)相對固定的大型企業(yè)來說，引起的變化已經(jīng)超出技術(shù)范疇。

（4）微服務(wù)架構(gòu)引起的一系列技術(shù)路線方面的變化，在一個(gè)有著成熟完善的IT管理制度和規(guī)范戰(zhàn)略的企業(yè)中意味著需要很多突破，需要企業(yè)信息化管理制度方面的許多變革，故而有很多請示、匯報(bào)、研討、論證環(huán)節(jié)，產(chǎn)生巨大的協(xié)調(diào)、溝通成本，作為一個(gè)資源有限、工期限制嚴(yán)格的項(xiàng)目，要在時(shí)間、人力資源等方面充分考慮，否則很可能技術(shù)上沒有問題，但是項(xiàng)目反而失敗了。

故而在對E1.0系統(tǒng)進(jìn)行微服務(wù)拆分的過程中，項(xiàng)目組堅(jiān)持了一個(gè)原則：要建設(shè)一個(gè)可用的E系統(tǒng)，而不是一個(gè)十分先進(jìn)的E系統(tǒng)。微服務(wù)架構(gòu)是一種手段，我們用它是要解決問題的，不能為了微而微。應(yīng)該注意到微服務(wù)架構(gòu)在解決一些問題的同時(shí)，也不可避免地提高了復(fù)雜性，盲目的微服務(wù)化，片面強(qiáng)調(diào)微服務(wù)的“微”，而忘了為什么要微，會使得引入的問題比解決的問題還多，導(dǎo)致項(xiàng)目失敗。

3 一得：微服務(wù)架構(gòu)本質(zhì)是“解耦”

首先我認(rèn)為微服務(wù)這個(gè)概念有一定誤導(dǎo)性，相對于傳統(tǒng)單體應(yīng)用，將其稱為“多體應(yīng)用”更準(zhǔn)確些。微服務(wù)架構(gòu)僅僅是一種新的解耦方式，是一種“徹底解耦的多實(shí)體應(yīng)用”，實(shí)體間徹底解耦，然后按照規(guī)范的方式協(xié)作是微服務(wù)架構(gòu)的根本特征。

一個(gè)系統(tǒng)可以分為開發(fā)態(tài)和運(yùn)行態(tài)，開發(fā)態(tài)即我們通過設(shè)計(jì)、開發(fā)、測試等過程逐漸構(gòu)建出來的系統(tǒng)，此時(shí)系統(tǒng)是作為靜態(tài)的代碼、配置文件和數(shù)據(jù)的集合存在于硬盤中，是沒有行為的。運(yùn)行態(tài)即系統(tǒng)運(yùn)轉(zhuǎn)起來以后具有的結(jié)構(gòu)。

傳統(tǒng)單體應(yīng)用的特征為：其開發(fā)態(tài)是一個(gè)實(shí)體，其運(yùn)行態(tài)是該實(shí)體的多個(gè)實(shí)例，就像類與對象的關(guān)系。傳統(tǒng)的單體應(yīng)用一般采用單機(jī)部署（很少，除非非常小的應(yīng)用或者實(shí)驗(yàn)性的系統(tǒng)）或者集群化部署，其根本特征是“一個(gè)設(shè)計(jì)、開發(fā)、測試實(shí)體，一個(gè)或者多個(gè)運(yùn)行實(shí)體”。

而微服務(wù)架構(gòu)在開發(fā)態(tài)時(shí)就是多個(gè)實(shí)體，運(yùn)行態(tài)更是每個(gè)開發(fā)態(tài)實(shí)體又產(chǎn)生多個(gè)實(shí)例，且如果與云技術(shù)結(jié)合，這些實(shí)例數(shù)可以動態(tài)調(diào)整，故微服務(wù)架構(gòu)是一個(gè)“多個(gè)設(shè)計(jì)實(shí)體、多個(gè)開發(fā)實(shí)體、多個(gè)測試實(shí)體、多個(gè)運(yùn)行實(shí)體”的架構(gòu)。endprint

4 二得：可用性第一、非功能需求優(yōu)先

一個(gè)系統(tǒng)最重要的是可用性，可用性包括功能完備性、可維護(hù)性、可改進(jìn)性，失去了可用性，談?wù)撌裁雌渌际ヒ饬x，故在做架構(gòu)設(shè)計(jì)時(shí)，所有技術(shù)決策都要確保和增強(qiáng)系統(tǒng)可用性，違背了這一原則引入的技術(shù)決策都是有問題的，而微服務(wù)架構(gòu)使用不當(dāng)是會引入過多的復(fù)雜性的，此時(shí)是違背了上述原則，為了避免該問題，在E系統(tǒng)的微服務(wù)拆分時(shí)我們始終堅(jiān)持可用性第一、非功能需求優(yōu)先的原則，筆者認(rèn)為這個(gè)原則具有普適性，特別是對于微服務(wù)劃分有一定指導(dǎo)意義。

在這個(gè)原則的指導(dǎo)下，對一個(gè)應(yīng)用系統(tǒng)進(jìn)行微服務(wù)拆分應(yīng)該在兩個(gè)層面做出決定：

（1）是否可拆分？

（2）有沒有必要拆分？

如果把需求分為功能性需求和非功能需求，則第一個(gè)問題的答案取決于功能性需求，此時(shí)重點(diǎn)考慮如下要素：

業(yè)務(wù)獨(dú)立性

數(shù)據(jù)獨(dú)立性

技術(shù)獨(dú)立性

第二個(gè)問題的答案取決于非功能需求，此時(shí)重點(diǎn)考慮如下幾項(xiàng)要素：

可用性：功能完備性、可維護(hù)性、可改進(jìn)性

性能

穩(wěn)定性

先進(jìn)性

第一個(gè)層面的基礎(chǔ)上給出了一個(gè)潛在的微服務(wù)候選者列表，第二個(gè)方面的基礎(chǔ)上對候選者進(jìn)行過濾，給出了真正的微服務(wù)列表。

微服務(wù)能夠劃分到什么程度取決于業(yè)務(wù)需求，比如互聯(lián)網(wǎng)應(yīng)用的業(yè)務(wù)性質(zhì)決定了應(yīng)用之間比較獨(dú)立，那么這種應(yīng)用切分就比較徹底，適宜于切分成比較小的微服務(wù)，傳統(tǒng)企業(yè)應(yīng)用由于業(yè)務(wù)模塊之間有著千絲萬縷的聯(lián)系，很難切分出比較小的微服務(wù)，即功能性需求決定了一個(gè)應(yīng)用是否可以拆分。

微服務(wù)應(yīng)該劃分到什么程度取決于非功能需求，如果某次拆分對改進(jìn)系統(tǒng)的非功能需求沒有貢獻(xiàn)，就沒有必要拆分，也即非功能需求決定了有沒有必要拆分，說到底是非功能需求決定了一個(gè)應(yīng)用系統(tǒng)會拆分出什么樣的微服務(wù)、拆分出多少微服務(wù)。

實(shí)施微服務(wù)化時(shí)很自然地做法是看到一個(gè)應(yīng)用可以拆分就會繼續(xù)分下去，直到拆無可拆，這種做法是有害的。在操刀之前必須問自己：難道能拆就必須拆嗎？否！并不是具備拆分條件的就必須把它拆分出來。在進(jìn)行遺留系統(tǒng)的微服務(wù)化時(shí)，要堅(jiān)持非功能需求優(yōu)先的原則，盡管有時(shí)業(yè)務(wù)的性質(zhì)決定了其可以繼續(xù)拆分成更小粒度的微服務(wù)，但是如果這次拆分對改進(jìn)系統(tǒng)的非功能需求沒有貢獻(xiàn)，就沒有必要拆分，繼續(xù)拆分不但無益，反而會引入更多的復(fù)雜性，如更多的分布式事務(wù)、更多的遠(yuǎn)程調(diào)用、更多的故障點(diǎn)、更多的運(yùn)行維護(hù)困難。畢竟管理幾千個(gè)微服務(wù)和管理幾十個(gè)微服務(wù)其復(fù)雜性不在一個(gè)數(shù)量級，此時(shí)一定要保持清醒頭腦，時(shí)刻記得我們引入微服務(wù)架構(gòu)的目的是什么，一般我們引入微服務(wù)架構(gòu)并不是因?yàn)槠湎冗M(jìn)，而是因?yàn)槠淠軌蚪鉀Q某些問題。

E系統(tǒng)的業(yè)務(wù)中可以識別出很多相對獨(dú)立的業(yè)務(wù)，這些業(yè)務(wù)在功能上、數(shù)據(jù)上都相對獨(dú)立，具備設(shè)立微服務(wù)的基本條件，但是只能說是潛在的微服務(wù)，是否必須設(shè)立為微服務(wù)？個(gè)人認(rèn)為還是從業(yè)務(wù)發(fā)展需要、可維護(hù)性、可擴(kuò)展性角度考慮，可拆可不拆的盡量不拆分。假如在設(shè)計(jì)階段不對復(fù)雜性進(jìn)行控制，則我們可能得到了一個(gè)架構(gòu)更加先進(jìn)的E系統(tǒng)，但是它更加難以維護(hù)，系統(tǒng)的綜合使用效果會大打折扣。

5 三得：微服務(wù)大小和個(gè)數(shù)是偽命題

微服務(wù)的“微”容易使人迷惑，很多團(tuán)隊(duì)在爭論到底要切分到什么層次、到底有多微才是“對的”等等問題。在項(xiàng)目組內(nèi)部、在專家研討會上，就遇到不止一次就“到底要多大”“到底切分到什么程度”等問題發(fā)生爭論，每當(dāng)此時(shí)我都會感慨起名字很重要，如果我們認(rèn)識到微服務(wù)實(shí)際上僅僅是一種新的解耦方式，是一種組件，只不過在開發(fā)態(tài)、運(yùn)行態(tài)都有一定獨(dú)立性，是一種解耦比較徹底的多實(shí)體架構(gòu)，那么我們就會知道“到底要多大（才是對的）？”，“到底多少個(gè)（才算是微服務(wù)架構(gòu)）？”等問題都是偽命題，顆粒度、數(shù)量都不是微服務(wù)架構(gòu)的關(guān)鍵特征，微服務(wù)的大小、數(shù)量不應(yīng)是微服務(wù)架構(gòu)關(guān)心的，這些特征不應(yīng)該作為判定一個(gè)架構(gòu)是否是微服務(wù)架構(gòu)的標(biāo)準(zhǔn)、只要實(shí)現(xiàn)了“徹底的解耦”，即使拆分出的微服務(wù)很大、包含非常多的業(yè)務(wù)功能也是微服務(wù)架構(gòu)，為何不是呢？

可以采取反證法來說明這個(gè)問題：假設(shè)我們手上有一組很大的微服務(wù)，我們計(jì)劃要對其進(jìn)一步拆分，只要保持了業(yè)務(wù)功能解耦、數(shù)據(jù)解耦，我們隨時(shí)可以把它簡單地進(jìn)一步拆分，這樣做沒有引起任何技術(shù)路線、系統(tǒng)運(yùn)行機(jī)理、運(yùn)維方式上的變化，只是每個(gè)實(shí)體變得小了，那么為何僅僅因?yàn)閷?shí)體變小了就成了微服務(wù)架構(gòu)，而原來的不是微服務(wù)架構(gòu)？

5.1 微服務(wù)不宜拆的過細(xì)

在對E系統(tǒng)進(jìn)行拆分時(shí)，不止一次遇到這個(gè)問題，對于這個(gè)問題每次我都會回答：微服務(wù)架構(gòu)并不關(guān)心某個(gè)微服務(wù)的大小。

業(yè)界有的認(rèn)為微服務(wù)應(yīng)該拆分到領(lǐng)域?qū)ο蟮牧６?，甚至有的說要到100行代碼！這都是沒有堅(jiān)持可用性第一的原則造成的錯(cuò)誤觀點(diǎn)。

（1）在對傳統(tǒng)企業(yè)應(yīng)用進(jìn)行微服務(wù)劃分時(shí)，劃分到領(lǐng)域?qū)ο蟮淖龇ㄊ堑貌粌斒У?，首先如果劃分到領(lǐng)域?qū)ο髸斐煞浅６嗟奈⒎?wù)，比如E系統(tǒng)的業(yè)務(wù)非常復(fù)雜，領(lǐng)域?qū)ο筮_(dá)到1000多個(gè)，按照這個(gè)做法會有1000個(gè)微服務(wù)，盡管有很多工具支撐，開發(fā)、運(yùn)維這個(gè)數(shù)量級的微服務(wù)不在話下，但是總是造成了很大的運(yùn)維復(fù)雜性，請問引入這些復(fù)雜性的同時(shí)我們得到了什么好處？架構(gòu)更清晰了？只要正確地按照領(lǐng)域驅(qū)動的設(shè)計(jì)原理去做，即使不把領(lǐng)域?qū)ο螵?dú)立成微服務(wù)也可以做到架構(gòu)很清晰。

（2）領(lǐng)域驅(qū)動是一種業(yè)務(wù)分析方法論，不是架構(gòu)設(shè)計(jì)方法論，其沒有考慮到分布式事務(wù)、數(shù)據(jù)一致性、運(yùn)維監(jiān)控等架構(gòu)設(shè)計(jì)場景的需要。按照該方法論領(lǐng)域?qū)ο笾g是設(shè)計(jì)上、邏輯上實(shí)現(xiàn)了解耦的，但是并沒有考慮到一旦它們物理上（運(yùn)行態(tài)）也解耦時(shí)面臨的問題如何解決，故使用領(lǐng)域驅(qū)動方法論進(jìn)行業(yè)務(wù)分析是可以的，但是把它用于架構(gòu)設(shè)計(jì)領(lǐng)域則不適用。

在傳統(tǒng)企業(yè)應(yīng)用中，同時(shí)對多個(gè)領(lǐng)域?qū)ο蟛僮鞯慕灰追浅６啵热缭趯贤M(jìn)行操作時(shí)，可能會同時(shí)對訂單進(jìn)行操作，按照領(lǐng)域?qū)ο蟮耐ǔＷ龇?，僅僅是在合同對象的某個(gè)方法中調(diào)用了訂單對象的某個(gè)方法，這個(gè)操作是本地調(diào)用，如果把每個(gè)領(lǐng)域?qū)ο笞鳛橐粋€(gè)微服務(wù)，則該種調(diào)用變?yōu)檫h(yuǎn)程調(diào)用，這就引入如分布式事務(wù)、增加了故障點(diǎn)等等一系列始料未及的問題，這些問題并不是沒有辦法解決，但是架構(gòu)設(shè)計(jì)的原則是以最小代價(jià)解決問題，能用本地調(diào)用解決的，為何用遠(yuǎn)程調(diào)用？能用簡單方法做到的，為何用復(fù)雜的方法去做？endprint

歸根結(jié)底是微服務(wù)劃分不宜太細(xì)，把微服務(wù)劃分到領(lǐng)域?qū)ο蠹墑e是劃分的太細(xì)了。

（3）至于微服務(wù)要到100行代碼的觀點(diǎn)，不知哪個(gè)平臺堅(jiān)持了這個(gè)原則。

5.2 不要追求微服務(wù)個(gè)數(shù)

除了對微服務(wù)大小產(chǎn)生迷惑外，也有人會關(guān)心微服務(wù)個(gè)數(shù)。這個(gè)問題也偶爾也產(chǎn)生過爭論，基本上可以把上面的回答復(fù)制下來回答這個(gè)問題：

微服務(wù)架構(gòu)本質(zhì)上是“一種新的解耦方式”，個(gè)數(shù)不是微服務(wù)架構(gòu)的關(guān)鍵特征，多少個(gè)微服務(wù)更不是微服務(wù)架構(gòu)關(guān)心的，只要按照規(guī)定方式實(shí)現(xiàn)了“徹底的解耦”，即使僅有幾個(gè)微服務(wù)也是微服務(wù)架構(gòu)，為何不是呢？

盡管不能因?yàn)槲⒎?wù)個(gè)數(shù)少就懷疑其是假的微服務(wù)架構(gòu)，但是討論“多少個(gè)微服是合適的”這個(gè)問題是有意義的。

每個(gè)微服務(wù)實(shí)例都是一組獨(dú)立的運(yùn)維單元，盡管微服務(wù)架構(gòu)必然伴隨著DevOPs，但是運(yùn)維單元越多，復(fù)雜性越大，運(yùn)維越困難這個(gè)事實(shí)是不爭的。因此微服務(wù)的數(shù)量當(dāng)然是越少越好，前提是解決了我們的問題，達(dá)到了目的。即使你有阿里那樣的黃金團(tuán)隊(duì)，但為何非要給自己找麻煩呢？

6 四得：微服務(wù)化是組件化的一種形式

架構(gòu)設(shè)計(jì)的通常做法就是“分而治之”，化復(fù)雜的問題為多個(gè)簡單的小問題，再逐個(gè)擊破，微服務(wù)架構(gòu)是這種思想的一個(gè)生動體現(xiàn)，這種思想的另一個(gè)重要實(shí)踐是組件化設(shè)計(jì)。

從組件化的角度來看微服務(wù)架構(gòu)，可以發(fā)現(xiàn)微服務(wù)是一個(gè)組件集合，只不過該種組件集合是一個(gè)獨(dú)立的設(shè)計(jì)、開發(fā)、測試、運(yùn)維實(shí)體。組件局限在一個(gè)邏輯層內(nèi)，一般不跨越層，但是微服務(wù)是跨越多個(gè)層。

組件劃分一般先水平分層，再層內(nèi)切分。微服務(wù)劃分則在組件劃分的基礎(chǔ)上還要多做一步工作：先水平劃分，再層內(nèi)切分，然后再根據(jù)功能把組件組合成一個(gè)集合，該集合即為微服務(wù)，其可以跨越多個(gè)層，向外提供一組服務(wù)接口。

6.1 從邏輯分層角度認(rèn)識微服務(wù)和組件的關(guān)系

E系統(tǒng)分為展現(xiàn)層、應(yīng)用服務(wù)層、業(yè)務(wù)邏輯層、基礎(chǔ)業(yè)務(wù)服務(wù)層、技術(shù)服務(wù)層、基礎(chǔ)架構(gòu)服務(wù)層，同層內(nèi)部再劃分為一個(gè)個(gè)組件。

E系統(tǒng)的組件分為技術(shù)型組件和業(yè)務(wù)型組件，同樣邏輯層也分為技術(shù)性層和業(yè)務(wù)性層：展現(xiàn)層、應(yīng)用服務(wù)層、技術(shù)服務(wù)層、基礎(chǔ)架構(gòu)服務(wù)層是技術(shù)性的層，里面分布的是技術(shù)性組件，一般不會隨著業(yè)務(wù)變化而變化；業(yè)務(wù)邏輯層、基礎(chǔ)業(yè)務(wù)服務(wù)層是業(yè)務(wù)性質(zhì)的層，里面容納的是功能組件，是領(lǐng)域?qū)ο?，可以認(rèn)為E系統(tǒng)的全部業(yè)務(wù)在這兩個(gè)層中；理論上說，業(yè)務(wù)發(fā)生變化，不會引起技術(shù)性層中組件的變化，同樣，替換技術(shù)層中的組件，也不會引起業(yè)務(wù)層發(fā)生變化。

6.1.1 沒有微服務(wù)化時(shí)的邏輯分層模型

圖3是簡化后的沒有微服務(wù)化時(shí)的E系統(tǒng)組件劃分圖。

6.1.2 微服務(wù)化后的邏輯分層模型

微服務(wù)與組件的區(qū)別在于微服務(wù)可以跨越多個(gè)邏輯層，微服務(wù)不以復(fù)用為目的，相反，為了達(dá)到高內(nèi)聚低耦合的目標(biāo)，微服務(wù)必須集成自己需要的各個(gè)組件，使得同一個(gè)組件在多個(gè)微服務(wù)中重復(fù)。

微服務(wù)同時(shí)容納業(yè)務(wù)型組件和技術(shù)型組件，其容納的業(yè)務(wù)型組件決定了其對外提供的服務(wù)，不同微服務(wù)之間的區(qū)別在于其業(yè)務(wù)邏輯層和基礎(chǔ)業(yè)務(wù)服務(wù)層集成的業(yè)務(wù)型組件是不同的，但是其他層的技術(shù)型組件則基本相同，即同一個(gè)技術(shù)組件在不同微服務(wù)中多次被集成，業(yè)務(wù)組件則每個(gè)微服務(wù)不同，換句話說微服務(wù)之所以能夠提供不同的功能，是因?yàn)槠淙菁{了不同的業(yè)務(wù)型組件。

圖4是E系統(tǒng)的微服務(wù)和組件關(guān)系示意圖。

區(qū)別于一般互聯(lián)網(wǎng)平臺，E系統(tǒng)的業(yè)務(wù)是典型的企業(yè)應(yīng)用，業(yè)務(wù)耦合數(shù)據(jù)耦合比較緊密，故E系統(tǒng)的微服務(wù)沒有遵循一個(gè)微服務(wù)一個(gè)數(shù)據(jù)庫的流行做法，即E系統(tǒng)的微服務(wù)僅包含了應(yīng)用服務(wù)層、業(yè)務(wù)邏輯層、基礎(chǔ)業(yè)務(wù)服務(wù)層，技術(shù)服務(wù)層，而沒有包含基礎(chǔ)架構(gòu)服務(wù)層。

6.2 微服務(wù)、系統(tǒng)、子系統(tǒng)與組件

6.2.1 微服務(wù)與組件

微服務(wù)就是組件的集合，也可以認(rèn)為是一種比較大的組件，其跨越多個(gè)邏輯層，同時(shí)包含了技術(shù)型組件和業(yè)務(wù)型組件，微服務(wù)提供的服務(wù)是業(yè)務(wù)型組件決定的，技術(shù)型組件輔助業(yè)務(wù)型組件提供了這些服務(wù)。

6.2.2 微服務(wù)與子系統(tǒng)

子系統(tǒng)仍然是傳統(tǒng)單體應(yīng)用架構(gòu)下的概念，第3節(jié)中關(guān)于單體架構(gòu)和微服務(wù)架構(gòu)之間的區(qū)別，也描述了子系統(tǒng)和微服務(wù)之間的區(qū)別：子系統(tǒng)雖然是一種解耦，但是多個(gè)子系統(tǒng)之間在分析、設(shè)計(jì)、開發(fā)、測試、運(yùn)維中都是在同一個(gè)實(shí)體中的，子系統(tǒng)之間不會作為獨(dú)立的運(yùn)維單元對待。而微服務(wù)則是在分析、設(shè)計(jì)、開發(fā)、測試、運(yùn)行過程中可以全程保持獨(dú)立，作為一個(gè)獨(dú)立的單元對待。

6.2.3 微服務(wù)與系統(tǒng)

微服務(wù)之間會使用同一組基礎(chǔ)架構(gòu)層的組件，如分布式消息隊(duì)列、分布式會話組件、分布式緩存組件等，且之間的通訊協(xié)議是比較規(guī)范的，一般提供遵循Restful風(fēng)格的接口；而系統(tǒng)之間一般是完全獨(dú)立的，不會共享組件，且之間的通訊協(xié)議是相當(dāng)豐富多彩。

7 五得：微服務(wù)劃分的其他原則

（1）一個(gè)微服務(wù)要實(shí)現(xiàn)一個(gè)比較獨(dú)立的業(yè)務(wù)，具有清晰的邊界，同時(shí)微服務(wù)應(yīng)該足夠大，盡量把業(yè)務(wù)變化包裹在自己的邊界之內(nèi)。

（2）盡量避免微服務(wù)之間的相互調(diào)用，避免分布式事務(wù)，一個(gè)微服務(wù)盡量提供一個(gè)完整的功能，不要把微服務(wù)之間的調(diào)用作為常態(tài)，要把其作為不得已而為之的選擇。

（3）微服務(wù)要自我完備，包含自己的各種技術(shù)上的依賴和第三方包，微服務(wù)的目的不是實(shí)現(xiàn)代碼復(fù)用，而是分而治之：把一個(gè)大的應(yīng)用拆分為幾個(gè)小的應(yīng)用。

（4）微服務(wù)應(yīng)該作為獨(dú)立的設(shè)計(jì)、開發(fā)、部署、運(yùn)維單元，獨(dú)立演進(jìn)而不影響其他微服務(wù)。

（5）不追求微服務(wù)數(shù)量，能少則少。

（6）迭代式前進(jìn)，微服務(wù)化是一個(gè)迭代的過程，不斷迭代，逐漸逼近最優(yōu)，而不是一步到位（實(shí)際上無法確定什么是最優(yōu)，只有不斷實(shí)踐、觀察、再實(shí)踐，通過這種迭代逼近最優(yōu)）endprint

8 六得：中間路線是最合適的架構(gòu)

E系統(tǒng)在微服務(wù)化過程中存在四種狀態(tài)：

（1）單體應(yīng)用狀態(tài)，是系統(tǒng)的原始狀態(tài)

（2）單體應(yīng)用+一組非功能型微服務(wù)狀態(tài)

這組微服務(wù)是按照非功能需求優(yōu)先的原則從遺留系統(tǒng)中拆分出來的，這個(gè)單體應(yīng)用自然是從遺留中拆分出微服務(wù)后剩下的沒有必要（或者暫時(shí)沒有必要）拆分的部分

（3）一組功能型微服務(wù)+一組非功能型微服務(wù)狀態(tài)

如果是從零開始構(gòu)建一個(gè)微服務(wù)架構(gòu)的系統(tǒng)，則建議是“一個(gè)或幾個(gè)大的微服務(wù)（實(shí)現(xiàn)了絕大多數(shù)業(yè)務(wù)，稱功能型微服務(wù)）”+“一系列小的微服務(wù)（出于非功能需求而拆分出來的，稱非功能型微服務(wù)）”，這樣更加簡單，避免了復(fù)雜性。

如果是從遺留系統(tǒng)進(jìn)行微服務(wù)化，此時(shí)因?yàn)榉枪δ苄枨笠呀?jīng)得到滿足，繼續(xù)對遺留的單體應(yīng)用拆分的理由可能是為了使得系統(tǒng)架構(gòu)更加統(tǒng)一，簡化技術(shù)路線，消滅單體應(yīng)用。盡管可以對遺留系統(tǒng)繼續(xù)拆分，但為了避免引入過多的復(fù)雜性，建議對遺留的單體進(jìn)行比較粗粒度的拆分，消滅單體即可。

（4）能拆盡拆后得到的一群微服務(wù)

最純的微服務(wù)架構(gòu)狀態(tài)，筆者認(rèn)為沒有必要追求。

第三、第四兩種狀態(tài)可以認(rèn)為是標(biāo)準(zhǔn)的微服務(wù)架構(gòu)了，實(shí)踐中筆者認(rèn)為對遺留系統(tǒng)來說，中間路線是最合適的架構(gòu)，如果對一個(gè)已經(jīng)存在的系統(tǒng)做微服務(wù)化改造，最合適的結(jié)果是第二或第三兩種狀態(tài)；如果是從零開始構(gòu)建一個(gè)微服務(wù)架構(gòu)的系統(tǒng)，則建議達(dá)到第三種狀態(tài)即可。

實(shí)踐中E系統(tǒng)在達(dá)到第三種狀態(tài)即停止進(jìn)一步切分，得出E系統(tǒng)中有兩類微服務(wù)：

（1）功能型微服務(wù)：包含一個(gè)完整、獨(dú)立的業(yè)務(wù)功能的一組微服務(wù)，比較大。

（2）非功能型微服務(wù)：出于性能、穩(wěn)定性、可維護(hù)性、可擴(kuò)展性等非功能需要而設(shè)立的一組微服務(wù)，如（舉例）：

投標(biāo)文件上傳微服務(wù)：在大批次招投標(biāo)業(yè)務(wù)時(shí)，要求規(guī)定時(shí)間內(nèi)上傳5TB數(shù)據(jù)，性能要求高。

解密微服務(wù)：在2小時(shí)內(nèi)完成2.4TB投標(biāo)文的解密，性能要求極高。

查詢開標(biāo)結(jié)果微服務(wù)：在開展大批次招投標(biāo)業(yè)務(wù)時(shí)瞬時(shí)流量非常大，性能要求高，需要彈性擴(kuò)展。

其中第二種微服務(wù)是真正有價(jià)值、有必要存在的微服務(wù)，是這次微服務(wù)化改造的重點(diǎn)；對于第一種微服務(wù)，綜合考慮各方因素項(xiàng)目組對該類微服務(wù)僅做了比較粗粒度的劃分。

9 結(jié)束語

本人非常贊同“架構(gòu)設(shè)計(jì)是做出一系列決策的過程”這個(gè)觀點(diǎn)，所謂決策，就有“趨之若鶩、甘之如飴”的主動選擇，也有“不得不做、兩害取輕”的被動選擇。在E系統(tǒng)的架構(gòu)設(shè)計(jì)過程中，本人迫切感到需要區(qū)分這兩種選擇，比如選擇微服務(wù)架構(gòu)就屬于后者，是因?yàn)樽鳛閱误w應(yīng)用的E1.0已經(jīng)不能滿足需要，使得我們不得不選擇微服務(wù)架構(gòu)，這是一個(gè)“不得不”做出的選擇，在利用其解決問題的同時(shí)，應(yīng)該非常小心地避免其帶來的副作用，在筆者看來其最大的副作用就是引入了過多的復(fù)雜性，因此在實(shí)施微服務(wù)化改造時(shí)要注意努力減少復(fù)雜性。網(wǎng)上有人談?chuàng)肀⒎?wù)架構(gòu)，我則要說：客觀對待微服務(wù)架構(gòu)。

微服務(wù)是一劑良藥，說它是良藥，就意味著它不是佳肴美味，不能當(dāng)飯吃，有病才吃無病遠(yuǎn)之，謹(jǐn)記關(guān)于分布式架構(gòu)的第一個(gè)原則：能不采用分布式的就不采用分布式。

參考文獻(xiàn)：

[1]李楠.計(jì)算機(jī)安全技術(shù)在電子商務(wù)中的應(yīng)用[J].科技創(chuàng)新與應(yīng)用，2015（06）：55.

[2]宋大為，侯婷婷，顧松敏，等.數(shù)據(jù)挖掘技術(shù)在電子商務(wù)領(lǐng)域的應(yīng)用研究[J].科技創(chuàng)新與應(yīng)用，2016（05）：87.

[3]尹紹捷.移動互聯(lián)網(wǎng)技術(shù)與電子商務(wù)[J].科技創(chuàng)新與應(yīng)用，2015（30）：89.endprint