3.2.3技術(shù)儲(chǔ)備

　　微服務(wù)學(xué)習(xí)導(dǎo)航和微服務(wù)周邊技術(shù)棧。周邊技術(shù)棧包括領(lǐng)域驅(qū)動(dòng)涉及，持續(xù)交付，分布式至少，負(fù)載均衡，CAP理論，緩存原理，DevOps和容器化技術(shù)。

3.2.4團(tuán)隊(duì)規(guī)模評(píng)估

　　楊波在給微服務(wù)的開發(fā)團(tuán)隊(duì)規(guī)劃時(shí)候給了一個(gè)百人左右的大概預(yù)估，至于到底需要多少開發(fā)人員就沒有細(xì)說，可能作者本身呆過的公司都是大廠，對(duì)人力成本控制沒有那么大的包袱，對(duì)于中小企業(yè)，人力是最貴的成本。如果要一定要上微服務(wù)，該怎么辦？

　　對(duì)于微服務(wù)的團(tuán)隊(duì)規(guī)模眾說紛紜，有的說要百來號(hào)人；有的說需要精兵10人左右；有的說和人數(shù)沒有關(guān)系，只和業(yè)務(wù)有關(guān)；有的說一個(gè)懂微服務(wù)的架構(gòu)師也能搞定。這些說法都比較籠統(tǒng)，如果你想上微服務(wù)，人力評(píng)估包括人力、能力、人數(shù)等等，這些因素還是非常重要的，畢竟成本才是商業(yè)的本質(zhì)，有可能不客觀的規(guī)劃會(huì)導(dǎo)致項(xiàng)目的潰敗。

　　對(duì)于微服務(wù)的團(tuán)隊(duì)規(guī)模是哪些方面決定的呢？我覺得至少要從以下兩個(gè)維度來評(píng)估：

業(yè)務(wù)規(guī)模：如果你們的業(yè)務(wù)架構(gòu)非常復(fù)雜，有倉(cāng)儲(chǔ)系統(tǒng)開發(fā)，ERP系統(tǒng)，OA系統(tǒng)，訂單系統(tǒng)等等，業(yè)務(wù)越多，需求人數(shù)越多(這里人數(shù)指的都是后臺(tái)開發(fā)人數(shù))。

技術(shù)能力：另外，別忘了非功能性的開發(fā)，比如API網(wǎng)關(guān)，服務(wù)跟蹤、治理等也是需要人去開發(fā)和維護(hù)的，這些非功能性的核心組件需要多少人，由于沒有完整的開發(fā)經(jīng)驗(yàn)，加上個(gè)別組件，比如跟蹤系統(tǒng)，開發(fā)的程度可深可淺，開發(fā)周期可長(zhǎng)可短，以目前個(gè)人的經(jīng)驗(yàn)還無法給與合理的建議?？赡芘Ｈ?個(gè)人兩周就夠了，也可能高級(jí)開發(fā)2個(gè)人，一人分工三個(gè)核心組件，兩周也夠用。或者架構(gòu)外包，只要交接的人能跟上，也是一種解決方案。

　　總結(jié)：1個(gè)精通微服務(wù)落地經(jīng)驗(yàn)的架構(gòu)師是必不可少的，圍繞架構(gòu)師周邊一幫高級(jí)開發(fā)，按根據(jù)實(shí)際業(yè)務(wù)來確定，一般一個(gè)開發(fā)負(fù)責(zé)2-3個(gè)核心模塊，不宜太多，比如目前核心模塊有8個(gè)，對(duì)應(yīng)人數(shù)配置大概在3-4個(gè)左右。

3.3轉(zhuǎn)微服務(wù)風(fēng)險(xiǎn)評(píng)估

3.3.1重寫面廣

　　由于是架構(gòu)級(jí)別的調(diào)整，之前能保留下來的大部分是解耦比較好的代碼，比如前端代碼，采集服務(wù)代碼，部分業(yè)務(wù)邏輯代碼，所以對(duì)現(xiàn)有框架沖擊面比較大。

3.3.2復(fù)雜度高

