国际化的功能离不开错误码的支持，客户端指定语言到服务端去请求，当出错了服务端会根据错误码和语言找到对应的国际化提示语。从上面图中我们发现，错误码不仅仅是客户端与服务端的交互，后台各个服务间的交互也需要约定的一套错误码。一般一个系统的错误码 code 都是唯一确定的。msg 不同场景下可能不一样，提供给用户的肯定是需要友好且不能暴露底层细节，给开发人员看的就要详细专业的错误内容。网关服务上面维护着多套不同语言的错误码提示语，响应的时候会根据客户端带的 Lang 信息进行国际化转译。模块模块编码错误编码底层描述中文提示语英文提示语库存10001商品规格表关联有误商品不存在goods don’t exist一般国际化的系统中会有多份 xxx_lang.properties文件，每一份代表一种语言的消息提示语。中文一般会转为 Unicode 编码进行存储（这个过程一般开发工具可以设置自动转），这样的处理可以规避不同开发环境下不同编码导致中文乱码。

上述例子发现输出的结果是英文的，显然是不适合在国内环境使用，moment.js 提供了国际化支持，在现有的库中，moment 支持的语言可以说是相对完备了。通过引入对应的国际化资源（语言文件），来切换语言。<script src="https://cdn.bootcdn.net/ajax/libs/moment.js/2.27.0/moment.min.js"></script><script src="https://cdn.bootcdn.net/ajax/libs/moment.js/2.27.0/locale/zh-cn.min.js"></script><script> var now = moment().calendar(); console.log(now);// 输出当前日历时间 moment().startOf('hour').fromNow(); // 相对这个小时过去了多少分钟 var timestamp = 1593933593236; // 2020年7曰5日下午15点20分38秒 moment(timestamp).fromNow(); // 相对时间戳多久前</script>有关国际化的更多内容可以参考文档。

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

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

技巧 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 下的路径了。

可以通过 CDN 引入 ECharts 文件：<!-- bootstrap 服务 --><!-- bootstrap 提供的免费CDN服务，亲测非常稳定 --><script src="//cdn.bootcss.com/echarts/4.5.0/echarts.common.js"></script><!-- 七牛云存储服务 --><!-- 国内速度稳定，开放性强 --><script src="//cdn.staticfile.org/echarts/4.5.0/echarts.common.js"></script><!-- jsdeliver 服务 --><!-- 微软的CDN服务，虽然国内访问速度比不上国内CDN，但速度不至于太慢，有国际化需求的可以试试 --><script src="//cdn.jsdelivr.net/npm/echarts@4.5.0/echarts.common.js"></script><!-- cdnjs 服务 --><!-- 一个非常全的CDN服务，存储了大多数主流的js、css、图片库 --><script src="//cdnjs.cloudflare.com/ajax/libs/echarts/4.5.0/echarts.common.js"></script>

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

01 的电频信号在物理介质的传输远不止上面一条横线带过那么简单，想想如果你跟美国的网友进行通信，信号需要跨洋交互，中间经过的设备数量，通信距离有多夸张。

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

通信双方无法确认对方的身份是否正确。案例1:本地电脑有木马，路由表被踹改，www.baidu.com 的域名被解析到另一台虚假的服务器，此时你在浏览器访问的百度就是黑客的另一个钓鱼网站，然后给你推送了很多虚假消息，此时客户端很难知情。案例2:路由表没问题，但是目标服务器被人黑了，处理不了请求，此时有其它服务冒充提供服务。案例3:某个资源只有特定用户有查询的权限，黑客通过伪造该客户端一样的请求来查询，服务端只是简单的根据入参判断，并无法知道对应客户端的真实性，于是消息很容易泄漏。

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

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

使用 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 的工作流程。

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

