传统的单体应用：
所谓的单体应用程序，通俗来说就是把所有的功能全部堆积在一起。这个应用大部分都是一个war包或者jar包。随着业务的发展、功能的增加，多年以后这个单体项目将得越来越臃肿。
这样的单体应用在公司创建初期是一种比较好的方案，要快速增加新功能或部署发布都比较简单。不过，随着时间的推移，危机也会慢慢显露出来。任何一个bug都可能导致整个应用瘫痪，正所谓牵一发而动全身。
微服务概述：
微服务是一种架构风格，即将单体应用划分为小型的服务单元，微服务之间使用http的api进行资源访问操作。
在笔者看来，微服务架构的演变更像是一个公司的发展过程，从最开始的小公司，到后来的大集团。大集团可拆分出多个子公司，每个子公司的都有自己独立的业务、员工，各自发展，互不影响，合起来则是威力无穷。
使用微服务架构的优势和劣势：
微服务：臃肿的系统、重复的代码，超长的启动时间带给开发人员的只有无限的埋怨，丝毫没有那种很舒服的，很流畅的写代码的感觉。他们把大部分时间都花在解决问题和项目启动上了。
优势：
使用微服务架构能为我们带来如下好处：
1.服务的独立部署，每个服务都是独立的项目，可以独立的部署，不依赖于其他服务，耦合性低。
2.服务的快速启动，拆分之后的服务启动速度必然要比拆分之前的快很多，因为依赖的库少了，代码量也少了。
3.更加适合敏捷开发：敏捷开发以用户的需求进化为核心、采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。
4.职责专一，由专门的团队负责专门的服务：业务发展迅速时，研发人员也会越来越来，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。
5.服务可以动态按需扩容：当某个服务的访问量较大时，我们只需要将这个服务扩容即可。
6.代码的复用：每个服务都提供rest api,所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。
劣势：
微服务其实是一把双刃剑，既然有利必然有弊。下面我们来谈一下微服务有哪些弊端，以及能采取什么办法避免。
1.分布式部署，调用的复杂性高：单体应用的时候，所有的模块之前的调用都是在本地进行的，在微服务中，每个模块都是独立部署的，通过http来进行通信，这当中会产生很多问题，比如网络问题、容错问题、调用关系等。
2.独立的数据库，分布式事务的挑战：每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务，可以选中适合自身业务的数据，比如订单服务可以用MySql,评论服务可以用Mongodb、商品搜索服务可以用ElasticSearch.缺点就是事务的问题了，目前最理想的解决方案就是柔性事务中的最终一致性。
3.测试的难度提升：服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方法都是有影响的，那工作量就太大了。这里强调一点，就是api文档的管理尤为重要。
4.运维难度的提升：在采用传统的单体应用时，我们可能只需要关注一个tomcat的集群，一个Mysql的集群就可以了，但这在微服务架构下是行不通的。当业务增加时，服务也将越来越多，服务的部署、监控将变得非常复杂，这个时候对于运维的要求就高了。
重构前的准备工作：
对于上不上微服务，关键在于公司的发展程度。系统是否真的到了必须做分解的地步？在微服务之前一定要做好技术选型。用什么框架来构建微服务？公司是否支持重构？这些问题都很重要，没有公司的支持一切都是空谈。
在重构之前，架构师一定要对公司所有产品做一遍梳理，出一个重构方案。重构时最好采用循坏渐进的模式，首先对一个产品进行重构规划，抽出业务服务，再抽出这个产品所依赖的基础服务，基础服务是最为重要的。等一个产品稳定之后，再重构其他产品，把核心业务放到最后面。不要想着一步登天，重构就像堆积木一样，堆着堆着就高了，一周抽一个微服务，慢慢就都变成微服务了。
Springcloud概述
springcloud是一系列框架的有序集合。它利用的springboot的开发便利性，巧妙地简化了分布式系统基础设施的开发，如服务注册、服务发现、配置中心、消息总线、负载均衡、断路器、数据监控等。这些都可以用springboot的开发风格做到一键启动和部署。通俗来讲，springcloud就是用于构建微服务开发和治理的框架集合（并不是具体的一个框架）
五大组件
1.Eureka注册中心
注册中心在微服务架构中是必不可少的一部分，主要来实现服务治理功能，Eureka是一个基于REST的服务，并且提供了基于Java的客户端组件，能够非常方便地将服务注册到springCloud Eureka中进行统一管理。注册中心无非就是管理所有服务的信息和状态。若用我们生活中的例子来说明的话，12306网站比较适合。
首先，12306网站就好比一个注册中心，顾客就好比调用的客户端，当他们需要坐火车时，就会登录12306网站上查询余票，有票就可以购买，然后获取火车的车次、时间等，最后出发。
程序也是一样，当你需要调用某一个服务的时候，你会先去Eureka中去拉取服务列表，查看你调用的服务在不在其中，在的话就拿到服务地址、端口等信息，然后调用。
注册中心的带来的好处就是，不需要知道有多少提供方、你只需要关注注册中心即可，就像顾客不必关心有多少火车在开行，只需要去12306网站上看有没有票就可以了。
2.客户端负载均衡Ribbon
目前主流的负载均衡方案分为两种：一种是集中式负载均衡，在消费者和服务者提供方中间使用独立的代理方式进行负载，有硬件的，也有软件的（比如Nginx）。另一种则是客户端自己做负载均衡，根据自己的请求情况做负载，Ribbon就属于客户端负载均衡的工具均衡。
Ribbon作为一款客户端负载均衡框架，默认的负载策略是轮询，同时也提供了很多其他的策略，能够让用户根据自身的业务需求进行选择。如图
3.Hystrix服务容错处理
在微服务构架中存在多个可直接调用的服务，这些服务若在调用时出现故障会导致连锁效应，也就是可能会让整个系统变得不可用，这种情况我们称为服务的雪崩效应。
我们可以通过Hystrix解决服务雪崩服务，Hystrix是针对微服务分布式系统采用的熔断保护中间件，相当于电路中的保险丝。在微服务构架下，很多服务都相互依赖，如果不能对依赖的服务进行隔离，那么服务本身也有可能发生故障，Hystrix通过HystrixCommand对调用进行隔离，这样可以阻止故障的连锁效应，能够让接口调用快速失败并迅速恢复正常，或者回退并优雅降级。
4.API网关
API网关是对外服务的一个入口，其隐藏了内部架构的实现，API网关可以为我们管理大量的API接口，还可以对接客户，适配协议、进行安全认证、转发路由，限制流量、监控日志、防止爬虫、进行灰度发布等，比如用户评估一个小区，评估完成之后需要展示小区详情、房价走势、成交数据、挂牌数据等，这些服务信息都在不同的服务中，前端服务想要实现这样一个功能就需要和众多的服务进行交互，调用它们提供的接口，这样性能肯定是低的，而且前端系统的逻辑更复杂了，它需要知道所有提供信息的微服务。这个时候Api网关的作用就体现出来了，通过API聚合内部服务，提供统一对外的api接口给前端系统，屏蔽内部实现细节。
Gateway作为springcloud生态系中的网关，它不仅提供了统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全、监控/埋点和限流等。
5.分布式配置
微服务架构下，服务的数量少则几十个，多则几百甚至上千。每次修改一个配置都需要跟进修改多个项目、然后再重启这些项目、配置的集中管理在这种情况下显得格外重要，分布式配置管理可以将多个项目的配置进行集中化的管理，统一修改，实时生效，避免重复的劳动，可以节约时间，降低出错的概率。
Spring cloud Config是一个用来为分布式系统提供配置集中化管理的服务，它分为客户端和服务端两个部分。客户端服务从服务端拉取配置数据，服务端负责提供配置数据。
Springcloud Config底层存储提供了多种方式，其中最好的是用git来存储配置信息，还可以跟踪版本，随时恢复到指定的版本，当然也支持svn、本地文件存储等方式。