關於微服務拆分,聽聽一位微服務架構師的肺腑之言

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務架構的盛行,解決了系統上可用性、可擴展、可維護性上的問題,成爲衆多企業架構轉型的不二之選。但在架構轉型時,原有系統應該如何進行微服務拆分呢?要避免哪些陷阱呢?"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"引言"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"天下大勢,分久必合,合久必分,架構設計風格隨着系統的不斷演進逐步進行着分分合合的變化。在整個變化過程中,技術框架的快速發展、用戶需求的不斷升級、雲計算多年來長足的發展等環境因素也對應用系統架構風格產生了重要影響。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"IT市場及從業人員對於技術框架、架構風格不斷進行選擇和優化。多年來,爲了滿足用戶爆炸式增長的個性化需求,系統架構逐步從單體架構轉變爲面向服務的SOA架構。SOA架構將單體架構中應用的不同功能模塊進行了粗粒度的拆分,各服務間以相同的契約進行通訊,使得系統具備一定的服務化、異構化、松耦合特性。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"但在系統變得逐步龐大和複雜之後,服務總線卻成爲服務通訊的瓶頸。微服務架構將服務粒度更加細化,基於DDD讓每個微服務達到服務自治,服務間通過輕量級的通訊機制直接調用,每個微服務都圍繞着一個具體的業務單元進行構建,使系統各服務間有機解耦,同時又保持互相協作、各自“生長”的狀態。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"不過微服務的落地需要研發團隊滿足更高的要求,比如可視化服務治理平臺、健全的Devops流程等。未來,微服務也可能被取代,例如目前各大雲廠商在雲原生領域的發展越來越迅速,Google、IBM、AWS等各大廠商紛紛加大競爭力度,雲原生未來必將成爲兵家必爭之地。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.infoq.cn\/resource\/image\/6b\/91\/6b5e84823664820b4367f4f5eyya1f91.png","alt":null,"title":"","style":[{"key":"width","value":"100%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"微服務實踐經驗"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"目前微服務應用在企業中逐步廣泛落地,各大雲廠商在各行業中爲了推進企業數字化改造落地,都做出了巨大努力和貢獻。Iaas、Paas、Saas平臺伴隨着雲計算產業的快速發展,已經進入了快車道。隨着越來越多的企業在微服務架構方面的落地實踐,對於微服務架構的可應用場景也越來越清晰。那麼,在企業實踐微服務架構時需要注意哪些陷阱,才能夠讓微服務架構在適當的場景中發揮出相應的優勢呢?"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"1. 微服務基礎設施不完備"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務架構的實際落地並沒有想象中的簡單,在基礎設施能力缺失或並不完善之時,就開始微服務的大踏步落地實踐,無疑會讓團隊成員產生諸多困惑。其實,微服務架構在基礎設施建設方面需達到比較高的要求,包括平臺框架方面的虛擬化技術平臺、CI\\CD管理平臺、微服務治理平臺、監控平臺、大數據平臺等,研發團隊方面的技術水平、運維能力等等。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"舉個例子,研發團隊雖然完成了業務代碼的拆分,但由於服務間依賴導致發佈時仍存在先後關係,加之基礎環境沒有容器化等合適的虛擬化技術支持,CI\\CD在效率和可視化方面也不夠完善,就很可能會出現生產環境的一次版本發佈時間長達若干小時。研發及運維人員的精力被消耗在“盯發佈”上,同時系統迭代的效率也大打折扣。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"虛擬化能力方面"},{"type":"text","text":",需要如Kubernetes、雲平臺之類的平臺技術,幫助應用提升標準化部署、測試快速反饋、可移植性保障、版本化發佈等方面的效率。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"持續集成方面"},{"type":"text","text":",需要與虛擬化技術整合,在功能開發過程中可以極大的減少非開發工作所帶來的時間成本。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"微服務治理方面"},{"type":"text","text":",試想如果系統服務成千上萬,但沒有微服務治理平臺做支撐,那麼服務健康狀態要如何掌控?更別提服務路由、限流、降級、熔斷等服務治理的成本。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"監控報警方面"},{"type":"text","text":",針對物理機、虛機容器的資源使用監控、服務調用量異常、服務響應異常、整體調用鏈路狀況等,需要統一整合APM、日誌平臺、微服務治理平臺等一衆平臺的能力,否則在應用排錯、異常巡檢、發現隱藏問題、全鏈路壓測等方面都會面臨巨大困難。同時提高監控報警平臺的可視化能力,也能夠有效增加系統運維的整體效率。所以,在開始落地微服務架構以及之後的落地過程中,需要不斷補全、完善微服務架構所需的基礎設施能力,否則只會“欲速則不達”。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"2. 服務拆分方案想當然"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在微服務拆分設計方案中,最常見的陷阱就是想僅僅通過將系統進行表面的拆分,就解決原有架構體系產生的諸多問題。比如,將原有單體中模塊之間的進程內(內存)調用,簡單的替換成微服務架構下的進程間調用(網絡)。這種爲了拆分而拆分的做法不僅增加了代碼拆分、微服務部署、功能測試等方面的成本,還會增加“網絡”這一不可靠因素(相比網絡內存顯然更加可靠)。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"舉個例子,兩個功能模塊在拆分前都由小明同學維護,功能在拆分成8個微服務之後還是由小明同學維護,但他需要將原有代碼邏輯進行分拆,同時增加微服務通訊的代碼,還要保證分拆後代碼的質量。負責測試的小紅同學還要重新跑通全流程測試,負責運維的小剛同學還要針對微服務架構重新進行硬件、網絡改造等……如果僅僅是簡單的“拆開”,而沒有在拆分過程中考慮加入MQ、定時任務、大數據異步處理等手段來解決單體應用高耦合的問題,最後只能讓系統變成“分佈式單體”。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在進行微服務拆分時應當更多的考慮“"},{"type":"text","marks":[{"type":"strong"}],"text":"高內聚、低耦合"},{"type":"text","text":"”原則,對現有業務梳理出核心、非核心鏈路,在合適的業務場景利用同步、異步的調用方式進行適當的編排。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"另外,微服務拆分是企業系統架構的一個演化過程。出於穩定性、業務發展的考慮,目前哪一部分可以優先拆分,哪一部分目前不適合變動,都需要架構師認真考量。尤其是在"},{"type":"text","marks":[{"type":"strong"}],"text":"數據層面上的拆分"},{"type":"text","text":",提前做"},{"type":"text","marks":[{"type":"strong"}],"text":"好冷熱數據分離、數據歸檔"},{"type":"text","text":"等操作,爲數據拆分降低難度。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"同時在微服務拆分後,如非必要情況要防止同一份數據在多個微服務中以不同的格式存儲,這樣持續發展數據會變得越來越難以維護,並且在複用層面上也會比較混亂。最後,微服務架構拆分需警惕“表面功夫”,根據自身業務場景和當前能力因地制宜的進行前、中、後臺規劃設計,才能保證微服務架構落地成功,並根據自身特點逐步演化。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"3. 忽略人和業務的複雜性"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"當微服務架構逐步落地企業的過程中,很難保證組織內相應的變更及時跟進,即都想要遵守康威定律,但實際落地可能困難重重。架構調整所帶來的工作內容變動與團隊各研發角色對原職能的固守之間的矛盾會在暗地裏湧動。歸根結底,人的問題纔是最難解決的問題。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"舉個例子,微服務改造前開發人員小明和運維人員之間交集並不多,但實施微服務需要做Docker容器化,那麼DockerFile中需要引用的組件、配置參數要由誰來定義?做的越多,錯的越多,所以很可能小明和小剛都不願意做。退一步講,如果由小明定義,那麼小明2、小明3陸續編寫自己的DockerFile後,小剛就會崩潰於容器化配置非標的問題。如果由小剛同學編寫,那麼衆多小明同學的個性化配置得不到滿足,小明們未必會繼續支持微服務改造。所以,"},{"type":"text","marks":[{"type":"strong"}],"text":"微服務架構改造需要添加“人”這一因素,重新確定角色的責任邊界、服務邊界,統一開發能力讓業務開發能夠快速進行"},{"type":"text","text":"。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"再比如,面對比較複雜的業務時,整個調用鏈路會很長,當調用接口變化(如需要在鏈路入口增加一個參數並一直傳遞到鏈路末端)時,就需要協調每個微服務的小明們進行代碼修改,還需要協調每個微服務的小紅們進行測試,還需要每個微服務的小剛們進行發佈生產。發佈雖然成功了,但是大家都在隱隱的捫心自問:我們不是已經做了微服務改造,不過爲什麼感覺上沒什麼改變?可以看到,大家並沒有理解的是,微服務改造後業務本身的複雜性只是被轉移到了每個服務上,而其本身並未消失。架構師作爲微服務架構的規劃者,應統一開發能力讓業務開發能夠快速進行,減少業務開發過程中的複雜性,如讓團隊有統一的中間件平臺、統一的工具組件,以較少的開發成本完成既定的業務功能。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"4.微服務並不完美"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務架構並不是銀彈,如果把它當做擺脫現有困境的救命稻草,反而會適得其反。微服務是個好東西,但是無論是從單體直接切換到微服務,還是從SOA過渡到微服務,都應根據自身技術能力、業務規劃、組織情況、預期規模等方面考慮,找到讓整個團隊在一個階段內都相對“舒適”的平衡點,不要因爲跟風“微服務””雲原生“而過於激進,也不要在架構變更上一味求穩而過於保守。企圖使用一種單一的架構模式適應所有的使用場景,這種想法本身就很危險。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"項目實踐"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"項目一"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"1.項目概況"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"業務主要是通過微信小程序接入用戶信息並進行採集記錄,功能模塊主要包括用戶管理、權限認證、進度跟蹤、報表導入導出、任務調度(Pyhton)、數據抽樣、數據統計等。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"2.拆分步驟"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"模塊劃分:"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"基礎管理:包括用戶管理、權限認證、進度跟蹤。功能相對簡單且業務耦合性較強,業務相關接口流量比較平均,所以整合爲一個服務。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"導入導出:包括報表的導入導出。大數據量的導入導出操作對內存 、CPU的消耗較大,爲防止導入導出時影響其他業務,所以單獨拆出。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"任務調度:包括各任務的調度。由於任務調度使用了異構的Python框架celery,並且任務調度屬於支撐平臺部分與業務不相關,所以單獨拆出."}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據管理:包括數據抽樣、數據統計。對已有數據進行統計分析屬於離線操作,其特點是數據量普遍較大,實時性要求不高,跟實時數據操作不同,所以單獨拆出。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"3.拆分建議"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"避免單個微服務內各業務場景間的資源(CPU、內存)爭搶。比如,導入導出的各個場景之間是否存在資源爭搶、Python任務同一執行時間段內的資源爭搶。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"使用異步方式對微服務調用鏈條上耗時比較長的進行解耦。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"通過相對準確的數據指標(調用量、資源消耗)進行微服務拆分粒度的決策,避免拆了又合或拆的太粗。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"項目二"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"1. 項目概況"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"業務主要支撐百餘家經銷商完成線上培訓,功能主要包括經銷商主數據、招募、選建、項目管理、權限管理、信息發佈等,涉及服務近50餘個。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"2.拆分問題"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"數據並未跟隨服務一起進行拆分。根據具體業務邏輯分析發現,有一部分服務的數據並不相關,但是卻耦合在了一個數據庫中。未來如果上述其中一個服務對應的數據爆發增長,那麼將給整個庫的讀寫帶來壓力,間接影響了庫中的其它服務。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"單個服務對其它服務的依賴過多。根據調用鏈路分析發現,個別服務對其它服務的依賴關係過多,但由於歷史原因導致核心代碼不敢做大的改動,此處風險在於關聯過強的服務變動頻繁就會對被關聯服務產生影響。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"部分服務拆分粒度過細。經過分析服務的業務邏輯,發現個別強耦合服務被分拆。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"持續集成基礎設施能力不足。目前還停留在jenkins手動觸發拉取代碼、編譯、打包的階段,每次發佈耗時近20分鐘。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"組織成員協作效率低下。項目涉及開發、基礎設施、架構、管理等多個參與方,但是沒有一個有力的組織協調者進行統籌,導致各自爲政。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"3.拆分建議"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"根據業務重新梳理微服務劃分粒度,強耦合少關聯的業務就合併成一個服務。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"同時對數據庫進行拆分,將非強耦合的數據拆分到多個微服務中去,可以存在若干服務調用一個數據庫。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"設置一個項目的統一協調部門,協調開發、運維對持續集成流程、容器化環境進行優化。儘量達到測試環境本地代碼變動,可以自動觸發遠程編譯打包發佈的動作,總過程時間儘量控制在5分鐘之內。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"由統一協調部門初步劃分各研發角色的主要責任,避免出現責任邊界不清晰導致的推諉。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"總結"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"筆者個人認爲,系統進行微服務改造之前要先充分了解自身情況,根據自身情況先捫心自問是否需要進行微服務拆分。然後,微服務拆分是一步步循序漸進的過程,其成功與否取決於對架構演進的把控能力以及實施細節上的逐步完善和調整。最後,積極的從組織內外聽取經驗意見,經驗意見不一定對,但是可以觸發架構師的思考,可以有效避免微服務拆分中的“深坑”。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"【參考文獻鏈接】"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/www.infoq.cn\/article\/Nd0RofAUp0WtlvlQArbu","title":"","type":null},"content":[{"type":"text","text":"https:\/\/www.infoq.cn\/article\/Nd0RofAUp0WtlvlQArbu"}]}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/www.infoq.cn\/article\/KSzctluch2ijbRbKYBgO","title":"","type":null},"content":[{"type":"text","text":"https:\/\/www.infoq.cn\/article\/KSzctluch2ijbRbKYBgO"}]}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/blog.51cto.com\/ygqygq2\/2332823","title":"","type":null},"content":[{"type":"text","text":"https:\/\/blog.51cto.com\/ygqygq2\/2332823"}]}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"horizontalrule"},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"頭圖"},{"type":"text","text":":Unsplash"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"作者"},{"type":"text","text":":崔凱"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"原文"},{"type":"text","text":":"},{"type":"link","attrs":{"href":"https:\/\/mp.weixin.qq.com\/s\/UDaKgjGW3ROTWWq8vvo-KQ","title":"","type":null},"content":[{"type":"text","text":"關於微服務拆分,聽聽一位微服務架構師的肺腑之言"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"來源"},{"type":"text","text":":騰訊雲中間件 - 微信公衆號 [ID:gh_6ea1bc2dd5fd]"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"轉載"},{"type":"text","text":":著作權歸作者所有。商業轉載請聯繫作者獲得授權,非商業轉載請註明出處。"}]}]}
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章