一、什么是微服务？
有时候，会有的人存在误解，所谓微服务就是SpringCloud。这种思想本身是不正确的，微服务是一种系统架构上面的设计风格，而SpringCloud则是一种较为适用于微服务架构的框架。 在java体系中，我们通常需要将一个大的类，拆分成若干个的小的类，每个类都具有自己独立的功能。多个类之间可能会根据自己的功能进行相互间的调用，但是每一个类又是独自存在的。
在微服务的架构体系中，我们则是将一个大服务拆分为多个独立的小服务，对服务进行颗粒度细分，每个服务都可以自己进行独立部署，开发，并具有自己独立的数据存储等。各个服务之间互相关联，但是同时也互相独立，分离，使用约定好的通讯体系进行通讯。依照这样的思想，我们不仅可以使用SpringCloud的体系进行微服务的搭建，同样也可以使用dubbo的体系进行微服务系统的搭建。
二、微服务的优缺点
微服务本身与单服务应用相比较，是具备着可以快速针对性扩容，容灾性更强，开发时冲突较少，解耦较为完善的优点的。但是同时也有着对开发人员的技术要求水平更高，对运维人员也是一种新的挑战。在进行小型项目开发时，如果强行使用微服务架构，则会产生一些多余的IO开销，并占用更多内存，造成服务比原本的性能更低下的问题，同时也会使开发进度降低，各方面的成本会直接的被提高，并且在处理事务时，还需要使用开发效率更低，性能相比Spring事务效率低下很多倍的分布式事务策略（事务补偿，或者TCC等）。
在上方的图片中，是一个较为完整的微服务架构图，在用户进行访问时，需要通过客户端或者web端进行访问，访问后由nginx服务分发到zuul路由服务进行转发处理，将请求转发到指定的服务。然后门户服务通过向eureka的注册中心获取需要调用的微服务，来进行实际的业务处理。 其中config服务为配置中心，在配置中心中对配置文件进行集中化管理。分布式事务服务为进行分布式事务管理的服务。 并且上图中的所有服务实际部署时，一般均为多个，并非一个，此处未更多的画出。
三、SpringCloud核心组件及其用途
在进行微服务架构时，进行使用的最基础组件为：Eureka服务治理，Ribbon负载均衡器，Feign声明式服务调用，Zuul路由网关，config配置中心。
Eureka服务治理：
Eureka服务治理组件，分为server服务端与client客户端两个部分，一般会使用server单独启动，作为注册中心使用，所有的服务在启动后，都需要主动的注册到eureka服务中。普通服务与注册发现服务之间，采用http心跳请求的形式进行连接，判断该服务是否还处于正常运行状态。在服务间进行调用时，需要先请求eureka服务，获取要调用的服务的地址列表，然后调用方选择所获取到的服务列表中的服务地址，进行调用。
Ribbon负载均衡器：
负载均衡器，是用于做负载均衡处理的组件，该组件会对从eureka中获取到的服务列表中的服务进行选择，在没有进行配置的情况下，会默认使用轮询的形式进行服务选择。
Feigh声明式服务调用：
Feign声明式服务调用组件中，其自身要求必须集成Ribbon组件，一般使用时，可以使用类似于mybatis的形式，以接口定义的形式来进行接口声明式的提供主动调用。接口声明后，不需要自己进行实现，Spring会自动进行扫描，然后实现被进行了注解的接口。在调用服务时，只要使用这些声明出的接口即可。
Zuul路由网关：
Zuul组件，是我们常用的路由组件，该组件可以直接自成服务，担任路由分发与网关过滤，权限控制，日志打印，以及限流的任务。该服务中会根据请求的url信息，来将请求分发到指定的服务中。
Config配置中心：
config组件，与Eureka组件一样，也是分为客户端与服务端两个部分，服务端部分，可以从一个远程git或svn地址，或一个本地的文件路径下，拉取配置文件的信息，然后根据请求的服务名，来将不同的配置文件提供给服务。config的服务的服务端，用于在启动时，从config服务中拉取配置文件信息进行服务的初始化。