uni-app 的 API 与微信小程序 API 基本一致。掌握微信小程序 API 对后面的开发很有帮助。微信小程序 API 文档:https://developers.weixin.qq.com/miniprogram/dev/api/

注册微信小程序账号，获取到 AppID，我们后面配置的时候会用到。在 HBuilderX 工具栏，点击发行，选择小程序-微信。输入小程序名称和 AppID，单击发行就可以了。这样我们就会获得一个微信小程序的打包文件，接下来我们来发布微信小程序项目，打开微信小程序开发者工具，导入刚刚生成的微信小程序项目的打包文件，在微信小程序开发者工具中先测试一下，项目运行是否正常，项目测试没有问题后，点击右上角>>按钮，上传代码就可以发布微信小程序了，最后等待微信团队审核通过，别人就可以在线上访问到你的项目了。

同样，我们展示了通过 C 语言 Socket API 编写 UDP 客户端和服务器程序的步骤，如下：图中的矩形方框都是 C 函数。对比 TCP 客户端、服务器的建立过程，我们发现 UDP 客户端可以调用 connect 函数，但是并不会去连接服务器，只是和本地接口做绑定；UDP 服务器是没有 listen 和 accept 调用的。对于 UDP 客户端来说，connect 函数的调用是可选的。接下来，我们就探讨一下如何用 Java 语言编写 UDP 客户端和服务器程序。

为了更好地理解编写 TCP 客户端和服务器程序的步骤，下图展示了通过 C 语言 Socket API 编写客户端和服务器程序的过程。图中的矩形方框都是 C 函数，很好的展示了客户端和服务器 Socket 的建立过程。对于 Java 语言来说，只是应用面向对象的思维对上面的过程进行了抽象，下来我们就探讨一下如何编写 Java 客户端和服务器程序。

技巧 1如果我们的微服务监控平台没有任何数据，或者说，在打开微服务平台之后，各参数一直处于 loading 状态，这个时候，我们只需要在服务端调用任意一个服务接口即可，这样在微服务监控平台，我们就能看到被监控实例的参数了。技巧 2如果我们在访问 /actuator/hystrix.stream 路径时，系统找不到对应的路径，即报 404 异常，那么我们需要在对应项目的启动类中添加一个 Bean ：@Beanpublic ServletRegistrationBean hystrixMetricsStreamServlet() { ServletRegistrationBean registration = new ServletRegistrationBean(new HystrixMetricsStreamServlet()); registration.addUrlMappings("/hystrix.stream"); return registration;}这样我们就能正常访问 /actuator/hystrix.stream 下的路径了。

微前端 尚处在发展时期，其核心概念和 微服务 相似。现阶段较为常用的微前端框架为 single-spa 和 qiankun，后者是基于前者实现的。该技术能做到 技术栈无关，即一个应用，能由多个不同技术的子应用构成，同时做到子应用的相互隔离，这里的隔离就可以选择采用 Web Components 实现。

Hystrix 中的服务监控平台，就是对微服务项目进行监控的平台，包括服务运行的状态、服务有无宕机、服务异常信息监控等内容，为开发者和运维者提供了比较友好地界面支持，开发者和运维者可以直接通过观察服务平台界面，来判断具体微服务的状态信息，从而更好地对微服务进行控制。默认的 Hystrix 中间件已经为我们封装好了微服务监控平台，但是需要通过引入依赖的方式来使用它，接下来就让我们来看一下如何搭建该服务监控平台吧。

客户端，是指发起请求的一方。也就是浏览器，或者指爬虫程序。通过发起请求，来获取想要的网页。服务端，请求的响应端，是 web 服务端。web 服务，是一个虚拟意思上的机器的概念。可以是一个计算机集群，也可以是一个软件或者程序。客户端，通过发送一个请求给服务端，然后进行等待。服务端按照客户端的请求，返回客户端需要的数据。这个过程，我们称之为经典的客户端——服务端模型。

