微服務(wù)規(guī)劃、微服務(wù)構(gòu)建、微服務(wù)協(xié)同、微服務(wù)測試、微服務(wù)治理、微服務(wù)下線等是企業(yè)采用微服務(wù)必須面對的微服務(wù)生命周期管理問題。我們討論過微服務(wù)治理的問題，由于一些原因未能整理微服務(wù)拆分、微服務(wù)設(shè)計、微服務(wù)構(gòu)建等相關(guān)內(nèi)容。網(wǎng)上對微服務(wù)的討論更多是微服務(wù)開發(fā)框架的使用，較少深入討論微服務(wù)拆分、設(shè)計和構(gòu)建。我們提出過采用主數(shù)據(jù)思想來構(gòu)建微服務(wù)體系，目前也有采用DDD方式來設(shè)計微服務(wù)的，這里我們探討下微服務(wù)構(gòu)建的一些思路和方法，以期拋磚引玉，帶來更多更深入的探討。
采用微服務(wù)，首先要有明確的目的，有清晰的認(rèn)知。微服務(wù)并不是放之四海而皆準(zhǔn)的理論，有其適用范圍和場景。如果用單體應(yīng)用能輕松解決的問題就沒必要用微服務(wù)架構(gòu)。在遇到有分布式、彈性擴(kuò)展等需求的情況，才需要考慮微服務(wù)架構(gòu)。一個微服務(wù)我們可以認(rèn)為其是一個小的單體應(yīng)用。在有很多單體應(yīng)用之間需要通信、協(xié)同的情況下，或者通過單體應(yīng)用之間的集成無法滿足業(yè)務(wù)性能要求，需要重構(gòu)業(yè)務(wù)應(yīng)用系統(tǒng)時，才需要考慮采用微服務(wù)架構(gòu)。
我們也提到過，微服務(wù)意在重構(gòu)！并且通常在大中型企業(yè)有眾多的單體業(yè)務(wù)系統(tǒng)情況下，各單體業(yè)務(wù)應(yīng)用集成可能成為一個問題的時候，需要考慮采用微服務(wù)架構(gòu)重構(gòu)業(yè)務(wù)應(yīng)用。由于微服務(wù)架構(gòu)體系需要眾多的基礎(chǔ)設(shè)施平臺和基礎(chǔ)組件支撐，才能發(fā)揮微服務(wù)架構(gòu)的優(yōu)勢，所以一些小公司或者沒有計劃進(jìn)行大規(guī)模改造的情況下，采用微服務(wù)可能無法展現(xiàn)其價值，并且管理任務(wù)有可能更多、更繁瑣。
服務(wù)化的目的在于重用，微服務(wù)也是一樣。其實無論函數(shù)化、模塊化、組件化、服務(wù)化等重要目的在于共享、重用。技術(shù)經(jīng)過若干年后總會以另外一種面貌重現(xiàn)，就像當(dāng)前的Serverless 函數(shù)編程，原來單體應(yīng)用的函數(shù)放到云端，加個Serverless的概念馬上就高大上了。微服務(wù)還有重要一點在于其分布式彈性，微服務(wù)實例數(shù)彈性伸縮，可以和容器平臺結(jié)合，利用容器彈性伸縮的特性，實現(xiàn)微服務(wù)的彈性，快速響應(yīng)業(yè)務(wù)變化需求。
采用微服務(wù)往往也是因為其輕量，可以快速迭代，即時響應(yīng)新業(yè)務(wù)需求，快速開發(fā)部署微服務(wù)應(yīng)用，在搶占市場的同時可以持續(xù)的迭代和完善。所以通常采用微服務(wù)是以業(yè)務(wù)需求變化快的場景為起始，比如活動促銷等，然后逐步推廣到其他業(yè)務(wù)場景。
跟很多廠商交流微服務(wù)，基本上都在談SpringCloud、Dubbo，談到用什么理論或方法來指導(dǎo)微服務(wù)的設(shè)計和構(gòu)建時，幾乎沒有廠商關(guān)注這些，感覺大部分人也就是用微服務(wù)開發(fā)框架去寫代碼，至于微服務(wù)設(shè)計和構(gòu)建，則基本上還不具備相應(yīng)的能力。沒有理論指導(dǎo)，每個人理解的微服務(wù)可能都不一樣，所以實現(xiàn)出來的微服務(wù)也就五法八門、千奇百怪了。
都知道微服務(wù)是一種架構(gòu)方式，但怎么架構(gòu)？什么是合適的微服務(wù)架構(gòu)？可能就仁者見仁、智者見智了。如果僅知道SpringCloud，那也就是一個編碼人員，不具備微服務(wù)設(shè)計和構(gòu)建的能力。微服務(wù)設(shè)計和構(gòu)建則需要相應(yīng)的理論功底，比如比較流行的DDD領(lǐng)域驅(qū)動設(shè)計方法，但領(lǐng)域驅(qū)動設(shè)計側(cè)重業(yè)務(wù)領(lǐng)域，而且整個體系復(fù)雜，業(yè)務(wù)領(lǐng)域?qū)＜宜O(shè)計的領(lǐng)域模型并不一定適合技術(shù)實現(xiàn)，需要技術(shù)人員的二次建模，最重要的是數(shù)據(jù)的存儲未充分考慮。微服務(wù)可能根據(jù)數(shù)據(jù)的量、請求負(fù)載的量、數(shù)據(jù)的類型、來源等采用不同的存儲方法，可能需要考慮分庫、分表、分區(qū)、物化視圖等不同的方式，也可能隨著業(yè)務(wù)數(shù)據(jù)的變化而更新微服務(wù)的存儲和實現(xiàn)。我們認(rèn)為這才是微服務(wù)設(shè)計和構(gòu)建需要重點考慮的方面。至于用什么工具開發(fā)，那是次要的選擇。
如果了解主數(shù)據(jù)管理（MDM）的話，我們建議采用主數(shù)據(jù)的思想來構(gòu)建和設(shè)計微服務(wù)。主數(shù)據(jù)強(qiáng)調(diào)唯一數(shù)據(jù)來源。主數(shù)據(jù)管理是實現(xiàn)主數(shù)據(jù)集成和治理，主數(shù)據(jù)是數(shù)據(jù)的骨架，其他數(shù)據(jù)是血肉，它們共同構(gòu)成一個完整的企業(yè)數(shù)據(jù)整體。主數(shù)據(jù)并不是不關(guān)注業(yè)務(wù)，恰恰是從業(yè)務(wù)流程梳理開始，只不過我們不是構(gòu)建一套主數(shù)據(jù)管理系統(tǒng)，而是以主數(shù)據(jù)的思路來構(gòu)建微服務(wù)數(shù)據(jù)模型和存儲模型。談主數(shù)據(jù)可能需要了解通用數(shù)據(jù)模型CDM，它非常有助于我們構(gòu)建適合的微服務(wù)數(shù)據(jù)模型。
當(dāng)然，我們覺得兩種方法結(jié)合可能會更好一些。目前只是理論上的思路，具體還缺少實踐，所以也希望能充分和有這方面考慮的團(tuán)隊或個人深入交流。
微服務(wù)重點不在采用什么語言或什么開發(fā)工具，我們曾經(jīng)討論過SpringCloud/SpringBoot不是微服務(wù)，SpringCloud/SpringBoot開發(fā)的服務(wù)也不一定就是微服務(wù)。微服務(wù)是一個從業(yè)務(wù)層到數(shù)據(jù)層到存儲層都是相對獨立完成特定功能的一個單元，所以我們經(jīng)常聽到拆庫、拆表的討論，但缺指導(dǎo)性的一些原則和方法論。微服務(wù)重點在數(shù)據(jù)，因此采用微服務(wù)和數(shù)據(jù)治理能力密切相關(guān)。數(shù)據(jù)標(biāo)準(zhǔn)、數(shù)據(jù)安全、數(shù)據(jù)所屬、數(shù)據(jù)模型、數(shù)據(jù)持久化等直接影響著微服務(wù)的質(zhì)量和實施難度。什么時候數(shù)據(jù)存放數(shù)據(jù)庫？選擇什么數(shù)據(jù)庫？什么時候需要分區(qū)表?什么時候分表？什么時候需要分庫？非結(jié)構(gòu)化數(shù)據(jù)如何處理？……這些不是選擇一個開發(fā)框架就能解決的問題，這才是微服務(wù)設(shè)計和構(gòu)建的重點。
通常情況下需要考慮由原子微服務(wù)來準(zhǔn)備數(shù)據(jù)。不同的場景數(shù)據(jù)準(zhǔn)備的方式可能是不一樣的。不過在當(dāng)前的大多數(shù)業(yè)務(wù)場景下，實時及準(zhǔn)實時的需求越來越多，所以數(shù)據(jù)準(zhǔn)備需要在原子微服務(wù)中以實時或準(zhǔn)實時的方式準(zhǔn)備好?？梢允歉咝У闹鲃荧@取，也可以是被動的實時更新，但要確保數(shù)據(jù)的正確、準(zhǔn)確。而關(guān)于用業(yè)務(wù)微服務(wù)和應(yīng)用微服務(wù)封裝業(yè)務(wù)邏輯和應(yīng)用組件協(xié)同邏輯，我們將在下一篇《微服務(wù)協(xié)同》中詳細(xì)討論。
采用微服務(wù)在梳理完業(yè)務(wù)應(yīng)用流程之后，首先就需要考慮提取基礎(chǔ)公共組件。這些組件是每個應(yīng)用系統(tǒng)都可能需要用到的，所以這些組件需要首先提取出來。比如日志服務(wù)、監(jiān)控服務(wù)、告警服務(wù)、統(tǒng)計服務(wù)、權(quán)限服務(wù)、認(rèn)證服務(wù)等。采用微服務(wù)架構(gòu)還會涉及微服務(wù)注冊發(fā)現(xiàn)、微服務(wù)配置、微服務(wù)網(wǎng)關(guān)等。這些服務(wù)通常也有開源的組件，可以協(xié)助構(gòu)建整個微服務(wù)體系基礎(chǔ)組件服務(wù)。但開源的畢竟只是在技術(shù)上可行，應(yīng)用于實際的業(yè)務(wù)環(huán)境還有不少的工作要做，后期技術(shù)支持也是個需要認(rèn)真考慮的事項。
在提取完非業(yè)務(wù)性功能組件服務(wù)之后，可能需要考慮業(yè)務(wù)性功能組件，比如公共數(shù)據(jù)字典服務(wù)、數(shù)據(jù)標(biāo)準(zhǔn)轉(zhuǎn)換服務(wù)、數(shù)據(jù)分發(fā)規(guī)則服務(wù)等等。這些服務(wù)和整個業(yè)務(wù)微服務(wù)設(shè)計架構(gòu)緊密相關(guān)，是其他業(yè)務(wù)微服務(wù)需要共享使用的，提取這些微服務(wù)將有助于快速的構(gòu)建其他業(yè)務(wù)微服務(wù)，快速敏捷的推進(jìn)微服務(wù)建設(shè)。
五、 基礎(chǔ)設(shè)施支撐
微服務(wù)不是開發(fā)幾個所謂的微服務(wù)就ok了，它需要眾多的基礎(chǔ)設(shè)施支撐才能更好的體現(xiàn)微服務(wù)的價值。微服務(wù)的開發(fā)、測試、部署、治理、運維等整個生命周期過程都需要各種設(shè)施的支持。比如基礎(chǔ)設(shè)施資源平臺，可以提供虛擬機(jī)、存儲等資源服務(wù)。數(shù)據(jù)治理平臺在設(shè)計構(gòu)建微服務(wù)時有相應(yīng)的數(shù)據(jù)標(biāo)準(zhǔn)和數(shù)據(jù)安全等支持。服務(wù)管控平臺則提供微服務(wù)的部署、運營管理。接口管理平臺提供微服務(wù)對內(nèi)對外的標(biāo)準(zhǔn)API服務(wù)等等。
微服務(wù)意在重構(gòu)，并不是為了某一個應(yīng)用系統(tǒng)，而是要考慮企業(yè)內(nèi)的所有應(yīng)用系統(tǒng)，這些應(yīng)用系統(tǒng)的公共的服務(wù)，首先就是共享，這是重構(gòu)的意義所在。
我們想強(qiáng)調(diào)的是，微服務(wù)設(shè)計和構(gòu)建不是一步到位的。它是一個持續(xù)構(gòu)建、持續(xù)優(yōu)化的迭代過程。就像前面我們提到的，隨著數(shù)據(jù)量的變化，微服務(wù)的實現(xiàn)可能需要優(yōu)化，這是一個迭代的過程。數(shù)據(jù)量小的情況下可以一個庫一張表，但數(shù)據(jù)量巨大的情況可能需要考慮分表、分庫，甚至分區(qū)域數(shù)據(jù)中心。數(shù)據(jù)物理存儲模型的改變必然導(dǎo)致微服務(wù)實現(xiàn)的變化。還有就是數(shù)據(jù)來源的變化，微服務(wù)協(xié)同的變化等都會帶來微服務(wù)實現(xiàn)的調(diào)整。
微服務(wù)初始實現(xiàn)的時候可能也就幾個、十幾個或幾十個微服務(wù)。不過在重構(gòu)第二個業(yè)務(wù)系統(tǒng)的時候就會簡單些，公共的組件服務(wù)不需要再構(gòu)建了，直接可以使用。關(guān)注的重點是業(yè)務(wù)邏輯在業(yè)務(wù)微服務(wù)中的實現(xiàn)，公共的能力比如日志、配置、權(quán)限等只需要按照標(biāo)準(zhǔn)的服務(wù)接口調(diào)用相應(yīng)的服務(wù)就可以了。還有一些公共的業(yè)務(wù)微服務(wù)組件可以共享，比如數(shù)據(jù)字典服務(wù)、一些公共的服務(wù)比如客戶服務(wù)、產(chǎn)品服務(wù)、賬戶服務(wù)等。所以隨著微服務(wù)構(gòu)建的增多，在重構(gòu)一個應(yīng)用系統(tǒng)時將會越來越容易，越來越便捷，越來越快速，越來越敏捷。
其實我們覺得微服務(wù)的構(gòu)建過程也會符合二八規(guī)則，前期做80%的工作可能只實現(xiàn)了20%的業(yè)務(wù)需求，但隨著量的增加，后期20%的工作就可以實現(xiàn)80%的業(yè)務(wù)需求。這就是服務(wù)共享的收益。
到后期，也許就沒有原子微服務(wù)的構(gòu)建需求，更多的是業(yè)務(wù)應(yīng)用微服務(wù)的構(gòu)建，在一個業(yè)務(wù)需求提出后，選擇合適的原子微服務(wù)或業(yè)務(wù)微服務(wù)通過流程配置就可以快速的發(fā)布部署，真正實現(xiàn)對業(yè)務(wù)需求的敏捷響應(yīng)。
