基礎知識
微服務架構
簡單來說微服務架構就是把一個原本整合在一起的系統拆分成多個系統。微，代表了每個系統拆分的體積都不是很大，便於後期的維護和管理。服務，代表了系統拆分後的職責是對外提供服務，無論是業務功能或者是數據支持等等，是一種對外，面向其他系統的設計。由於拆分成了不同的項目，每個項目都可以存在自己的架構、體系、數據存儲、自動化測試等等，各個服務之間沒有耦合使得每個單體的自由度非常高，甚至可以使用不同的語言來編寫。
爲什麼要做微服務
其實就算你的公司裏沒有使用Spring Cloud之類的微服務框架，但是隻要存在系統拆分之後相互調用的關係，其實也就可以說是一種微服務架構，爲什麼要使用微服務架構其實答案很簡單，現在的互聯網行業發展迅速競爭激烈，基本上各種app，活動都是幾天一變，反映到我們開發人員的身上基本就是各種需求變更，快速迭代。如果你們的系統是一整個完整的單體系統的話，那麼顯然隨着業務發展和公司壯大，這個系統將會越來越大，越來越複雜，維護成本越來越高甚至於到最後沒有人敢維護，而且這麼大的項目，編譯打包一次都需要很長時間吧？而拆分了微服務之後每個團隊各司其職，需求來了之後各自開發再對接接口即可，出了問題可以快速定位到是哪個服務哪個接口甚至哪個人身上，省時省力而且系統架構更加清晰。而且各個服務之間的側重點不同，甚至可以結合自己系統的特點選擇做適當的技術選型，靈活又方便。
微服務帶來的挑戰
- 運維成本增加
既然拆分了服務，那麼對應的部署的服務肯定會大量增加，對於運維人員來說工作量和工作難度應該都會有所增加。 - 接口的質量
雖然拆分了服務，但是畢竟服務永遠是服務於業務的，那麼各個系統之間肯定還會存在業務依賴，只不過不再是單體服務中代碼互相調用，而是系統間通信調用，所以接口的質量和管理就顯得更加重要了 - 分佈式的複雜性
一提起分佈式顯然大家都明白，很多情況會變得複雜起來，包括寫代碼的過程中可能要引入分佈式事務，異步消息等等，而分佈式之間可能還存在網絡、環境等各種問題，對於開發和運維人員排查問題都是挑戰。
微服務的實施要點
組件化
每個服務都應該被拆分後看作是整個公司系統運轉的組件，大家各司其職又團結合作，相互之間既有依賴也有獨立，每個組件獨立部署、維護、升級，不影響其他組件
按業務區分
一般來講微服務會以業務區分，過往的體系中也許我們只需要從技術角度區分人員團隊，例如DBA團隊，運維團隊，後端團隊，前端團隊，但是微服務中，我們大可以打破這種界限，直接根據業務去進行劃分，而業務中可以是全棧式的，從前端到DBA甚至到產品，應有盡有。
去中心化治理
當一個項目是集中化管理的話，那麼很有可能存在一套統一的標準體系，但是畢竟所有事物都是在進步和改變的，當初設計的標準對於某些方面來說可能已經拖了後腿，但對於某些方面來說又是金科玉律，尤其是各種技術幾乎都有自己擅長和不擅長的事情，完美的編程語言或者技術目前來說是不存在的，所以造成了業務和技術不匹配，但是如果採用了微服務治理可以有效地做到去中心化治理，各個服務自己揚長避短。
容錯
一個單體應用的話可能由於某個模塊的崩潰導致整個系統同時也不可用，而微服務很可能存在某個服務出現了問題，但是其他服務用的好好的，這看似是個優點，但是如果某個業務由於崩潰，導致其接口全部超時，其他項目調用接口時會阻塞等待，那時間長了甚至有可能由此引起其他項目的崩潰，原因恰恰是使用了微服務導致服務下線沒有第一時間被相關人員注意到。
Spring Cloud
Spring Cloud可以說是微服務領域的佼佼者，雖然不是最早的微服務框架，但是可以說是目前最完善並且最流行的。Spring Cloud是基於SpringBoot實現的微服務架構開發工具，整套微服務架構中包括了配置中心，註冊中心，服務治理，網關，負載均衡，斷流器，智能路由，全局鎖，集羣決策，分佈式會話等等一系列的工作，對於中小型企業來說，可能沒有足夠的人力和能力去研發自己的微服務架構，那麼Spring Cloud絕對是不二之選。
