軟件工程師羅小東，多年平臺架構(gòu)設(shè)計和落地經(jīng)驗，從單體工程到服務(wù)化工程，從整合再到拆分再整合實踐過程中，對多邊型架構(gòu)的一些落地心得。

背景

這里以開源項目alinesno-cloud微服務(wù)架構(gòu)的建設(shè)拆分再到整合成產(chǎn)品型結(jié)構(gòu)的進行闡述，從原來的幾十個工程基線(近百個服務(wù)模塊)，再到后來的20個左右產(chǎn)品模塊的組合，進行服務(wù)能力的輸出。過程工程由微服務(wù)、六邊型、再到多邊型工程結(jié)構(gòu)的實踐經(jīng)驗，這里偏向于工程結(jié)構(gòu)以適應(yīng)平臺產(chǎn)品化發(fā)展的變更。

需要達到的效果是把工程結(jié)構(gòu)多組合的結(jié)構(gòu)以適應(yīng)項目的需求變化。多邊形架構(gòu)是一個泛指的概念，指的是由多個組件或模塊組成的系統(tǒng)架構(gòu)。這些組件或模塊可以以不同的形狀和大小組合在一起，形成各種不同形態(tài)的系統(tǒng)架構(gòu)。多邊形架構(gòu)中的每個組件或模塊都可以擔(dān)任不同的角色和功能，并通過定義清晰的接口和協(xié)議，實現(xiàn)彼此之間的通信和交互。

概述

軟件架構(gòu)也在不斷地演化。從單體應(yīng)用到RPC服務(wù)再到微服務(wù)，這些技術(shù)的出現(xiàn)和應(yīng)用都是為了解決不同階段的問題。而六邊形架構(gòu)是在微服務(wù)架構(gòu)基礎(chǔ)上的一種新型架構(gòu)，它強調(diào)領(lǐng)域驅(qū)動設(shè)計（DDD）和面向接口的編程，旨在更好地支持業(yè)務(wù)復(fù)雜度的增長和應(yīng)對變化。

這里以時間維度闡述自己從MVC架構(gòu)到六邊型架構(gòu)，再到多邊型架構(gòu)的產(chǎn)品線整合嘗試，這里以過程以時間維度（18年到21年）和成熟度進行闡述過程。

• 初版定義：單體到Dubbo服務(wù)工程的嘗試建設(shè)

• 技術(shù)升級：從Dubbo服務(wù)工程到Cloud工程結(jié)構(gòu)的改造

• 產(chǎn)品改造：從Cloud工程到自定義工程結(jié)構(gòu)的改造

• 模型成熟：從六邊型概念到多邊型工程結(jié)構(gòu)的改造

  
  

對于這塊的模型的定義有很多不一致的理解層面，這里針對的是問題和解決兩個角度進行闡述，經(jīng)驗不一，我有我思。

過程

在產(chǎn)品型建設(shè)過程中，軟件架構(gòu)也在不斷地演變和升級。從單體應(yīng)用到分布式系統(tǒng)、再到微服務(wù)和六邊形架構(gòu)，每一種架構(gòu)都有其獨特的優(yōu)勢和適用場景。本文將會介紹從單體工程到RPC服務(wù)、再到微服務(wù)、再到六邊形架構(gòu)以及多邊形架構(gòu)的技術(shù)發(fā)展。

初版定義：單體到Dubbo服務(wù)工程的嘗試建設(shè)

這個過程的改造適合國情化的發(fā)展

在單體應(yīng)用時代，由于業(yè)務(wù)需求相對簡單且交互較為單一，使用單體架構(gòu)是比較合適的選擇。但是，隨著業(yè)務(wù)的不斷擴大和功能的不斷增加，單體架構(gòu)也開始暴露一些問題，如代碼耦合度高、代碼可維護性差等。為了解決這些問題，在RPC服務(wù)時代，我們將原本單體應(yīng)用中的模塊拆分成了獨立的服務(wù)，同時采用遠程過程調(diào)用方式進行通信，使得不同服務(wù)之間的耦合度降低，系統(tǒng)的可擴展性得到了提升。

