一、微服务架构Spring Cloud的基本介绍

1. 前言

之前接触过不少的分布式、微服务等相关技术，但是从未真正系统的总结过，趁着年底有些空闲的时间，写点博客来总结、梳理一下自己知识点。要知道程序员是一个不断学习的过程。我最初接触的语言并非是Java，因为本身对网站技术比较感兴趣，所以在高中时候就接触了HTML超文本传输语言，那时候先研究的是网页三剑客：Dreamweaver、Fireworks、Flash三个东西。后来接触了Java，进而开发网站项目使用Java Web，使用最多的是SSM、SSH架构，也是最为流行的，甚至目前有些新开单体应用项目依旧使用。单体应用项目是相对于分布式项目而言的，但现在开发的单体项目基本上都是用Spring Boot来开发，Spring Boot这个东西一旦用上之后，就很难再去使用SSM、SSH这种配置很复杂的东西，Spring Boot确实简化了我们繁琐的一些配置，使我们更加专注的进行业务开发。废话不多说了，前言这里面主要强点一点本文章写的，是本人对Spring Cloud知识点的复盘和总结，有些可能会借鉴别人的一些知识点和看法，也有可能写的一些地方稍有误差，请大家积极指正。

2. Spring Cloud基本架构

介绍Spring Cloud之前，首先谈一谈架构的演变过程。上面讲到单体应用，其实微服务架构和单体应用之间，还有SOA面向服务、ESB企业服务总线等。架构的演变过程目前来讲是从传统架构（也就是单体应用架构）、分布式架构、SOA架构到现在的微服务架构。但请相信，微服务架构并非是架构演变的终点。每一个新的架构的诞生，都是由于现有的架构无法更好的满足现有的业务，或者不能够完美的兼容。

但是架构的演变并不能完全替代之前的架构，可以认为是每个架构有自己适合的应用场景。单个小项目、小系统的开发必然会使用单个应用架构，而不是微服务架构。但随着项目的扩大，开发团队的扩大，单个应用架构耦合性太高、维护不便，所以按照项目的业务模块开始进行解耦，这样就形成了分布式架构。后来进一步分将这些业务模块服务化，形成面向服务的架构，也就是SOA架构，各个服务之间使用RPC远程调用技术进行通讯，这个可以和微服务的架构已经很相似了。SOA架构中通过Web Service进行通讯，Web Service使用的是soap协议通讯，他会有一个WSDL文档，各个客户端可以通过WSDL向服务端发起请求。soap的简单理解可以认为：Http协议再加上XML传输数据。XML文件其实非常大而笨重的，传输、解析的效率不高。而且随着系统的不断扩大，业务增多的同时服务也会增多，各个服务之间的依赖关系的管理会变得非常麻烦，所以提出了服务治理这一概念。

微服务架构采用json格式传送数据，其实底层使用的还是HttpClient。在Spring Cloud中客户端通讯使用Feign客户端，这也是Spring Cloud中非常重要的一个轻量级通讯架构。目前比较流程的两种微服务架构一个是Spring Cloud，一个阿里系的Dubbo，使用zookeeper作为注册中心。Dubbo之前停更了一段时间，直到2017年发布了新的版本2.5.6。但Spring Cloud一直都在高速的发展，版本迭代的也非常快，目前已经更新到Hoxton.SR1版本了。

Spring Cloud的架构可以参考下图：

上面的图粗看即可。其实主要想说的是Spring Cloud可以看做是一个脚手架，就是为了方便搭建微服务架构而生，其基于Spring Boot并且封装了Netfix。学习Spring Cloud说白了也就是学习5个主要的架构：Eureka注册中心、Hystrix容错框架、Feign内部通讯架构、Ribbon负载均衡、Zuul网关路由。

 

Spring Cloud的工作流程是前端访问服务网关，服务网关能够做的事比如熔断、负载均衡以及权限验证等。通过网关路由到服务注册中心Eureka，微服务架构的核心就是注册中心。上面说到Dubbo和Spring Cloud的不同，最重要一点是Spring Cloud使用Eureka作为服务中心，而Dubbo使用zookeeper做注册中心，另外还有一种注册中心称之为Consul，使用go语言编写的，这些之后的文章都会有讲到。

微服务架构和传统的架构对接口的理解稍有不同，传统框架会有一个视图层controller专门负责和前端交互，但是微服务架构之专注于系统内部各服务之间的调用API。所有的API需要在服务中心注册。通过服务中心可以将服务分为两大类：服务提供者和服务消费者，一个业务需求至少需要一个服务提供者和一个服务消费者。但是一个较为复杂的业务，可能存在多个服务提供者，甚至出现多级服务调用的情况，如下图所示

服务A是一个简单消费API接口其和服务B中Provider_1组成了一个业务1，即两个相互之间可以干成一件完整的事。若服务B中不能满足业务需要，服务B由依赖于服务C才能实现一个完整的业务，那么服务B此时在业务2中充当消费者的角色。更为复杂的情况是服务C中由于逻辑的不同，需要使用第三个业务或者第四个业务，此时就会有更多的服务纳入其中。以此类推，一个复杂的业务将会串联或者并联很多服务，服务之间的管理就变得尤为重要。服务中心的服务治理功能主要就是做这部分工作。

 

接下的文章我们会以这五个组建为前提，介绍Spring Cloud的功能。