最近在进行项目架构的调整，准备从springmvc转换到spring cloud，也就是微服务框架。自然就需要将原有的项目转化为spring boot形式。
微服务
在了解spring boot之前，先了解一下微服务的概念。在刚开始的时候我简单理解微服务就是将服务切割放在不同的线程，后来查看资料之后，有了更深刻的理解。
What 微服务是什么
简单来说，微服务是根据业务来拆分项目独立部署并且隔离开来，通过轻量的API调用不同的服务，也就是组件。这句话的核心在于拆分项目，这就定义了责任；API调用，这就定义了通信方式。理解这两点就可以基本明白微服务是什么。
这时候自然而然我就对比了一下我们目前的三层架构，举个例子：三层架构就好像大超市一样，顾客就相当于用户，顾客进入沃尔玛超市后进行购物，在这个过程中，超市在没开门前要进货、整理货物、打开大门等（Tomat启动）。如果想增加商户，就得开新的店面（增加新的功能模块）。要进行安全演习和测试，就得全局设定（测试）。人太多了，就只能对整个超市进行疏散人流（负载均衡）等等，这都是以整体的思维来看待问题。而微服务将整个超时拆成不同的地方，比如菜市场、书店、五金店等等，然后不同的店铺都是独立的个体，大部分问题都是独立解决。这就是思维的不同，一个是整体思维，一个是独立责任思维。
Where 微服务适用什么地方
微服务代表着拓展性，随着云服务的概念不断深入人心，微服务与之结合能够大大降低企业的运营成本，其团队组织也更倾向于全能。那么微服务应当适用在什么地方呢，任何东西都有其两面性，我认为整体性在项目复杂度不高的情况优于微服务，因为其投入不会太大，拓展性的需求不高，相比于分布式的微服务更为稳定。之后随着项目复杂度以及运维要求增加，这个时候的微服务优越性不断体现，那我们就可以使用微服务架构来进行开发。就比如以前京东可以采用整体性架构来完成客服模块，但是随着其体量越来越大，运营成本越来越高，功能要求越来越多，那么转换成微服务架构收益远远高于整体性架构。
When 微服务适用于什么时间段
根据上一段的结论，总结其适用于项目复杂度高、运维成本高、功能要求多的时间段。
Who 微服务的团队怎么样
根据我的了解，以亚马逊的微服务团队（十二人）为例，他们每个人都身经百战，具有非常高的技术素质和能力，他们不仅能够进行编程，也能完成运维工作。因而微服务团队经常是一个完整的项目团队，有能力完成一个单独的项目，从前台到后台，从数据库到服务器，都能提供支持。
Why 为什么要使用微服务
上学时候做阅读题经常会要求从优点缺点来分析一个问题，同样按照这种方法来分析微服务。
微服务的优点：
1、解决复杂性问题，容易开发、理解和维护组件，形成单体型的应用，关注于一个业务功能。
2、每个微服务都可以由单个团队开发。
3、微服务是解耦的，它们之间的通信是以轻量api的方式进行通信。
4、微服务因为是独立，所以不同微服务可以采用不同的技术来实现，易于发挥技术的长处。
缺点：
1、通信及延迟问题，这是我第一想到的问题，因为不同的线程之间的通信是受网络制约的。
2、团队和运维要求，因为每个微服务都需要团队支持，这个团队素质要高，能够完成独立项目，人就很重要了
3、同步异步问题，不同服务之间的数据处理及事务处理
总而言之，优点在于其独立的思想，能够发挥出高拓展新、耦合度低、专注于业务，缺点也在于其独立的思想，如何让它们形成整体是个问题。
Spring boot简介
理解了微服务架构的思想之后，我们再来看看为快速开发领域而生的Spring boot。
spring boot是伴随spring4推出，为了帮助spring摆脱“配置地狱”的微框架。所以可以这么说，spring boot是Spring为了简化配置，在快速应用开发领域成为领导者而开发的微框架，因为其很多东西跟spring有相同的地方，从原有的springmvc转化到spring boot，其实就是各种配置以spring boot的形式重写，另外需要处理各种jar包，将不需要的jar包依赖去除。其价值要在Dubbo或者spring cloud下才能发挥更为重要的作用。
其核心思想就是“习惯大于配置”，所以很多东西它都帮助配置好了，目的就是快速搭建一个可运行的项目。当然如果你认为不需要配置就错了。其实很多东西还是需要自己配置的，只是配置手法和操作被简化了。
我感觉就是Spring的简化版本，在理解或用过Spring配置之后使用它真的很轻松，就是将注解替代xml。
我通过百度配置方式的方法将项目中的两个模块都转化为了Spring boot方式，配置简单很多，但是并没有感受到微服务的优越性，接下来继续学习spring cloud吧。