資訊專欄INFORMATION COLUMN
摘要：今天介紹下我一年前完成的一個兩個獨立系統的模塊打通過程，換句話說就是系統可以直接使用系統的業務模塊。需求分析上面是這兩個系統的基本架構，拆分成線上線下兩個部分。問題二這個模塊在系統中調用時，如何找對路徑。
面試時經常問的一個問題是，你最近或者做過的項目中挑戰最大的內容，然后順著其中的技術點挖一些更深入的內容，看看候選人了解多少，理解程度。
然后突然想了想我做的有什么難度比較大的項目，可以給大家分享下。
今天介紹下我一年前完成的一個兩個獨立系統的模塊打通過程，換句話說就是A系統可以直接使用B系統的業務模塊。
背景介紹A系統是一個古老的系統，B系統是一個新做的系統，（原本是希望A系統的功能全部遷移到B系統上的，但是由于各種原因擱置了）當時結果導致兩個系統在同時使用和升級。
隨著業務的開發，很多需求在A和B系統之間產生了關聯性，例如B系統上線了一個新產品，然后為了增加入口和使用量，需要在A系統上可以直接調用新產品的某個功能。
直觀的解決方案是A系統上面復制粘貼一份B系統上面這個產品的功能，但是問題就來了，未來維護起來怎么辦，同時維護兩份代碼？以后這樣的需求多了怎么辦，重復代碼越來越多？
另外一個解決辦法就是A,B兩個系統間的融合。當然這樣評估的一個前提是A和B雖然是兩個系統，但是大家開發模式，底層依賴還是相似的。
需求分析上面是這兩個系統的基本架構，拆分成線上線下兩個部分。
A網站有兩個業務模塊A1和A2。
B網站有三個業務模塊，B1,B2,B3。
現在的需求是B1這個模塊不僅能在B系統中運行，而且可以共享到A系統中。
目標如下圖：
那么問題來了：
問題一支持業務代碼的底層dep和common不一樣。
隨著時間的推移，dep依賴第一個是引入的庫有些差別，第二個更加嚴重是是大部分庫的版本已經不一樣了。
業務模塊的底層就像是生態環境，如果生態環境差別越大，那么這兩個生態融合在一起的困難也就越大。
問題二B1這個模塊在A系統中調用時，如何找對路徑。
舉個例子：
B系統中有一個 module/b/c/d.js;
B1中require了一個 module/b/c/d，在B系統中是可以正確訪問到的。
但是如果在A系統中調用到B1的require的module/b/c/d。它是會找到A系統中的module/b/c/d.js;
這只是其中的一個例子，由于系統中的AMD模式，路徑的尋找也是一個坑點。
當然對于上面的問題可以通過map方式（esl.js中有個map，require.js應該也有對應的）。當時是用過另外一種方式解決的。
問題三編譯兩個問題，
一是路徑問題，當時坑我最深的。
二是業務模塊獨立打包，A系統中應該是僅僅需要B1這個業務，而不是所有B系統中的代碼。
如何對開發人員透明，這個很關鍵。如果系統融合了，一線的開發人員需要為此做很多事情，就比較失敗了。
所以整個調用過程如何讓開發無感知，B系統中正常開發一個模塊，A系統通過一個api就能直接使用了，也不需要區分線上線下。
具體步驟主要問題拋出了，后面就是看如何一一對應的解決問題了。
當然了上面介紹的以外，還有很多細節問題，例如融合后樣式沖突這種很多細節上面的坑。只是這些沒有上面四個問題那么嚴重。
第一步，底層打平dep打平（1）A系統中補充B系統中新增的庫，相對簡單
dep打平（2）A和B系統中有差異的庫，都升級到同樣版本，這個非常坑，由于很多使用的是公司或者部門內部的庫，升級不想外部jquery一樣對開發透明，他們的升級絕對不是透明的，哪怕是百度最火的echart。所以解決升級庫的兼容問題是一個工作量很大的活。
common基礎依賴合并。找出不同內容互補，然后相同又沖突的內容，修改打補丁方式，雖然有坑，但是經理了dep的升級，覺得還ok。
完成上面三步后的一個期望的成果是，B1模塊以及依賴的內容可以直接復制到A系統中，在A里面可以直接調用打開。
注意一些細節就是初始化是否相同，A和B如果初始化不一樣，可能在A系統調用B1時，B1有些內容缺少初始化過程。（這種就是屬于細節上的坑了）
第二部，處理path路徑當時處理思路比較簡單，B1模塊前面統一加上B1這個前綴，這樣就能夠在require時找到指定的路徑了。
這個地方的難點在于打包編譯，因為破壞了默認的打包規則，而且根據一些打包的擴展配置也無法達到期望。
當時解決的方式是仔細的研究了打包編譯流程，很大程度上面重寫了或者說hack了默認的打包規則。
其實打包編譯都研究到這里了，也就順便把問題三解決了。當時的對于打包的研究已經可以安裝需要隨意打包了。
這里的預期效果就是B1模塊在B自己的系統中，A中可以調用打開了
第三部，對開發人員透明完成上面步驟后，有一個遺留問題是，線上打開的方式和線下打開的方式不一樣，對于開發人員非常不友好。
所以這一步應該是優化過程，讓這個功能更加完善，所以寫了一個簡單的api，開發人員只需要調用api即可，不需要考慮線上和線下邏輯。這個復雜的邏輯包含到了api中處理。
項目難點我個人認為這個項目的難點：
對于兩個系統的架構要非常熟悉
對于打包編譯需要非常熟悉，因為一旦涉及到線上和線下，編譯就是必須要了解的內容
對于系統底層代碼要熟悉，因為在升級dep過程中，很多版本兼容bug必須要定位到底層代碼中
對于AMD需要熟悉，當時定位甚至發現了esl.js和require.js在某種場景的細微區別
目前狀態在最近一年中，A和B兩個系統以及融合在一起了。
個人博客http://tangguangyao.github.io/
微信公眾號文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/78858.html
摘要：模塊內聚和耦合的基礎知識是軟件評測師考試的重要考點，經常出現在上午場的客觀選擇題當中。外部耦合模塊間通過軟件之外的環境聯結如將模塊耦合到特定的設備格式通信協議上時稱為外部耦合。這種模塊之間的耦合稱之為內容耦合。 模塊內聚和耦合的基礎知識是軟件評測師考試的重要考點，經常出現在上午場的客觀選擇題當中。模塊獨立是指模塊只完成系統...
摘要：是一個相對比較新的微服務框架，年才推出的版本雖然時間最短但是相比等框架提供的全套的分布式系統解決方案。提供線程池不同的服務走不同的線程池，實現了不同服務調用的隔離，避免了服務器雪崩的問題。通過互相注冊的方式來進行消息同步和保證高可用。 Spring Cloud 是一個相對比較新的微服務框架，...
摘要：解釋模塊耦合性的含義，對不同的耦合舉例說明耦合性，也叫耦合度，是對模塊間關聯程度的度量。模塊間的耦合度是指模塊之間的依賴關系，包括控制關系調用關系數據傳遞關系。軟件設計中通常用耦合度和內聚度作為衡量模塊獨立程度的標準。 ...
摘要：子模塊的創建和設置在創建好的父模塊中右鍵填寫項目名稱選擇項目中需要的部件完成父模塊的創建。對于多個模塊共同的依賴，在父中設置即可。 本文旨在用最通俗的語言講述最枯燥的基本知識 最近要對一個不大不小的項目進行重構，用spring覺得太過于繁瑣，用cloud又有覺得過于龐大，維護的人手不夠；權衡之下，最終選了springboot作為架子，但是因為項目涉及的業務模塊較多，各個模塊之間的業務交...
閱讀 2034·2021-11-11 16:54
閱讀 2111·2019-08-30 15:55
閱讀 3611·2019-08-30 15:54
閱讀 391·2019-08-30 15:44
閱讀 2228·2019-08-30 10:58
閱讀 424·2019-08-26 10:30
閱讀 3048·2019-08-23 14:46
閱讀 3191·2019-08-23 13:46
