分布式微服务架构：原理与实战(txt+pdf+epub+mobi电子书下载)

作者：黄文毅

出版社：清华大学出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

分布式微服务架构：原理与实战试读：

作／者／简／介

内容简介

随着互联网技术的发展，系统架构由单体架构、垂直MVC架构、SOA服务化、分布式服务演变到分布式微服务架构，这是互联网企业架构的必经之路。分布式微服务架构涵盖的技术面广，知识点多。本书旨在让更多计算机从业者熟悉一个完整的分布式微服务架构所涉及的基础概念、涵盖的技术以及实战开发。

本书蕴含的知识体系甚广，第1~2章主要讲解架构是如何向前演化发展的以及阅读本书之前需要准备的环境。第3~5章主要讲解服务之间的RPC调用、通信协议等。第6~7章主要讲解服务路由以及服务注册中心的原理和实践。第8章主要讲解服务调用。第9章主要讲解服务容器化以及如何部署和发布服务。第10~11章主要讲解服务限流、降级、容错以及熔断等技术。第12~13章主要讲解如何搭建服务日志和监控体系。第15章主要讲解配置中心的原理以及如何搭建配置中心。第16章主要讲解分布式数据库、分布式缓存、分布式事务、分布式Session以及服务如何通过Kafka解耦。第17章主要讲解微服务如何测试。第18章主要讲解目前主流的分布式微服务架构案例。

本书适用于所有Java编程语言开发人员、分布式微服务架构爱好者以及计算机专业的学生等。前　言

微服务是一种分布式系统架构，是近年来备受关注的话题。它是大型互联网公司系统架构发展到一定程度的产物。它建议我们将业务切分为更加细粒度的服务，并使每个服务的职责单一且可独立部署，服务内部高内聚，服务之间低耦合，彼此相互隔离。分布式微服务架构在大型互联网公司是一把利剑，但并非适合所有企业，比如传统IT企业。因为分布式微服务架构对技术要求高，需要我们有一个自动化部署系统、分布式微服务日志中心以及完善的服务监控和告警平台，对公司的运维人员要求更高，需要投入更多的人力和物力，只有大公司或者一流的技术团队才能真正玩得起微服务架构。所以，我们不能为了微服务而去微服务，需要根据企业自身的情况选择适合自己公司的系统架构。

本书是一本理论和实践相结合的图书，将非常完善地介绍分布式微服务所涵盖的方方面面的知识，并通过大量生动形象的原理图以及实战案例加深读者对微服务架构的理解，相信读者必会受益匪浅。

让我们开始分布式微服务架构的探险之旅吧！本书结构

本书共18章，以下是各章节的内容概要。

第1章主要介绍系统架构的发展历程和架构演变：单体架构、垂直MVC架构、SOA面向服务架构、分布式系统架构、分布式微服务架构。

第2章主要介绍开始学习分布式微服务架构之前的环境准备，包括JDK安装、Intellij IDEA安装、Maven安装、快速搭建Spring Boot项目以及Spring Boot核心功能及生产级特性。

第3章主要介绍微服务之间如何通过RPC相互调用、RPC核心组件、RPC调用过程、RPC框架的性能以及目前流行的RPC框架等。

第4章主要介绍微服务之间调用时，数据如何进行序列化与反序列化，以及目前主流的序列化框架和实战。

第5章主要介绍回顾Java网络通信，包括传统BIO编程、伪异步I/O编程、NIO编程，介绍目前非常流行的通信框架Netty，以及如何通过Netty开发具体实例。最后，介绍分布式服务框架使用的私有协议和公有协议，设计自定义私有协议需要注意的问题。

第6章主要介绍微服务路由、服务信息存放方式、负载均衡的实现以及负载均衡算法。

第7章主要介绍微服务注册中心的概念、ZooKeeper的概念、ZooKeeper的原理、ZooKeeper的安装、ZooKeeper搭建集群环境、命令行客户端ZkClient以及ZooKeeper实现服务注册与发现。

第8章主要介绍服务调用的方式：同步调用、异步调用、并行调用、泛化调用等。

第9章主要回顾Docker容器化技术，包括Docker的基本概念、Docker的架构、Docker的安装、Docker常用命令、Docker构建镜像以及如何通过Docker技术将Spring Boot应用容器化。最后，介绍微服务部署的几种方式：蓝绿部署、滚动发布以及灰度发布／金丝雀部署等。

第10章主要介绍服务限流定义、服务限流算法、限流设计以及分级限流。

第11章主要介绍服务降级原因、服务降级开关、自动降级、读服务降级、写服务降级、服务容错策略、Hystrix降级与熔断、服务优先级设计等。

第12章主要介绍服务版本和服务发布的三种方式：注解方式、XML配置化方式、API调用方式。

第13章主要介绍分布式日志、日志类型、日志结构、常用的日志框架以及如何搭建ELK日志中心。