乐观与悲观是两种不同的态度，从名字上看，二者就是以开发者的态度作为边界来分类的。乐观锁认为，同一数据在并发条件下，发生冲突是小概率事件，因此我们不加锁，而是加上版本号判断修改是否成功。悲观锁认为，同一数据在并发条件下，冲突是大概率事件，因此我们必须先加锁，不允许别人修改。悲观锁和乐观锁其实是一种思想，主要取决于开发者对待它的态度。在锁这一小节中，里面谈到的所有锁宏观上（可能实现的思想是乐观锁）来说都是悲观锁，因此一旦加锁，都会锁定数据，直到解锁才会释放。

在将 Swagger Codegen 的依赖引入到 Spring Boot 中去后，我们就可以使用 Maven 自带的命令来将上述配置信息分别生成服务端和客户端代码，命令如下：首先，将上述配置好的文件利用 Swagger Codegen 来生成服务端和客户端代码 java -jar swagger-codegen-cli.jar generate -i swagger.yaml -c swaggerConfig.json -l spring -o server代码解释：第一行，使用 generate 命令来将配置在 swagger.yaml 文件中的服务端代码进行生成。第一行，使用 -c 参数，表明使用 json 配置文件，并且该配置文件的名称为 swaggerConfig.json。第二行，使用 -l 参数，表明客户端所使用的语言为 spring 。第二行，使用 -o 参数来指定代码最终的存放位置，server 表示将生成的代码存放到名为 server 的文件夹下。然后我们使用 cd 命令来进到我们生成代码后所存放的目录： cd server最后我们将生成的代码打成 Jar 包: mvn package这是 Maven 自带的打包命令，执行该命令之后，Maven 会默认读取项目中的 pom 文件中配置的打包规则，即 packaging 节点，如果该节点没有配置任何规则，则 Maven 会默认打成 Jar 包 (这里我们配置了 Jar)。这样我们就可以在项目的 target 目录下，找到我们利用 Swagger Codegen 所生成的服务端和客户端代码的 Jar 包了，我们可以把该 Jar 包放到其他环境中使用，也可以供其他项目使用，这就是我们利用 Swagger Codegen 所生成的服务端和客户端代码的最终使用目的。

使用 Zookeeper 客户端连接 Zookeeper 服务，我们需要使用 ./zkCli.sh 命令：# 进入 bin 文件夹cd /usr/local/zookeeper/apache-zookeeper-3.6.1-bin/bin/# 连接命令./zkCli.sh # 连接时输出信息Connecting to localhost:2181...# 出现下面这一行时，表示我们连接成功[zk: localhost:2181(CONNECTED) 0] 这里我们就可以使用上一节学习过的命令来操作节点了，我们来测试一下：# 获取根节点的子节点ls /# 输出默认的子节点 zookeeper[zookeeper]# 创建根节点的子节点 imooccreate /imooc# 输出创建成功信息Created /imooc# 创建后再次获取根节点的子节点ls /# 输出两个子节点[imooc, zookeeper]# 我们可以给节点设置数据set /imooc wiki# 然后我们再获取 imooc 节点的数据get /imooc# 输出我们设置的信息wiki# 最后我们测试一下删除命令delete /imooc# 删除后再次获取根节点的子节点ls /# 输出子节点 zookeeper，imooc 节点被删除[zookeeper]# 退出 Zookeeper 客户端命令quit通过上面的学习，我们知道了如何部署单机模式的 Zookeeper 服务，以及如何通过 Zookeeper 客户端连接 Zookeeper 服务端，来对 Znode 节点进行操作。那么 Zookeeper 是如何为我们提供服务的呢，接下来我们就来了解单机模式下的 Zookeeper 的工作流程。

可以看到，乐观锁虽然有缺陷，它会使更新失败，因此必须重复获取数据然后重试，但是它保证了数据的正确性和完整性。在读多写少的场景下，乐观锁不会出现太多的重试，当然如果出现了很多重试，证明场景已经可能不是读多写少了，可以尝试换方案了。乐观锁的实现也颇为简单，不需要任何第三方依赖，你完全可以自己直接实现，不过仍然有一些第三方框架提供了开箱即用的乐观锁，你可以根据自己的使用语言和生态去查找相应的乐观锁框架。

