提到微服務，服務拆分是繞不過去的話題，但是微服務不是說拆就能拆的，需要很多的前提條件。

成都創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設,讓胡路企業(yè)網(wǎng)站建設,讓胡路品牌網(wǎng)站建設,網(wǎng)站定制,讓胡路網(wǎng)站建設報價,網(wǎng)絡營銷,網(wǎng)絡優(yōu)化,讓胡路網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

首先，首先在基礎設施層面，要有一個持續(xù)集成的平臺，使得服務在拆分的過程中，功能的一致性，這種一致性不能通過人的經(jīng)驗來，而需要經(jīng)過大量的回歸測試集，并且持續(xù)的拆分，持續(xù)的演進，持續(xù)的集成，從而保證系統(tǒng)時刻處于可以驗證交付的狀態(tài)，而非閉門拆分一段時間，最終誰也不知道功能最終究竟有沒有bug，因而需要另外一個月的時間專門修改bug。

其次在接入層，API和UI要動靜分離，API由API網(wǎng)關統(tǒng)一的管理，這樣后端無論如何拆分，可以保證對于前端來講，統(tǒng)一的入口，而且可以實現(xiàn)拆分過程中的灰度發(fā)布，路由分發(fā)，流量切分，從而保證拆分的平滑進行。而且拆分后的微服務之間，為了高性能，是不建議每次調用都進行認證鑒權的，而是在API網(wǎng)關上做統(tǒng)一的認證鑒權，一旦進入網(wǎng)關，服務之間的調用就是可信的。

其三對于數(shù)據(jù)庫，需要進行良好的設計，不應該有大量的聯(lián)合查詢，而是將數(shù)據(jù)庫當成一個簡單的key-value查詢，復雜的聯(lián)合查詢通過應用層，或者通過Elasticsearch進行。如果數(shù)據(jù)庫表之間耦合的非常嚴重，其實服務拆分是拆不出來的。

其四要做應用的無狀態(tài)化，只有無狀態(tài)的應用，才能橫向擴展，這樣拆分才有意義。

那么， 滿足了服務拆分的基礎設施前提之后，我們應該先拆哪個模塊，后拆哪個模塊呢？在什么情況下一個模塊應該拆分出來呢？

切記，微服務拆分絕非一個大躍進運動，由高層發(fā)起，把一個應用拆分的七零八落的，最終大大增加運維成本，但是并不會帶來收益。

滿足上述基本條件后，我們還要看業(yè)務變化，才能找到拆分的最佳時機。

第一，有快速迭代的需求。

互聯(lián)網(wǎng)產(chǎn)品的特點就是迭代速度快，一般一年半就能決出勝負，第一一統(tǒng)天下，第二被第一收購，其他死翹翹。所以快速上線，快速迭代，就是生命線，而且一旦成功就是百億身家，所以無論付出多大運維成本，使用微服務架構都是值得的。

這也就是為什么大部分使用微服務架構的都是互聯(lián)網(wǎng)企業(yè)，因為對于這些企業(yè)來講收益明顯。而對于很多傳統(tǒng)的應用，半年更新一次，企業(yè)運營相對平穩(wěn)，IT系統(tǒng)的好壞對于業(yè)務沒有關鍵性影響，在他們眼中，微服務化改造帶來的效果，還不如開發(fā)多加幾次班。

第二，提交代碼頻繁出現(xiàn)大量沖突

微服務對于快速迭代的效果，首先是開發(fā)獨立，如果是一單體應用，幾百人開發(fā)一個模塊，如果使用GIT做代碼管理，則經(jīng)常會遇到的事情就是代碼提交沖突。

同樣一個模塊，你也改，他也改，幾百人根本沒辦法溝通。所以當你想提交一個代碼的時候，發(fā)現(xiàn)和別人提交的沖突了，于是因為你是后提交的人，你有責任去merge代碼，好不容易merge成功了，等再次提交的時候，發(fā)現(xiàn)又沖突了，你是不是很惱火。隨著團隊規(guī)模越大，沖突概率越大。

所以應該拆分成不同的模塊，每十個人左右維護一個模塊，也即一個工程，首先代碼沖突的概率小多了，而且有了沖突，一個小組一吼，基本上問題就解決了。

每個模塊對外提供接口，其他依賴模塊可以不用關注具體的實現(xiàn)細節(jié)，只需要保證接口正確就可以。

第三，小功能要積累到大版本才能上線，上線開總監(jiān)級別大會