第14章主要介绍分布式微服务架构监控，包括：监控价值、监控的完整体系、微服务监控的类型、Spring Boot应用监控、Spring Boot Admin监控系统以及如何集成InfluxDB+cAdvisor+Grafana搭建监控系统等。

第15章主要介绍配置中心的演化、配置中心的原理以及如何使用Spring Cloud Config搭建配置中心。

第16章主要介绍分布式数据库架构与原理、分布式事务理论、分布式缓存架构与原理、分布式Session架构与原理以及微服务之间的解耦。

第17章主要介绍微服务测试，包括：Spring Boot单元测试、Mockito/PowerMockito测试框架、H2内存型数据库、REST API测试以及性能测试等。

第18章主要介绍微服务架构案例：分布式微服务框架Dubbo、Spring Boot+Spring Cloud解决方案、Spring Boot+Kubernetes+Docker解决方案等，同时介绍Spring Cloud的概念、Spring Cloud生态、Dubbo的原理、Kubernetes的概念、Kubernetes的原理与使用等。学习本书的预备知识Java基础

读者需要掌握J2SE基础知识，这是最基本的，也是最重要的。Java Web开发技术

在项目实战中需要用到Java Web的相关技术，比如：Spring、Spring MVC、Tomcat等技术。Spring Boot技术

本书的很多内容都是建立在读者了解Spring Boot的基础上展开的，读者需要对微服务脚手架Spring Boot的基础知识和功能特性有一定的了解。其他技术

读者需要了解目前主流的技术，比如数据库MySQL、缓存Redis、消息中间件Kafka、容器技术Docker等。本书使用的软件版本

本书项目实战开发环境为：● 操作系统Mac Pro● 开发工具Intellij IDEA 2018.1● JDK使用1.8版本以上● Spring Boot最新版2.1.4.RELEASE● 其他主流技术基本使用最新版本读者对象● 使用Java技术体系的中、高级开发人员● 系统架构师● 系统运维人员● 对分布式微服务架构感兴趣的所有开发人员源代码下载

本书GitHub源代码下载地址：

https://github.com/huangwenyi10/distributed-service-architecture-book.git。致谢

本书能够顺利出版，首先感谢清华大学出版社的王金柱老师及背后的团队对本书的辛勤付出，这是我第四次和王金柱老师合作，每次合作都能让我感到轻松和快乐，也让我体会到写作是一件快乐的事情，我很享受这个过程。

感谢厦门美图之家科技有限公司，书中很多的知识点和项目实战经验都来源于贵公司，如果没有贵公司提供的实战案例，这本书就不可能问世。感谢主管黄及峰，导师阮龙生和吴超群，同事张汉铮、兰可成、彭阳坤、黄灿槟、王怀宗、许巡枝、吴旭星，项目管理张春宇等在学习和生活上对我的照顾。

感谢笔者的女朋友郭雅苹，感谢她一路不离不弃地陪伴和督促，感谢她对我工作的理解和支持，感谢她对我生活无微不至的照顾，使我没有后顾之忧，全身心投入本书的写作中。

限于笔者水平和写作时间有限，书中肯定存在不妥之处，欢迎读者批评指正（邮箱：huangwenyi10@163.com）。黄文毅2019年5月31日第1章从架构演进启程

本章主要介绍系统架构的发展历程和架构演变，包括单体架构、垂直MVC架构、SOA面向服务架构、分布式系统架构、分布式微服务架构。1.1　水平分层架构1.1.1　应用架构概述

人会随着生存环境的变化而不断成长，应用架构也一样。应用架构所处的环境是什么呢？答案是很明显的，应用架构所处的环境就是业务。业务由简单到复杂，应用架构也要相应地做出调整来适应业务的变化。任务脱离业务的架构都是图1-1　应用无架构与MVC架构图耍流氓，因为架构一旦脱离业务，就好像人脱离了生存环境，皮之不存，毛将焉附。最早的应用程序业务比较简单，因此呈现出一种几乎无架构的状态，具体如图1-1所示。

无架构应用包括几十或者几百个功能项，而所有功能项都被打包进了一个单体的应用中，例如传统的OA、ERP、CRM等其他各种各样的软件。对于这种野兽级别的软件应用，其部署、排错、扩展和升级等工作对开发人员来说都是噩梦。1.1.2　MVC架构／水平分层架构

随着业务不断复杂，我们意识到架构可以做到水平分层，比如展示层、控制层、数据层等。我们将这样的架构称为“MVC架构”。（1）展示层（View）

视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML+CSS元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色。（2）控制层（Controller）

控制层接收用户的输入并调用模型和视图完成用户的需求，所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后确定用哪个视图来显示返回的数据，经典的技术有Servlet、Structs、Spring MVC等。（3）模型层（Model）

