1.為什么要微服？
首先我們目前后台系統業務鏈目前還是相對不是那么復雜，但隨着項目的拆分，業務的快速推進，各項目模塊的接口也隨之增加，開發的復雜度不斷增加，為以后擴展埋下隱患，而規划新的框架目前主要解決的問題的 組內開發的復雜度和技術棧的統一。
首先，通過分解巨大單體式應用為多個服務方法解決了復雜性問題。在功能不變的情況下，應用被分解為多個可管理的分支或服務。每個服務都有一個用RPC-或者消息驅動API定義清楚的邊
界。微服務架構模式給采用單體式編碼方式很難實現的功能提供了模塊化的解決方案，由此，單個服務很容易開發、理解和維護。
其次，微服務架構模式是每個微服務獨立的部署。開發者不再需要協調其它服務部署對本服務的影響。這種改變可以加快部署速度。快速的部署變化。微服務架構模式使得持續化部署成為可能。
最后，微服務架構模式使得每個服務獨立擴展。你可以根據每個服務的規模來部署滿足需求的規模。甚至於，你可以使用更適合於服務資源需求的硬件
2. Spring Boot是什么，解決哪些問題
SpringBoot是伴隨着Spring4.0誕生的；從字面理解，Boot是引導的意思，因此SpringBoot幫助開發者快速搭建Spring框架；
SpringBoot幫助開發者快速啟動一個Web容器，SpringBoot繼承了原有Spring框架的優秀基因，SpringBoot簡化了使用Spring的過程。
Spring由於其繁瑣的配置，一度被人認為“配置地獄”，各種XML、Annotation配置，讓人眼花繚亂，而且如果出錯了也很難找出原因。
Spring Boot更多的是采用Java Config的方式，對Spring進行配置。
可以看到，采用了spring-boot-start-actuator之后，直接以REST的方式，獲取進程的運行期性能參數。
當然這些metrics有些是有敏感數據的，spring-boot-start-actuator為此提供了一些Basic Authentication認證的方案，這些方案在實際應用過程中也是不足的。
Spring Boot作為一個微框架，離微服務的實現還是有距離的。
沒有提供相應的服務發現和注冊的配套功能，自身的acturator所提供的監控功能，也需要與現有的監控對接。沒有配套的安全管控方案，對於REST的落地，還需要自行結合實際進行URI的規范化工作。
采用了Spring Boot之后，技術管理應該如何進行？
正因為Spring Boot是與Spring一脈相承的，所以對於廣大的Java開發者而言，對於Spring的學習成本幾乎為零。
在實踐Spring Boot時學習重點，或者說思維方式改變的重點在於：
1）對於REST的理解，這一點尤為重要，需要從設計、開發多個角色達成共識，很多時候都是對於HTTP 1.1協議以及REST的精髓不理解，導致REST被「盲用」而產生一些不好的效果。
2）對於YAML的理解和對於JavaConfig的理解，這兩點相對較為簡單，本質上是簡化了xml文件，並提供等價的配置表述能力。
1. 豐富的工具鏈為SpringBoot的推廣帶來了利好。
2. SpringBoot的工具鏈主要來自於兩個方面：
1) 原有Spring積累的工具鏈；
2) SpringMVC或者其他REST框架使用HTTP協議，使得HTTP豐富的工具成為SpringBoot天然的資源。