一位屢獲殊榮的資深全端開發人員分享工程團隊如何現代化舊有平台、擴展企業系統以應對高負載工作量，並在不降低開發速度的情況下交付具韌性的架構。
隨著組織加速數位轉型，許多工程團隊發現他們最大的障礙是仍然依賴的舊有基礎設施。根據 Pegasystems 的調查,68% 的企業 IT 決策者表示,過時的平台和應用程式阻礙了他們的組織全面採用現代技術。為了更好地了解工程團隊如何在實踐中克服這些挑戰,我們採訪了 Abduaziz Abdukhalimov,他是一位屢獲殊榮的資深全端開發人員,擁有超過十年將技術脆弱的系統轉變為可擴展、具韌性平台的經驗。
Abduaziz 在 SoftClub Company 創建了現代化舊有企業資源規劃(ERP)和財務系統的方法,將它們轉變為模組化微服務。在 Barso LLC,他開發了一個雲原生企業平台,服務超過 100,000 名使用者。他還主導了烏茲別克全國基於 Moodle 的學習平台部署,使學生和教師能夠透過一個需要穩定效能、可靠發布以及快速但安全迭代的系統進行線上工作。在與 Abdukhalimov 的對話中,我們討論了現代化舊有平台需要什麼、工程團隊如何在不影響系統可靠性和可維護性的情況下擴展企業系統,以及為什麼架構紀律往往比技術選擇更重要。
Abduaziz,現今許多公司面臨現代化核心系統的壓力。從您的角度來看,團隊在開始現代化舊有平台時犯的最大錯誤是什麼?
最大的錯誤是將現代化視為技術升級,而不是業務關鍵的架構決策。許多團隊一開始就認為他們只需要從單體架構遷移到微服務,或從本地基礎設施遷移到容器,卻沒有首先了解真正的營運痛點在哪裡。
在實踐中,舊有系統通常在應對變更時失敗,而不是在擴展時失敗。問題往往不是平台無法運行,而是每個新功能、修復或整合都變得更慢、風險更高、更難測試。如果團隊僅專注於工具來開始現代化,他們最終可能會以更分散的形式重建相同的問題。
更好的起點是識別當前系統造成最多阻力的地方:發布瓶頸、緊密耦合的模組、不穩定的依賴關係,或效能和可維護性已經衝突的領域。一旦這些壓力點清晰了,現代化就變得更有紀律。它不再是一個模糊的遷移工作,而是成為一系列有針對性的工程決策。
您在職業生涯早期在 Open Data Challenge 中獲得第一名,並在 Best Soft Challenge 中獲得最高排名。這些經歷如何塑造了您後來處理大規模工程問題的方式?
在職業生涯的那個階段參加競賽幫助我養成了超越快速技術修復的思考習慣。我學會了審視解決方案如何在複雜性增加時保持穩定、在更多人依賴它時表現如何,以及系統必須持續演進時的情況。這種觀點在專業工作中一直伴隨著我。我不是專注於流行趨勢,而是首先審視系統是否結構清晰、是否可以在沒有持續摩擦的情況下得到支援,以及隨著需求增長是否仍然可靠。
在 SoftClub Company,您從事企業現代化工作,並協助將舊有 ERP、財務和人力資源系統遷移到模組化微服務。您的工作帶來了更可擴展的企業應用程式、改善的可維護性和更廣泛的雲端採用。您如何判斷單體架構是否仍應漸進式重構?
這次經驗教會我,決策取決於現有系統是否仍可以在不破壞業務邏輯的情況下分離成有意義的模組。主要挑戰通常不僅僅是年齡問題。而是隨著時間累積的依賴關係密度。
如果系統仍然允許您隔離功能區域、穩定它們之間的介面,並在不持續干擾其他部分的情況下改善一個部分,那麼漸進式重構通常是更強的路徑。當平台對業務至關重要且無法承受一次性替換所有內容的交付風險時,這種方法特別有用。當架構不再支援清晰的邊界、當一個變更持續在不相關的區域產生連鎖反應、以及即使在有針對性的改進後可維護性仍持續下降時,完全重寫變得更為實際。在這種情況下,系統不再對作為一系列受控步驟的現代化做出回應。
所以真正的測試不是單體架構是否過時。而是它是否仍然為工程團隊提供足夠的結構控制,以便分部分改善可擴展性和可維護性。如果這種控制仍然存在,重構就有效。如果它已經消失,重寫就成為更安全的長期決策。
作為 Barso LLC 的資深全端開發人員,您協助建立了一個雲原生企業平台,將系統效能提升了 40%。根據這次經驗,您在 Spring Boot 環境中最常看到的隱藏效能殺手是什麼?
許多效能問題不是由演算法引起的,而是由架構決策引起的。
一個常見的問題是隱藏的阻塞操作。一個服務可能看起來是非同步的,但仍然依賴阻塞的資料庫呼叫或外部 API。在高流量下,這些呼叫會消耗執行緒池,造成連鎖延遲。另一個常見問題是過度的服務間通訊。微服務有時變得過於頻繁通訊,在單一使用者請求中包含多個同步呼叫。即使每次呼叫的延遲很小,也會迅速累積。資料庫存取模式也很重要。效率低下的查詢、缺少索引或過度使用 ORM 可能會產生只在生產負載下出現的瓶頸。最後,可觀察性經常被低估。沒有適當的指標和追蹤,團隊很難識別哪個元件實際造成效能下降。效能工程從可見性開始。
您使用 Apache Kafka 和 RabbitMQ 開發了事件驅動架構,以支援一個服務超過 100,000 名活躍使用者的平台,改善了可擴展性、容錯能力和系統可靠性。根據您的經驗,在什麼情況下事件驅動架構真正增強了韌性和可擴展性?
當服務必須保持鬆散耦合但又要交換關鍵資訊時,事件驅動系統非常強大。例如,如果多個子系統依賴同一個事件,例如金融交易或使用者活動,將該事件發布到訊息代理允許每個服務獨立處理它。這減少了系統之間的直接依賴關係。
另一個優勢是韌性。如果下游服務暫時不可用,訊息可以排隊並稍後處理,而不會遺失資料。然而,不應盲目採用事件架構。對於需要即時一致性或簡單請求-回應邏輯的工作流程,同步通訊可以更清晰、更易於維護。目標不是最大化技術堆疊中的技術數量,而是在真正改善容錯能力和可擴展性的地方使用非同步模式。
您主導了烏茲別克全國基於 Moodle 的電子學習平台部署,使大學能夠繼續遠端教學,並獲得高等教育部的認可。當平台突然需要服務大量學生和教師時,工程團隊如何平衡速度與可靠性?
這樣的情況迫使團隊將穩定性和可存取性置於完美架構之上。
一個關鍵原則是專注於關鍵使用者旅程。對於教育平台,這意味著登入、課程存取以及學生和教師之間的溝通。如有必要,次要功能可以延遲。基礎設施也成為優先事項。快速擴展需要可靠的負載平衡、資料庫最佳化和仔細監控以及早偵測故障。
另一個教訓是,工程團隊內的清晰溝通變得與程式碼本身一樣重要。當部署週期加速時,協調有助於防止可能使系統不穩定的衝突變更。在高壓環境中,工程成為防範混亂的主要保障。
在您的職業生涯中,您從事了現代化企業系統、建立雲原生平台和支援高負載應用程式的工作。基於這一進展,全端開發人員這個術語現在實際上意味著什麼?
過去用來描述處理客戶端和伺服器端程式碼的人,現在涵蓋的範圍更廣。這個角色越來越涉及從介面行為和應用程式邏輯到發布工作流程、系統可見性以及啟動後效能等端到端的產品運作方式。在這個領域的優秀工程師不僅僅局限於編碼。他們還需要了解雲端環境、交付管道、執行時行為以及軟體的營運面。這項工作變得更廣泛,並與技術在實際業務條件下的表現更加緊密相關。
在從事提供可衡量效能提升並支援大規模營運的企業平台工作後,您會向技術長和工程主管提供什麼實用建議,關於在轉型計畫變得過於龐大或過於冒險之前應該做出的首要現代化決策?
首先,在進行大型架構變更之前投資於可觀察性。清晰的指標、日誌和追蹤有助於團隊了解當前系統的行為方式以及最需要改進的地方。
其次,儘早重新設計部署工作流程。可靠的 CI/CD 管道能夠實現更快的實驗並減少對變更的恐懼。
第三,根據業務領域而非技術模組識別正確的服務邊界。清晰的所有權使系統更易於維護和擴展。
當這些基礎就位時,現代化就成為一個結構化的過程,而不是一個冒險的飛躍。