模型层是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。一个模型可以同时为多个视图提供数据。标准的MVC框架事实上并不包含模型层，通常需要专门的数据库连接池和统一的数据库访问接口对接数据库。因此，ORM框架逐渐流行起来，常用的有iBatis、MyBatis、Hibernate等。这些ORM框架屏蔽了底层的数据库连接池和数据源的实现，实现程序对象到关系数据库数据的映射。

通过MVC框架开发的项目会统一打成大的War包，部署到Tomcat、Jetty等Web服务器上。传统的MVC框架如何实现高可用和高并发呢？具体原理如图1-2和图1-3所示。图1-2　传统架构高可用解决方案

传统应用架构一般采用热双机的模式。正常情况下，Master主机提供服务，当Master主机出现故障或者宕机的时候，切换到Slave从机。我们可以通过Linux的WatchDog或者Keepalived检测服务器的状态，如果有一台Web服务器宕机或工作出现故障，Keepalived就会检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后，Keepalived自动将服务器加入服务器群中。这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的服务器。对于高并发、大流量的场景，传统应用架构一般采用Apache（软负载）或者F5做负载均衡，具体如图1-3所示。图1-3　传统架构高并发解决方案

随着业务不断发展，业务变得越来越复杂，传统MVC架构下的系统应用代码越来越多，其缺点也渐渐显露出来。● 部署效率低。业务膨胀导致代码膨胀、测试用例膨胀，编译和部署效率变低，某个功能出问题或者编译异常都得重新打包部署，效率极低。● 维护困难。由于业务的膨胀，功能越来越复杂，代码修改牵一发而动全身，维护和定制都非常困难。● 团队协作效率低，代码重复率高。● 系统可靠性和可用性变差。业务的发展导致访问量、网络流量上升，负载均衡、数据库连接等都会面临巨大压力。由于所有的模块都在一个应用进程里，因此如果某个应用接口发生故障，比如内存泄漏，就会导致整个应用宕机，严重影响业务的正常进行。● 新功能上线周期变长。新开发的功能需要和老功能一起打包、编译和测试，如果测试出Bug，整个系统就需要重新修改、回归测试、打包和部署，这些强耦合会导致整个交互效率下降。1.2　SOA服务化架构

当水平分层应用越来越多时，应用之间的交互不可避免，我们需要将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心。同时将公共API抽取出来，作为独立的公共服务供其他调用者消费，以实现服务的共享和重用，降低开发和运维成本。应用拆分之后会按照模块独立部署，接口调用由本地API演进成跨进程的远程方法调用，具体如图1-4所示。图1-4　SOA服务化原理图

应用和服务之间的远程调用或者服务之间的远程调用通常有两种方式，即基于HTTP的远程调用和基于RPC的远程调用。1.2.1　SOA概述

SOA（面向服务的架构）将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。

SOA是一种粗粒度、松耦合的服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。SOA可以看作是B/S模型以及Web Service技术之后的自然延伸。

SOA面向服务架构是站在一个新的高度理解企业级架构中的各种组件的开发、部署形式的，它将帮助企业系统架构者更迅速、更可靠、更具重用性地架构整个业务系统。SOA架构能够更加从容地面对业务的急剧变化。1.2.2　SOA的特征

SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化作用。要实现这一目标，就要在实施SOA的过程中牢记以下特征：● 可从企业外部访问。● 随时可用。● 粗粒度的服务接口分级。● 松散耦合。● 可重用的服务。● 服务接口设计管理。● 标准化的服务接口。● 支持各种消息模式。● 精确定义的服务契约。1.2.3　SOA面临的问题

SOA是一种粗粒度、松耦合的服务架构，随着业务的不断发展，服务数量越来越多，服务治理、服务运维、服务日志在线搜索查询、服务性能、面向服务后服务数量暴增对运维人员的挑战等一系列问题接踵而来。基于这些问题，分布式微服务架构应运而生。1.3　分布式微服务架构1.3.1　微服务概述

微服务是在2014年由Martin Fowler大神提出的。首先，可以肯定的是SOA和微服务是一脉相承的。Martin Fowler提出这一概念可以说把SOA的理念继续升华，精进了一步。微服务的核心思想是在应用开发领域，使用一系列微小服务来实现单个应用，或者说微服务的目的是有效地拆分应用，实现敏捷开发和部署，可以使用不同的编程语言编写。1.3.2　SOA与微服务

从实现的方式来看，两者都具有中立性，与语言无关，协议跨平台。相比SOA，微服务框架将能够带来更大的敏捷性，并为构建应用提供更轻量级、更高效率的开发。而SOA更适合大型企业中的业务过程编排和应用集成。

从服务粒度来看，既然是微服务，必然更倡导服务的细粒度，重用组合，甚至是每个操作（或方法）都是独立开发的服务，足够小到不能再进行拆分。而SOA没有这么极致的要求，只需要接口契约的规范化，内部实现可以更粗粒度。

