一、個人理解之技術選型：

首先在當前的大環境下，微服務已經是大趨勢所在，目前微服務有兩個解決方案，dubbo和spring cloud，下面將對比一下兩個解決方案的優缺點，然後在說一下為何我最終會選擇spring cloud。但是我們不必在這個方便過於糾結，這兩個方案在當下都有很多的公司在採用，所以無論學習哪一個都是可以保證能夠找到工作的，所以在選擇的時候選擇自己拿手的喜歡的就可以了，當然如果有心儀的公司那就可以參考一下其技術棧在選擇也是可以的，以下之言有部分來自其他博文供參考。
- dubbo：（來自網上）
1、歷經阿里雙11的考驗，大廠背書
2、使用二進位制傳輸，減少寬度的消耗，但同時也增加開發的難度dubbox增加restful
3、有很多阿里出來的員工，在很多公司任職，自帶架構所以採用的也比較多
- spring cloud ：
1、東家是大名鼎鼎的spring source產物，社群活躍同時spring組建的有公司專職做開源，所以這個發展會更加穩定，相比於dubbo斷更以及不是專職做這個事情，這個更有保證
2、以spring boot為基礎構建，sprng boot 整合大量常用的框架技術，使得我們在初學的時候成本大大降低（這裡我就想到曾經的同學一個java環境變數配幾個周-_-），這個也是很多新興網際網路公司選擇的原因，減去大量的配置，使得我們的精力在於開發和學習框架的使用上
3、元件眾多，每個元件的替代性強（當然對於選擇強迫症的同學這也可能是個缺點，同時的確面臨選型的抉擇問題），是一套完整的解決方案，不同於dubbo其只提供rpc

綜上所述 我是優先於選擇spring cloud的，但是這裡我依舊說明，dubbo也是可選的，上面由於對於dubbo瞭解不多，所以講解也有點片面，所以僅供參考

二、spring cloud 有17各元件，我滴天呀怎麼學

是的spring cloud 提供一整套的微服務解決方案，所以體系龐大大致有17個元件。有些同學估計看到這個地方頭都大了起來，但是我們要了解我們並不是所有的元件都要去學去用到，學習的二八原則即學20%的東西解決80%的問題，一個模組一個模組的來啃就好了。

其次有很多的時候我們也要有良好的學習方法，記得我曾經閱讀mybatis原始碼的時候，我從配置檔案入口開始看，結果一個XMLConfigBuilder裡面的的配置解析我看了一個周，最終倒在了ognl上面的解析Mapper檔案，後來，我發現這樣的學習方法是不對的，我們需要有一個整體的概念，然後採用自頂向下的學習方法，在來逐一攻克從面到線最終才是到點

三、springcloud的整個元件架構圖

這個是本人目前理解的一個架構圖，在附上一張在網上找的傳智播客的一張圖（由於以前是看著傳智播客王健老師的視訊進階和入門的，雖然現在王老師不在傳智，但是他曾經的確是我的領路人，再次是非感謝王健老師，他目前就職於甲骨文華育興業任CTO一職，負責大資料的教學，公眾號 “ [健哥說程式設計]”）

的確有很多的元件，但是我們現在目前只學習那些關鍵性的元件即可，後面再慢慢的啃。在筆者的學習的過程中，發現只是單純的學習如何去用，其實並沒有那麼難

四、為何要使用微服務

因為網上有大把的介紹，所以把這個內容放在了最後，肯定會有相同的，但是也加上自己的理解在裡面。

• 1、降低模組間的耦合，開發人員更加專注於一個模組的開發，大廠的人一般初期都是擰固定螺絲的，人員的離職對於整個專案影響較小，當然這個maven的多模組也是可以做到的
• 2、結合docker部署可以做到更加的便捷，針對每個模組來進行升級提升迭代效率，針對單點部署，更容易擴充套件
• 3、容錯性設計（熔斷、限流、服務發現）大大加強對外提供服務的穩定性
• 4、元件化，提高複用，簡化開發

當然缺點也在裡面：
- 1、提高了專案的複雜度
- 2、出錯不易找出原因
- 3、cap理論的取捨，以及資料庫端如何去保證一致性等產生的問題