什么是微服务架构
是系统架构上的一种设计风格，将独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间基于HTTP的RESTful API进行通信协作。
每个小型服务都围绕各自的业务功能进行构建。每个服务都维护自身的数据存储、业务开发、自动化测试案例以及独立部署机制。
注：由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言编写。
与单体系统的区别
随着业务增长与开发，单体系统会显得更加臃肿，且由于单体系统往往部署在一个进程中，修改一个小功能，为了部署上线会影响其他功能的运行。单体系统内各个模块的使用场景、并发量、消耗的资源类型都各不相同，对资源利用又互相影响，导致各个业务模块的系统容量很难评估。
单体系统在初期可以实现比较方便地开发与使用，但是随着系统的发展，维护成本变大，且难以控制（这个是深有体会，当你一个系统业务复杂且架构设计不合理，同时以前的开发者之间没有什么规范的时候，这时候对于后来者来说对于功能的修改、维护、完善都是异常痛苦的）。
为了解决单体系统的问题，微服务架构将不同的模块拆分成多个不同的服务，服务能够实现独立的部署与扩展，且不同的服务都运行在自己的进程内，由于部署存在稳定的边界，这样每个服务的更新都不会影响到其他服务的运行。
同样由于是单独部署，我们可以更准确的为每个服务评估性能容量，通过配合服务间的协作流程可以更容易发现系统的瓶颈位置，以及给出较为准确的系统级性能容量评估。
微服务带来的新问题
运维的新挑战：由于微服务框架中，需要维护的进程数量增大，运维的过程需要更多的自动化。
接口的一致性：虽然拆分了服务，但业务逻辑的依赖不会消除，只是从单体应用的代码依赖变为了服务间的通信依赖。我们需要完善接口和版本管理，遵循更加严格的开闭原则。
分布式的复杂性：网络延迟、分布式事务、异步消息。
微服务的九大特性
服务组件化：
我们需要对服务进行组件化拆分。个人理解是，根据实际的业务需要，将业务耦合性强的业务内容放在一个服务中，然后不同的服务之间可以通过HTTP等通信协议进行协作。
就类似于乐高积木。
按业务组织团队：
这个目前跟我的领域无关，毕竟我现在只处于一个小兵的位置。
需要说明的是，开发大型项目时，微服务团队拆分建议按业务线进行拆分。
做“产品”的态度：
每个业务团队应该对其服务的整个生命周期负责，而不是以往的项目的模式。
智能端点与哑管道：
在微服务架构中，通常会使用以下两种服务调用方式：
1）使用HTTP的RESTful API或轻量级的消息发送协议，实现信息传递与服务调用的触发。
2）通过轻量级消息总线上传递消息，类似于RabbitMQ等一些提供可靠异步交换的中间件。
去中心化治理：
去中心化管理数据：
每个服务都有其自有的数据库，这就是数据管理的去中心化。
对于分布式事务，在微服务架构间强调各服务间进行“无事务”的调用，而对于数据一致性，只要求数据在最后的处理状态是一致的即可；若在过程中发现错误，通过补偿机制来进行处理，使得错误数据能够达到最终的一致性。
基础设施自动化：
在微服务架构中，务必从一开始就构建“持续交付”平台来支撑整个实施过程，该平台需要两大内容：
1）自动化测试 2）自动化部署
容错设计：
快速检测故障，并可能自动恢复服务是必须设计和考虑的。
演进式设计：
可以在项目初期使用单体系统，随着项目演变逐步将业务进行拆分。
Spring Cloud介绍
Spring Cloud包含多个子项目：
Spring Cloud Config：配置管理工具，支持使用Git存储配置内容，可以使用它实现应用配置的外部化存储，并支持客户端配置信息刷新，加密/解密配置内容。
Spring Cloud Netflix：核心组件，对多个Netflix OSS开源套件进行整合。
Eureka：服务治理组件，包含服务注册中心，服务发现和发现机制的实现。
Hystrix：容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和故障提供强大的容错能力。
Ribbon：客户端负载均衡的服务调用组件。
Feign：基于Ribbon与Hystrix的声明式服务调用组件。
Zuul：网关组件，提供智能路由、访问过滤
以上是能够搭建起一个基本项目所使用到的组件。