从部署方式来看，传统的SOA服务粒度比较大，多数会采用将多个服务合并打成War包的方案。而微服务则打开了这个黑盒子，把应用拆分成一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通信机制联系，经常是基于HTTP或者RPC的，这些服务基于业务能力构建，能实现集中化管理。

另外，微服务是去ESB（总线）、去中心化、分布式的，而SOA还是以ESB总线为核心，大量的WS标准实现。1.3.3　微服务架构的特点

微服务的主要特点有：● 单一职责：与面向对象原则中的单一职责原则类似，需要确保每个微服务只做一件事情。● 独立部署、升级、扩展和替换：每个服务都可以单独部署及重新部署而不影响整个系统。微服务能以独立进程进行部署（对于重要服务而言），也可将多个微服务合设到同一个进程中，进行高密度部署（对于非核心服务）。服务可以被部署到物理机器上，也可以通过Docker技术实现容器级部署，降低部署成本，提高资源利用率。● 支持异构／多种语言：每个服务的实现细节都与其他服务无关，这使得服务之间能够解耦，团队可以针对每个服务选择最合适的开发语言、工具和方法。● 服务无状态：所有的微服务都尽量保证无状态或者有状态的可以做状态转移，例如session等数据，可以转移到Redis集群中。● 微服务间采用统一的通信模式，如RPC、REST等。● 隔离化：每个微服务相互隔离，互不影响。每个微服务运行在自己的进程中，某一个服务出现问题不会影响其他服务。● 自动化管理：需要对微服务提供自动化部署和监控预警的能力，实现真正的DevOps。1.3.4　微服务架构的缺点1. 复杂度高

微服务间通过REST、RPC等形式交互，需要考虑被调用方故障、过载、消息丢失等各种异常情况，代码逻辑更加复杂。

对于微服务间的事务性操作，因为不同的微服务采用不同的数据库，所以无法利用数据库本身的事务机制保证一致性，需要引入二阶段提交等分布式事务技术。2. 运维复杂，成本高

在采用微服务架构时，系统由多个独立运行的微服务构成，需要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才能够更好地运维系统，微服务架构的引入会带来运维成本的上升。3. 影响性能

微服务之间通过REST、RPC等形式进行跨进程交互，增加网络IO，通信的时延会受到较大的影响。4. 依赖更加复杂

微服务架构模式下，应用的改变将会波及多个服务。比如，在完成一个需求时需要修改服务A、B、C，而A依赖B，B依赖C。在单体应用中，只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，需要更新服务C，然后是B，最后才是A。1.3.5　微服务架构全景图

微服务架构平台技术体系非常庞大，这里只能简单列举平台基础的技术，具体内容如图1-5所示。图1-5　微服务架构简单全景图● 日志系统（日志中心）：主要用于收集和管理微服务应用产生的日志，快速帮助开发人员定位异常，同时还可以在日志系统中搜索历史日志。日志配合告警系统，可以按照日志信息的等级（error、info等）、日志的某一个具体的字段设置告警规则，通过短信、企业微信、邮箱提醒开发人员，帮助开发人员及时发现并解决问题。● 监控中心：主要用于实时监控微服务运行情况，比如CPU、内存、QPS、成功率等。设置各项指标的阈值，当微服务应用程序的某一个指标达到设置的阈值时，发出告警提醒开发人员及时处理问题。● 配置中心：主要用于统一管理微服务的配置，开发人员或者运维人员通过配置中心可以实时动态更新微服务的配置参数，不需要重启系统，配置的参数即可生效。● 网关：主要用于给前端调用提供统一的入口。● 部署中心：主要用于编译并打包微服务源码并将其部署到Docker容器中，技术可以选择Jenkins（慢慢淘汰）和GitHub CI（主流）。● 注册中心：主要用于管理微服务相关的配置信息，如服务提供者信息，常用的技术有ZooKeeper等。● 消息中心：主要用于微服务之间相互解耦，常用的技术有Kafka、RabbitMQ等。大型互联网企业都有自己的消息中心，可以在消息中心管理topic、查看消息队列的消费情况、查看消息队列的消费速度和堆积情况等。如果队列出现消息堆积，那么还会结合监控中心进行告警通知。● 追踪中心：主要用于管理微服务的调用轨迹。● 容器化：容器化技术促进微服务架构落地，目前流行的技术主要是Docker技术。● 应用层：在应用层中主要相关的业务服务有用户服务、订单服务、产品服务等，各个微服务由不同的开发团队管理，每个团队可以选择适合自己业务开发的语言和技术框架，开发语言如Java、Go、PHP，技术架构如目前流行的微服务脚手架Spring Boot。

图1-6只是简单列举微服务中重要的组成部分，企业中用的技术更为复杂，其他子系统更为繁多。图1-6　微服务架构各部分协调与分工

