? ? ? ? 上回說到，我們把架構體系的工程剝離了出來，由原來的一個大工程，分成了9個自工程，把springMVC和dubbo都分別拆了出來，目前架構其實清晰多了。

? ? ? ? 我們就按照這個思路，繼續往前跑，dubbo的api我們放到了自己的git私服上，然后出現了一個問題，就是版本迭代有時候要升級接口參數，但往往因為通知不到位，會出現其他接口報錯。以前我在上一家公司的做法是：

? ? ????1.先用dubbo-monitor查一下調用方

? ? ? ? 2.挨個通知調用方我的接口要升級了

? ? ? ? 3.期間我會同時允許亮哥版本同時存在

? ? ? ? 4.調用方從我的1.0版本升級到2.0版本的時候，我開始觀察1.0版本接口的流量

? ? ? ? 5.確認沒有流量的情況下，我會下掉api及dubbo服務。

? ? ? ? 但是問題來了，我發現從0-1建立這樣的一個制度，并完全讓大伙執行下去的難度很大，這主要由兩方面決定的。一個是公司人員對dubbo的熟悉程度并不夠，其次是，本身能力并不強，在執行方面也會出現各種問題。因此，我開始考慮通過技術方式改變這種問題。

? ? ? ? 當時我想到的，dubbo的接口升級，如果是加字段的話，消費者即便不更新也不會受影響，因此我嘗試了dubbox提供的kyro序列化方式（dubbo默認的序列化是hession2）的方式來解決，測試了一下沒問題，就匆匆上線了。結果上線沒多久，有坑了，添加一個基礎類型字段是沒問題，但如果增加一個class，或者list就報錯了。因此，這個方式驗證失敗。

? ? ? ? 接下來，我去嘗試json的序列化方式，結果發現也存在對象套用對象的坑在里頭，遂放棄。

? ? ? ? 這時，架構師和我提了個概念，我們可以考慮spring cloud的微服務的方式去解決這塊的問題，通過http的方式訪問，能繞開序列化的問題。但因為當時技術部只有10多個人，我們連dubbo都沒掌握完全，更不敢嘗試新的框架。另外一點是，當時我也打聽了一下，杭州沒有哪家成熟的互聯網公司是用spring cloud在做微服務的，因此，不敢做第一個吃螃蟹的人啊。所以這塊，就硬著頭皮讓大伙按照規矩，修改接口及時通知的策略執行，其實后面有好多次事故都是因為這步驟沒有執行到位，直到spring cloud服務體系切換完畢的時候，才能種根治了這個問題。（那都是2年后的事兒了）

? ? ? ? dubbo這的問題，我印象中好像也就這么多了，因為公司小，version的概念我們用不上，一般不推薦修改接口，而是新追加接口來完成功能的進化，但帶來的就是服務化內部的代碼復雜度很高，一個dubbo服務要同時維護著好幾個接口，這是缺點。dubbo就這么一直陪著我們到2018年中旬，