微服務對于快速迭代的效果，首先是上線獨立。如果沒有拆分微服務，每次上線都是一件很痛苦的事情。當你修改了一個邊角的小功能，但是你不敢馬上上線，因為你依賴的其他模塊才開發(fā)了一半，你要等他，等他好了，也不敢馬上上線，因為另一個被依賴的模塊也開發(fā)了一半，當所有的模塊都耦合在一起，互相依賴，誰也沒辦法獨立上線，而是需要總監(jiān)協(xié)調各個團隊，大家開大會，約定一個時間點，無論大小功能，死活都要這天上線。

這種模式導致上線的時候，單次上線的需求列表非常長，這樣風險比較大，可能小功能的錯誤會導致大功能的上線不正常，將如此長的功能，需要一點點check，非常小心，這樣上線時間長，影響范圍大。因而這種的迭代速度快不了，頂多一個月一次就不錯了。

服務拆分后，在接口穩(wěn)定的情況下，不同的模塊可以獨立上線。這樣上線的次數(shù)增多，單次上線的需求列表變小，可以隨時回滾，風險變小，時間變短，影響面小，從而迭代速度加快。

對于接口要升級部分，保證灰度，先做接口新增，而非原接口變更，當注冊中心中監(jiān)控到的調用情況，發(fā)現(xiàn)接口已經(jīng)不用了，再刪除。

微服務解決的問題還有高并發(fā)。互聯(lián)網(wǎng)一個產(chǎn)品的特點就是在短期內要積累大量的用戶，這甚至比營收和利潤還重要，如果沒有大量的用戶基數(shù)，融資都會有問題。

因而對于并發(fā)量不大的系統(tǒng)，進行微服務化的驅動力差一些，如果只有不多的用戶在線，多線程就能解決問題，最多做好無狀態(tài)化，前面部署個負載均衡，單體應用部署多份。

 第四，橫向擴展流程復雜，主要業(yè)務和次要業(yè)務耦合

單體應用無狀態(tài)化之后，雖然通過部署多份，可以承載一定的并發(fā)量，但是資源非常浪費。因為有的業(yè)務是需要擴容的，例如下單和支付，有的業(yè)務是不需要擴容的，例如注冊。如果一起擴容，消耗的資源可能是拆分后的幾倍，成本可能多出幾個億。而且由于配置復雜，在同一個工程里面，往往在配置文件中是這樣組織的，這一塊是這個模塊的，下一塊是另一個模塊的，這樣擴容的時候，一些邊角的業(yè)務，也是需要對配置進行詳細審核，否則不敢貿然擴容。

第五，熔斷降級全靠if-else

在高并發(fā)場景下，我們希望一個請求如果不成功，不要占用資源，應該盡快失敗，盡快返回，而且希望當一些邊角的業(yè)務不正常的情況下，主要業(yè)務流程不受影響。這就需要熔斷策略，也即當A調用B，而B總是不正常的時候，為了讓B不要波及到A，可以對B的調用進行熔斷，也即A不調用B，而是返回暫時的fallback數(shù)據(jù)，當B正常的時候，再放開熔斷，進行正常的調用。

有時候為了保證核心業(yè)務流程，邊角的業(yè)務流程，如評論，庫存數(shù)目等，人工設置為降級的狀態(tài)，也即默認不調用，將所有的資源用于大促的下單和支付流程。

如果核心業(yè)務流程和邊角業(yè)務流程在同一個進程中，就需要使用大量的if-else語句，根據(jù)下發(fā)的配置來判斷是否熔斷或者降級，這會使得配置異常復雜，難以維護。

如果核心業(yè)務和邊角業(yè)務分成兩個進程，就可以使用標準的熔斷降級策略，配置在某種情況下，放棄對另一個進程的調用，可以進行統(tǒng)一的維護。

總之，微服務拆分的過程，應該是一個由痛點驅動的，是業(yè)務真正遇到了快速迭代和高并發(fā)的問題。如果不拆分，將對于業(yè)務的發(fā)展帶來影響，只有這個時候，微服務的拆分才有確定收益，增加的運維成本才值得。

(本文作者為：網(wǎng)易云首席架構師 劉超)

分享文章：什么時候才是微服務拆分的最佳時機？-創(chuàng)新互聯(lián)
分享鏈接：http://chinadenli.net/article14/cepcde.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供建站公司、品牌網(wǎng)站建設、網(wǎng)站制作、網(wǎng)站排名、虛擬主機、網(wǎng)站設計公司

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)