在上一章中，我们讨论了Redis服务的运维，包括单机运行和Sentinel运行。

在本小节中，我们讨论如何在Spring Boot中集成Redis。

Spring Boot内置了Redis的接入方式，spring-data-redis，这种方案在Jedis客户端的基础上尽心过了简单的封装。若只使用Redis的KV存储特性，该方案可以满足要求。但对于Redis的高级特性(如SortedSet、SETNX等)，则需要手动调用底层Jedis客户端的API，使用方式较为晦涩且容易出错。

为此，我们推荐使用Redisson作为接入客户端，它提供了简单易用的封装，可以用最小的编程代价来发挥Redis的最大功能。

作为纯内存缓存，Memcached拥有非常出色的读写性能，但也存在一个较为严重的缺点：无法持久化。

这意味着，一旦Memcached服务重启(更常见的是掉电)，之前所有的缓存就会丢失。若线上的流量很大，这种重启很容易诱发"缓存雪崩"，从而导致系统故障。

Redis的出现很好的解决了这个问题，它是一款高性能的内存的数据库，既不仅数据的支持持久化、也内置了许多数据结构，方便实现各种需求。在一些场景下1，可以直接用Redis取代Memcached + MySQL的组合。

本节将讨论Redis运维相关的问题。

前面已经提到，缓存是快速提升系统性能，缓解瓶颈的有效手段。

缓存的种类多种多样，小到CPU的缓存，大到静态生成的页面缓存。在本小节中，我们主要讨论在Spring Boot中整合如下两种缓存:

本地缓存: 在内存中开辟一小块空间，用于缓存，速度很快，但容量受限。我们采用Gruva中的缓存实现。
网络缓存: 同一微服务的不同节点间，通过网络共享，例如Memcached。

如果业务进一步发展，通过"读写分离"、"分库分表"后，数据库的性能依然无法满足高并发读请求，此时就需要缓存出马了。

经过上一节的讨论，相信你已经有了一套可运维的MySQL服务器了，接下来的两节，我们来讨论如何在Spring Boot中整合MySQL。

在介绍服务发现和负载均衡时已经提到，我们的架构中，对每个微服务开放两个虚拟IP端口，一个是RPC，另外一个是REST(HTTP)。

在上一节中，我们探讨了Spring Boot中集成Thrift RPC的方案，主要是针对RPC端口。

在本节中，我们首先看一下优雅停机的问题，随后探讨REST服务的发现与负载均衡均衡的问题。

在介绍RPC之前，我们先来学习下Spring Boot的自动配置。

如前序章节微服务技术栈概览所述，本书选用Java作为开发语言、Gradle作为构建工具。

在熟悉了的基本操作后，我们来讨论下如何实现微服务的自动发现。

前面已经提到，微服务架构离不开容器技术。

子曰：“工欲善其事，必先利其器”。前面已经提到，微服务架构的对开发水平提出了更高的＝要求，我们更应该注重研发工具链的建设，以提高开发效率。

下面来看一下微服务相关的技术选型

在看过微服务整体架构后，我们来讨论下架构的各个层次中，本书所选用的技术栈。与前面类似，我们依然自底向上讨论。

在正式讨论微服务架构前，有必要用简短的篇幅，讨论下微服务以及这种架构风格的优点和缺点。

如果你一直从事研发职位，或很少接触运维岗位，可能会觉得将"运维"放到架构设计中，有一些多余。

事实上，上述想法大错特错，我们来看几个案例:

"刚才的上线，研发人员是从test分支打的jar包，引入了新的bug，赶快从主分支打个jar包，我要重新上线..."
"在我的本地跑的很好的啊，一上到线上就NPE，这线上环境有毒!"
"从一大早就开始上线，每次都要重新打jar包，拷贝、重启...郁闷的是有个顽固的bug，研发改了3次，我也上了3次，现在已经晚上9点了，还没上完..."
"这个服务周日就挂掉了，直到周一早上才被发现，客服电话都被打爆了！"
如果你曾在一些不重视运维技术的公司呆过，一定对上述场景颇有感触。

