咱们打开新浪微博，然后随便找个带皇冠的，按下F12键(Mac用户按command+option+i)然后选中控制台的箭头，再点击皇冠：再点开这个图片可以发现：可以看到那些大 V 图标皇冠图标以及各种微博认证等图标，都是放在了一张雪碧图里(即使再牛的大 V，身份标志也是放在雪碧图中的)。
uni-app 的 API 与微信小程序 API 基本一致。掌握微信小程序 API 对后面的开发很有帮助。微信小程序 API 文档:https://developers.weixin.qq.com/miniprogram/dev/api/
国际化的功能离不开错误码的支持，客户端指定语言到服务端去请求，当出错了服务端会根据错误码和语言找到对应的国际化提示语。从上面图中我们发现，错误码不仅仅是客户端与服务端的交互，后台各个服务间的交互也需要约定的一套错误码。一般一个系统的错误码 code 都是唯一确定的。msg 不同场景下可能不一样，提供给用户的肯定是需要友好且不能暴露底层细节，给开发人员看的就要详细专业的错误内容。网关服务上面维护着多套不同语言的错误码提示语，响应的时候会根据客户端带的 Lang 信息进行国际化转译。模块模块编码错误编码底层描述中文提示语英文提示语库存10001商品规格表关联有误商品不存在goods don’t exist一般国际化的系统中会有多份 xxx_lang.properties文件，每一份代表一种语言的消息提示语。中文一般会转为 Unicode 编码进行存储（这个过程一般开发工具可以设置自动转），这样的处理可以规避不同开发环境下不同编码导致中文乱码。
注册微信小程序账号，获取到 AppID，我们后面配置的时候会用到。在 HBuilderX 工具栏，点击发行，选择小程序-微信。输入小程序名称和 AppID，单击发行就可以了。这样我们就会获得一个微信小程序的打包文件，接下来我们来发布微信小程序项目，打开微信小程序开发者工具，导入刚刚生成的微信小程序项目的打包文件，在微信小程序开发者工具中先测试一下，项目运行是否正常，项目测试没有问题后，点击右上角>>按钮，上传代码就可以发布微信小程序了，最后等待微信团队审核通过，别人就可以在线上访问到你的项目了。
微前端 尚处在发展时期，其核心概念和 微服务 相似。现阶段较为常用的微前端框架为 single-spa 和 qiankun，后者是基于前者实现的。该技术能做到 技术栈无关，即一个应用，能由多个不同技术的子应用构成，同时做到子应用的相互隔离，这里的隔离就可以选择采用 Web Components 实现。
技巧 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 下的路径了。
Flask 是一个 Python 实现的 Web 开发微框架，但是这个“微”并不代表着 Flask 功能比较简陋、有所欠缺。微框架中的 “微” 意味着：Flask 旨在保持核心简单而易于扩展；Flask 不会替用户做出太多决策，比如使用何种数据库；Flask 的选项（比如使用何种模板引擎) 通常有多个，用户很容易替换。默认情况下，Flask 不包含数据库抽象层、模板引擎、身份认证或其它任何已有多种库可以胜任的功能，如下图所示。然而，Flask 支持用扩展来给应用添加这些功能，应用程序可以很方便的集成这些扩展。众多的扩展提供了数据库集成、表单验证、上传处理、各种各样的开放认证技术等功能。
上述例子发现输出的结果是英文的，显然是不适合在国内环境使用，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>有关国际化的更多内容可以参考文档。
服务熔断机制的服务快速失败所实现的目标，和我们在上述小节中所介绍的普通的服务快速失败所实现的目标相同，都是为了保证，在某一微服务发生故障时，不影响后续微服务的正常运行。雪崩效应产生原理在上述小节中，各位同学已经对什么是雪崩效应有所了解，如上图所示，我们所讲的服务熔断也是为了避免和解决雪崩现象的发生，只不过所采用的手段不同而已，那么接下来，就让我们来看一下基于服务熔断机制的服务快速失败的概念是什么吧。针对服务熔断机制，我们先来介绍什么是熔断？熔断这一名词，其实不是来源于计算机相关专业，而是来源于电子工程相关专业。熔断的核心是断路器，对于断路器来说，我们可以将断路器理解为一根保险丝，在日常生活中，当我们家庭用电超过负载时，保险丝就会迅速烧断，阻止由于电流过大而烧毁整个家庭电路。同样地，熔断我们也可以像保险丝那样理解，即在计算机相关领域中，由于中断上游的故障服务，而保全整体的服务的措施就被称为熔断，而实现中断上游的故障服务所采取的核心措施就是我们的断路器。服务熔断机制就是把这些概念都统一起来，然后封装到 Hystrix 中，且最终应用于我们的微服务项目中间，通过配置断路器，来保全我们整体的微服务项目，这就是 Hystrix 所提供的服务熔断机制。Tips: 1. 在实际工作中，我们需要灵活的去配置微服务项目中，各个领域的微服务所对应的断路器配置，包括间隔时间、持续时间等关键属性，切记不要凭感觉去配置； 2. Hystrix 本身所提供的服务熔断机制并不是很好用，往往需要我们在项目中集成其他的微服务服务中间件来一起集成使用，单独使用 Hystrix 服务熔断机制的项目很少见。
Hystrix 中的服务监控平台，就是对微服务项目进行监控的平台，包括服务运行的状态、服务有无宕机、服务异常信息监控等内容，为开发者和运维者提供了比较友好地界面支持，开发者和运维者可以直接通过观察服务平台界面，来判断具体微服务的状态信息，从而更好地对微服务进行控制。默认的 Hystrix 中间件已经为我们封装好了微服务监控平台，但是需要通过引入依赖的方式来使用它，接下来就让我们来看一下如何搭建该服务监控平台吧。
可以通过 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>
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 不能自己监测自己本身，这一点请同学们注意。
在介绍服务快速失败之前，我们需要首先了解一个概念，那就是雪崩效应，那么什么是雪崩效应呢？雪崩效应，是一种微服务项目间出现的一种不良现象，一般是指：由一个微服务发生故障之后，影响到了其他微服务的正常运行，或者说，当一个微服务发生故障不能正常运行时，所导致的其他微服务也跟着受影响，导致其他的微服务也不能正常运行。假设现在有 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. 理解什么是雪崩效应是理解什么是服务快速失败的前提概念，同学们一定要对这两个概念有所了解才行。
业务场景描述有这样一个真实的业务场景：在某大厂某销售业务项目中，由于某大厂销售业务板块业务的持续增加，导致之前原本设计好的项目架构出现了问题，不足以支撑持续增长的业务需要，于是，某大厂程序员对项目架构做了拆分，并最终形成了以 Spring Cloud 为基础架构的微服务分布式项目架构。在拆分了项目架构之后，虽然可以支撑持续增长的业务需要，但是，在拆分后的项目架构中，Hystrix 无法对所有项目进行监控，即 Hystrix 服务监控平台只能监控一个分散的项目，无法对项目整体进行监控。问题原因分析在解决问题之前，我们首先来分析一下这种问题产生的原因。上述场景场景中，项目的架构方式是微服务的分布式架构，而一般来说的 Hystrix 微服务监控平台默认只对一个项目实例起作用，所以，也就导致了一个微服务平台只对一个微服务实例起作用。
有些同学乍一听九宫格可能不知道是什么，但其实它在我们的日常生活中很常见：顾名思义，九宫格通常为如图这种三行三列的布局。微信客户端就用到了这种布局方式：大家最熟悉的朋友圈也采用了九宫格：还有微博：
1. 独立的页面维护了全局 错误码错误码由5位整数构成2. 每个接口一个独立的 参数说明页面正常情况下出参只返回业务实体异常情况才有 errCode errMsg每个接口下也可能有自己的业务错误码
在上一章中，我们对 Hystrix 中的所有的微服务治理特性都做了学习和了解，同时我也通过 demo 样例的形式，来对每一个特性都做了代码实现，可是这些代码并不是我们真实业务场景下的代码，只能用来学习特性所用。为了将我们所学习和了解到的微服务治理特性应用于真实项目中，于是规划了 4 节在实际业务场景下 Hystrix 微服务治理特性的应用内容，希望可以通过这 4 节的介绍，大家可以了解到如何在实际项目中去应用这些特性。在本节中，我将为大家介绍真实业务场景下，服务容错与降级的应用方法，及代码实现。本节主要内容：服务容错与降级真实业务场景描述；业务场景实现思路分析与实操。
本节我们讨论了如何利用第三方平台做我们系统的 OAuth2.0 认证中心，主要的知识点如下：Spring Security 实现了 OAuth2.0 客户端的常用功能，开发者可以轻松的将 Spring Boot 应用作为 OAuth2.0 客户端集成到安全体系中；在使用第三方作为 OAuth2.0 认证服务器时，首先要在第三方平台上完成应用注册，并获取到 Client ID 和 Client Secret 两个重要参数；使用第三方 OAuth2.0 认证源，可以简化系统开发中的关于认证的操作，并且可以更轻易的实现单点登录；使用第三方 OAuth2.0 认证源的时候，用户在本系统内的权限、详细用户信息等，仍需要在本地系统内维护；目前在国内支持度比较好的第三方认证源有：QQ、微信、微博、Github 等。下一节中，我们继续在 OAuth2.0 协议的基础上，构造出属于自己的认证中心。
go mod 虽然可以直接帮我们下载好我们需要的包，但是因为 Go 语言很多包都是在国外的服务器上，国内下载具有一定的困难。但是不用担心，go mod 提供了代理服务，同时很多国内的云服务器产商都提供了自己的代理服务:阿里云： https://mirrors.aliyun.com/goproxy 微软： https://goproxy.io 七牛云： https://goproxy.cn GoCenter： https://gocenter.io
我们都知道，什么事情都不可能是十全十美的。抛开 RabbitMQ 不说，在互联网行业中的其他工具，也不能百分百保证每时每刻都在正常工作，更何况是涉及到消息通信的工具。RabbitMQ 在传递消息时，由于一些客观原因或者是其本身的原因，可能会出现，在有大批量消息传递时，所有的消息不能百分百传递到目的地的问题。RabbitMQ 在设计之初就考虑到了这个问题的出现，所以，RabbitMQ 提供了内置的消息补偿机制，这里我们简单做一下介绍。当存在大批量的消息都需要经过 RabbitMQ 来投递时，RabbitMQ 会将这些消息划分成若干组，然后通过为组设置顺序的方式，来依次投递这些消息。如果在任意一组中，出现了消息未能投递到目的地的现象，那么， RabbitMQ 会将该条消息进行短暂的存储，待其他消息都到达目的地后，RabbitMQ 会重新将该条消息进行投递，然而，这个过程执行的时间是微乎其微的，几乎近于实时。
本节内容概览本小节为大家介绍了，Hystrix 这款微服务治理中间件在企业级应用时，经常遇到的一些坑，包括 Hystrix 参数配置、回调方法等常见问题，并针对这些问题都给出了相应的解决方案。在介绍常见问题的同时，结合我的实际工作经历，给大家介绍了 Hystrix 的微服务监控平台，已经高可用实现方案，希望各位同学能够运用到真实项目中去。本套课程就到这里了，希望同学们学的开心，码的快乐。最后，感谢各位同学的支持与关注，江湖路远，我们有缘再会！
实现思路分析针对上述场景，我们需要将所有拆分出来的微服务都要集成到 Hystrix 的微服务监控平台中去，但是我们应该怎么集成呢？Hystrix 针对不同场景下，提供了不同的微服务监控方式：针对单体架构或只需要对一个服务实例进行监控的业务场景，我们只需要像我在介绍微服务监控平台时那样，进行配置即可；针对分布式的项目结构，或同时需要监控多个微服务的场景，Hystrix 提供了一个名为 Turbine 的多服务器微服务监控组件。我们只需要将 Turbine 引入到我们的项目中去，即可实现分布式架构下的多微服务监控了。实操要想在项目中引入 Turbine ，我们首先需要将 Turbine 的依赖引入到项目中：<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-turbine</artifactId></dependency>在引入了 Turbine 依赖之后，我们需要对 Turbine 进行一些简单的配置，在 yml 配置文件中：turbine: aggregator: clusterConfig: default appConfig: service-one,service-two,service-three clusterNameExpression: "'default'"代码解释第 3 行，我们通过 clusterConfig 属性来配置 turbine 采用的集群策略，一般我们配置 default 即可。第 4 行，我们通过 appConfig 属性来配置需要继承到 turbine 中的微服务，即需要同时刻进行监控的微服务，多个微服务使用英文状态下的逗号隔开。第 5 行，我们通过 clusterNameExpression 属性来配置集群的名称表达式，一般也是采用 default 配置即可。yml 配置文件配置完成后，我们需要在项目的启动类中添加 turbine 的注解：@SpringBootApplication@EnableHystrix@EnableHystrixDashboard@EnableTurbinepublic class SaleApplication { public static void main(String[] args) { SpringApplication.run(SaleApplication.class, args); }代码解释第 4 行，我们添加了 @EnableTurbine 注解，来在项目中开启 turbine 服务，以支持同时监控多个微服务。在配置完了上述两部分后，我们的 Hystrix Turbine 组件就引入到了我们的项目中，我们就可以对多个微服务进行监控了。配置完成后，运行我们的项目，在浏览器地址栏中输入我们的监控地址：http://localhost:port/turbine.stream我们即可在浏览器中看到多个微服务已经被监控了，如下图所示：Hystrix Dashboard 多微服务同时监控从上图可知，这里我们对两个微服务进行了监控，其图中的各项监控参数和我们在之前介绍 Hystrix 微服务监控平台中的参数一样，这里就不再赘述了。Tips: 1. 在 appConfig 属性配置中，属性的值为每个需要监控的微服务的 serviceId 名称，同学们不要配置错了。 2. 各位在引入 Turbine 的依赖时，注意不要引错依赖了，如果大家引入了 aitifactId 为 spring-cloud-starter-turbine 的依赖，我们是无法使用 Turbine 的，因为这个依赖并不是 Spring Cloud 微服务组件中所提供的 Turbine 服务，而是单独的 Turbine 服务，我们无法在微服务项目中使用。 3. 各位同学在访问 Turbine 多微服务监控平台时，注意访问地址发生了变化，大家使用之前的微服务监控平台访问地址时访问不到的，这点需要同学们注意。
在之前的小节中，我们已经对 Hystrix 提供的微服务监控平台做了详细的介绍，基本上已经把这个微服务监控平台的常用内容都介绍完毕了，那么在本节中，将会结合这些基本参数对我们的微服务进行一个监控和配置。本节主要内容：实际业务场景描述；业务场景实现思路分析与实操。
在介绍完 Hystrix 微服务监控平台的基础搭建工作之后，我们需要对平台中的基础必要参数做一些了解。本节会为大家介绍，在微服务监控平台中的一些常用的基础参数属性，大家在对这些基础参数属性有所了解之后，就可以使用该微服务监控平台了。本节主要内容：Hystrix 服务监控平台基础使用介绍。接下来让我们来看一下都有在平台中都有哪些常用的基础参数属性吧。
本节内容概览本小节为大家介绍了什么是服务容错、什么是服务降级，以及对服务容错和服务降级的代码实操，希望各位同学通过学习本节的内容，可以对服务容错与服务降级有自己的理解和看法，这样，在实际的工作中，我们在管理微服务项目时，才能得心应手，在遇到问题时，才能从容应对。
本节内容概览本小节采用图文并茂的方式，为大家详细介绍了什么微服务监控平台，以及如何在 Spring Cloud 项目中搭建 Hystrix 微服务监控平台，同时，在搭建过程中，针对容易出现问题的地方我也做了相应的补充。在介绍完 Hystrix 微服务监控平台之后，接下来我们就需要对监控平台中的各个参数属性进行介绍，让我们下节见吧。
模板方法模式是定义一个操作中的算法的骨架，从而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。通常对于一些重要的复杂方法和多个子类共有的方法且逻辑相同的情况下会使用模板方法模式。比如用户第三方用户认证的时候就比较适合使用模板方法。我们来看一个例子：假设我们现在需要用到微信、微博的第三方用户授权来获取用户的信息。//使用模板方法模式描述获取第三方用户信息的过程 public abstract class Authentication{ public void checkUserAuthentication(){ checkIdentity(); fetchInfo(); } protected abstract void checkIdentity(); protected abstract void fetchInfo(); } //微信用户 public class WechatAuthenication extends Authentication{ @Override protected void checkIdentity() { System.out.println("获得微信用户授权"); } @Override protected void fetchInfo() { System.out.println("获取微信用信息"); } } //微信用户 public class WeiboAuthenication extends Authentication{ @Override protected void checkIdentity() { System.out.println("获得微博用户授权"); } @Override protected void fetchInfo() { System.out.println("获取微博用信息"); } } //调用模板方法 public class Demo{ public static void main(String...s){ Authentication auth = new WechatAuthenication(); auth.checkUserAuthentication(); auth = new WeiboAuthenication(); auth.checkUserAuthentication(); } }输出结果：获得微信用户授权 获取微信用信信息 获得微博用户授权 获取微博用信信息现在我们使用 Lambda 表达式换个角度来思考模板方法模式。如果我们用函数式接口来组织模板方法中的调用过程，相比使用继承来构建要显得灵活的多。//定义一个处理接口，用来处理一项事务，如授权或者获取信息。 public interface Processer{ public void process(); } //封装调用过程 public class Authentication{ private final Processer identity; private final Processer userinfo; public Authentication(Criteria identity,Criteria userinfo){ this.identity = identity; this.userinfo = userinfo; } public void checkUserAuthentication(){ identity.process(); userinfo.process(); } } //使用模板方法 public class Demo{ Authentication auth = new Authentication(()->System.out.println("获得微信用户授权"), ()->System.out.println("获取微信用户信息")); auth.checkUserAuthentication(); auth = new Authentication(()->System.out.println("获得微博用户授权"), ()->System.out.println("获取微博用户信息")); auth.checkUserAuthentication(); }输出结果：获得微信用户授权 获取微信用信信息 获得微博用户授权 获取微博用信信息此时，我们的模板方法得到了大幅的简化，同时通过函数接口让模板方法获得了极大的灵活性。
通过上面小节的例子，想必大家已经对使用 TensorFlow 进行梯度求解有了一个大体的了解。具体来说，我们大致需要经过几个步骤进行自动微分的操作：定义梯度带 tf.GradientTape () 的上下文；指定我们要跟踪梯度的数据，tape.watch()；在梯度带上下文之中进行我们想要的操作（一般是让数据通过网络）；通过得到的结果来使用梯度带求得各个参数的梯度；后续的操作，比如根据梯度进行优化等。那么让我们来看一个更加实际一些的例子，使用矩阵进行运算。import tensorflow as tfx = tf.ones((5, 5))with tf.GradientTape() as t: t.watch(x) y = tf.reduce_sum(x) y = tf.reduce_sum(y+x) z = tf.multiply(y, y)dz_dx = t.gradient(z, x)print(dz_dx)我们可以得到输出，值得注意的是，因为我们的输入都是矩阵，因此得到的梯度也是一个矩阵：tf.Tensor([[33800. 33800. 33800. 33800. 33800.] [33800. 33800. 33800. 33800. 33800.] [33800. 33800. 33800. 33800. 33800.] [33800. 33800. 33800. 33800. 33800.] [33800. 33800. 33800. 33800. 33800.]], shape=(5, 5), dtype=float32)如此，我们便求得了梯度，这是我们进行自定义网络的第一步，下一步，我们要将整个网络的计算放在梯度带的上下文之中进行计算。
single-spaqiankunmicro-appwujie
到这里有关Kotlin应用于服务端的微服务开发就简单介绍完毕了。实际上只是一个简单入门，有关很多ktor的高级应用可以去参考Ktor的官网。