本节我们讨论了如何利用第三方平台做我们系统的 OAuth2.0 认证中心，主要的知识点如下：Spring Security 实现了 OAuth2.0 客户端的常用功能，开发者可以轻松的将 Spring Boot 应用作为 OAuth2.0 客户端集成到安全体系中；在使用第三方作为 OAuth2.0 认证服务器时，首先要在第三方平台上完成应用注册，并获取到 Client ID 和 Client Secret 两个重要参数；使用第三方 OAuth2.0 认证源，可以简化系统开发中的关于认证的操作，并且可以更轻易的实现单点登录；使用第三方 OAuth2.0 认证源的时候，用户在本系统内的权限、详细用户信息等，仍需要在本地系统内维护；目前在国内支持度比较好的第三方认证源有：QQ、微信、微博、Github 等。下一节中，我们继续在 OAuth2.0 协议的基础上，构造出属于自己的认证中心。

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

Http 的整个报文信息，从客户端到服务端到都是明文传输到。信息从我们的电脑发出去，中间需要经历哪些设备才能被另一台电脑接收，我们是不好确定也很难评估的。有可能跨越多个运营商机房，有可能通过海底光缆横跨大洋，有可能穿过 某某学校 / 某某厂房 / 某某集团 的内部 路由器/ 交换机 / 集线器 等。中间这么多节点我们都是控制不到的，所以只要别人有心，我们就很难保证我们的信息不被泄漏。

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

客户端收到服务端的 Cookie 后，该 Cookie 会在接下来的每个请求中被发送至服务器。Cookie 的值被存储在名为 Cookie 的 HTTP 消息头中，并且只包含了 Cookie 的值，其它的选项全部被去除。客户端向服务端发送的 HTTP 请求中设置 Cookie 消息头，一个具体的例子如下：Connection:keep-aliveCookie:user=ZhangSanHost:localhost:8080User-Agent:Mozilla/5.0 AppleWebKit/537.36 Chrome Safari在这个例子中，客户端向服务端发送的 HTTP 消息头中，设置了 ‘Cookie:user=ZhangSan’，服务端接受到字符串 ‘user=ZhangSan’ 作为 Cookie，从而确认此次请求对应的用户。

填充常用属性，见下表。属性描述 pattern 设置背景颜色的模式 pattern_fore_colour 背景颜色对应代码中访问，如下所示：datestyle = xlwt.XFStyle()bgcolor = xlwt.Pattern()bgcolor.pattern=xlwt.Pattern.SOLID_PATTERNbgcolor.pattern_fore_colour=22 #背景颜色datestyle.pattern=bgcolor上述代码中，首先通过 xlwt.Pattern 进行初始化，为单元格设置填充背景颜色样式，其中 xlwt.Pattern 为填充背景颜色的模式，SOLID_PATTERN 表示完全填充。完成配置后，将对象赋值给 XFStyle。

go mod 虽然可以直接帮我们下载好我们需要的包，但是因为 Go 语言很多包都是在国外的服务器上，国内下载具有一定的困难。但是不用担心，go mod 提供了代理服务，同时很多国内的云服务器产商都提供了自己的代理服务:阿里云： https://mirrors.aliyun.com/goproxy 微软： https://goproxy.io 七牛云： https://goproxy.cn GoCenter： https://gocenter.io

一般服务器采用 Linux 或者 Windows Server 系统，相对而言 Linux 系统更加稳定安全。实际上 Windows Server 系统对于一般应用来说也足够了，本篇我们使用 Windows Server 系统进行演示。推荐使用云服务器，更加稳定且易于维护，国内厂商阿里云、华为云都还不错。Tips： 云服务器的硬盘读写性能非常重要，在购买云服务器时务必关注下云硬盘的 IOPS 值（衡量硬盘读写性能的一个指标），一般建议要采用 IOPS > 3800 的云磁盘。具备云服务器后，需要安装 JDK 以便运行 Spring Boot 应用。由于 nginx 对静态资源的负载能力非常强悍，所以我们将前端应用部署到 nginx 上。