图1-6只是微服务架构简单的全景图，接下来我们了解各个部分是如何协调与分工的。● 开发人员将代码提交到代码仓库（GitHub）。● 部署中心从配置中心获取服务相关的配置参数。● 部署中心将应用程序和配置文件一同复制到Docker镜像中，并上传镜像到镜像仓库。● 服务发布时，从镜像仓库下载指定的镜像，启动并运行容器，容器启动后，会自动将配置信息写入注册中心。● 用户通过浏览器或者移动端访问应用系统时，首先请求进入网关。● 网关通过服务名称从服务注册中心获取服务所在的IP地址和端口，根据服务地址（IP地址和端口）以反向代理的方式，结合一定的负载均衡策略调用具体的容器。● 服务在容器运行过程中会产生大量的日志，这些日志会被收集到日志系统中进行管理，监控中心可以监控容器的运行情况，并通过可视化的报表展示数据（如Grafana技术），追踪中心提供图形化界面查看服务之间的调用轨迹以及所产生的调用时延迟等。1.3.6　微服务类型

我们根据服务的作用以及特点，将其分为4种类型：基础服务、业务服务、前置服务、组合服务。不同服务迁移的优先级不同。● 基础服务：基础组件，与具体的业务无关，比如短信服务、邮件服务等。这种服务最容易拆出来做微服务，是第一优先级分离出来的服务。● 业务服务：一些垂直的业务系统，只处理单一的业务类型，比如评论服务、点赞服务、Feed服务等。这类服务职责比较单一，根据业务情况来选择是否迁移，是第二优先级分离出来的服务。● 前置服务：前置服务一般为服务的接入或者输出服务，比如网站的前端服务、App的服务接口等，这是第三优先级分离出来的服务。● 组合服务：组合服务涉及具体的业务，比如订单服务，需要调用很多垂直的业务服务，这类服务一般放到最后进行微服务化架构改造，因为这类服务最为复杂，除非涉及大的业务逻辑变更，否则不会轻易进行迁移。1.3.7　微服务拆分原则与步骤

微服务拆分是一个渐进的过程，不能一步到位。服务拆分之前，需要确认公司业务是否适合，是否需要进行微服务化改造，毕竟很多传统的垂直系统是不适合走微服务这一套的；需要梳理系统的业务，对不同的业务进行分类；同时需要加强团队成员的微服务架基础知识的配置，比如Spring Boot技术、Spring Cloud技术等。

在进行微服务改造的过程中，优先对新业务系统进行微服务化，前期可以只有少量的项目进行微服务化改造，随着大家对技术的熟悉度增加，可以加大微服务改造的范围。这里总结几个微服务拆分的步骤：（1）梳理业务

梳理出业务模块以及模块之间的依赖关联关系。这一过程需要相关的业务人员一起评估。（2）优先对公共业务进行服务化

优先对公共业务进行服务化，如用户服务、邮箱服务、消息服务等。（3）对业务服务进行服务化

对业务服务进行服务化，切分的服务之间尽量不要有任何的关联，开始服务化时，先粗粒度地进行服务的划分，之后再慢慢根据业务的情况进行细粒度服务的切分，不必追求一步到位。微服务拆分后，服务之间的依赖关系复杂，如果循环调用，升级的时候就很头疼，不知道应该先升级哪个，后升级哪个，难以维护。● 基础服务层以及基础业务服务层主要做数据库的操作和一些简单的业务逻辑，不允许调用其他任何服务。● 组合服务层可以调用基础服务层完成复杂的业务逻辑，也可以调用组合服务层，但不允许循环调用，也不允许调用Controller层服务。● Controller层服务可以调用组合业务层服务，不允许被其他服务调用。（4）微服务的领域模型设计

微服务拆分完成后，需要设计每个服务设计的数据库表、表与表之间的关系。数据库表设计需要文档化，方便相关开发人员查阅。（5）定义微服务接口

数据库表设计完成后，需要定义服务接口，让外部调用。服务接口的入参、出参、方法的名称以及注释等都需要仔细思考，必要时还需要开会评审。服务接口也需要文档化，方便调用者查阅。第2章微服务开发框架

本章将介绍学习分布式微服务架构之前的环境准备，包括JDK安装、Intellij IDEA安装、Maven安装、快速搭建Spring Boot项目以及Spring Boot核心功能及生产级特性。2.1　环境准备2.1.1　安装JDK

JDK（Java SE Development Kit）建议使用1.8及以上的版本，其官方下载路径为https://www.oracle.com/technetwork/java/javase/downloads/jdk11-downloads-5066655.html。访问该链接出现如图2-1所示的界面。读者可以根据计算机的操作系统配置选择合适的JDK安装包，笔者的计算机是MacBook Pro，因此下载安装包：jdk-11.0.1_osx-x64_bin.dmg。图2-1　JDK安装包下载

安装包下载完成之后，双击下载软件，按照提示安装即可，如图2-2所示。图2-2　JDK安装

打开Finder，找到安装好的JDK路径，具体如图2-3所示。图2-3　JDK安装路径图