如果你恰好没有经历过上述场景，我推荐你读一下《凤凰项目:一个IT运维的传奇故事》。

相信读完后，你会对"运维部门"有更加深刻的理解。

运维并不是简单的"将代码推上线"，他至少应当包含两个职能:

尝试通过"自动化"、"可重用"、"稳定"的方式解决部署问题。即打造所谓的"持续部署"平台。
维护公司内的基础设施，例如后端服务所需要的数据库、消息队列等组建。
监控系统运行状况，尝试自动恢复故障，对潜在的故障作出预警。
看了上述介绍后，你还会觉得在"运维"是"架构设计"中可有可无的一部分么?

当然，本书并不是以运维作为核心主题的。因此，在本章中，我们将介绍运维工作与微服务架构关系最紧密的几个部分:

后端组建的运维，包括Docker仓库、数据库、缓存、消息队列
日志与监控，日志的收集、异常报警系统，平台监控系统。
生产、测试环境的构建，如跳板机、机房打通等。
好了，让我们开启微服务架构下，运维工作的新篇章吧。

子曰: "工欲善其事必先利其器"。

本书的开篇已经指出，微服务的架构对研发人员提出了更高的要求。

幸运的是，通过不断完善、改进研发工具链，可以为研发人员提供更高效、更便捷的开发环境。

本书反复强调"微服务"、"研发工具链"、"运维工具链"三者是一个整体，如果只重视微服务的开发技术，而不重视工具链的建设，微服务的架构便无从谈起。

本章将对微服务架构下，常见的研发工具进行介绍。

大致又可分为两部分：

研发环境构建: 主要包括内部帐号管理、代码版本管理、Java依赖管理，这些基础研发环境。
高效研发构建: 主要通过小工具、代码模板、开源项目的引入，降低微服务开发难度，提升开发效率。
现在，让我们开始研发工具链的构建之旅吧！

"持续集成"(Continuous integration)：频繁地将开发代码合并到主干，并保证可以编译通过，并通过基本额单元测试。 坚持持续集成的优点有：

快速失败(Fast Fail): 尽早发现错误，"早发现、早治疗"，将错误的成本降到最低。
减少代码冲突风险：使用频繁、多次、小的分支合并，来很久不合并代码导致的大量的代码冲突。
提升迭代速度和质量：小步快跑，让进度更可控，避免"Deadline前赶工期"的现象。
"持续交付"(Continuous delivery)：频繁地将代码的最新版本，交付给用户（或线上环境），它的优势不言而喻：

更快的交付速度：借助自动化的持续交付系统，可以做到1天上线多次
产品功能可并行上线：持续交付降低了上线的人力成本，多个功能可并行开发、上线
在互联网软件开发领域，持续集成和持续交付已经成为基本的共识，极大地提升了项目的迭代、交付速度。

与之形成鲜明对比的是，在传统软件开发领域，持续集成和持续交付的理念还没有得到贯彻，软件的开发、上线以周、月为单位，并且功能之间往往难以进行拆分。

本章将围绕上述两个问题，探讨探讨微服务架构下，借助Jenkins实现持续集成、持续部署。

"熔断"、"限流"这两个词看起来是和性能相关的。你可能会有疑问：微服务架构支持横向拓展，性能不够加机器就可以，为什么还需要熔断呢？

是的，横向拓展确实可以提升性能，但同时也降低了可用性。假设一个服务的可用性是99.9%，假设有100个服务实例依赖这个微服务，那么整体的可用性就0.999^100=90%，可用性下降了接近10！考虑到微服务架构下的性能横向拓展，微服务有多个副本的情况下，100个实例的依赖是很正常的情况。

微服务的实际应用中，调用链条可能更长，A调用B、B调用C...链条上的任何一个服务发生故障，都会导致调用链条上后续服务发生故障，从而将故障的影响逐级放大，最终导致整个系统崩溃，这称为雪崩效应。

为了避免雪崩的发生，除了提高服务的稳定性外，还可以采取"熔断"、"限流"等防御性手段。

本章将就这两种手段进行讨论，并引入Hytrix和Guava两款开源解决方案，探讨如何在微服务架构下快速地实现服务的熔断和限流。