为应对传统单体架构的缺陷，微服务架构被企业广泛应用。Spring Cloud 为开发人员提供了快速构建微服务的系列工具，但是并没有进行相关整合， vole 是在其基础上搭建的一套可以快速实现微服务的基础脚手架工具。
1、传统单体架构的缺陷
传统单体应用将所有功能的表示层、业务逻辑层、资料访问层、包括静态资源等全部糅合在一个工程内，编译 打包 部署在单台服务器上线，比如打成 war 包放在 Tomcat 的 webapp 目录中部署。这样的开发部署流程适合小型专案，系统功能不复杂，访问量不大的情况下有绝对的优势，开发速度快且运维方便。但是，当业务越来越复杂，功能越来越多，参与的开发人员越来越多，该流程就暴露出如下问题：
业务复杂，程式码量增大，程式码可读性、可维护性、可扩充套件性下降。一旦要新同事接手程式码，需要花很多时间理解 ;测试难度增大 ;单体应用并发能力有限，访问量高，使用者体验差 ;单体应用容错率低，一旦出错，可能导致整个专案崩亏 ;将单体应用做丛集部署，新增负载均衡服务器（例如 Nginx 反向代理转发请求）可略微缓解以上两条条缺点，但不能完美解决问题。2、微服务是什么？
微服务架构：就是将原来的单体应用按义务范围来，划分为多个小 model，每个微服务执行在自己的程序中，相互不产生影响，完全自动化独立部署，并使用轻量级机制通讯，通常是 HTTP RESTUFUL API，可对各微服务进行集中管理。这些小 model 可以使用不同的程式语言及储存技术，微服务架构是分散式架构。
2.1、微服务架构的优点
按业务划分的微服务单元独立部署，执行在独立的程序中，服务之间没有任何耦合，具备良好的扩充套件性和复用性；服务之间通常采用 HTTP 通讯，该通讯机制与平台和语言无关，可以使用不同的程式语言和储存方法。也可以采用轻量级讯息总线通讯，如 RabbitMQ、Kafaka 讯息伫列等，资料格式一般采用 JSON；每个微服务都有自己的数据库，服务间数据库相互是独立；微服务一般采用自动化工具部署。Docker 容器技术是微服务最佳部署容器；服务集中化管理（服务注册与发现：Eureka、Zookeeper、Consul），监控（服务执行状况监控：Spring-Boot-Admin-Server）；微服务架构是分散式架构。3、微服务脚手架工具：vole
Spring Cloud 为开发人员提供了快速构建微服务系统的系列工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、分散式会话等相关功能，但是并没有进行相关整合， vole 是在 Spring Cloud 基础上搭建的一套可以快速实现微服务架构的基础脚手架工具，vole 基于 Spring Cloud Finchley 版本 的框架搭建，可以快速帮助专案组完成老系统微服务改造。苏宁新广告平台原来大单体应用的基础上使用 vole 对原来单体应用进行了快速改造，帮助业务系统快速搭建微服务化。
架构模型图如下所示：
主要包括以下功能模组：
基础核心工具包 common微服务服务中心 eureka微服务配置中心 config微服务鉴权中心 auth微服务登陆统一中心 passport微服务后台统一管理中心 portal微服务边缘闸道器管理中心 gateway微服务其他相关模组（监控，讯息，job）
vole-common
vole-common 基础核心工具包，主要负责如 请求切面、服务配置、异常处理、引数格式化、请求防护、redis、Db、基础配置元件、以及其他相关如档案服务、基础工具类等元件。这里，重点要介绍 bean 包下元件 。
如上图 bean 包下主要是 aop Controller 增强切面，保证各微服务的界面返回值都基于基础格式类 ® 。
config 包主要负责 请求忽略配置外挂， api 文件外挂配置以及 - MVC 引数管理配置类。
handler 和 resolver 包 分别处理全域性异常和使用者请求引数解析。
Xss 包处理请求攻击过滤的 比如 xss 攻击，sql 注入等。
基础工具类为整个脚手架提供了基本配置管理功能，为其他相关元件提供了基础功能。
vole- eureka
vole- eureka 微服务注册中心 eureka 高可用配置方案，Eureka 通过执行多个例项，使其更具高可用性。事实上，这是它的预设属性，使用者需要做的就是给对等例项一个合法的关联 serviceUrl, 如下图所示：
eureka 互备两个节点 Eureka-eserver peer1 8761,Eureka-eserver peer2 8769 相互感应。当有服务注册时，两个 Eureka-eserver 是对等的，它们都存有相同的资讯，这就是通过服务器的冗余来增加可靠性，当有一台服务器宕机了，服务并不会终止，因为另一台服务存有相同的资料。
vole-config 微服务配置中心
在分散式系统中，由于服务数量巨多，为了方便服务配置档案统一管理，实时更新，所以需要分散式配置中心元件。在 Spring Cloud 中，有分散式配置中心元件 spring cloud config ，支援配置服务放在配置服务内存中（即本地），也支援放在远端 Git 仓库中。在 spring cloud config 元件中，分两个角色，一是 config server，二是 config client。
如上图 vole-config 预设使用本地方式，也可以配置到 git 服务器上去。
当服务例项很多时，都从配置中心读取档案，这时可以考虑将配置中心做成一个微服务，将其丛集化，从而达到高可用，架构图如下：
配置中心高可用架构图
vole-auth
vole-auth 是微服务鉴权中心。在微服务架构下，一个应用会被拆分成若干个微应用，每个微应用都需要对访问进行鉴权，每个微应用都需要明确当前访问使用者以及许可权。尤其当访问来源不只是浏览器，还包括其他服务呼叫时，单体应用架构下的鉴权方式就不是特别合适。在微服务架构下，要考虑外部应用接入的场景、使用者 - 服务鉴权、服务 - 服务鉴权等多种鉴权场景。vole-auth 是基于 spring cloud auth2 基础上配置的鉴权中心，实现了服务与资料分离的方式，即使用者相关资料 都是通过服务获取，vole-auth 负责相关鉴权功能。
如下图所示：
鉴权关系图
auth 的 memberService 去掉用 mps 服务的相关会员基本资讯来确认 使用者许可权是否正常；Auth 服务内部有两个重点服务包 :config 包 和 component 包；Config 包：主要负责 auth 服务的基本配置 ,- 包括安全配置方案，token 增强和储存方案以及 JWT 配置；Component 包 ：主要负责自定义 token 使用方案，这里主要是自定义手机号 token 方案。vole-passport
vole-passport 是微服务登陆统一中心主要负责各系统后台相关登陆服务管理，基于 springSecurity 改造使用 cookie 管理登陆资讯的服务，vole-passport 支援各个服务注解式一键配置方式。
如下图所示:
统一登入配置中心图
业务人员需要通过登陆相关业务系统进行检视或者新增相关资料先要经过 passport 进行认证和鉴权。Vole-passport 采用集中式服务管理模式，各个子业务系统的介入只需系统上配置相关客户端资讯。Passport 重点工模组是 passport-common 负责 passport 所有功能服务元件。
如上图所示包括：
auth 使用者认证基本资讯管理；config 服务配置管理包括服务端配置和客户端配置；cookie 是负责写入和读取 cookie 基本资讯；detail 是使用者基本配置资讯宝库使用者的密码，登陆状态，id 等等；Filter 是基于 springSecurity 改造的相关的客户端和服务端的配置管理服务；Handler 是使用者正常登陆等处的成功或失败处理；Permission 是负责使用者登入后相关资源的鉴权服务；Token 使用者基本 token 操作管理。相关系统配置 passport-config 如下所示：使用配置继承 WebSecurityConfigurerAdapter 的配置类，并 @EnablePassportSso 开启 sso 配置
在 springboot 启动配置档案 (application.yml) 上配置相关统一登入服务连结：
vole-portal
vole-portals 是分散式统一管理后台门户，实现对各系统后台的许可权统一管理，包括 - 使用者管理、角色管理、选单和许可权管理以及系统管理，是相关系统后台管理的基本功能集合体。
如下图：
统一门户管理分三个元件：门户服务端 vole-portal、门户资料端 vole-portal-data、和门户基本元件 vole-portal-common，用微服务方式实现服务和资料分离。
vole-portal: 主要负责门户的基本配置功能 如选单，许可权，系统，使用者配置等；vole-portal-data: 负责对使用者，许可权，选单的基本资料读取的管理。服务和资料分离的好处是 - 对于任何前端程式都能接入相关 portal 服务，便于定制化管理界面。
如下图：
前端业务系统可以使用任何服务进行整合，便于前后端分离。
vole-gateway
微服务边缘闸道器 vole-gateway 是基于 zuul 改造的边缘闸道器服务，在 zuul 基础上添加了动态路由配置，服务鉴权，异常，安全等相关功能。
zuul 的服务方式如下图：
微服务闸道器 zuul 架构
为什么要使用边缘服务闸道器？
客户端直接和微服务互动，增加了复杂度；某些场景下可能存在跨域；如果一个功能点需要呼叫多个微服务，每个服务都需要身份认证，使得身份验证复杂冗余；客户端直接和微服务互动，后期程式码重构难度大。基于以上问题，使用边缘闸道器使得整个微服务系统对外部服务的管理，尤其是移动端服务更加规范，简单，清晰。
vole-modules
vole-modules 包括了微服务的其他功能，比如任务、讯息、监控等相关元件，可以帮助快速搭建微服务相关基础功能，提供基本骨架工程结合包。
如下图所示：
vole-job 使用的是 Elastic-Job-Lite；定时任务一般都是使用 quartz 或者 spring-task（ScheduledExecutorService），无论是使用 quartz 还是 spring-task，我们都会至少遇到两个痛点：
不敢轻易跟着应用服务多节点部署，可能会重复多次执行而引发系统逻辑错误；quartz 的丛集仅仅只是用来 HA，节点数量的增加并不能给我们的每次执行效率带来提升，即不能实现水平扩充套件。Elastic job 的主要功能有支援弹性扩容，通过 Zookepper 集中管理和监控 job，支援失效转移等。
vole-message 对钉钉，阿里云大鱼简讯平台的基础服务能够快速的支援讯息接入。
vole-mq 集成了对 kafka,rabbit,rocket 等主流 mq 客户端的集合包。
vole-monitor 和 vole-turbine 分别是对容器基础资料监控以及服务聚合熔断监控的组合。
结束语
通过精简或者重组 vole 微服务脚手架可以快速提炼出适应相关专案组的微服务脚手架工具，解决专案组大量的前期框架整合时间，提升开发效率和专案进度。
看到这里，说明你喜欢本文，你的转发，是对我最大的鼓励！在看亦是支援↓
