? ? ? ? 上回說到瞬欧，我們把架構體系的工程剝離了出來呢铆，由原來的一個大工程晦鞋，分成了9個自工程，把springMVC和dubbo都分別拆了出來棺克，目前架構其實清晰多了悠垛。
? ? ? ? 我們就按照這個思路，繼續(xù)往前跑娜谊，dubbo的api我們放到了自己的git私服上确买，然后出現(xiàn)了一個問題，就是版本迭代有時候要升級接口參數(shù)因俐，但往往因為通知不到位拇惋，會出現(xiàn)其他接口報錯。以前我在上一家公司的做法是：
? ? ????1.先用dubbo-monitor查一下調用方
? ? ? ? 2.挨個通知調用方我的接口要升級了
? ? ? ? 3.期間我會同時允許亮哥版本同時存在
? ? ? ? 4.調用方從我的1.0版本升級到2.0版本的時候抹剩，我開始觀察1.0版本接口的流量
? ? ? ? 5.確認沒有流量的情況下撑帖，我會下掉api及dubbo服務。
? ? ? ? 但是問題來了澳眷，我發(fā)現(xiàn)從0-1建立這樣的一個制度胡嘿，并完全讓大伙執(zhí)行下去的難度很大，這主要由兩方面決定的钳踊。一個是公司人員對dubbo的熟悉程度并不夠衷敌，其次是勿侯，本身能力并不強，在執(zhí)行方面也會出現(xiàn)各種問題缴罗。因此助琐，我開始考慮通過技術方式改變這種問題。
? ? ? ? 當時我想到的面氓，dubbo的接口升級兵钮，如果是加字段的話，消費者即便不更新也不會受影響舌界，因此我嘗試了dubbox提供的kyro序列化方式（dubbo默認的序列化是hession2）的方式來解決掘譬，測試了一下沒問題，就匆匆上線了呻拌。結果上線沒多久葱轩，有坑了，添加一個基礎類型字段是沒問題藐握，但如果增加一個class靴拱，或者list就報錯了。因此趾娃，這個方式驗證失敗缭嫡。
? ? ? ? 接下來缔御，我去嘗試json的序列化方式抬闷，結果發(fā)現(xiàn)也存在對象套用對象的坑在里頭，遂放棄耕突。
? ? ? ? 這時笤成，架構師和我提了個概念，我們可以考慮spring cloud的微服務的方式去解決這塊的問題眷茁，通過http的方式訪問炕泳，能繞開序列化的問題。但因為當時技術部只有10多個人上祈，我們連dubbo都沒掌握完全培遵，更不敢嘗試新的框架。另外一點是登刺，當時我也打聽了一下籽腕，杭州沒有哪家成熟的互聯(lián)網(wǎng)公司是用spring cloud在做微服務的，因此纸俭，不敢做第一個吃螃蟹的人啊皇耗。所以這塊，就硬著頭皮讓大伙按照規(guī)矩揍很，修改接口及時通知的策略執(zhí)行郎楼，其實后面有好多次事故都是因為這步驟沒有執(zhí)行到位万伤，直到spring cloud服務體系切換完畢的時候，才能種根治了這個問題呜袁。（那都是2年后的事兒了）
? ? ? ? dubbo這的問題敌买，我印象中好像也就這么多了，因為公司小阶界，version的概念我們用不上放妈，一般不推薦修改接口，而是新追加接口來完成功能的進化荐操，但帶來的就是服務化內(nèi)部的代碼復雜度很高芜抒，一個dubbo服務要同時維護著好幾個接口，這是缺點托启。dubbo就這么一直陪著我們到2018年中旬宅倒，