　　因?yàn)槲⒎?wù)是一種觀念和思想，又是新近技術(shù)，本身就有各種架構(gòu)實(shí)現(xiàn)方式和技術(shù)解決方案。所以對(duì)技術(shù)人員來說，對(duì)比選型本身就是一個(gè)考驗(yàn)。加上本身涉及的技術(shù)面就比較廣，所以復(fù)雜度和門檻相對(duì)比較高。

但是該技術(shù)發(fā)源于亞馬遜，經(jīng)過近些年的發(fā)展，雖然還在發(fā)展，但是已經(jīng)相對(duì)成熟。

3.3.3人員配置

　　微服務(wù)架構(gòu)工作量主要集中在后端，對(duì)后端開發(fā)人員的技術(shù)級(jí)別有較高的要求，主要是對(duì)微服務(wù)原理和開源組件的熟悉上，同時(shí)需要具備整體的微服務(wù)的意識(shí)。暫時(shí)不具備整體微服務(wù)開發(fā)意識(shí)和經(jīng)驗(yàn)，需要通過培訓(xùn)后進(jìn)行轉(zhuǎn)型升級(jí)。

3.3.4合作方式

　　如果采用借助外部架構(gòu)力量來助推架構(gòu)升級(jí)，和架構(gòu)單位的合作就不是簡(jiǎn)單的外包，涉及的面會(huì)變得比較廣，在完全交接過來之前，周期會(huì)比較長(zhǎng)。包括對(duì)我們業(yè)務(wù)架構(gòu)的深入了解，然后根據(jù)業(yè)務(wù)架構(gòu)繪制可靠技術(shù)架構(gòu)藍(lán)圖，再根據(jù)技術(shù)藍(lán)圖進(jìn)行落地實(shí)施(不建議只提供架構(gòu)方案而由其他單位實(shí)施落地)，包括新系統(tǒng)的開發(fā)，舊系統(tǒng)的升級(jí)，當(dāng)然這種升級(jí)是平滑過度的，對(duì)業(yè)務(wù)窗口并不會(huì)產(chǎn)生影響。

3.4合理的拆分姿勢(shì)

　　如何正確拆分？這里正確指的是合理，因?yàn)闆]有絕對(duì)的標(biāo)準(zhǔn)。按照前人的經(jīng)驗(yàn)可以分為縱向和橫向兩種劃分方法：

3.4.1縱向拆分

　　是從業(yè)務(wù)維度進(jìn)行拆分。標(biāo)準(zhǔn)是按照業(yè)務(wù)的關(guān)聯(lián)程度來決定，關(guān)聯(lián)比較密切的業(yè)務(wù)適合拆分為一個(gè)微服務(wù)，而功能相對(duì)比較獨(dú)立的業(yè)務(wù)適合單獨(dú)拆分為一個(gè)微服務(wù)，比如上圖中的訂單服務(wù)，用戶服務(wù)。另外粒度太小，服務(wù)聚合是一個(gè)坑，粒度太大，分和沒分一個(gè)樣。

3.4.2橫向拆分

　　是從公共且獨(dú)立功能維度拆分。標(biāo)準(zhǔn)是按照是否有公共的被多個(gè)其他服務(wù)調(diào)用，且依賴的資源獨(dú)立不與其他業(yè)務(wù)耦合。比如上圖中的元數(shù)據(jù)服務(wù)和消息服務(wù)。

3.4.3總結(jié)

　　借用《微服務(wù)設(shè)計(jì)》中的一句話：“你越不了解一個(gè)領(lǐng)域，為服務(wù)找到合適的界限上下文就越難……服務(wù)的界限劃分錯(cuò)誤，可能會(huì)導(dǎo)致不得不頻繁地更改服務(wù)間的協(xié)作，而這種更改成本更高……”

四、SOA和微服務(wù)

　　由于SOA和微服務(wù)有千絲萬縷的關(guān)系，這里簡(jiǎn)單羅列雙方的對(duì)比圖，算是一個(gè)小知識(shí)點(diǎn)：

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
																						

																					

																					

																						
																					

長(zhǎng)按訂閱更多精彩▼
																					

																						
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