建站
咨詢
售后
建站咨詢
新聞中心
架構(gòu)設(shè)計中，大家都不喜歡耦合，但有哪些典型的耦合是我們系統(tǒng)架構(gòu)設(shè)計中經(jīng)常出現(xiàn)的，又該如何優(yōu)化?
站在用戶的角度思考問題，與客戶深入溝通，找到溫宿網(wǎng)站設(shè)計與溫宿網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都做網(wǎng)站、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、虛擬空間、企業(yè)郵箱。業(yè)務(wù)覆蓋溫宿地區(qū)。
這里列舉了 6 個點：IP、jar 包、數(shù)據(jù)庫、服務(wù)、消息、擴容。
這些點，如果設(shè)計不慎，都會導(dǎo)致系統(tǒng)出現(xiàn)一些耦合問題，基本都是大家實際遇到的痛點。本文將與大家分享如何用常見的方案去解除這些耦合。
如何找到系統(tǒng)中的耦合
什么是耦合?就是每每我們作為技術(shù)人，在心中罵上下游、罵兄弟部門，說這個東西跟我有什么關(guān)系?為什么我要配合來做這個事情?這里面就非常有可能是系統(tǒng)中存在耦合的地方。
明明我們不應(yīng)該聯(lián)動，但兄弟部門要做一個事情，上下游要做一個事情，我卻要被動地配合來做這個事情。還有可能這個配合的范圍特別特別的大，那就說明耦合非常非常的重。
下面來看具體的六個案例。
典型耦合與對應(yīng)解耦實踐
IP 耦合
第一個案例，特別常見。原來線上有服務(wù)或者有條數(shù)據(jù)庫，因為各種原因，例如磁盤硬件有故障，要換一臺機器，然后運維給了我們一臺機器，我們把數(shù)據(jù)庫或者把服務(wù)給部署好了。
部署好了 IP 要換，原來有個舊 IP，現(xiàn)在有個新 IP。那就有很多上游依賴我，我 IP 換了怎么辦?就找到上游說我的 IP 換了，麻煩上游部門改配置重啟一下，連到我新的 IP 上去。
不知道大家工作中會不會遇到這樣的場景，這時如果你作為上游的調(diào)用方，不管你調(diào)數(shù)據(jù)庫還是調(diào)服務(wù)，你心里可能就在罵他了，明明是你 IP 變了，為什么配合重啟、配合改配置的人是我?
特別是如果一個基礎(chǔ)服務(wù)或者一個基礎(chǔ)數(shù)據(jù)庫，依賴它的人很多，那么你可能要找到這些依賴它的人，可能有 A 部門、B 部門、C 部門，所有業(yè)務(wù)都依賴你，你要全部找一遍，全部重啟。
所以這個因為 IP 配置使得上下游耦合在一起的案例，它的耦合范圍其實是非常廣的，我們都覺得很討厭。
我們的希望是：你改一個 IP，能不能我不動，你自己升級了，我流量就默默遷移過去，這是一個非常直觀的理解上下游的耦合。
內(nèi)網(wǎng) IP 修改為內(nèi)網(wǎng)域名，這是我們的實踐，強烈的建議大家回去馬上干這個事情。為什么我們 IP 要修改、要重啟?
很有可能是我們將 IP 寫在了自己的配置文件中。如果我們把這個內(nèi)網(wǎng) IP 變?yōu)閮?nèi)網(wǎng)域名，那么我們是不是就可以不讓上游配合去改配置重啟呢?
假設(shè)我們現(xiàn)在不用 IP 了，用域名了?，F(xiàn)在換了一臺機器域名沒變，IP 指向變了。我們可以讓運維統(tǒng)一將內(nèi)網(wǎng) DNS 切到新的機器上面去，并將舊機器的連接切斷，重連后就會自動連到新機器上去了。
這樣的話只要運維配合就可以完成遷移，對于所有上游的調(diào)用方、服務(wù)的調(diào)用方、數(shù)據(jù)的調(diào)用方都不需要動，這是第一個案例。
我們的最佳實踐是強烈建議使用內(nèi)網(wǎng)域名來替換內(nèi)網(wǎng)的 IP，連服務(wù)、連數(shù)據(jù)庫統(tǒng)統(tǒng)取走。
公共庫耦合
第二個案例是公共庫，這個公共庫可能是一個跟業(yè)務(wù)相關(guān)的通用業(yè)務(wù)庫，比如用戶的業(yè)務(wù)、支付的業(yè)務(wù)，這些業(yè)務(wù)寫在了一個 jar 包里，各個業(yè)務(wù)線通過這個 jar 包來實現(xiàn)相關(guān)的一些業(yè)務(wù)邏輯。
所有的業(yè)務(wù)方因為這個公共庫耦合了，不管你是 so、dll，還是 jar 包代碼，不同語言的公共庫方式不一樣，本質(zhì)是上游通過這個公共庫耦合在一起。
我們曾經(jīng)碰到什么樣的情況呢?58 有招聘、房產(chǎn)、二手很多業(yè)務(wù)線，用戶的一些操作，登錄、查詢信息、修改信息可能都是相通的，所以我們有一個 user.jar，對所有用戶的操作可能通過這個 jar 包去做。
然后有個業(yè)務(wù)線，比如說招聘，他可能修改了用戶的操作的一些代碼，修改了這個 jar 包。
修改之后，上線之前會進行測試，但招聘只會測試自己的業(yè)務(wù)，不會測試兄弟業(yè)務(wù)線的業(yè)務(wù)，導(dǎo)致上線的結(jié)果是，上線后兄弟業(yè)務(wù)線全掛了。
于是就出現(xiàn)了一個很有意思的場景， A 和 B 的業(yè)務(wù)老大在群里面說怎么業(yè)務(wù)都掛了，然后有研發(fā)兄跳出來解釋說 C 部門上線了，所以我們都掛了，這個解釋是很難說通的。
為什么兄弟部門好好的，他上線了他沒問題，而我們掛了，就是因為 jar 包耦合在一起，可能我們也在心里會默默地罵他們，修改代碼的是你，沒問題的也是你，有問題的是我，我其實什么都沒動，我很委屈。
多個上游因為 jar 包耦合在了一起，那有什么樣的優(yōu)化方法?
如果代碼庫個性很強
如果這個 jar 包、這個公共庫的個性比較強，如果是偏招聘的、房產(chǎn)的、二手的，我們的建議是把這些個性的代碼拆分到各個業(yè)務(wù)線自己的 jar 包里面去。
這樣的話，你修改的那一塊只影響你自己，至少不會擴大影響范圍，這個需要對業(yè)務(wù)進行剖析，把個性的地方拿出來。
如果長時間解決不了，我剛剛說的那種耦合頻發(fā)，出現(xiàn)的次數(shù)特別多，最差的情況下我們可以 copy 代碼，比如說拷三份，但這個不推薦。
我們的建議：還是抽取其中的個性部分，把原來的一個 business 的 jar 包變成三個加包，每一塊只跟一塊業(yè)務(wù)相關(guān)。
如果公共庫通用性很強
那如果這個庫的共性比較強，我們建議通用的部分下沉獨立一個 service，這個 service 對上游提供接口，我每次測試你也要測試接口的兼容性。
如果是新的業(yè)務(wù)，我們建議新增接口，這樣至少不會對舊有的代碼產(chǎn)生影響，通過 service 或 RPC 調(diào)用的方式來解除耦合。
數(shù)據(jù)庫耦合
第三個案例應(yīng)該也是大家會遇到比較多的情況，數(shù)據(jù)庫的耦合。
我先說一下業(yè)務(wù)場景：業(yè)務(wù) A、業(yè)務(wù) B、業(yè)務(wù) C，這里還是拿用戶的業(yè)務(wù)舉例，有些用戶的數(shù)據(jù)是通用的，存在 table-user 里，而個性的數(shù)據(jù)我們存在個性的數(shù)據(jù)庫里。
比如業(yè)務(wù) A 我們可能有個 table-A、業(yè)務(wù) B 有 table-B、業(yè)務(wù) C 有 table-C。
假設(shè)我的業(yè)務(wù)線既要取個性的數(shù)據(jù)，又要取共性的數(shù)據(jù)，我們的代碼往往這么寫，個性表 join 個性表，UID 相同，UID 等于我的用戶 1、2、3，個性的數(shù)據(jù)和共性的數(shù)據(jù)一起抽取出來，沒有任何問題。
業(yè)務(wù)線 B、業(yè)務(wù)線 C 也是這么做的。所以你會發(fā)現(xiàn) join 語句其實導(dǎo)致了 user 的 table 和業(yè)務(wù)線 A、B、C 的 table 耦合到一個數(shù)據(jù)庫實例里。
這樣會導(dǎo)致什么問題呢?比如 A 業(yè)務(wù)線要上線一個功能，這個功能沒有索引，對全表都要掃描，數(shù)據(jù)庫 CPU 100%，數(shù)據(jù)庫實例 IO 性能下降，影響業(yè)務(wù)。
對B 和 C 都有影響，即某個業(yè)務(wù)線的數(shù)據(jù)庫性能急劇下降導(dǎo)致所有業(yè)務(wù)都受影響。
這時 DBA 兄弟、運維兄弟殺過來說性能不行了，我再給你兩臺機器，給我兩個實例，你會發(fā)現(xiàn)沒用，所有表都耦合在一個實例里，給機器也拆不開，擴不了容。
2015 年我調(diào)去 58 到家時，當(dāng)時整個 58 到家有一個庫叫做 58 到家?guī)欤锩嬗袔装賯€表，性能越來越低，但因為各種 join 又必須耦合在一個實例里，很悲慘。
我們怎么做呢?垂直切分與服務(wù)化。你會發(fā)現(xiàn)跟 jar 包解耦非常相似，垂直拆分。
比如說用戶的基礎(chǔ)數(shù)據(jù)，我抽向一個用戶的服務(wù)，user 最基礎(chǔ)的數(shù)據(jù)庫只能夠被這個服務(wù)鎖訪問，數(shù)據(jù)庫私有是服務(wù)化的一個特點。
此時業(yè)務(wù)線原來的業(yè)務(wù)怎么樣滿足?原來是業(yè)務(wù)方直接一個 join 既取了共有的數(shù)據(jù)又取了私有的數(shù)據(jù)，此時原來的一次數(shù)據(jù)庫訪問變成了兩次數(shù)據(jù)庫訪問，第一次取個性數(shù)據(jù)，第二次取共性數(shù)據(jù)，然后業(yè)務(wù)層拼裝。
之前的方式和之后的方式相比，之前的方式業(yè)務(wù)代碼可能會更簡單一些，因為它是將這個業(yè)務(wù)邏輯放在了 SQL 語句中，但是導(dǎo)致數(shù)據(jù)庫耦合在了一起。
后面這種方式就是業(yè)務(wù)的代碼會更復(fù)雜，會變成多次訪問，將原來在 SQL 中進行的邏輯計算變成我們自己的代碼的邏輯計算。
此時業(yè)務(wù)有自己的庫，公共有公共的庫，你會發(fā)現(xiàn)很有可能這些庫早期也在一個實例，但是性能下降時可以很容易地新增實例，把其中一個公共的庫從一個實例里放到另外一個實例，甚至新增一臺機器做到硬件的擴容。
所以垂直切分是指業(yè)務(wù)側(cè)自己的數(shù)據(jù)庫放到自己的上去，公共的放到公共的上去，不要耦合在一個實例當(dāng)中，這是一個比較典型的業(yè)務(wù)場景。
服務(wù)化耦合
第四個案例是服務(wù)化耦合的例子。服務(wù)化之后，如果業(yè)務(wù)代碼拆分得不干凈，即使你做了服務(wù)化也不能夠解除耦合。這里舉一個服務(wù)化解耦不徹底的案例。
上面是 ABC 三個業(yè)務(wù)方，底下是一個通用的服務(wù)。假如你解耦不徹底，你這個通用的服務(wù)里有業(yè)務(wù)側(cè)的代碼，最典型的業(yè)務(wù)側(cè)的代碼是什么樣的?
即服務(wù)層 switch case，根據(jù)調(diào)用方的類型走不通的業(yè)務(wù)邏輯代碼。我們做服務(wù)化其實是想把共性的部分抽象下沉，是共性的部分會做的服務(wù)。但如果解耦不徹底，就會有傳入不同 biz-type 執(zhí)行不同邏輯這樣的代碼。
這會出現(xiàn)什么問題呢?如果新增業(yè)務(wù)需求，你會發(fā)現(xiàn)很有可能要改代碼的是底層的服務(wù)，比如說業(yè)務(wù) 1 來了一個需求，他過來找到你，說我這個需求有個擴展，麻煩你這邊升級一下。
業(yè)務(wù) 2 和業(yè)務(wù) 3 相同，明明有需求的是業(yè)務(wù)方，為什么修改代碼的是我底層呢，業(yè)務(wù)需求方很多，所有業(yè)務(wù)需求側(cè)都是你來實現(xiàn)，你是忙不過來的。這時你可能在心中罵他。
這個的耦合范圍相對較小，因為只有一個基礎(chǔ)服務(wù)維護的痛點。解決方案也很容易想到，當(dāng)然是把業(yè)務(wù)個性化的 case 分支搬到上游去，底層只做通用的功能。
業(yè)務(wù)代碼上浮，這樣的話上游的業(yè)務(wù)迭代速度、迭代效率會提升，每塊業(yè)務(wù)有功能就會自己實現(xiàn)了，不需要兄弟部門去實現(xiàn)，沒有一個溝通的過程。這是服務(wù)化不徹底的一個常見的耦合的案例。
消息通知耦合
第五個案例是消息通知的耦合。我猜應(yīng)該也有很多公司遇到過，有一些事件，這個事件可能要讓很多下游知曉，這里舉一個我們曾經(jīng)出現(xiàn)過的案例。
58 同城發(fā)布帖子，發(fā)布帖子的這個事件可能要周知很多方，例如有一個用戶分級的服務(wù)，他發(fā)了帖之后，這個用戶發(fā)帖的一些統(tǒng)計數(shù)據(jù)，一些信息數(shù)據(jù)可能要進行更新。
還要通知離線消息反作弊的部門在發(fā)布這個帖子之后，可能做一些離線的分析和處理，看有沒有反作弊的嫌疑。
甚至我們這個消息可能要通知業(yè)務(wù)線，比如說招聘業(yè)務(wù)線，最近做了一些營銷活動，只要發(fā)招聘的帖子就給你獎積分。
帖子發(fā)布服務(wù)，這本來應(yīng)該是一個非常基礎(chǔ)的服務(wù)，它是否要承擔(dān)將帖子消息同步給通知關(guān)注方的職責(zé)呢?
最早我們是怎么實現(xiàn)的?58 同城都是服務(wù)化的架構(gòu)，通過 RPC 告訴你發(fā)布一個帖子。
所以我們的上游是帖子發(fā)布的基礎(chǔ)服務(wù)，他會通知反作弊的部門說發(fā)了一個帖子，會通知數(shù)據(jù)統(tǒng)計的部門發(fā)個帖子，會通知業(yè)務(wù)線說發(fā)個帖子，這樣的架構(gòu)其實是因為這個通知上下游耦合在了一起。
然后我們在什么時候會偷偷地去罵這個下游呢?假設(shè)現(xiàn)在又新增了一個業(yè)務(wù)線，房產(chǎn)業(yè)務(wù)線也做營銷活動，也要關(guān)注帖子發(fā)布，麻煩發(fā)布的兄弟能不能調(diào)用一下我。
發(fā)布的兄弟會發(fā)現(xiàn)改的是發(fā)布服務(wù)的代碼，他原來要調(diào) 123，他現(xiàn)在還要調(diào) 4，有人有新增的需求還要調(diào) 5。發(fā)布服務(wù)的工程師很痛苦，明明有需求的是業(yè)務(wù)方，但修改代碼的卻是我。
原因就是消息的上下游耦合在一起。非常常見的解耦方案是通過 MQ，這個案例里的 MQ 以及下一個案例里的配置中心是互聯(lián)網(wǎng)架構(gòu)中兩個非常常見的解耦工具。
MQ 能夠做到上下游物理上和邏輯上都解耦，增加 MQ 之后，首先上游互不知道彼此的存在，它當(dāng)然不會建立物理連接了，大家都與 MQ 建立物理連接，就是物理連接上解耦了。
邏輯上也解耦了，消息發(fā)布方甚至不用知道哪些下游訂閱了這個消息。新增消息的訂閱方只需要找 MQ 就行了，上游不需要關(guān)注。
所以 MQ 是一個非常常見的物理上解耦、邏輯上也解耦的利器。
下游擴容耦合
第六個案例，我相信也幾乎是所有的公司都會遇到的一個案例，它和第一個案例很像，但又不一樣。
我們的第一個案例是說 IP 變化，上游調(diào)下游 IP 發(fā)生了變化，我們的建議是使用內(nèi)網(wǎng)域名，而不是 IP 來做配置，來做上下游的連接解耦。
擴容換 IP 是一個場景，擴容又是第二個場景。
現(xiàn)在有 service1、service2、Web1，底層的 service 是個集群，隨著業(yè)務(wù)、數(shù)據(jù)量、并發(fā)的增長，service 要擴容了，我要新增兩個節(jié)點。
假設(shè)我要新增 IP4、IP5，你會發(fā)現(xiàn)案例一的場景又出現(xiàn)了，你得通知所有的上游麻煩幫忙增加兩 個IP，增加兩個內(nèi)網(wǎng)域名，因為我擴容了。擴容的明明是下游，但需要修改配置、需要重啟的是上游。
我們早期的解決方案是怎么樣的?我們對配置采用的是配置私藏的方式。
一般對于每個上游來說，都有個自己的配置文件，依賴于下游，這個配置文件會放在上游的配置文件里。
service2 一般有一個配置 conf，這個里面寫了依賴于內(nèi)網(wǎng)配置，內(nèi)網(wǎng)域名是 123，然后這個服務(wù)在啟動時可能通過配置把這個連接建立上。
Web 也是一樣，它有一個 Web1.conf，大家想想自己所服務(wù)的公司是不是這樣的。
它是一個數(shù)據(jù)的擴散，本來數(shù)據(jù)在這一份，但是你會發(fā)現(xiàn)這個數(shù)據(jù)擴散到不同的上游，每個人都存儲一份這樣的數(shù)據(jù)，我這個數(shù)據(jù)要變動時每個上游都需要變動。
如果數(shù)據(jù)只存在一個地方，這一個地方變了就都變了，不用擔(dān)心數(shù)據(jù)的一致性。
如果你能夠知道上游是誰，通知你的上游去為用戶改善配置重啟還好，我們碰到的痛點是什么?
58 同城幾千號人，業(yè)務(wù)幾百個，那么多，我不知道誰依賴了我，如果我能知道 123 依賴了我，那我就告訴你就行了。
現(xiàn)在我不知道誰依賴了我，因為你連接我，你不需要經(jīng)過我的允許，你在手冊上看調(diào)用方式是什么就看懂了。我們會增加 IP，我怎么通知你?
剛剛說根本的原因其實是一份配置數(shù)據(jù)擴散到了多個上游，那我們能不能將這個配置數(shù)據(jù)放在一個地方不擴散，我改了這一個地方就都改了?
解決方案是配置中心，配置中心的細節(jié)我在這不展開講，網(wǎng)上可能也有一些公司的實踐，配置后臺、DB 存儲等。
配置中心是一個典型的邏輯上解耦、但物理上不解耦的一個架構(gòu)工具。我們的所有上游依賴于下游，還要建立物理的連接。
你引入配置中心之后，它不是通過私有的配置，也不是通過全局的配置文件去讀取下游的 IP，而是配置中心說我要訪問 user service。
配置中心告訴他 user service 的內(nèi)網(wǎng)域名是 123，service 的 1、2、3 還是按照內(nèi)網(wǎng)的 1、2、3，物理上還是連接 user service，所有的上游都按照這種方式讀取下游的配置。
在配置中心側(cè)，他就能夠知道有哪些人連接了 user service，他在配置中心的后臺就可以配哪些人我設(shè)置多少的限流，然后將這個限流可以同步到調(diào)用方的客戶端，當(dāng)然也可以同步到服務(wù)端進行雙向的保護。
如果 user service 進行擴容，比如我要增加幾個節(jié)點，我增加了 4 和 5，那么我在配置后臺說增加了 4 和 5，后臺能夠知道哪些上游依賴了它，反向給后臺通知，就完全不需要上游去做了。
總結(jié)
解耦之后系統(tǒng)能夠更美好一點，程序員心中能夠少一點怨氣，希望今天分享的主題及案例能夠幫助大家解決一些工作中的實際問題，謝謝大家。
沈劍，架構(gòu)師之路公眾號作者。曾任百度高級工程師、58 同城高級架構(gòu)師、58 同城技術(shù)委員會主席、58 同城 C2C 技術(shù)部負責(zé)人?，F(xiàn)任 58 到家技術(shù)委員會主席，高級技術(shù)總監(jiān)，負責(zé) 58 速運研發(fā)與管理工作。本質(zhì)，技術(shù)人一枚。
當(dāng)前標(biāo)題：你的解耦戰(zhàn)術(shù)，決定了架構(gòu)高度！
文章出自：http://www.fisionsoft.com.cn/article/cosgojj.html