如果状态码是 4xx，服务器就应该向用户返回出错信息。一般来说，返回的信息是键值对形式的数据，将 error 作为键名，出错信息作为键值即可。比如，在一个提供查询学生信息的 API 中，要求客户端提供正确的 API key（可以理解为输入了正确的用户名和密码）才能访问，如果提供的 API key 不正确，此时服务器应拒绝访问，并返回错误信息。这样，客户端就知道了为何没能查到信息，修改成正确的 API key 即可。{ error: "Invalid API key"}

Zookeeper 服务初始化的过程主要是实例化服务对象，下面我们来介绍会实例化哪些对象ServerStats： ServerStats 类用于统计 ZooKeeper 服务运行过程中的状态信息，包括接受到客户端的请求次数，处理客户端请求的次数，向客户端发送请求的次数以及出现请求延迟情况的次数。也就是说这个类会对 Zookeeper 服务的运行状态和性能进行监控；FileTxnSnapLog： 我们用 FileTxnSnapLog 类来实现 Zookeeper 服务的数据存储，对数据进行持久化操作。数据存储的路径会读取 zoo.cfg 配置文件的 dataDir；ServerCnxnFactory： 我们可以通过 ServerCnxnFactory 类来指定 Zookeeper 的通信框架。在 Zookeeper 3.4.0 版本后，引入了第三方 Netty 等框架供我们选择使用。经过一系列的对象实例化，Zookeeper 还需要从快照数据和事务日志中恢复数据，才真正的完成启动，这时就可以使用 Zookeeper 客户端来进行连接发送请求了。

http 最常用的协议，用于客户端主动向服务器发送请求，单向传递；ajax HTTP 的扩展版，底层还是 HTTP 协议，只不过客户端是无刷新的；comet 也是基于 HTTP 封装的，使用 HTTP 长连接的方式，原理大致是将 HTTP 的timeout 设置较长，服务器有数据变化时返回数据给客户端，同时断开连接，客户端处理完数据之后重新创建一个 HTTP 长连接，循环上述操作（这只是其中一种实现方式）；websocket 这是 HTML5 中的新标准，基于 socket 的方式实现客户端与服务端双向通信，需要浏览器支持 HTML5；Adobe Flash Socket 这个也是使用 socket 的方式，需要浏览器支持 flash 才行，为了兼容老版本的浏览器；ActiveX object 只适用于 IE 浏览器；目前尚没有一种方式能兼容所有的浏览器，只能针对软件的目标客户人群做一定的兼容。sse 服务端单向推送。

这是一种优化的读模式。乐观读模式相关的几个方法如下。tryOptimisticRead () 方法：非阻塞尝试乐观获取读锁，只有当写锁没有被获取时返回一个非 0 的 stamp 。乐观读取模式适用于短时间读取操作，降低竞争和提高吞吐量。在使用时一般需将数据存储到一个副本中，在后继处理中用于对比数据是否是最新状态；validate (long stamp) 方法：用于检查在获取到读锁 stamp 后，锁有没被其他写线程抢占。如果写锁没有被获取，那么 validate () 方法返回 true。可多次调用验证这一信息。另外，此类也提供了一组读写锁之间的转换方法：tryConvertToWriteLock (long stamp) 方法：尝试转换为写锁。转换条件：tryConvertToReadLock (long stamp) 方法：尝试转换为悲观读锁。tryConvertToOptimisticRead (long stamp) 方法：尝试转换为乐观读锁。注意此类的编程方法有这样一个共通特征：所有获取锁的方法，都返回一个邮戳（Stamp），Stamp 为 0 表示获取失败，其余都表示成功；所有释放锁的方法，都需要一个邮戳（Stamp），这个 Stamp 必须是和成功获取锁时得到的 Stamp 一致；下面我们举一个具体的编程例子。

业务场景： 模拟微信聊天，每个客户端和服务端建立连接，并且可以实现点对点通信（单聊），点对多点通信（群聊）。设计思路： 我们要实现的是点（客户端）对点（客户端）的通讯，但是我们大部分情况下接触的业务都是客户端和服务端之间的通讯，客户端只需要知道服务端的 IP 地址和端口号即可发起通讯了，那么客户端和客户端应该怎么去设计呢？思考：难道是手机和手机之间建立通讯连接，互相发送消息吗？这种方案显然不是很好的方案，第一： 客户端和客户端之间通讯，首先需要确定对方的 IP 地址和端口号，显然不是很现实。第二： 即使有办法拿到对方的 IP 地址和端口号，那么每个点（客户端）既作为服务端还得作为客户端，无形之中增加了客户端的压力。其实，我们可以使用服务端作为中转站，由服务端主动往指定客户端推送消息，如果是这种模式的话，那么 Http 协议是无法支持的，Http 是无状态的，只能一请求一响应的模式，只能使用 TCP 协议去实现了。

