【微服務】開啓巨石應用到微服務的探索

背景

在過去的一年時間裏，我一直在從事一件事情，將現有的單體應用（巨石應用）向微服務改造。 接下來，將持續整理一些在微服務路上的學習與成長。

爲何要作微服務

單體應用，開發、部署簡單，適合於小項目快速開發。但隨着業務增加，也會暴露出一些問題：

1. 代碼錯綜複雜。代碼相互依賴，常常出現修改一個bug，卻影響了其餘功能模塊。
2. 資源搶佔，相互影響。整個系統運行在一個進程中，時常由於導出大量數據致使服務響應時間過長，嚴重影響用戶體驗。
3. 性能優化困難，不便擴展。有的服務是IO密集型，有的服務是CPU密集型，在同一個項目的時候，只能購買更高配置的機器，成本太高。
4. 系統升級效率慢。新功能開發和bug修復週期時間長，修改後，迴歸測試執行較長。
5. 學習成本高。業務愈來愈多，新加入的同事不能快速上手。文件數量多，業務耦合度高。

而引入微服務後，將各個模塊按照業務單元拆分後，將較好的避免以上問題。

1. 微服務自己能夠按照本身的計劃進行維護升級，只須要保證接口和參數格式穩定，將不影響其餘調用方。
2. 對於qps較高的服務，能夠經過擴展節點數量，提升服務吞吐量。
3. 程序運行獨立的環境中，避免資源搶佔。

帶來的問題

當咱們享受微服務帶來的幸福時候，也要明白這樣架構，所帶來的複雜性。

1. 自動化運維（DevOps）。服務數量愈來愈多，系統配置，運行狀況，上線操做將指數型增加。若是還依舊像單體應用的時候，人爲處理，將變得很是吃力。
2. 服務調用時候，超時機制。服務在網絡中調用時候，若是遇到超時後，如何重試，如何避免數據重複提交等問題。
3. 分佈式事務。在單體應用中，咱們能夠經過spring的事務管理器很容易實現。但微服務後，若是使用跨數據庫的分佈式事務，將嚴重影響性能。如何根據業務解決數據異常帶來問題？

總結

微服務探索中，痛並快樂着。

最後，給出兩點建議：

1. 微服務不建議一下拆分很細，增長系統維護成本。最後粗略拆分，不斷迭代，拆分。
2. 微服務擁有獨立的數據庫，不可共享。數據訪問必須經過服務調用實現。雖然很痛苦，可是堅持下來很不錯。