這是一個發生在公司的真實對話：
A：我下載了你們的代碼庫怎麼編譯不通過啊，依賴中xxx-api-1.1.3版本的jar包找不到了，那可都是RELEASE版本啊。
B：你不知道我們nexus容量有限，只能保存最新的20個RELEASE版本嗎?那個API現在最新的版本是1.1.31啦。
A：啊，這才幾個月就幾十個RELEASE版本啦?這接口太不穩定啦。
B： 其實接口一行代碼沒改，我們業務分析是很牛逼的，一直很穩定。但是這個API是和我們項目一起打包的，我們需求更新一次，就發佈一次，API就被迫一起升級版本。發生這種事，大家都不想的。
如何看待這樣的事情?
事情的起因是因為nexus容量不夠，但是卻暴露了一個問題，API沒有改變，卻在大量的發佈無效版本。API的jar包在工程內部，對最初的開發是比較便利的，可以直接引用到未發佈的代碼，不需要maven build。
但是在後續長期的迭代過程中，這種和業務一起強制升級的做法，會極大的影響用戶(調用者)的體驗。我們一直說API應該是一種契約，一種承諾，那在平時生活中我們如何處理契約合同?— 合同都是一式兩份，雙方各保留一份作為憑證，如果要更新，需徵得雙方的同意。
而我們現在處理API代碼的這種做法，相當於只保留了一份合同在乙方手裡，乙方(服務方)想改就直接改了，甚至可以刪除原來的合同(刪除舊版本的api包)，導致甲方(調用者)根本找不到原來合同來維權了。
如何改進比較好?
將API作為單獨工程，或者在Maven做Submodule可以設定單獨的版本號，就不用一起升級了。不過這樣都會帶來額外的工作量，也可以在jenkins打包的時候設置參數，這部分API不和項目一起升級。
RPC和REST優缺點分析
RPC優勢和缺點
優勢：我們覺得RPC好用的原因就是可以將服務端的API功能直接發佈為可以引用的代碼，我們避免瞭解析Payload這樣的繁瑣工作。在初期上線的時候特別方便，減少了前端開發人員的工作量。
缺點：但是RPC的接口代碼由服務端開發，服務端的人為了省事，往往把所有接口都放到了一個大的Endpoint中，號稱“門面模式 Facade”。這就對調用者來說不方便了，也許我只需要調用一個接口，但是要把一個Facade所有涉及到的對象、參數、異常都導入進來，這樣後續升級的耦合就麻煩來了。即使和我需要的接口沒啥相關的，也會被迫升級。
REST優勢和缺點
優勢：而REST卻恰好相反，因為REST只有協議定義，沒有代碼，甚至客戶端是JavaScript，服務器端是Java，即使想重用代碼也不可能。而且因為REST的Endpoint可以直接到資源這樣的細粒度，調用者只需要實現自己的業務領域的客戶端代碼即可。松耦合帶來了後續持續維護的便利
缺點：給我們初期帶來了工作量。
微服務的陷阱
可以這麼認為REST是一種意義上的依賴反轉，明確了客戶端的對協議、Payload的解析的代碼責任是客戶端自己的。作為調用方的開發者，我們不能依賴服務端的代碼。傳統的軟件設計一直在強調重用，但是在微服務架構中，很多設計是反直覺的，我們必須要做一些反模式的折中設計，其中共享代碼就是要反對的。對於微服務架構來說 -- 松耦合大於重用。
閱讀更多 萬米電商雲 的文章
