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天然的资源。
