3.2.3技術儲備

　　微服務學習導航和微服務周邊技術棧。周邊技術棧包括領域驅動涉及，持續(xù)交付，分布式至少，負載均衡，CAP理論，緩存原理，DevOps和容器化技術。

3.2.4團隊規(guī)模評估

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

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

　　對于微服務的團隊規(guī)模是哪些方面決定的呢？我覺得至少要從以下兩個維度來評估：

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

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

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

3.3轉微服務風險評估

3.3.1重寫面廣

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

3.3.2復雜度高

　　因為微服務是一種觀念和思想，又是新近技術，本身就有各種架構實現(xiàn)方式和技術解決方案。所以對技術人員來說，對比選型本身就是一個考驗。加上本身涉及的技術面就比較廣，所以復雜度和門檻相對比較高。

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

3.3.3人員配置

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

3.3.4合作方式

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

3.4合理的拆分姿勢

　　如何正確拆分？這里正確指的是合理，因為沒有絕對的標準。按照前人的經(jīng)驗可以分為縱向和橫向兩種劃分方法：

3.4.1縱向拆分

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

3.4.2橫向拆分

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

3.4.3總結

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

四、SOA和微服務

　　由于SOA和微服務有千絲萬縷的關系，這里簡單羅列雙方的對比圖，算是一個小知識點：

特別推薦一個分享架構+算法的優(yōu)質內容，還沒關注的小伙伴，可以長按關注一下：
																						

																					

																					

																						
																					

長按訂閱更多精彩▼
																					

																						
如有收獲，點個在看，誠摯感謝