我去，拷貝代碼，居然還有這等好處？
什么是耦合?
耦合，是架構中，本來不相干的代碼、模塊、服務、系統因為某些原因聯系在一起，各自獨立性差，影響則相互影響，變動則相互變動的一種架構狀態。
感官上，怎么發現系統中的耦合?
作為技術人，每每在心中罵上下游，罵兄弟部門，“這個東西跟我有什么關系?為什么需要我來配合做這個事情?”。明明不應該聯動，卻要被動配合，就可能有潛在的耦合。
因為公共庫，導致相互受影響，就是一個耦合的典型案例。
場景還原
一個看似“公共”的業務庫(*.so *.jar *.dll *.php)，很多業務系統都依賴于這個公共庫，這個庫使得這些系統都耦合在了一起。
畫外音：這里的公共庫不是指像“字符串操作”這樣的不變化的工具庫，更多是指通用業務的公共庫。
耦合如何導致相互影響?
業務1，業務2，業務3都依賴于某一個biz.jar，業務1因為某個需求需要升級biz.jar。上線前，業務1的QA進行了大量的測試，確保無誤后，代碼發布，發布完線上驗證無誤后，上線完成，閃人。
突然，bug群里有人反饋，業務2的系統掛了，業務3的系統也掛了，一下炸開了鍋：
- 業務2的大boss首先發飆：“技術都干啥了，怎么系統掛了”
- 業務2的rd一臉無辜：“業務1上線了，所以我們掛了”
額，然而，這個理由，好像在大boss那解釋不通…
- 業務2的大boss：“業務1上線?業務1上線前測試了么”
- 業務1的qa自信滿滿：“測試了呀，上線前上線后都驗證了，沒問題呀”
- 業務2的大boss對業務2的rd吼道“還想甩鍋，拖出去祭天”
不知道大家工作中會不會遇到這樣的場景，因為公共庫的耦合，兄弟部門上線，影響的確是你，此時你心里可能就在罵娘了，這幫不靠譜的**隊友。
特別的，如果公共庫的使用方很廣，這個耦合很嚴重，可能影響很大的范圍。
如何解除公共庫耦合?
方案一：代碼拷貝一份。
別嘲笑這個方案，誰敢說自己寫代碼的時候沒這么干過?
我們都知道這不是一個好的方案，但不可否認，拷貝之后，代碼各自演化，一個地方升級出錯，只影響一方，拷貝方只要不動原有代碼，至少是不會受影響的。
代碼拷貝缺點很多，系統拆分時，萬不得已不要使用這個方案。
方案二：垂直拆分，將公共庫里業務個性化的代碼拆到調用方去，不要放在公共庫里。
需要把業務個性的代碼拆分到各個業務線自己的工程，自己的業務庫里去，例如s1.jar / s2.jar / s3.jar，修改各自的代碼，至少不會擴大影響范圍。
大家為什么都把代碼往一個公共庫里塞?
很多時候，因為惰性，一點一點的惰性，日積月累，終成大坑。
這個垂直拆分是一個架構重構的過程，需要各業務方配合。
方案三：服務化，將公共庫里通用業務代碼拆到下層去。
完成了第一步，業務個性化的代碼提取到業務側上游。
接下來是第二步，業務通用的代碼，下沉抽取一層服務，服務對上游提供RPC接口：
- 每次修改底層接口，需要測試接口的兼容性，保證不影響舊調用方;
- 如果是新的業務，則建議新增接口;
最終，達到通過服務RPC調用的方式來解除耦合。
有朋友會問：
- 底層服務接口的測試;
- 上游業務層對公共庫的測試;
都是測試，為何前者能控制影響范圍呢?
- 底層接口，所有人調用，接口沒問題則調用方都沒問題
- 上游業務層對公共庫測試，只能保證自己的業務沒有問題，并不能保證其他業務方沒有問題。
個性業務代碼上浮，共性業務代碼服務化下沉，只是一個很小的優化點，但對于公共庫解耦卻是非常的有效。
希望大家每天收獲一點點，這樣架構就能美好一點點。
畫外音：原來拷貝代碼，還有解耦的功效?
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