其中，Contents下的Home文件夹是该JDK的根目录，具体如图2-4所示。图2-4　JDK Home文件夹

在英文输入法的状态下，按键盘上的“Command+空格”组合键，调出Spotlight搜索，输入ter，选择【终端】，然后按回车键，便可以快速启动终端，具体如图2-5所示。图2-5　Spotlight搜索启动终端

在【终端】输入“java –version”，如果看到JDK版本为11.0.1，就说明JDK安装成功，具体如图2-6所示。图2-6　JDK安装成功

如果是第一次配置环境变量，那么可以使用touch .bash_profile创建一个.bash_profile的隐藏配置文件。如果是编辑已存在的配置文件，那么可以使用open -e .bash_profile命令。假如配置文件已存在，这里我们使用open -e .bash_profile命令打开配置文件。在配置文件中添加如下代码，具体如图2-7所示。 //JAVA_HOME是Java的安装路径（注意该行注释不可加到.bash_profile配置文件中） JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home PATH=$JAVA_HOME/bin:$PATH:. CLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/dt.jar:. export JAVA_HOME export PATH export CLASSPATH图2-7　bash_profile添加JDK配置

保存并关闭.bash_profile文件，在命令行【终端】输入命令“source .bash_profile”使配置文件生效。同时在【终端】输入“echo $JAVA_HOME”显示刚才配置的路径，具体如图2-8所示。图2-8　验证JDK配置是否添加成功2.1.2　安装Intellij IDEA

在Intellij IDEA的官方网站（https://www.jetbrains.com/idea/download/#section=mac）可以免费下载IDEA。下载IDEA后，运行安装程序，按提示安装即可。本书使用的是Intellij IDEA 2018.1版本，当然大家也可以使用其他版本的IDEA，版本不要过低即可。2.1.3　安装Apache Maven

Apache Maven是目前流行的项目管理和构建自动化工具。虽然IDEA已经包含Maven插件，但是还是希望大家在工作中能够安装自己的Maven插件，方便以后项目配置需要。我们可以通过Maven的官网（http://maven.apache.org/download.cgi）下载最新版的Maven。本书的Maven版本为apache-maven-3.6.0，具体如图2-9所示。图2-9　apache-maven-3.6.0下载页面

打开命令行【终端】，输入“open -e .bash_profile”命令打开配置文件。然后输入Maven的环境变量，具体代码如下所示： ###MAVEN_HOME是Maven的安装路径（注意该行注释不可加到.bash_profile配置文件中） MAVEN_HOME=/Users/ay/Downloads/soft/apache-maven-3.6.0 ###JAVA_HOME是Java的安装路径（注意该行注释不可加到.bash_profile配置文件中） JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home ###在原有的基础上添加:$M2_HOME/bin（注意该行注释不可加到.bash_profile配置文件中） PATH=$JAVA_HOME/bin:$PATH:.:$M2_HOME/bin CLASSPATH=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/dt.jar:. export JAVA_HOME export PATH export CLASSPATH

Maven环境变量添加完成之后，保存并退出.bash_profile文件。在命令行【终端】输入“source~/.bash_profile”命令使环境变量生效。输入mvn -v查看Maven否安装成功。2.2　一分钟快速搭建Spring Boot项目2.2.1　使用Spring Initializr新建项目

使用Intellij IDEA创建Spring Boot项目有多种方式，比如使用Maven和Spring Initializr。这里只介绍Spring Initializr这种方式，因为这种方式不但为我们生成完整的目录结构，还为我们生成一个默认的主程序，节省时间。我们的目的是掌握Spring Boot知识，而不是学一堆花样。具体步骤如下：

步骤　在Intellij IDEA界面中，单击【File】→【New】→01【Product】，在弹出的窗口中选择【Spring Initializr】选项，在【Product SDK】中选择JDK的安装路径，如果没有，就新建一个，然后单击【Next】按钮，具体如图2-10所示。图2-10　新建Spring Boot项目

步骤　选择【Spring Boot Version】，这里按默认版本（本书02使用的Spring Boot版本为2.1.1）即可。勾选【Web】选项，然后单击【Next】按钮，具体如图2-11所示。图2-11　选择Spring Boot版本

步骤　填写项目名称【my-spring-boot】，其他保持默认即03可，然后单击【Finish】按钮。至此，一个完整的Spring Boot创建完成，具体如图2-12所示。图2-12　填写Spring Boot项目名称

步骤　在IDEA开发工具上，找到刷新依赖的按钮04（Reimport All Maven Projects），下载相关的依赖包，这时开发工具开始下载Spring Boot项目所需依赖包，如图2-13所示。图2-13　刷新Spring Boot项目依赖

步骤　在项目的目录com.example.demo.controller下创建05HelloController控制层类，具体代码如下所示：2.2.2　测试