工程結(jié)構(gòu)開始是MVC型，后面改成Dubbo型，將Service層抽取出來，提供出api實體和接口工程給第三方依賴，這個過程的改造會將龐大的業(yè)務(wù)系統(tǒng)架構(gòu)進行拆分，形成多個模塊化，將單體應(yīng)用改造為Dubbo服務(wù)，可以將原本臃腫而難以維護的單體應(yīng)用拆分成多個獨立的服務(wù)，使得系統(tǒng)變得更加模塊化和清晰。這樣做的好處包括：

• 提高可伸縮性：將單體應(yīng)用改造成Dubbo服務(wù)后，每個服務(wù)可以獨立部署和擴展，可以根據(jù)實際負載情況進行動態(tài)伸縮，提高了系統(tǒng)的可伸縮性。

• 提高可靠性：Dubbo提供了多種服務(wù)治理功能，比如容錯機制、路由策略等，可以有效保證服務(wù)的可靠性和穩(wěn)定性，相對于單體應(yīng)用更加可靠。

• 提高可維護性：將單體應(yīng)用拆分成多個服務(wù)后，每個服務(wù)的代碼規(guī)模變小了，易于維護和升級。同時，模塊化的設(shè)計也使得開發(fā)人員更加關(guān)注自己的業(yè)務(wù)領(lǐng)域，提高了團隊的開發(fā)效率。

• 提高代碼復(fù)用率：Dubbo服務(wù)通過接口進行解耦，將相同或類似的功能封裝到獨立的服務(wù)中，提高了代碼復(fù)用率，減少了重復(fù)開發(fā)的工作量。
  通過將單體應(yīng)用改造成基于Dubbo的分布式服務(wù)架構(gòu)，可以幫助企業(yè)構(gòu)建基于微服務(wù)的架構(gòu)體系，從而提高系統(tǒng)的可伸縮性、可靠性、可維護性和代碼復(fù)用率。

這是一個不錯的工程結(jié)構(gòu)，而且確實也解決了原始大型工程的問題，這個過程的建設(shè)相對于傳統(tǒng)項目來說，有可能會形成微服務(wù)，也可能會形成大型的分布式工程（也就是偽微服務(wù)），不過總的來說，會解決單體陷阱的問題。

技術(shù)升級：從Dubbo服務(wù)工程到Cloud工程結(jié)構(gòu)的改造

新型的分布式服務(wù)，也會帶來新的問題，需要讓這個服務(wù)就做這個事情

Dubbo服務(wù)之間有很強的依賴性，在不小心或者不輕易間，會產(chǎn)生強依賴性和不斷傳遞問題，這個形成的影響又是另一方面，特別是在公用網(wǎng)絡(luò)或者外部網(wǎng)絡(luò)的情況下，服務(wù)之間的關(guān)聯(lián)還有調(diào)用不穩(wěn)定性常常發(fā)生，還包括操作系統(tǒng)的因素等，另一個更為明顯的，Dubbo只是一個RPC架構(gòu)，針對微服務(wù)和分布式來說，外圍生態(tài)和組件成熟度不高，基本上都是東拼西湊起來。

另一個更加夸張的是原阿里團隊的不維護，導(dǎo)致出來了很多不一致的版本，生態(tài)體系有可能無法發(fā)展的情況，這個時候，不得來說，會轉(zhuǎn)向SpringCloud體系，一個是協(xié)議的通用性，另一個是社區(qū)生態(tài)。雖然來說，不管從工程結(jié)構(gòu)和代碼量來說，Dubbo服務(wù)會少于Cloud體系，而且工程資源還有開發(fā)的習(xí)慣、有高性能、低延遲、易擴展等特點，但是無法在很多場景下，會帶來很多限制。

另一個致命的是，由于工程結(jié)構(gòu)的特點，它對外提供的是RPC接口是直接面向Service層服務(wù)，在很多情況下會影響項目開發(fā)人員，設(shè)計人員的設(shè)計思維，很多情況下我們只寫到Service層服務(wù)，這個會讓人有一種誤區(qū)就是邏輯只到Service層，那這樣的話，Rest層接口這個自然就不會存在，這樣的設(shè)計，很多時候會無形的影響設(shè)計人員在處理服務(wù)模塊的時候，會自然而然的將工程設(shè)計只到Service層。

