使用spring cloud搭建微服务框架，是我最近最主要的工作之一，一开始我使用bubbo加zookeeper制作了一个基于dubbo的微服务框架，然后被架构师否了，架构师曰：此物过时。随即，我上一套spring cloud，与公司大环境框架一致，也废了不少功夫，现在在这里分享给各位博友，如有不对的地方，欢迎大家直接评论区怂我。嘿嘿。
后续的代码已传至我的github，大家可以下载查看。
下载文件地址
微服务
首先我们要了解什么是微服务，以及微服务的作用，我们才能够顺利的搭建一个微服务架构。
博主先用一句话总结什么是微服务。
微服务就是对某个应用系统的每个API进行有效的拆分，然后通过某种连接方式，用以提供给其他应用系统调用的API的服务，在调用过程中实现和解决了一系列问题的综合就是微服务架构
顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"。
微
简单的讲就是体积小，随处运行，开发简单。传统的spring mvc框架配置繁杂，项目依赖杂乱，常常令开发和维护头疼不已。
服务
所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。
微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。
应用的拆分
有程序员A,B,C,他们现在都需要开发一套订单管理系统。
程序员A采用单系统架构，业务代码做mvc拆分，前端部分使用php做渲染层。
程序员B采用多应用架构，将产品、订单、物流、工单、客服等做应用级拆分，然后使用REST API或者tcp直接交互，每个应用都是一个mvc系统，独立开发。
程序员C采用微服务，将产品、订单、物流、工单、客服等做应用级拆分，再使用微服务框架将他们打散拆分成一个个的服务，例如订单列表查询服务、产品列表查询服务、产品详情查询服务等。使用一个个服务组成应用系统然后整合为订单管理系统
毫无疑问，程序员A的架构方式只能够在订单量小，吃了上顿没下顿的公司应用了。
而程序员B的架构类似大部分电商平台前期的架构逻辑，这套架构适应能力不错，但是随着系统的不断扩大，维护变的极为复杂，版本的更替，应用之间的API调用随着各种各样的需求复杂多变。
随着B架构的演变，诞生了程序员C的架构模式，微服务。微服务的理解就是将类似 订单列表查询服务、产品列表查询服务、产品详情查询服务进行细分，微分。使我们的代码能够通过统一的网关进行整合，能够让整个公司的系统开发力量彻底整合起来，并且微服务中的服务治理、熔断、负载均衡等等功能加强了对整个系统的治理能力。
目前应对中大型站点的后台架构，微服务是最适合的一套模式。同时spring boot的出现让微服务的开发变得更简单，理解更容易，例如dubbo的开发方式其实比较简单、易懂，spring cloud更是深度整合spring boot的能力，借用网友的一张对比图：
图出处：https://blog.csdn.net/zhouyanqingbfq/article/details/79407285
另外有很多关于微服务的知识理念，博主整理了一些：
https://blog.csdn.net/fly_zhyu/article/details/76408158
https://www.cnblogs.com/wintersun/p/6219259.html
spring boot
Spring Boot不是一门新技术，所以不用紧张。从本质上来说，Spring Boot就是Spring,它做了那些没有它你也会去做的Spring Bean配置。它使用“习惯优于配置”（项目中存在大量的配置，此外还内置了一个习惯性的配置，让你无需手动进行配置）的理念让你的项目快速运行起来。使用Spring Boot很容易创建一个独立运行（运行jar,内嵌Servlet容器）、准生产级别的基于Spring框架的项目，使用Spring Boot你可以不用或者只需要很少的Spring配置。
这一部分博主不再追述，提供一些资料大家看看就好，能点进这篇博文的人这里默认你会一些的吧。
spring cloud