关于基于Spring Cloud的微服务应用架构，网上已经有很多文章了，但我还是觉得把自己的架构过程和经验写下来，对自己来说算是知识和技术的梳理，对于误打误撞进来看到这篇文章的读者来说，或许也能起到一些借鉴作用。

Spring Cloud OSS相关概念可以去官网看看，是Netflix公司贡献给社区的一系列组件，通过组合这些组件可以迅速设计出一个微服务应用架构，而这一套框架组件及其组合方式也已经成为微服务事实上的标准。相对与阿里的开源框架dubbo，Spring Cloud的组件形态更为丰富，社区更为活跃，因此也是被很多公司采用的原因之一。在我们的项目中，使用到的组件包括Eureka、Config、Zipkin、Zuul和Ribbon，整体的应用架构图大致如下，当然还有一些逻辑关系没有在图中体现，我将在架构解析部分进行更多说明。

基于Spring Cloud的微服务架构图

上面的架构图中，我们先看左边部分。Eureka-Server是注册服务，所有其它服务都注册到Eureka-Server，包括配置服务Config-Service，链路追踪服务Zipkin-Service、监控服务Monitor-Service和右边的业务逻辑所包含的各种服务(图中省略了很多业务服务)。其中监控服务使用到的组件包括Hystrix和Turbine，配置服务的配置信息可以来自类似于GitLab这种源码/文件管理系统。配置服务作为一个中心管理服务，除了注册服务，其它服务启动时都需要从配置服务获取到自己的配置文件来完成自身的正常启动。

左边这些服务可以认为是辅助业务系统或者运维相关的服务，右边的服务包含了主要的业务逻辑。比如一个Pay-Service API调用的流程大致如下：

Client客户端发起请求，请求先进入到Gateway-Service，也就是网关服务，网关服务有使用到Spring Cloud的Zuul和Ribbon组件，这两组件分别提供路由和负载均衡服务。Gateway-Service在启动后会从Eureka-Server中获取到服务列表，列表里包含所有注册了并且状态良好的服务所使用的IP地址和端口，这样Zuul组件根据路由配置规则就知道将该请求路由到哪个服务，比如这里是Pay-Service。如果Pay-Service部署了多个服务实例，就会用到了Ribbon的负载均衡功能，根据一定规则将请求发送到后端其中一个Pay-Service服务实例。Pay-Service需要记录日志时，调用Log-Service服务接口，是通过Feign组件调用的，然后Log-Service将日志信息写入到MySQL数据库。通过同步工具，我们将MySQL数据实时或者定期同步到ElasticSearch，再使用其它的开源组件(比如Kibana)对ElasticSearch的数据进行处理展示。

我们还可以看到，微服务之间可能需要互相调用，我们使用Feign组件来完成，Feign组件自动包含了Ribbon功能，也就是如果要调用的服务部署了多个实例，Feign调用时就使用了Ribbon的负载均衡功能。因此，为方便调用其它服务，右边所有的微服务基本都集成了Feign组件，这一点也是图中没有体现出来的。

图中还有一个UAA-Service服务比较特殊，也是很关键的一个服务。UAA全称为User Authentication Authorization，即用户认证和授权。项目中使用了JWT + Oauth2 + Spring Security来实现认证授权逻辑。UAA-Service负责JWT Token的生成，是一个授权服务器，而其它所有的业务服务都属于资源服务，当客户端要调用资源服务的接口时，需要携带一个Token，资源服务从Token解析出相应的用户信息，存储到Spring Security上下文，然后业务代码里面就可以取出相应的用户信息，判断该用户是否有权限访问指定接口等等。认证授权的逻辑图如下：

JWT+Oauth2+Spring Security 认证授权逻辑

从上面的逻辑图中可以看到，如果用户访问的不是登录/注册接口，则先看请求是否携带了Token，如果没有携带，直接返回给客户端相应的提示信息，比如“请求缺少Token字段”，否则从Redis中查找是否存在客户端传过来的Token，如果没有，则返回“无效Token”信息，否则解析Token，存储到Spring Security上下文(这个逻辑是和业务代码分开的，在进入到业务代码之前就完成)，然后在业务代码中可以使用诸如@PreAuthorize(“hasRole(‘ADMIN’)”)来判断当前用户是否具有ADMIN权限，如果有则可以访问当前接口，否则给客户端返回无访问权限等信息。

综上，我们看到整个微服务架构包含了以下几个主要部分：

注册服务，用于管理其它服务； 配置服务，给各服务提供配置管理； 网关服务，给后端微服务提供路由和负载均衡； 用户服务、认证授权服务，给微服务访问提供保护机制； 监控、链路追踪服务，辅助系统运维； 其它业务服务，提供真正的业务功能逻辑； 这六部分是一个微服务应用系统必不可少的，当然这里展示的仅仅是一个最小的微服务系统所包含的模块或服务，还有其它很多服务没有画出来，大家根据实际情况，可以在自己的项目中基于此进行各种扩展来真正满足您业务系统的功能、安全、性能等需求。

微信扫码，进入【技术人成长】社群逛逛。