類似於雜談性質的文，總結下公司實行微服務化上遇到的一些問題。
雖然參與了開發過程，但整體更像是個旁觀者，前期還是大家討論怎麼做，後來慢慢就由負責架構的同事專職做規劃，拆分任務去完成。

萬事開頭難

最初的架構(資料庫和其他部分都做了簡化)

初衷並不是為了趕時髦，為了團隊KPI之類的，而是遇到了一個很現實的問題。
研發團隊慢慢從幾個人發展為十幾，幾十人，所有人都在一個項目上開發，代碼倉庫越來越大，merge衝突越來越頻繁，部署時也往往會因為一些bug導致全站部署拖延。
再加上訪問量越來越高，帶來的不確定性越來越大，一些流量較大的業務可能會導致整站都掛掉。
內部和外部都出現了問題。

當時雖然研發團隊的人比較多了，但大家都基本是做業務兼做非業務的東西，沒有成立專門的非業務部門。
大家都是在業務開發之外安排了微服務化相關的開發，這導致了進程緩慢，並且也隱式確定了微服務化不能影響現有業務開發。

最開始設想劃分粒度應該粗一些，按照各個大頻道來劃分（有點類似於分子站）。
但遇上了一個問題，BL和DAL層的代碼是共用的，再加上之前的模塊化不合理，導致一個模塊直接使用了屬於另一個模塊的業務代碼。
讓這更糟糕的是業務還在飛快迭代，這兩層的代碼也會發生很大的改變。
這時就有兩種選擇：
一種是複製，把需要的BL和DAL層代碼複製到各服務中；
另一種是抽取依賴，把BL和DAL層代碼抽離成一個單獨的jar，被各個服務依賴。

前者會需要做頻繁的同步，容易出現問題，很耗費精力。
當時我們選擇了後者，先將他變為一個技術債解決現在的問題。

結構就成為了這樣
組內也有同事開始脫離業務，慢慢專註在微服務化這一方向上，隨後從業務組中慢慢抽離出了一個基礎架構組（簡稱基架）。

路由 服務間調用

這一部分我就基本是路人了，會更接近於講故事。
現在，spring cloud已經成為了一個比較成熟的解決方案，dubbo也重新被維護。
但當時，比較靠譜的選擇只有dubbo，可能是出於對今後自己維護方便的考慮，基架最後的方案是參考dubbo，再結合一些現有的技術來實現自己的服務註冊中心和服務請求路由。
註冊中心用zk實現，裡面存儲服務版本、各個微服務名稱、微服務版本以及伺服器列表和API。
服務間調用使用了netty，ribbon等框架。
具體細節在這裡不做過多描述了。
除了保留session處理相關、文件上傳下載相關服務等介面以及頁面渲染，原來的主站變為了一個gateway。
於是變成了以下這樣：

我們的坑

至此其實已經稍微有點微服務的樣子了... ...
但還存在很多問題。
細心的朋友可能發現了上圖中所有的服務還都依賴一個db！（以及對應的只讀實例等）
所以...存儲掛了，該掛的還是都掛了。
於是再接下來的一段時間里，基架那邊進行了一些比較大的業務拆分，將一些核心業務進行了分表分庫使用單獨的存儲，這工作今日還在進行，為網站的穩定做出來很大貢獻。

明天

其實還有很多東西都沒有(鏈路監控已經做好了...插不進上面 這裡說下):
一些服務間直接調用的解耦，舉個例子，一個用戶發完帖子後，現在是在代碼里依次調用其他服務去執行一些操作，其實這裡應該用消息發佈的模式去做；
配置中心；
安全性；
等等。
其實想一想這些是現在的spring cloud開箱即用的功能，如果當時這方案已經成熟或許可以少走一些彎路也說不定。

題外話

和技術和業務無關。
專門成立了基架組其實有好處也有壞處，好處是有一部分人可以專門攻堅網站遇到的問題，壞處是其他人怎麼辦。
首先這並不是說業務組沒有機會做一些技術相關的事，而是業務組做這些事的機會其實減少了，這給人帶來的技術提升也不一樣。
那在業務組怎麼提升自己的技術能力呢？
這也是我一直思考的問題。

我現在的一些方式無非就是課餘多看書看資料，增長自己的知識和視野。
但其實這樣也挺容易迷茫的，如何實用化呢，怎麼確保自己所學落地呢？
我的想法以及之後的做法會是直接在項目里用上，但這也不是說隨便往項目中加入不必要的東西，而是要加入會帶來性能提升潛力的東西，至於能否提升就要看自己的實戰了。
書看完就過，沒有自己的想法和思考終究只是錶面上的東西，會隨著時間漫漫淡忘，昨天在看NIO.2的筆記，14年記的現在基本已經忘卻了，這就很糟糕了。
最悲慘的不是學過後忘記了相關知識，而是忘記了曾經自己學過。