作者：张方兴
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
微服务分布式架构基础与实战——基于Spring Boot + Spring Cloud试读：
前言
目前，Spring Boot+Spring Cloud架构已经成为Java程序员的必备技能之一，刚开始学习时看到琳琅满目的Spring全家桶，可能会感到无从下手。如果只了解微服务中的各知识点，而忽略了以微服务分布式架构的方式学习系统的架构顺序，初学者可能就不知道如何使用微服务构建分布式系统。为了使读者更快掌握Spring Boot+Spring Cloud的基础知识与架构方法，本书的章节顺序即应用系统的架构顺序。
分布式可以理解为人体器官，人体可看成分布式系统，大脑是注册中心的集群，四肢与器官是提供服务的微服务，前进的距离是微服务运行之后的返回值，消耗的体力是微服务中处理的逻辑，影响的记忆是某些微服务对数据库的增删改查。分布式可看成一种思想，而Spring Cloud 与 Spring Boot是实现了这种思想的工具。
无论多复杂的分布式应用程序，整合多少个服务器，调用多少种服务接口，使用多少种协议，使用集群还是高可用的何种架构方式，使用客户端还是服务端的何种负载均衡，使用哪个消息中间件、哪个数据库集群，使用搜索引擎/非关系型数据库/时序性数据库/关系型数据库/文件管理等多少种存储介质，其分布式本质都是分布式自身的思想。建议读者动手将本书实例都敲在IDE中，在Linux服务器上搭建各集群，那么上面那些看起来颇具难度的问题，都将不会是难题。
本书主要内容如下。
介绍微服务分布式的相关概念，搭建第一个微服务项目，了解微服务项目的运行过程。通过微服务整合Consul注册中心，搭建第一个微服务+注册中心的分布式系统。多个微服务与Consul注册中心相连，彼此通信，微服务获得彼此的接口及地址，调用彼此的接口与服务。然后无可避免地需要处理彼此通信时报错的情况，以免单一微服务无法正常提供服务，导致整个分布式系统的瘫痪。此时采用Ribbon客户端负载均衡方案，依靠多台服务器部署多个相同微服务项目，以提高系统的性能。在分布式通信不足以解决全部报错问题时，可选择 Hystrix 进行更精细划分，保证在任何一台微服务出现问题时，系统整体仍然能正常运行。
至此初步搭建了分布式系统，然后开始增加微服务的增删改查等业务功能。在系统处理增删改查过程的同时，还需要事务功能的支撑与管理。在初步增删改查后，依靠微服务的缓存增加微服务的性能，同时需要确保Redis与MySQL之间的增删改查一致性。另外，如果有特殊业务需求，可由分布式消息通信彼此协作、沟通、处理。
在处理基本业务后，还会有定时任务等业务需求，此时需要微服务的任务调度进行处理。而单节点任务调度的微服务可能会有宕机或重复执行等相关问题，只有使多台微服务同时进行任务调度，且彼此协同的情况下，才能解决此类问题。这时需要 Quartz分布式任务调度解决多个任务调度间彼此协同、相互管理等问题。若有文件上传、下载等相关需求，需要使用微服务的文件上传管理。单节点文件上传可能存在磁盘空间不足或不易管理等问题，需要 FastDFS 分布式文件管理以解决多台文件管理服务器彼此协同、磁盘扩容等问题。
在对整体分布式微服务编程后，需要进行部署，第12章介绍如何部署微服务分布式项目，以及架构方案、设计方式、编程框架、网关等。
本书适合作为高等学校计算机、软件工程等相关专业Java架构课程的教材，也可供对微服务分布式架构感兴趣的人员参考阅读。
本书由张方兴编著。本书即将付梓，还要感谢张鑫编辑持之以恒的支持与帮助。编者微信公众号为北漂程序员的吐槽人生（微信号：beipiaochengxuyuan），读者有任何意见与建议，可随时沟通。
非常感谢阅读本书，学无止境，与君共勉。
由于编者水平有限，加之编写时间仓促，书中难免出现错误与不足之处，欢迎读者批评指正。编者2020年1月
第1章 微服务分布式架构设计原理
本章按照微服务分布式架构的顺序对其进行讲解，并以实例形式介绍如何编写分布式微服务的代码。每个微服务的架构都先从微服务的注册、微服务间的通信开始，然后编写每个微服务的持久化、缓存等内容。
1.1 Java Web应用程序的发展历史
Java Web应用程序的发展历史经历了以下几个过程。
1.Servlet类项目
在web.xml中对Servlet容器方式的项目架构进行配置。截至目前依然还有部分老项目用Servlet方式进行运行。
2.EJB类项目
EJB 将业务逻辑从客户端软件中抽取出来，封装在一个组件中。EJB 组件运行在一个独立的服务器上，客户端软件通过网络调用组件提供的服务以实现业务逻辑，而客户端软件的功能是只负责发送调用请求和显示处理结果。在Java中，能够实现远程对象调用的技术是RMI，而EJB技术的基础正是RMI。通过RMI技术，J2EE将EJB 组件创建为远程对象，客户端可以通过网络调用EJB对象。
3.REST+JBoss平台类项目
REST+JBoss 的设计风格很独特。JBoss 提供了一个编程平台，以及一系列拦截器和Web类工具，在编写代码时拦截并过滤模块、向外提供服务，构建REST轻量级开发，只需编写很少的配置文件即可引用相关拦截器。在REST+JBoss平台时期，国内很多公司也在研发自己的Java平台，平台中会集成多种框架和工具，如线程池、持久化、缓存、异步、数据模型等，方便公司内部员工编程。
4.SSM类项目（Spring+Struts/Struts2+Hibernate/MyBatis）
Java逐渐开始研发更完善的轻量级开发架构，减少配置文件等压力，将程序专注于业务本身。在 EJB时期每个项目至少都有几十个配置文件，相比较下 SSM减轻了依赖很多配置文件的压力，因为SSM类项目的架构快速便捷，大部分功能由Spring进行集中管理。由于SSM架构具备此优点，所以国内部分公司开始减少重复开发的行为，小规模公司则很少再开发公司内部的编程平台。
5.SOA类项目
在单个SSM无法解决大批量高并发需求时，人们开始将一些大型程序分成多个独立运行的模块进行处理，将每个模块部署在不同的服务器上，模块之间用WebService协议进行通信。虽然在SOA初期便逐渐有了微服务分布式的苗头，但在SOA阶段如果大型Java项目写得精细一些，每个 WebService 下就都会有相关的管理工具、调度页面、性能监控、业务监控、前置系统和黑白名单，整个大型项目的代码十分复杂且数量庞大。在 SOA 模式下写出来的项目十分安全、稳定、性能优良。因此，时至今日安防类、金融类项目仍然会采取SOA架构模式来架构系统，并且在不同的公司之间通信通常也会采用WebService协议。
6.Dubbo+Zookeeper类项目
Dubbo+Zookeeper 分布式服务架构的项目也流行了一段时间，Dubbo 是阿里巴巴公司于2011年末开源的一个高性能服务框架，使用高性能RPC实现服务的输入和输出，属于分布式项目。在分布式的思想上与 Spring Cloud+Spring Boot 并无任何区别，只是因为Dubbo还没有推广起来，阿里巴巴公司就在2013年停止了Dubbo的更新维护，所以这个服务框架渐渐地被埋没了，虽然现在阿里巴巴公司正在重启 Dubbo 项目，但目前 Spring Cloud过于火热，Dubbo一直处于不温不火的状态。
7.Spring Cloud+Spring Boot类项目
微服务的分布式架构利用Eureka或Consul平台进行注册，将每个业务分成一个个小的 Spring Boot 微服务包，让每个微服务包独立运行后在注册平台进行注册，通过 Spring Cloud Feign进行相互通信，也是目前主流的架构。
1.2 微服务分布式
微服务工程将众多框架通过一个入口集成到自身的程序中，让编程人员不需关注框架原理即可直接进行调用。当初的SSM类项目也基于相同的思想，但当SSM类项目集成的框架过多后，配置文件数目与日俱增且难以管理，而此时Spring Boot微服务赋予了它们所需基本配置参数的大部分框架和工具，将初始配置参数的压力再次缩减。
分布式架构将不同的业务模块通过不同的服务器运行，曾经的多个WebService组建的SOA架构的项目也基于相同的思想，而此时的Spring Cloud把过去的架构变得更加简便、轻松。
从SOA类项目开始将大型应用程序拆分成多个独立运行的小型应用程序，多个应用程序之间由WebService协议进行通信。因为每个WebService服务还要集成SSM，甚至每个服务还要做相关的管理页面和各种监控，所以每个WebService服务开发的过程都比较冗长。
微服务架构下的每个微服务和WebService一样都是独立运行的，将复杂的业务以模块的形式拆开，方便开发人员编写。微服务通常使用Spring Boot进行快捷开发，大部分基础信息在Spring Boot的底层之中都已经被配置好了，不像SSM一样需要编写大量XML程序，因此每个微服务在编程的过程中都会十分快速。1.2.1 Spring Boot微服务的定义和特点
Spring Boot微服务可以轻松地创建独立的产品级应用程序。Spring平台和第三方库采取自行管理的方式，可更加便捷地开始编写应用程序。Spring Boot通过pom.xml文件，依赖Spring Boot的Starter，将所有需要的Jar包集中在一起。Spring Boot微服务替代了原本的Spring+SpringMVC/Struts2+MyBatis/Himbernate结构。
Spring Boot做了很多配置文件的管理。原本需要写三四个Application.xml文件，对数据库资源池、事务、服务、视图、静态资源等进行配置，现在则完全不需要，而事实上与以前做的传统项目大部分的配置文件也没有较大的区别。
打包变成了直接运行的 Jar 包，因为包变小了，包内所提供的内容更加清晰明确，所以称为微服务，特点如下。
● 创建独立的Spring应用程序。
● 直接嵌入Tomcat、Jetty或Undertow（不需要部署war文件）。
● 提供被约定好的Starter依赖内容，以简化构建配置。
● 尽可能自动配置Spring和第三方库。
● 提供产品在生产过程中所需要的如健康检查和外部化配置等。
● 没有绝对的代码生成，也不需要XML配置。
Spring Boot的部署简单，只要服务器有Java环境便可运行，即使再多的服务器也能快速且稳定运行。
Spring Boot的设计初衷是约定大于配置，过多的重复性配置压力在SSM里让人深有体会，每个SSM项目中的XML大部分内容都是类似的，对于资深程序员来讲，任何一个新项目的编写都是一个复制粘贴的过程，而Spring Boot省略了初始化配置和重复性配置的过程。1.2.2 Spring Boot的职场导读
如今Spring Boot+Spring Cloud的微服务分布式项目架构，如同当年的SSM类架构一样，属于1～3年工作经验Java Web研发程序员找工作的必备技能之一。通常初级Java Web研发职位的技能要求如下：（1）熟练掌握Java后台编码基础技术，如JVM、语法、GC、多线程、IO、网络编程、反射等；（2）熟练掌握Spring Cloud与Spring Boot架构开发；（3）熟悉Spring、SpringMVC、MyBatis等开源框架，最好了解其中部分源码；（4）熟悉Tomcat、JBoss、Weblogic等主流应用服务器；（5）熟悉HTML、CSS、JavaScript，JQuery等前段基础知识；（6）熟悉Oracle或MySQL数据库开发，如SQL与存储过程；（7）熟练使用Linux操作系统，掌握基本Shell命令；（8）熟练掌握Radis、MongoDB；（9）熟练使用WebService主流框架，如CXF、Axis等；（10）熟练使用Maven、Git、SVN等相关版本控制工具。
目前，主流的架构通常用Spring Boot+Spring Cloud作为程序后台，用VUE或AngrulJS作为程序前台，达到VUE+Spring Boot+Spring Cloud前后台分离的架构模式，Java程序员再不需要关心JSP等前台相关内容，这些都由前端人员自行管理，减轻了沟通成本，也减轻不少编程和维护上的压力。
微服务类框架除了Spring Boot，还有JFinal、JBoot等国产微服务框架。1.2.3 Spring部分内容
如表1-1所示，Spring的常用框架有很多种，而且Spring定制了大多分布式架构所需的工具与框架。Spring已经替编程人员完成了分布式的架构，而分布式编程人员在其中挑选一些适合项目的工具并参照操作文档进行集成即可。表1-1 Spring的常用框架续表续表1.2.4 微服务的拆分
微服务将整个大型Web项目拆分成了多个小型的Spring Boot工程，彼此依靠Spring Cloud相关分布式框架工具进行整合，通常编程人员将一个大项目中不同的业务和技术分别拆分成不同的小模块进行独立运行。例如，一个已上线的项目一般包含以下微服务工程。（1）zfx_account微服务工程：关于账号、鉴权、缓存的微服务。（2）zfx_admin微服务工程：微服务自身的控制管理服务。（3）zfx_service微服务工程：给外部系统提供服务的微服务。（4）zfx_control微服务工程：业务监控、性能监控的微服务。（5）zfx_mobile微服务工程：给手机端提供接口的微服务。（6）zfx_produce微服务工程：管理自身产品的微服务。（7）zfx_message微服务工程：邮件、短信通知的微服务。（8）zfx_pay微服务工程：对接支付接口的微服务。（9）zfx_mq微服务工程：给其他微服务提供消息队列功能的微服务。（10）zfx_common 微服务工程：通常实体类都存在 common 中，别的项目会依赖common，common中存放其他微服务共通性的工具。（11）zfx_parent微服务工程：别的项目会依赖parent，通常在parent中不会编写实际意义的代码，parent主要定义相关框架的版本信息等相关内容。（12）zfx_paytran微服务工程：支付相关的微服务。（13）zfx_dataaccess 微服务工程：一些数据库增删改查外的索引管理、数据库心跳及预警等相关功能的微服务。
上述拆分中每个微服务项目都是一个独立运行的Spring Boot工程。每个Spring Boot工程之间依靠注册中心进行关联，依靠Feign进行相互通信，依靠Spring Cloud Security进行鉴权和单点登录。
不同的业务场景所需要进行拆分的业务模块和技术模块肯定不同，通常根据自身的业务进行调整，不过像zfx_parent、zfx_common肯定是系统必备的内容。因为一个工程中再多的业务也必须有互相需要依赖的 Jar 包、提取的共同点、共同需要的技术内容，所以在微服务拆分时可先将parent和common两个模块拆分出来，抽出程序的共通性，再慢慢新增其他的服务模块。
线上项目拆分成 40～50 个微服务工程是正常现象，因此在做分布式微服务项目架构时，只要维护管理到位，就不用担心微服务的数目是否过多，如果重用性得当，让每个程序员管理其中几个微服务，就能达到以最快速度开发迭代的目的。
移动端使用H5，再利用Android和iOS的Webview整合H5进行混合开发，大部分内容在Android与iOS之间都不需要重新编写，即一套页面在两个系统中使用，不需要重复开发。
1.3 【实例】微服务工程Hello World
1.3.1 实例背景本书采用Eclipse配合Maven进行编程，JDK采用1.8版本，如果使用Idea、STS等相应开发工具，并无任何区别。STS是专门为Spring Boot制作的开发工具，全称为Spring Tool Suite，其中含有各种Spring Boot模板，在引入模板时，会自动生成pom.xml中所需要依赖的文件，但是本书使用Eclipse进行开发。STS基于Eclipse并进行了一定程度的封装，因此其快捷键、代码提示等功能和Eclipse无任何区别。
建议Spring Boot的版本在2.0.0上，因为有一些新特性可以使用。
本实例将创建boot_01工程，首先使用Maven插件集成Spring Boot微服务依赖，再通过@RestController注解编写REST风格的HTTP接口输出Hello World字符串。1.3.2 创建Maven Project
在Eclipse工具下进行编程，Spring Boot通常在Maven工具的辅助下创建，因为Spring Boot内部所继承的依赖Jar包太多，Maven能够一次性将Spring Boot所有需要的依赖Jar包下载完成。
因为微服务工程只使用Spring Boot而并非Spring Boot下的一个模块，所以创建的是Maven Project，而不是Maven Module。表1-2所示为Maven工程类型及其含义。表1-2 Maven工程类型及其含义1.3.3 使用空Maven Project模板
模板的最大优点是能自动生成pom.xml文件。例如，当需要引入MySQL的驱动包对数据库增删改查时，STS创建工程可进行选择和引入。
如图1-1所示，创建Maven Project工程后选中Create a simple project（skip archetype selection）复选框，即不使用Maven模板。图1-11.3.4 编辑Maven坐标定位及工程名
Maven 的一个核心作用是对管理工程的依赖，同时引入所需要的各种 Jar 包等。为了能自动化地解析任何一个Java构件，Maven必须将依赖Jar包或其他资源进行唯一标识，标识即 Maven坐标。Maven坐标是对工程依赖的基础。拥有其他工程的 Maven坐标才能引用其他工程，或被其他工程所引用。Maven坐标的作用好像Maven世界中的身份证一样。
Maven坐标通过Group Id、Artifact Id、Version、Packaging、Name、Decription等元素来定义，如同坐标轴中的X轴、Y轴一样。
Group Id：定义当前Maven工程隶属的实际项目。图1-2中建立的Jar文件默认将处于C：\Users\Administrator\.m2\repository\org\zfx\boot文件夹中，在Maven世界里别人依赖此工程，也会处于$Maven_Home\.m2\repository\org\zfx\boot 文件夹中。通常命名会表明该工程处于各项目中的哪个位置，以方便理解。
Artifact Id：定义Group Id位置下实际工程的名字，推荐与工程名保持一致，Maven生成的构件其文件名都会以Artifact Id作为开头。
Version：定义当前Maven工程所在的版本，因为作为名字后缀存储，所以建议尽量简短，方便后续对其进行维护。
Packaging：定义Maven的打包方式，通常为Jar文件或War文件。若不对其进行定义，则默认为Jar文件。
Decription：对Maven工程进行描述的内容，通常不会使用。
图1-2所示为输入该工程的Maven坐标等基本信息。图1-21.3.5 检查Maven目录结构
好的目录结构方便开发人员编写程序，也将为程序在未来使用过程中的维护工作打下良好的基础。
Maven目录结构是业界公认的最佳目录结构，为开发者提供了缺省的标准目录模板，Eclipse中Maven目录结构如图1-3所示。Idea的Maven目录结构与Eclipse的Maven目录结构略有不同。
Maven目录结构释义如表1-3所示。图1-3表1-3 Maven目录结构释义1.3.6 编写Pom文件
pom.xml 文件是 Maven 插件用来引入相关依赖 Jar 包的管理文件。其中，pom.xml内的＜parent＞标签代表该工程继承父类 Maven 工程的坐标，并且将会集成父类 Maven下所有相关依赖，类似于 Java 的 extend。＜dependencies＞标签下引入其他相关 Maven工程坐标。
pom.xml文件代码如下。
更新Pom文件前要了解当前计算机上是否含有JDK1.8版本，JDK1.7或以下版本需尝试使用spring-boot-starter-parent，版本为1.5.3.RELEASE。而JDK1.7使用Spring Boot 2.0以上版本会报Pom文件相关编译错误。具体可查询Spring.io网站信息。
编写本书时Spring Boot最高版本为2.0.x。
1.若无法从parent里进行继承
若工程有其他的包需要继承，则直接在pom.xml文件中对Spring Boot进行引入，即不使用＜parent＞＜/parent＞标签，pom.xml文件部分代码如下。
注意，如果没有编写＜dependencyManagement＞＜/dependencyManagement＞标签进行定义，经常会报错。Spring Boot官方文档同样编写了该标签。
2.保存pom.xml文件会报错误
在Maven工程的pom.xml文件被更改并保存的情况下，工程会报如下错误：
工程报错效果如图 1-4 所示。该错误是未更新Maven工程依赖的报错，原因是虽然进行了依赖但并未导入 Maven 相关依赖包。此时需要对 Maven工程进行Update操作。1.3.7 Spring Boot依赖包的导入
Maven Update Project是指Maven进行了一系列跟自身配置有关的操作，如更新SVN、更新工程关联、编译工程、构建发布、下载Jar包、下载Jar doc文件等。图1-4
如图1-5所示，选择Update Project更新Maven工程依赖，可解决图1.4中在编写完pom.xml相关依赖并保存时未更新Maven工程的错误。图1-5
图1-6中Maven Update导入文件依赖包的选项释义如下。
Offline：启动离线模式，即不会通过Maven镜像地址下载资源，而重新检查自身仓库内的资源，内网开发的公司若没有自身的Maven镜像，则经常会使用离线模式。图1-6
Force Update of Snapshots/Releases：强制更新模式，在Update dependencies更新依赖下，强制更新模式代表无论此时所有依赖包是否处于正常依赖状态，都会重新到Maven仓库中进行检查，并重新把该包导入工程中。若工程在导入包后仍然发生错误，有些包没有被正常导入，则需要启动强制更新模式进行强制重新导入。
如果编写了一个 zfx_common-1.0.jar 包，已经导入工程中，但是编程人员手动在本地仓库中删除了该依赖包，并置入一个更新后的 zfx_common-1.0.jar 依赖包（但两个版本拥有相同的名称和版本号），就需要启动离线模式加强制更新模式，离线模式加强制更新模式会在自身的工程中删除原有 zfx_common-1.0.jar 包，并依赖更新后的同版本号的zfx_common-1.0.jar依赖包。
Update project configuration from pom.xml：根据pom.xml的配置文件更新工程。
Refresh workspace resources from local filesystem：从本地仓库系统刷新工作区资源。若仓库中含有该依赖包，则从仓库中进行获取；若仓库中没有该依赖包，则会通过Maven镜像地址进行下载。镜像地址在$Maven_HOME/config/setting.xml文件中配置。
Clean projects：重新编译工程。1.3.8 编写Spring Boot启动类
Spring Boot微服务工程都是JavaSE工程，因此需要main方法来启动并加载Spring容器等相关操作。启动核心代码如下。
和
上述两种都是Spring Boot微服务的启动核心代码。启动类Application-Main.java代码如下（启动类名称可自行定义）。1.3.9 编写Spring Boot接口
在boot_01工程中创建HelloWorld.java类，在HelloWorld.java类中编写REST风格的HTTP接口代码如下。
@RestController 注解相当于@Controller 注解和@ResponseBody 注解的集成注解，@RestController注解可直接返回json格式字符串，不需要新增其他代码。
@RequestMapping（＂/＂）是 springMVC 的注解，映射路径给外部进行访问。若该工程中含有相同的@RequestMapping路径，则会发生启动报错异常。1.3.10 当前项目结构
ApplicationMain放置在com.zfx文件夹中，而其他文件则放置在com.zfx.xxx中，原因是Spring Boot的@SpringBootApplication只能扫描com.zfx的下级文件夹。
若某个@Component 组件类注解放置在com.zfx同级文件夹下，则无法被@SpringBoot-Application 注解扫描到，也无法被注册到Spring的Application容器内。当前项目结构如图1-7所示。1.3.11 启动工程
因为Spring Boot将Tomcat集成到自身上的框架，所以通过main命令可启动。图1-7
启动项目时直接在 ApplicationMain.java类中运行Run As→Java Application命令即可，如图1-8所示。图1-81.3.12 Spring Boot初始化启动后
根据日志最后看到部分启动信息如下。
Spring Boot内嵌Tomcat 默认加载端口号为8080。
Spring Boot默认不需要输入工程名。如果有特殊需要，可在配置文件中增加自定义工程名配置。如果@RequestMapping 写成@RequestMapping（＂HelloWorld＂），访问的路径为localhost：8080/HelloWorld，后续对工程使用Spring Cloud进行控制时可以用增加工程名的方式来区分不同的微服务。
启动工程后，输入localhost：8080调用工程中的相关接口，执行结果如图1-9所示。图1-9
如果访问 localhost：8080/XXX，会报找不到接口的错误。这是因为 Spring Boot 不像Tomcat自带了一个欢迎页面。找不到相关接口报错提示如图1-10所示。图1-10
注意，HTTP-404 错误只在前台报错，后台正常打印日志且不输出“错误”信息，错误日志如下。1.3.13 实例易错点
1.缺少启动注解错误
SpringContext 容器没有启动成功的报错信息如下，通常是因为缺少@EnableAuto-Configuration注解所引起的，此时应检查main方法的类是否含有@EnableAutoConfiguration注解或@SpringBootApplication注解修饰。
2.@RequestMapping路径重复错误
@RequestMapping路径重复错误是初学者常见错误之一，错误日志如下。
通常说明@RequestMapping（＂＂）在映射路径时，如果某一个路径相同，重复了一次或以上，需要修改成不同的路径名。
注意，下述代码使用@PathVariable注解用来获取URL路径上携带参数的信息，虽然@RequestMapping（/HelloWorld/{id}）注解中的花括号内使用了不同的命名方式，但由于URL路径重复，所以@RequestMapping注解无法正常识别并获取URL路径与其携带的参数，无法正确将URL映射到Java接口中去，因此会引发多个相同路径的错误异常。
以上方法并不会报启动错误。部分启动日志如下。
多个相同路径的错误在运行后调用会报以下错误，找不到相对应的接口函数如图 1-11所示。因此应当避免出现多个相同位置的@PathVariable，让维护人员混淆或模糊的写法。
试读结束[说明：试读内容隐藏了图片]