文|作者|文大師
/本文屬原創，轉載請聯系
因為工作原因，無暇更新，最近更新的技術文章還要追溯到去年9月份，近期會恢復更新，還是以spring系列為主，上一次講述了spring-security-oauth2的相關應用，簡單定制適合中小項目，最近正在學習spring-cloud微服務架構，遂決定記錄在此以作學習交流之用。
隨著項目規模擴大以及業務分化，模塊服務化成為必然，spring.io因為具備良好的生態結構，微服務架構spring-cloud應運而生，微服務通常伴隨著分布式系統的建立，至于微服務的各種利弊，這里就不再贅述了，自請搜索各大社群查看。這里主要講我自己的看法，國內一般都是使用Dubbo+ZooKeeper實現分布式系統，但個人拙見，RPC協議不可避免的代碼層面的耦合度問題讓我始終沒有好感，REST Full的微服務模式對于國內多變的業務和各種變態的產品需求變更顯得更加親民，故在此選擇spring-cloud構建微服務框架，本章屬完全理論知識概括，無實際內容，已了解的同學可直接略過。
無論是Dubbo或是別的分布式框架，理論上的框架結構都是相似的，區別僅在于各實現不同而已，一個好的架構體系應該是考慮實際業務選用不同的實現來最終滿足產品業務的需要，先來看看分布式一般應該具備的基礎服務：
以上是我認為的最小基礎服務，本系列文章也將圍繞這些基礎服務構建一個微服務基礎架構，至于其他理論知識點都不在本系列文章討論，只關注實用性，代碼本身也盡量不涉及邏輯業務，目標是最后集成Docker做到開箱即用，因為本人也是初學，代碼可能數次更新，照慣例每次更新都會有一篇文章介紹，代碼會打上tag發布到https://github.com/kaenry，錯誤與改進希望大家指正。
先說說目前已看到的缺點：
-
spring生態雖然看似完整，但是屬于嚴格的Java體系，與其他語言配合會非常吃力，再者現在稍微大點的項目都會集成很多不同語言環境，比如最近風靡的NodeJS等，這是可以預見的最大缺陷 - 分布式事務是一個非常棘手的問題，在本次實戰中將采用分化服務，將事務控制在單一服務中從設計上避開此問題，感興趣的同學可搜索冪等性了解更多
- 部署可能成為難點
技術選型暫定為Gradle多模塊構建項目，jdk 1.8編譯環境，spring boot 1.5+，spring cloud Dalston.RELEASE，DAO層目前在JPA和MyBatis之間徘徊，服務之間調用采用REST，工具利用RestTemplate，前端頁面采用Vue 2，可能會使用SSR Nuxt，緩存使用Redis，隊列使用Rabbit，模擬使用GitHub API...
/
以上
我的博客即將搬運同步至騰訊云+社區，邀請大家一同入駐：https://cloud.tencent.com/developer/support-plan?invite_code=3b89y7er14g04