Spring Boot项目创建完成之后，找到入口类MySpringBootApplication中的main方法并运行。当看到如图2-14所示的界面，表示项目启动成功。同时还可以看出项目启动的端口（8080）以及启动时间。在浏览器输入访问地址：http://localhost:8080/hello，便可以在控制台打印信息“hello ay”。图2-14　Spring Boot启动成功界面2.3　Spring Boot简单介绍

Spring Boot是目前流行的微服务框架，倡导“约定优先于配置”，其设计目的是用来简化新Spring应用的初始化搭建以及开发过程。Spring Boot是一个典型的“核心＋插件”的系统架构，提供了很多核心的功能，比如自动化配置、提供starter简化Maven配置、内嵌Servlet容器、应用监控等功能，让我们可以快速构建企业级应用程序。Spring Boot使编码变得简单，使配置变得简单，使部署变得简单，使监控变得简单。2.3.1　Spring Boot核心功能及特性

Spring Boot提供的特性如下：（1）遵循习惯优于配置的原则

Spring Boot的配置都在application.properties中，但是并不意味着在Spring Boot应用中就必须包含该文件。application.properties配置文件包含大量的配置项，而大多数配置项都有其默认值，很多配置项不用我们去修改，使用默认值即可。这类行为叫作“自动化配置”。（2）提供了“开箱即用”的Spring插件

Spring Boot提供了大量的Starter，当我们需要整合其他技术（比如Redis、MQ等）时，只需要添加一段Maven依赖配置即可开启使用。每个Starter都有自己的配置项，而这些配置都可以在application.properties配置文件中进行统一配置，例如常用的spring-boot-starter-web、spring-boot-starter-tomcat、spring-boot-starter-actuator等。（3）内嵌Servlet容器

传统的项目都需要将项目打包成War包部署到Web服务器，比如Tomcat、Jetty、Undertow。而Spring Boot应用程序启动后会在默认端口8080下启动嵌入式Tomcat，执行Spring Boot项目的主程序main()函数，便可以快速运行项目。（4）倡导Java Config

Spring Boot可以完全不使用XML配置，并倡导我们使用Java注解方式开发项目。（5）多环境配置

项目开发过程中，项目不同的角色会使用不同的环境，比如开发人员会使用开发环境，测试人员会使用测试环境，性能测试会使用性能测试环境，项目开发完成之后会把项目部署到线上环境，等等。不同的环境往往会连接不同的MySQL数据库、Redis缓存、MQ消息中间件等。环境之间相互独立与隔离才不会相互影响。隔离的环境便于部署，提高工作效率。假如项目my-spring-boot需要3个环境：开发环境、测试环境、性能测试环境。我们复制my-spring-boot项目配置文件application.properties，分别取名为application-dev.properties、application-test.properties、application-perform.properties，作为开发环境、测试环境、性能测试环境。多环境的配置文件开发完成之后，我们在my-spring-boot的配置文件application.properties中添加配置激活选项，具体代码如下所示： ### 激活开发环境配置 spring.profiles.active=dev 如果我们想激活测试环境的配置，可修改为： ### 激活测试环境配置 spring.profiles.active=test 如果我们想激活性能测试环境的配置，可修改为： ### 激活性能测试环境配置 spring.profiles.active=test（6）提供大量生产级特性

Spring Boot提供大量的生产级特性，例如应用监控、健康检查、外部配置和核心指标等。我们可以给Spring Boot应用发送/metrics请求获取JSON数据，该数据包含内存、Java堆、类加载器、处理器、线程池等信息。我们还能在Java命令（备注：java -jar xxx.jar）上直接运行Spring Boot应用，并带上外部配置参数，这些参数将覆盖已有的默认配置参数。我们甚至可以通过发送一个URL请求去关闭Spring Boot应用。Spring Boot提供了基于HTTP、SSH、Telnet等方式对运行时的项目进行监控。2.3.2　Spring Boot的缺点

Spring Boot为我们带来诸多便利的同时也带来了如下缺点：● 高度集成，开发人员不知道底层实现。● 如果开发人员不了解Spring Boot底层，项目出现问题就会很难排查。● 将现有或传统的Spring Framework项目转换为Spring Boot应用程序相对来说比较困难和耗时。Spring Boot适用于全新Spring项目。● Spring Boot整合公司自研的框架和组件相对比较麻烦，例如Spring Boot整合公司自研的RPC框架等。2.4　Spring Boot目录介绍2.4.1　Spring Boot工程目录

Spring Boot的工程目录如图2-15所示。● /src/main/java：目录下放置所有的Java文件（源代码文件）。● /src/main/resources：用于存放所有的资源文件，包括静态资源文件、配置文件、页面文件等。● /src/main/resources/static：用于存放各类静态资源。● /src/main/resources/application.properties：配置文件，这个文件非常重要。Spring Boot默认支持两种配置文件类型（.properties和.yml）。● /src/main/resources/templates：用于存放模板文件，如Thymeleaf（这个技术不懂不用着急，以后会介绍）模板文件。● /src/test/java：放置单元测试类Java代码。● /target：放置编译后的.class文件、配置文件等。图2-15　Spring Boot项目目录