這個容易產(chǎn)生大量的工程服務(wù)組件，在領(lǐng)域設(shè)計上，容易（這里只是說容易，但并不絕對）無形中拆分了這個模塊，這個跟高內(nèi)聚、低耦合的思想有一定偏離，在后期的使用過程中，總會感覺需要有一層進行聚合，而這個聚合的服務(wù)其實最好的體現(xiàn)在Rest層上面，而dubbo面向service的設(shè)計，讓很多工程結(jié)構(gòu)下無形的把這個思維在潛意識里面隱藏了。

開始嘗試會在前面加一層聚合服務(wù)進行整合，但是這個鏈路并不是很樂觀，因為從實際結(jié)果上，還是拆分了。

以上種種，將Dubbo服務(wù)工程結(jié)構(gòu)轉(zhuǎn)成SpringCloud工程結(jié)構(gòu)，增加了一些層級和工程代碼量，但是效果上會把上面潛意識的問題消除掉，達到的效果就是：這個服務(wù)就做這個事情，由原來的RPC服務(wù)減少，轉(zhuǎn)成模塊形的設(shè)計，進一步減少復(fù)雜度和提高服務(wù)的內(nèi)聚。

產(chǎn)品改造：從Cloud工程到自定義工程結(jié)構(gòu)的改造

在一些架構(gòu)不滿足的情況下，需要自定義工程結(jié)構(gòu)

前期在使用Cloud過程中，過多的復(fù)雜組件和概念，還有starter工程結(jié)構(gòu)的增加，無形中加劇和工程變重，這個過程容易影響業(yè)務(wù)的開發(fā)，另一個問題是，在服務(wù)組件不斷的成熟下，這些組件會開始進一步的平臺化（直白的說增加一個管理界面）。

它包含多個工程和組件，使得開發(fā)人員可以快速構(gòu)建復(fù)雜的微服務(wù)應(yīng)用程序。然而，使用大量的工程組件也有一些弊端：

• 復(fù)雜性：Spring Cloud包含眾多的組件和工具，這使得整個應(yīng)用程序變得非常復(fù)雜。開發(fā)人員需要學(xué)習(xí)和掌握各種組件的使用方法，這增加了開發(fā)難度和時間成本。

• 版本兼容性：由于Spring Cloud包含眾多的組件和工具，每個組件都有自己的版本號。當(dāng)一個組件更新版本時，它可能會影響其他組件的兼容性。這給開發(fā)人員帶來了額外的負擔(dān)，需要測試和修復(fù)版本兼容性問題。

• 性能問題：每個組件都需要運行在不同的進程中，這可能會導(dǎo)致性能問題。每個進程都需要消耗CPU和內(nèi)存資源，這可能會降低整個應(yīng)用程序的性能表現(xiàn)。

另外一個特別讓人意外的是，Netflix組件在不斷的放棄維護，而又發(fā)展出alibaba版、tenant版，還有n多的個人版本，這些基本上容易導(dǎo)致被牽著走。

在市場架構(gòu)調(diào)整中，做了一些調(diào)整，以適配工程結(jié)構(gòu)，同時拋棄掉Cloud思維結(jié)構(gòu)：

• 去掉Cloud體系和大量的第三方組件，只保留基礎(chǔ)的springboot工程結(jié)構(gòu)，同時將第三方組件需要用到的核心能力進行自定義封裝。

• 去掉所謂官方“好的”微服務(wù)插件，比如配置中心、注冊中心、鏈路跟蹤等，將這些獨立出來，一般小的工程用不上，大的工程通過自定義封裝包的形式加載（比如nacos)

• 將工程結(jié)構(gòu)進一步的獨立化，適當(dāng)?shù)慕M件進行平臺化，通過租戶的形式提供服務(wù)，并提供出可視化的管理界面

• 將大量的工程進一步壓縮消減，形成模塊化，提供包的形式，需要的時候依賴，而不是都通過接口調(diào)用，通過插件的概念形式進行整合（類似于wordpress插件）

