? ? ? 微服務被越來越多的企業(yè)擁抱舶胀，在使用微服務的過程中概说，我們經(jīng)常會思考的問題是為什么使用微服務，服務又怎么拆分嚣伐？?如何避免亂用微服務糖赔。
服務的拆分
? ? ? ? 首先我們應該知道一個概念，服務拆分是對系統(tǒng)而言轩端，是通過某個維度（一般是系統(tǒng)高可用）去做到服務責任單一放典，比方說，商城系統(tǒng)有詳情頁基茵，訂單等模塊奋构，對于大型商城，詳情頁的讀多寫少拱层，這個時候可以做成一個微服務弥臼。原則是拆分粒度應該保證微服務具有業(yè)務的獨立性和完整性，服務的拆分圍繞業(yè)務模塊進行拆分根灯。服務的拆分圍繞業(yè)務模塊進行拆分是一種理想狀態(tài)下的拆分方法径缅，換句話說掺栅，我們在架構設計之初就假定我們可以掌握一切。然而纳猪，不同的服務可能由不同的團隊開發(fā)與維護氧卧，實際場景下，微服務的便利性更多的在于團隊內(nèi)部能夠產(chǎn)生閉環(huán)兆旬，換句話說假抄，團隊內(nèi)部可以易于開發(fā)與維護，便于溝通與協(xié)作丽猬，但是對于外部團隊就存在很大的溝通成本與協(xié)作成本∷薇ィ現(xiàn)在，我們來看一個案例脚祟。團隊A 考慮到功能的復用性而開發(fā)了一個“互動組件”谬以，其中包括 “評論模塊”功能。此時由桌，團隊 B 并不知情也開發(fā)了一個類似的“互動組件”为黎。而團隊 C也有這個需求，它知道團隊 A 有這個“互動組件”行您，希望可以復用铭乾，但是由于這個“互動組件”在設計的時候更多地考慮了團隊 A的當前業(yè)務，沒有很好的復用性娃循，例如不支持“評論蓋樓”功能炕檩，而由于團隊 A 出于當前其他項目的進度原因無法馬上提供支持，團隊 B評估后決定花一周時間自己開發(fā)一個符合自己業(yè)務需求的“互動組件”捌斧。此時笛质，各個項目團隊各自維護了一個“互動組件”。此外捞蚂，我們再來看一個案例妇押。一個OA系統(tǒng)擁有“用戶管理”、“文件管理”姓迅、“公告管理”敲霍、“政策管理”、“公文管理”队贱、“任務管理”色冀、“審批管理”等功能，如果按照微服務架構思想可以圍繞業(yè)務模塊進行拆分柱嫌，但是事實上這個OA 系統(tǒng)的最終用戶只有 30多人锋恬，使用微服務架構可能有點“殺雞用牛刀”的感覺了”嗲穑回顧下与学，第一個案例中彤悔，由于團隊之間的職責與邊界導致了服務的復用存在局限性，甚至造成各自為戰(zhàn)的局面索守，這種情況一般需要公司層面進行規(guī)劃和統(tǒng)籌晕窑。第二案例中，由于用戶量不大卵佛，系統(tǒng)也不復雜杨赤，使用微服務反而帶來了不必要的設計和運維難度，同時也帶來了一些技術的復雜度截汪。此外疾牲，我們還需要考慮服務依賴，鏈式調(diào)用衙解、數(shù)據(jù)一致性阳柔、分布式事務等問題。
總結下蚓峦，服務的拆分是一個非常有學問的技術活舌剂，要圍繞業(yè)務模塊進行拆分，拆分粒度應該保證微服務具有業(yè)務的獨立性與完整性暑椰，盡可能少的存在服務依賴霍转，鏈式調(diào)用。但是一汽，在實際開發(fā)過程中谴忧，有的時候單體架構更加適合當前的項目。實際上角虫，微服務的設計并不是一蹴而就的，它是一個設計與反饋過程委造。因此戳鹅，我們在設計之初可以將服務的粒度設計的大一些，并考慮其可擴展性昏兆，隨著業(yè)務的發(fā)展枫虏，進行動態(tài)地拆分也是一個不錯的選擇。
