什么是微服务架构？看下图的这段英文，这是Martin Fowler 在2014年提出来的，微服务架构是一种架构模式，既然是架构模式，那么，它就必然需要满足一些特点。他提到，微服务架构是一系列小的微服务构成的组合，那么，什么是“小的微服务”？可能每个人的理解都不一样，大家都应该都知道SOA架构，SOA架构的粒度是比较粗的，到底我们应该以什么样的粒度拆分微服务？我认为，微服务架构本质上一个业务架构，那么对业务了解的越深刻，你的微服务拆分就越合理。

服务网关

在微服务架构模式下，后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway作为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。

Spring Cloud体系中支持API Gateway落地的技术就是Zuul。Spring Cloud Zuul路由是微服务架构中不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。

它的具体作用就是服务转发，接收并转发所有内外部的客户端调用。使用Zuul可以作为资源的统一访问入口，同时也可以在网关做一些权限校验等类似的功能。

链路跟踪

随着服务的越来越多，对调用链的分析会越来越复杂，如服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等，对这些信息进行监控就成为一个问题。在实际的使用中我们需要监控服务和服务之间通讯的各项指标，这些数据将是我们改进系统架构的主要依据。因此分布式的链路跟踪就变的非常重要，Spring Cloud也给出了具体的解决方案：Spring Cloud Sleuth和Zipkin

Spring Cloud Sleuth为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。

微服务架构的优势

可扩展性：在增加业务功能时，单一应用架构需要在原先架构的代码基础上做比较大的调整，而微服务架构只需要增加新的微服务节点，并调整与之有关联的微服务节点即可。在增加业务响应能力时，单一架构需要进行整体扩容，而微服务架构仅需要扩容响应能力不足的微服务节点。

容错性：在系统发生故障时，单一应用架构需要进行整个系统的修复，涉及到代码的变更和应用的启停，而微服务架构仅仅需要针对有问题的服务进行代码的变更和服务的启停。其他服务可通过重试、熔断等机制实现应用层面的容错。

技术选型灵活：微服务架构下，每个微服务节点可以根据完成需求功能的不同，自由选择最适合的技术栈，即使对单一的微服务节点进行重构，成本也非常低。

开发运维效率更高：每个微服务节点都是一个单一进程，都专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模团队或者个人完全掌控，易于保持高可维护性和开发效率。

Spring Cloud作为目前最流行的微服务开发框架，不是采用了Spring Cloud框架就实现了微服务架构，具备了微服务架构的优势。正确的理解是使用Spring Cloud框架开发微服务架构的系统，使系统具备微服务架构的优势（Spring Cloud就像工具，还需要“做”的过程）。

路线图

博主整理了微服务架构路线图，供大家参考一下，主要包括以下内容：

漫谈微服务架构

Docker虚拟化

微框架

Spring cloud

上面都是自己整理好的！我就把资料贡献出来给有需要的人！顺便求一波关注，哈哈~各位小伙伴关注我后私信【Java】就可以免费领取哒