Spring Boot将很多配置文件进行了统一管理，且配置了默认值。Spring Boot会自动在/src/main/resources目录下找application.properties或者application.yml配置文件。找到后将运用此配置文件中的配置，否则使用默认配置。这两种类型的配置文件有其一即可，也可以两者并存。两者区别如下： application.properties： server.port = 8080 application.yml: server: port:8080注　意.properties配置文件的优先级高于.yml。例如在.properties文件中配置了server.port = 8080，同时在.yml中配置了server.port = 8090，Spring Boot将使用.properties中的8080端口。2.4.2　Spring Boot入口类

入口类的类名是根据项目名称生成的，我们的项目名称是my-spring-boot，故入口类的类名是“项目名称+Application”，即MySpringBootApplication.java。入口类的代码很简单，代码如下：● @SpringBootApplication：一个组合注解，包含@EnableAutoConfiguration、@ComponentScan和@SpringBootConfiguration三个注解，是项目启动注解。如果使用这三个注解，项目依旧可以启动起来，只是过于烦琐。因此，需要用@SpringBootApplication简化。● @SpringApplication.run：应用程序开始运行的方法。注　意MySpringBootApplication入口类需要放置在包的最外层，以便能够扫描到所有子包中的类。2.4.3　Spring Boot测试类

Spring Boot的测试类主要放置在/src/test/java目录下。项目创建完成后，Spring Boot会自动为我们生成测试类MySpringBootApplicationTests.java。其类名也是根据“项目名称+ApplicationTests”生成的。测试类的代码如下：● @RunWith(SpringRunner.class)：@RunWith(Parameterized.class)参数化运行器，配合@Parameters使用Junit的参数化功能。查源码可知，SpringRunner类继承自SpringJUnit4ClassRunner类，此处表明使用SpringJUnit4ClassRunner执行器。此执行器集成了Spring的一些功能。如果只是简单的Junit单元测试，该注解可以去掉。● @SpringBootTest：此注解能够测试我们的SpringApplication，因为Spring Boot程序的入口是SpringApplication，所以基本上所有配置都会通过入口类去加载，而该注解可以引用入口类的配置。● @Test：JUnit单元测试的注解，注解在方法上，表示一个测试方法。

当我们右击执行MySpringBootApplicationTests.java中的contextLoads方法的时候，大家可以看到控制台打印的信息和执行入口类中的SpringApplication.run()方法打印的信息是一致的。由此便知，@SpringBootTest是引入了入口类的配置。2.4.4　pom文件

Spring Boot项目下的pom.xml文件主要用来存放依赖信息。具体代码如下所示：● spring-boot-starter-parent：一个特殊的starter，它用来提供相关的Maven默认依赖，使用它之后，常用的包依赖可以省去version标签。● spring-boot-starter-web：只要将其加入项目的Maven依赖中，就得到了一个可执行的Web应用。该依赖中包含许多常用的依赖包，比如spring-web、spring-webmvc等。我们不需要做任何Web配置，便能获得相关Web服务。● spring-boot-starter-test：这个依赖和测试相关，只要引入它，就会把所有与测试相关的包全部引入。● spring-boot-maven-plugin：一个Maven插件，能够以Maven的方式为应用提供Spring Boot的支持，即为Spring Boot应用提供了执行Maven操作的可能，能够将Spring Boot应用打包为可执行的JAR或WAR文件。2.5　Spring Boot生产级特性2.5.1　应用监控

Spring Boot大部分模块都是用于开发业务功能或连接外部资源的。除此之外，Spring Boot还为我们提供了spring-boot-starter-actuator模块，该模块主要用于管理和监控应用。这是一个用于暴露自身信息的模块。spring-boot-starter-actuator模块可以有效地减少监控系统在采集应用指标时的开发量。spring-boot-starter-actuator模块提供了监控和管理端点以及一些常用的扩展和配置方式，具体如表2-1所示。表2-1　监控和管理端点

在Spring Boot中使用监控，首先需要在pom.xml文件中引入所需的依赖spring-boot-starter-actuator，具体代码如下所示：

在pom.xml文件引入spring-boot-starter-actuator依赖包之后，需要在application.properties文件中添加如下的配置信息： ### 应用监控配置 #指定访问这些监控方法的端口 management.server.port=8099

management.port用于指定访问这些监控方法的端口。spring-boot-starter-actuator依赖和配置都添加成功之后，重新启动my-spring-boot项目，项目启动成功之后，在浏览器测试各个端点。比如在浏览器中输入：http://localhost:8099/actuator/health，可以看到如图2-16所示的应用健康信息。图2-16　应用健康信息

试读结束[说明：试读内容隐藏了图片]

下载完整电子书