客户端实现的功能：在连接准备就绪时 channelActive () 发起登录认证。实例：public class ClientLoginHandler extends ChannelInboundHandlerAdapter { //1.通道激活的时候，发送账号、密码 @Override public void channelActive(ChannelHandlerContext ctx) throws Exception { Map<String,String> map=new HashMap<String,String>(); map.put("username","admin"); map.put("password","1234567"); //对象流序列化Map ByteArrayOutputStream os = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(os); oos.writeObject(map); byte[] bytes=os.toByteArray(); //关闭流 oos.close(); os.close(); //发送 ctx.channel().writeAndFlush(Unpooled.copiedBuffer(bytes)); }}代码说明：channelActive 事件是通道建立时触发该事件，并且仅触发一次该事件，通常情况下，在 channelActive 里面实现登录认证；客户端往服务端发送数据的时候需要使用对象流进行序列化，客户端接收服务端响应信息的时候，需要通过对象流进行反序列化；Netty 底层是 ByteBuf 进行传输的（后面章节会详细介绍），最终网络底层传输则是 byte []，因此需要做序列化和反序列化操作。

在 Zookeeper 客户端中，当我们使用 addauth digest mooc:mooc 命令来添加认证用户信息时，Zookeeper 客户端会使用 ClientCnxn 客户端类的 addAuthInfo 方法来封装请求信息，把请求类型包装成权限类请求，封装完毕后发送给服务端。// 添加认证信息，参数一：授权类型，参数二：认证信息的字节数组public void addAuthInfo(String scheme, byte[] auth) { // 判断当前客户端状态 if (this.state.isAlive()) { // 封装认证信息 scheme:digest this.authInfo.add(new ClientCnxn.AuthData(scheme, auth)); // 封装请求头 -4为请求头的xid，100为请求类型：auth this.queuePacket(new RequestHeader(-4, 100), (ReplyHeader)null, new AuthPacket(0, scheme, auth), (Record)null, (AsyncCallback)null, (String)null, (String)null, (Object)null, (WatchRegistration)null); }}简单地介绍了 Zookeeper 客户端处理权限类请求的过程，接下来就是 Zookeeper 服务端的处理过程了。

乐观是一种积极的解决问题的态度。所谓乐观锁认为系统中的事务并发更新不会很频繁，即使冲突了也没事，大不了重新再来一次。基本思想：每次提交一个事务更新时，查看要修改的数据从上次读取以后有没有被其它事务修改过，如果修改过，那么更新就会失败。实现方案：在实体中增加一个版本控制字段，每次事务更新后就将版本 (Version) 字段的值加 1。Tips： 乐观锁本质就是版本控制管理的实现，记录的每一次更新操作都会以版本递增的方式进行记录。一个事务在更新之前，先获取记录的当前版本号，更新时，如果版本还是最新的则可以更新，否则说明有事务比你先更新，则需要放弃。或者重新查询到最新版本信息后再更新。所以，在乐观锁的实现中，冲突是常态。实现过程：在学生实体类中添加新属性，用来记录每次更新的版本号。public class Student implements Serializable {//省略…… @Versionprivate Long version;//省略…… ｝stu = (Student) session.get(Student.class, new Integer(1));System.out.println("当前版本号："+stu.getVersion);//模拟延迟，如果在这个时间内有其它事务进行了更新操作，此事务的更新不会成功Thread.sleep(30000);stu.setStuName("Hibernate");transaction.commit();好了，悲观也好，乐观也好，只是一种解决问题的态度。对于这两种态度，咱们要总结一下。乐观锁：优势：性能好，并发性高。缺点：用户体验不好，可能会出现高高兴兴去更新，却告知已经有人捷足先登了。悲观锁：优势：锁住记录为我所用，没修改完成之前，其他事务只能瞪眼瞧着，时间虽然延迟，至少心里有底。缺点：并发性不好，性能不高。Hibernate 的其它性能优化：随时使用 Session.clear（）及时清除 Session 缓存区的内容；1+N 问题 ( 一条 SQL 语句能解决的问题用了很多条 SQL 语句来实现) ；使用 Criteria 查询可以解决这个问题；Lazy 加载：需要时，使用 get（） 方法发出 SQL 语句。使用类似于 from Student s left join s.classRoom c 的关联查询语句。缓存使用：在对象更新、删除、添加相对于查询要少得多时， 二级缓存的应用将不怕 n+1 问题，因为即使第一次查询很慢，之后直接缓存命中也是很快的，刚好又利用了 n+1。

服务熔断机制的服务快速失败所实现的目标，和我们在上述小节中所介绍的普通的服务快速失败所实现的目标相同，都是为了保证，在某一微服务发生故障时，不影响后续微服务的正常运行。雪崩效应产生原理在上述小节中，各位同学已经对什么是雪崩效应有所了解，如上图所示，我们所讲的服务熔断也是为了避免和解决雪崩现象的发生，只不过所采用的手段不同而已，那么接下来，就让我们来看一下基于服务熔断机制的服务快速失败的概念是什么吧。针对服务熔断机制，我们先来介绍什么是熔断？熔断这一名词，其实不是来源于计算机相关专业，而是来源于电子工程相关专业。熔断的核心是断路器，对于断路器来说，我们可以将断路器理解为一根保险丝，在日常生活中，当我们家庭用电超过负载时，保险丝就会迅速烧断，阻止由于电流过大而烧毁整个家庭电路。同样地，熔断我们也可以像保险丝那样理解，即在计算机相关领域中，由于中断上游的故障服务，而保全整体的服务的措施就被称为熔断，而实现中断上游的故障服务所采取的核心措施就是我们的断路器。服务熔断机制就是把这些概念都统一起来，然后封装到 Hystrix 中，且最终应用于我们的微服务项目中间，通过配置断路器，来保全我们整体的微服务项目，这就是 Hystrix 所提供的服务熔断机制。Tips: 1. 在实际工作中，我们需要灵活的去配置微服务项目中，各个领域的微服务所对应的断路器配置，包括间隔时间、持续时间等关键属性，切记不要凭感觉去配置； 2. Hystrix 本身所提供的服务熔断机制并不是很好用，往往需要我们在项目中集成其他的微服务服务中间件来一起集成使用，单独使用 Hystrix 服务熔断机制的项目很少见。

定义：乐观锁是相对悲观锁来说的，它认为数据在一般情况下不会造成冲突，所以在访问记录前不会加排它锁，而是在进行数据提交更新的时候，才会正式对数据冲突与否进行检测。乐观锁的实现：依旧拿数据库的锁进行比较介绍，乐观锁并不会使用数据库提供的锁机制， 一般在表中添加 version 宇段或者使用业务状态来实现。 乐观锁直到提交时才锁定，所以不会产生任何死锁。Java 中的乐观锁：我们之前所学习的 CAS 原理即是乐观锁技术，当多个线程尝试使用 CAS 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。Tips：我们这里所说的对于乐观锁，当多个线程尝试使用 CAS 同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败。注意失败两字，失败意味着有操作，而悲观锁是等待，意味着不能同时操作。

在 Zookeeper 服务端接收到 Zookeeper 客户端发送过来的请求后，首先解析请求头，识别请求的类型，发现客户端的请求类型是 auth 时，也就是权限类请求时，Zookeeper 会使用 scheme 来判断授权类型，找具体处理授权的实现类，在实现类中来进行权限验证，然后把认证用户保存到认证信息的集合中。在 Zookeeper 客户端使用刚才添加的认证用户信息来进行节点操作时，向 Zookeeper 服务端发送权限请求，服务端解析完成请求类型和授权类型后，再去具体的认证信息集合中去匹配请求中携带的授权信息，匹配成功则执行具体操作，匹配不到则说明该请求无授权，返回 NoAuthException 异常信息。

在介绍服务快速失败之前，我们需要首先了解一个概念，那就是雪崩效应，那么什么是雪崩效应呢？雪崩效应，是一种微服务项目间出现的一种不良现象，一般是指：由一个微服务发生故障之后，影响到了其他微服务的正常运行，或者说，当一个微服务发生故障不能正常运行时，所导致的其他微服务也跟着受影响，导致其他的微服务也不能正常运行。假设现在有 4 个微服务，分别用服务 A 、服务 B 、服务 C 、服务 D 表示，并且，服务 B 的运行依赖于服务 A ，服务 C 的运行依赖于服务 B ，服务 D 的运行也依赖于服务 B , 这 4 个微服务之间的正常运行关系如下图所示：假想微服务架构为了验证雪崩效应，现在，我们假设服务 B 由于外界因素发生了宕机现象，那么此时的服务 B 由于没有任何保护措施，所以服务 B 无法正常运行。由于服务 B 不能正常运行，所以，导致依赖于服务 B 的服务 C 和服务 D 都不能继续正常运行了，如下图所示：雪崩效应产生原理Tips: 1. 在实际工作中，在正式开发项目之前，应该就可能会出现雪崩现象的因素展开集中讨论，并将讨论结果以书面文件形式进行存储，这样一来，在真正发生雪崩现象时，可以及时启用应急方案； 2. 在开发微服务项目时，我们应该尽最大可能的去避免雪崩现象的发生，因为雪崩现象除了会影响业务的正常开展之外，也会影响我们的资源消耗。在了解了什么是雪崩效应之后，接下来我们来看一下什么是服务快速失败。服务快速失败，就微服务而言，是指：当微服务之间发生雪崩现象时，在程序中通过采用某种技术方法或手段，来将引起雪崩效应的微服务快速处理，其处理的最终目的是要保证该微服务不会导致其他后续的微服务出现故障。说白了，服务快速失败就是当微服务发生故障时，所采取的一个兜底的方案，该方案的执行会迅速终止发生故障的微服务的继续运行，且可以保证后续微服务的正常运行，具体如下图所示：服务快速失败的作用在上图中，我们可以看到，发生故障的服务 B，由于采用了服务快速失败机制，导致在发生故障时采取了快速失败措施，且同时也保证了服务 C 和服务 D 的正常运行（至于如何保证的服务 C 和服务 D 的正常运行，就涉及到了源码层面，由于该知识不符合本套课程的初衷，所以这里不予介绍）。Tips: 1. 服务快速失败几乎称为了每个微服务项目中必不可少的措施，所以，我们在开发微服务项目时，一定要采用服务快速失败机制，来保证我们项目的正常运行； 2. 理解什么是雪崩效应是理解什么是服务快速失败的前提概念，同学们一定要对这两个概念有所了解才行。

今天来学习 Android 的另一个组件——Service，相比于 Activity，Service通常运行在后台，没有任何 UI 界面，对用户是透明感知。通常用来执行一些后台任务，比如播放音乐、下载、加载一些数据等等，也可以用作一些进程间通信（IPC）机制。

乐观锁的使用十分广泛，我们也推荐你在实际的开发中使用乐观锁，接下来，我们以一个例子来详细的说明一下乐观锁。我们新建一个测试数据表 imooc_order ：DROP TABLE IF EXISTS imooc_order;CREATE TABLE imooc_order( id int PRIMARY KEY, price decimal(10,2), -- version 字段作为乐观锁版本控制位 version int NOT NULL DEFAULT 0);INSERT INTO imooc_order(id,price,version)VALUES (1,23.2,1);注意： 我们已经在表中添加了 version 字段

Hystrix 将原生特性和服务监控平台分为了两部分进行集成，目前，我们所引入的 Hystrix 依赖是下面这样的：<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId></dependency>这个依赖只提供了 Hystrix 的基本特性，就是我们前面所介绍的服务容错与降级、服务熔断、服务快速失败等基础内容，并没有把微服务监控台集成到该依赖中，所以，如果我们想搭建微服务监控平台，就需要引入专门支持微服务监控平台的依赖，如下所示：<dependency> <groupId>org.springframework.cloud</groupId> <artifactId> spring-cloud-starter-netflix-hystrix-dashboard </artifactId></dependency>从上述 artifactid 可以看出，基础的 Hystrix 依赖只比微服务监控平台的依赖名称少一个 dashboard ，这就是 Spring Cloud 潜在的命名规范，大家可以参考学习。在服务提供者的项目中，我们还需要引入一个依赖，如下所示：<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId></dependency>这个依赖是 Spring boot 框架提供的一个监控器，HystrixDashboard 需要配置这个监控器来完成对微服务项目的监控。由于我们的项目是基于 Maven 包管理工具所构建的项目，所以我们需要将微服务监控平台的依赖引入到我们的项目中去。在将微服务监控平台的依赖引入项目中去后，等待我们的编译器解析完成，没有报任何的红色错误，说明我们已经将 Hystrix 的微服务监控平台引入到了项目中去。在将依赖引入成功后，我们需要对我们的 Spring Cloud 微服务项目做一下简单的配置，以可以使用 Hystrix 的服务监控平台。首先，找到我们项目的启动类，然后在启动类的上方，添加 @EnableHystrixDashboard 注解，表明在项目中启用 Hystrix 的微服务项目监控平台，如下代码所示：@SpringBootApplication@EnableHystrix@EnableHystrixDashboardpublic class DemoApplication { public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); }}代码解释：第 3 行，我们在项目启动类的上方添加了 EnableHystrixDashboard 注解，表明在项目中已经开启了 Hystrix 微服务监控平台的使用，可以在项目中使用微服务监控平台了。经过上述配置之后，运行我们的项目，然后在浏览器地址栏输入：localhost:8060/hystrix即项目地址 + 项目端口号 + hystrix 路径，当看到下面截图时，说明我们的 Hystrix 微服务监控平台已经成功集成到了我们的项目中来。Hystrix Dashboard 登录界面这就是搭建 Hystrix 微服务监控平台的全部流程，希望同学们可以一次成功。Tips: 1. 各位同学在选择 HystrixDashboard 的依赖时，一定要确保 HystrixDashboard 的依赖版本与我们所使用的 Hystrix 的依赖版本保持一致，否则就会出现由于版本不一致而引起的兼容问题，导致我们的 HystrixDashboard 无法引入到项目中去； 2. 在配置项目启动类时，需要保证 @EnableHystrix 注解和 @EnableHystrixDashboard 注解同时存在，这两个注解少一个，我们的微服务监控平台就无法正常使用，这点需要同学们注意。 3. 在访问 Hystrix 的微服务项目监控平台时，/hystrix 为 Hystrix 提供的默认访问路径，不需要我们进行额外的配置，实际工作中，也很少有人会专门对这个路径名称进行修改； 4. 使用 Hystrix 的微服务监控平台，需要至少存在 2 个微服务项目，Hystrix 不能自己监测自己本身，这一点请同学们注意。

