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