通過上面的調(diào)整，你會發(fā)現(xiàn)，工程結(jié)構(gòu)會有點類似于云平臺，每個服務(wù)組件都有單獨的能力，這個時候，產(chǎn)品型的體現(xiàn)已經(jīng)慢慢程現(xiàn)，但是還不夠充分。

模型成熟：從六邊型概念到多邊型工程結(jié)構(gòu)的改造

為了產(chǎn)品更好的迭代和發(fā)展，提取出領(lǐng)域的概念，進一步徹底的產(chǎn)品化

架構(gòu)也開始出現(xiàn)一些問題，如服務(wù)之間的依賴關(guān)系復(fù)雜、服務(wù)治理難度大等。為了解決這些問題，領(lǐng)域模型的思維進一步的切入到服務(wù)建設(shè)中。將微服務(wù)合并拆分出領(lǐng)域服務(wù)，并以領(lǐng)域模型為中心進行設(shè)計和開發(fā)，強調(diào)了面向API接口編程的思想，通過定義清晰的接口，使得不同服務(wù)之間的交互更加規(guī)范化、靈活化。

在這個過程中，特別需要關(guān)注的是業(yè)務(wù)本身的特點和復(fù)雜性，導(dǎo)致軟件難以維護、擴展和適應(yīng)業(yè)務(wù)變化，做了一些調(diào)整方向，主要是：

• 明確業(yè)務(wù)領(lǐng)域模型，提高業(yè)務(wù)分析和設(shè)計的準(zhǔn)確性和效率，可以自由地進行修改、測試和演化，而不會對其他系統(tǒng)產(chǎn)生影響。

• 將業(yè)務(wù)邏輯與外部依賴分離開來，使得業(yè)務(wù)邏輯在不同的環(huán)境中都能夠獨立運行。

• 多個模塊間內(nèi)部核心和外部適配器之間通過接口來進行通信，使得它們可以相互獨立地演化和變化。

• 多種不同類型的適配器，使得系統(tǒng)可以更加靈活地適應(yīng)不同的業(yè)務(wù)場景和需求變化，從而提高了系統(tǒng)的可擴展性。

這個原來在調(diào)整工程結(jié)構(gòu)過程時，發(fā)現(xiàn)六邊型概念是跟我想要的基本上吻合的，而且融合度非常高，但是過多的代碼編碼概念，開發(fā)人員來說可能會有一定的技術(shù)門檻，特別是在領(lǐng)域建模、聚合、限界上下文等方面，在某個程度會讓我們感覺到這個是否是我們需要的，最終我們把工程結(jié)構(gòu)進一步拆分和根據(jù)內(nèi)部的習(xí)慣定義，重新設(shè)計和工程結(jié)構(gòu)，以下是調(diào)整的結(jié)構(gòu)圖：

這個調(diào)整的結(jié)構(gòu)使得服務(wù)產(chǎn)品間更穩(wěn)定，組件或模塊可以以不同的形狀和大小組合在一起，形成各種不同形態(tài)的系統(tǒng)架構(gòu)，每個組件或模塊都可以擔(dān)任不同的角色和功能，并通過定義清晰的接口和協(xié)議，實現(xiàn)彼此之間的通信和交互，以適應(yīng)不同的業(yè)務(wù)場景。

總結(jié)

以上為在過程工程由微服務(wù)、六邊型、再到多邊型工程結(jié)構(gòu)的實踐經(jīng)驗，這里偏向于工程結(jié)構(gòu)以適應(yīng)平臺產(chǎn)品化發(fā)展的變更，最終發(fā)展形成產(chǎn)品化的工程結(jié)構(gòu)調(diào)整過程。工程結(jié)構(gòu)的調(diào)整是解決的是應(yīng)用程序的可測試性、可維護性和可擴展性問題，同時針對于自己所面對的場景不斷的適配調(diào)整過程，這個過程的調(diào)整差不多有4年左右，不斷的進行優(yōu)化調(diào)整而形成的結(jié)果，這里也是輸出一些經(jīng)驗，供參考。

本文使用 文章同步助手 同步