CAS 客户端是指可以和 CAS 服务端进行安全通讯的业务系统。CAS 通讯支持以下协议：CAS（版本1，2，3）SAML 1.1OpenIDOAuth（1.0，2.0）

Flask 是一个 Python 实现的 Web 开发微框架，但是这个“微”并不代表着 Flask 功能比较简陋、有所欠缺。微框架中的 “微” 意味着：Flask 旨在保持核心简单而易于扩展；Flask 不会替用户做出太多决策，比如使用何种数据库；Flask 的选项（比如使用何种模板引擎) 通常有多个，用户很容易替换。默认情况下，Flask 不包含数据库抽象层、模板引擎、身份认证或其它任何已有多种库可以胜任的功能，如下图所示。然而，Flask 支持用扩展来给应用添加这些功能，应用程序可以很方便的集成这些扩展。众多的扩展提供了数据库集成、表单验证、上传处理、各种各样的开放认证技术等功能。

整个 Hystrix 微服务监控平台分为平台首页和平台内容页，在平台首页，我们需要配置被监控项目的信息，包括被监控项目的地址、获取被监控项目参数的间隔时间，以及服务监控平台的标题。在平台内容页才是我们真正查看被监控项目之参数的地方，接下来就让我们先看平台首页中都有哪些内容。平台首页Hystrix 微服务监控平台登录界面如下图所示：Hystrix Dashboard 登录界面我们按照图中字母顺序依次进行介绍。1 表示需要进行监控的服务访问地址。2 表示获取服务监控信息的刷新频率，即间隔多长时间之后重新获取被监控服务的信息。3 表示进入微服务监控平台之后，所展示的标题名称，往往这里会被设置为项目的名称。4 表示进入微服务监控平台的按钮，当我们将 1 2 3 的信息都填写正确之后，点击 4 按钮，即可进入微服务监控平台内容页面，如果 1 2 3 信息中有一项填写错误，则在微服务监控平台的内容页面就无法看到任何服务监控信息。Tips: 上面的 1 2 3 项中，只有 1 是必填项，如果 2 3 没有填写，则 Hystrix 会启用默认的配置进入微服务监控平台。平台首页一共就需要我们了解以上这些信息就可以了，接着我们来看平台内容页。平台内容页Hystrix Dashboard 内容页面整个平台内容页面被分为了 Circuit 和 Thread Pools 两部分，分别表示项目熔断的监控，以及项目线程池的监控。我们首先来看平台内容界面的 Circuit 部分。上图中，在 Circuit 部分的右上角位置，我用箭头标出了每个名词的对应关系，接下来我们一一来说明。success ： 表示请求服务成功的数量。short-circuited ： 表示请求服务被熔断的请求数量。bad request ： 表示不能访问的请求的数量。timeout ： 表示请求服务时，服务超时的请求数量。rejected ：表示请求服务时，被拒绝的请求数量。failure ：表示请求服务时，请求失败的数量。error ：表示请求服务时，错误的服务的数量。然后，我们接着来看，在 Circuit 部分的中间位置，有一个 Circuit 的单词，该单词表示被监控项目此时的断路器的状态，当 Circuit 的值为 Closed 时，表示当前项目的断路器处于关闭状态，即当前服务的项目熔断没有启用。当项目的断路器打开时，此时的 Circuit 的值为 Open ，表示，此刻当前被监控的项目使用了服务熔断机制。在 Circuit 单词的上方，还有两个重要的参数，分别是：Host、Cluster ，Host 表示当前被监控项目的主机的请求频率，Cluster 表示当前被监控项目的项目集群的请求频率。Circuit 部分的左上方是一个图标，其由实心圆和曲线组成，其中，实心圆会根据实例的健康程度来改变自身的颜色，健康程度从绿色、黄色、橙色、红色递减，而实心圆的大小则表示请求流量的变化，流量越大该实心圆就越大，所以可以在大量的实例中快速发现故障实例和高压实例。曲线则记录了在 2 分钟内请求流量的相对变化程度，可以通过它来观察流量的上升和下降趋势。Tips: 由于本项目只是用来演示，并没有请求流量产生，所以这里就不会出现曲线，当我们有请求过来时，曲线就会发生变化。Circuit 部分最下面的 Hosts 、Median 、 Mean 我们不需要可以去了解分别代表什么含义，我们只需要知道这三个参数都是用来表示延迟时间的就可以了。最后，我们来看平台内容页的 Thread Pools 部分。在 Thread Pools 部分的左上方，同样也有一个由实心圆和曲线所构成的图标，其含义同 Circuit 部分的图标，这里不再赘述。在 Thread Pools 图标的右侧，同样也有 Host 和 Cluster 的请求频率的记录，这个和 Circuit 部分也是一样的。在 Thread Pools 图标的下方，有两列非常重要的参数，如下图：Hystrix Dashboard-Thread Pools 重点监控属性Active : 表示当前活跃的线程数量。Max Active : 表示当前最大活跃线程数量。Queued : 表示当前线程等待队列中的线程数量。Executios : 表示正在执行的线程的数量。Pool Size : 表示当前线程池的大小。Queue Size : 表示当前线程等待队列的长度。最后，我们再来看一下 Circuit 部分和 Thread Pools 部分的最上方位置，均有一个 Sort 名词，在这个名词的后面，也有很多单词，这表示我们查看服务监控参数时的顺序，当我们点击后面的一个单词时，HystrixDashboard 就会根据我们所点击的单词来对服务监控参数进行一个排序，仅此而已。Tips: Thread Pools 部分可以为我们展示被监控项目中线程池的活跃状态，我们可以直接从这些参数中分析出来当前线程池的活跃程度，从而动态地去调整每个微服务项目的线程池内容。