在 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 服务端的处理过程了。

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

信号量隔离和线程池隔离的方式很相似，只不过把分配线程池的方式改为了分配信号量（至于什么是信号量，请同学们自行查阅）。在处理请求时，Hystrix 会分配一个信号量的阀值，当服务接收到一个请求后，信号量的阀值减 1 ，当请求处理完毕后，信号量的阀值加 1，当信号量的阀值减为 0 时，则不再接收请求，即该请求会被拒绝处理。@RequestMapping(value = "hello", method = RequestMethod.GET)@HystrixCommand(fallbackMethod="helloFail", commandProperties = {@HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_STRATEGY, value = "SEMAPHORE"),@HystrixProperty(name = HystrixPropertiesManager.EXECUTION_ISOLATION_SEMAPHORE_MAX_CONCURRENT_REQUESTS, value = "100")})@ResponseBodypublic String hello() throws InterruptedException { return "helloWorld";}public String helloFail() { return "helloFailed";}代码解释：第 4 行，通过指定 HystrixPropertiesManager.EXECUTION_ISOLATION_STRATEGY 参数的值为 SEMAPHORE ，来声明该接口使用信号量隔离。第 7 行，通过指定 HystrixPropertiesManager.EXECUTION_ISOLATION_SEMAPHORE_MAX_CONCURRENT_REQUESTS 参数的值为 100 ，可以理解为设置信号量的阀值为 100 。通过添加上述配置参数，我们就可以通过信号量隔离的方式来实现服务资源隔离。Tips: 一定要合理设置信号量的阀值，不要随意设定，如果阀值设置过大，则请求不会停止，如果阀值设置过小，则不能满足业务需要。

业务场景描述有这样一个真实的业务场景：在某大厂某销售业务项目中，由于某大厂销售业务板块业务的持续增加，导致之前原本设计好的项目架构出现了问题，不足以支撑持续增长的业务需要，于是，某大厂程序员对项目架构做了拆分，并最终形成了以 Spring Cloud 为基础架构的微服务分布式项目架构。在拆分了项目架构之后，虽然可以支撑持续增长的业务需要，但是，在拆分后的项目架构中，Hystrix 无法对所有项目进行监控，即 Hystrix 服务监控平台只能监控一个分散的项目，无法对项目整体进行监控。问题原因分析在解决问题之前，我们首先来分析一下这种问题产生的原因。上述场景场景中，项目的架构方式是微服务的分布式架构，而一般来说的 Hystrix 微服务监控平台默认只对一个项目实例起作用，所以，也就导致了一个微服务平台只对一个微服务实例起作用。

在介绍服务快速失败之前，我们需要首先了解一个概念，那就是雪崩效应，那么什么是雪崩效应呢？雪崩效应，是一种微服务项目间出现的一种不良现象，一般是指：由一个微服务发生故障之后，影响到了其他微服务的正常运行，或者说，当一个微服务发生故障不能正常运行时，所导致的其他微服务也跟着受影响，导致其他的微服务也不能正常运行。假设现在有 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. 理解什么是雪崩效应是理解什么是服务快速失败的前提概念，同学们一定要对这两个概念有所了解才行。

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

本节内容概览本小节从服务资源隔离的前提概念开始介绍，采用图文并茂的方式，详细介绍了进程和线程、Web 项目中的进程与线程、服务资源隔离产生的原因，以及服务资源隔离的概念；接着，我们采用代码实现的方式，对 Hystrix 中的线程池隔离和信号量隔离这两种实现服务资源隔离的措施进行了介绍，并对其中需要注意的地方做了补充。服务资源隔离是微服务项目治理中的最后一关，同时也是至关重要的一关，微服务项目经常由于服务没有响应而导致后续服务瘫痪，所以，掌握服务资源隔离是保证微服务项目正常运行的关键所在。

客户端实现的功能：在连接准备就绪时 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 []，因此需要做序列化和反序列化操作。