從0開始看dubbo原始碼過程中，對於整個原始碼閱讀與之前閱讀部分的Spring原始碼不太一樣，首先之前沒有看過原始碼，因為Spring的一個流程比較複雜，所以一直在跳轉跳轉，大流程比較多，生命週期較長。自己當時也不會做一下筆記。又元件比較多且複雜。但是Dubbo的分層很是清晰，幾層分下來一層一層的看下去，邊記筆記邊看，很舒服。以及Dubbo SPI初始化過程，裡面的SPI 雖簡潔，但不失優雅。通過約定的方式解決的依賴注入的問題。裡面的服務註冊中心、服務釋出、服務呼叫、攔截器鏈等等這些都是很舒服。在使用上通過策略自行組裝各個層面的擴充套件點實現RPC。

這次看看原始碼和之前的也不一樣，這一次更多的是思考了為什麼這樣寫，這樣寫有什麼好處。並且對類之間的關係通過UML圖等方式進行學習與瞭解。也做了筆記，也發表出來部落格，雖然質量上還是有些牽強，但是堅持下去，後面再回過頭來去提煉提煉，終究也是可以幫助自己成長的更好的。

總而言之，這一次並不是為了把所有的dubbo讀懂讀透，而是再出了問題的時候，知道是哪裡的問題， 能夠第一時間定位問題。無論是開發時期的依賴問題，服務釋出等常見的問題，知道了哪些元件可以擴充套件，可以更好的服務於當前業務。
因為目前在產品的定位就是可以解決開發過程、測試過程的任何問題，雖然很艱難，但是每一次也能逢凶化吉。

這次的總結並不代表結束，在交換層的netty這些技術也是需要深挖的，zk註冊中心也是可以深挖的，比如zk的選舉演算法，ZAB協議，雖然看了但是還不是很懂。dubbo的框架的整個流程分層，根據領域分層這也是需要一定的思考。

目前還很渺小，前幾天也和一位大佬面基，也強調了技術是為業務服務，其實我們現在的產品中除了功能 的完整性也是可以深挖很多東西的。比如應用機器學習提高準確性，當前的情感分析還是未處理階段，大資料效能問題並未真正的研究測試，只是浮於表面，對於這些，如果能夠根據業務場景進行不斷地深挖，還是很有挑戰的。