我为什么要放弃 RESTful，选择拥抱 GraphQL
REST作为一种现代网络应用非常流行的软件架构风格，自从Roy Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性，可扩展性，伸缩性受到广大Web开发者的喜爱。REST 的 API 配合JSON格式的数据交换，使得前后端分离、数据交互变得非常容易，而且也已经成为了目前Web领域最受欢迎的软件架构设计模式。??但随着REST API的流行和发展，它的缺点也暴露了出来：滥用REST接口 ，导致大量相似度很高（具有重复性）的API越来越冗余。对于前端而言：REST API粒度较粗 ，难以一次性符合前端的数据要求，前端需要分多次请求接口数据。增加了前端人员的工作量。对于后端而言：前端需要的数据往往在不同的地方具有相似性，但却又不同 ，比如针对同样的用户信息，有的地方只需要用户简要信息（比如头像、昵称），有些地方需要详细的信息，这就需要开发不同的接口来满足这些需求。当这样的相似但又不同的地方多的时候，就需要开发更多的接口来满足前端的需要。增加了后端开发人员的工作量和重复度。那我们来分析一下，当前端需求变化，涉及到改动旧需求时 ，会有以下这些情况：做加法 ：产品需求增加，页面需要增加功能，数据也就相应的要增加显示，那么REST接口也需要做增加，这种无可厚非。做减法 ：产品需求减少，页面需要减少功能，或者减少某些信息显示，那么数据就要做减法。一种通常懒惰的做法是，前端不与后端沟通，仅在前端对数据选择性显示。因为后端接口能够满足数据需要，仅仅是在做显示的时候对数据进行了选择性显示，但接口的数据是存在冗余的，这种情况一个是存在数据泄露风险，另外就是数据量过大时造成网络流量过大，页面加载缓慢，用户流量费白白消耗，用户体验就会下降。另外一种做法就是告知后端，要么开发新的接口，要么，修改旧接口，删掉冗余字段。但一般来说，开发新接口往往是后端开发人员会选择的方案，因为这个方案对现有系统的影响最低，不会有额外的风险。修改旧接口删除冗余数据的方案往往开发人员不会选择，这是为什么呢？这就涉及到了系统的稳定性问题了，旧接口往往不止是一个地方在用，很有可能很多页面、设置不同客户端、不同服务都调用了这个接口获取数据，不做详细的调查，是不可能知道到底旧接口被调用了多少次，一旦改动旧接口，涉及范围可能非常大，往往会引起其他地方出现崩溃。改动旧接口成本太高，所以往往不会被采取。同时做加减法：既有加法，又有减法，其实这种就跟新需求没啥区别，前端需要重做页面，后端需要新写接口满足前端需要，但是旧接口还是不能轻举妄动（除非确定只有这一处调用才可以删除）。往往这个时候，其实用到的数据大多都是来自于同一个DO或者DTO，不过是在REST接口组装数据时，用不同的VO来封装不同字段，或者，使用同样的VO，组装数据时做删减。看到这些问题是不是觉得令人头大？所以需求频繁改动是万恶之源 ，当产品小哥哥改动需求时，程序员小哥哥可能正提着铁锹赶来......那么有没有一种方案或者框架，可以使得在用到同一个领域模型（DO或者DTO）的数据时，前端对于这个模型的数据字段需求的改动，后端可以根据前端的改动和需要，自动适配，自动组装需要的字段，返回给前端呢？如果能这样做的话，那么后端程序猿小哥可能要开心死了，前端妹子也不用那么苦口婆心地劝说后端小哥哥了。所以GraphQL 隆重出世了！那么问题来了！Part 1 What is GraphQLGraphQL简介GraphQL是一种新的API标准，它提供了一种比REST更有效、更强大和更灵活的替代方案。它是由Facebook开发并开源的，现在由来自世界各地的公司和个人组成的大型社区维护。GraphQL本质上是一种基于api的查询语言，现在大多数应用程序都需要从服务器中获取数据，这些数据存储可能存储在数据库中，API的职责是提供与应用程序需求相匹配的存储数据的接口。它是数据库无关的，而且可以在使用API的任何环境中有效使用，我们可以理解为GraphQL是基于API之上的一层封装，目的是为了更好，更灵活的适用于业务的需求变化。简单的来说，它??它的工作模式是这样子的：GraphQL 对比 REST API 有什么好处？REST API 的接口灵活性差、接口操作流程繁琐，GraphQL 的声明式数据获取，使得接口数据精确返回，数据查询流程简洁，照顾了客户端的灵活性。客户端拓展功能时要不断编写新接口（依赖于服务端），GraphQL 中一个服务仅暴露一个 GraphQL 层，消除了服务器对数据格式的硬性规定，客户端按需请求数据，可进行单独维护和改进。REST API 基于HTTP协议，不能灵活选择网络协议，而传输层无关、数据库技术无关使得 GraphQL 有更加灵活的技术栈选择，能够实现在网络协议层面优化应用。举个经典的例子：前端向后端请求一个book对象的数据及其作者信息。我用动图来分别演示下REST和GraphQL是怎么样的一个过程。先看REST API的做法：REST API获取数据再来看GraphQL是怎么做的：GraphQL获取数据可以看出其中的区别：与REST多个endpoint不同，每一个的 GraphQL 服务其实对外只提供了一个用于调用内部接口的端点，所有的请求都访问这个暴露出来的唯一端点。Endpoints对比REST API's EndpointsGraphQL 实际上将多个 HTTP 请求聚合成了一个请求，将多个 restful 请求的资源变成了一个从根资源 POST 访问其他资源的 Comment 和 Author 的图，多个请求变成了一个请求的不同字段，从原有的分散式请求变成了集中式的请求，因此GraphQL又可以被看成是图数据库的形式。??图数据库模式的数据查询那我们已经能看到GraphQL的先进性，接下来看看它是怎么做的。GraphQL 思考模式使用GraphQL接口设计获取数据需要三步：GraphQL获取数据三步骤1、首先要设计数据模型，用来描述数据对象，它的作用可以看做是VO，用于告知GraphQL如何来描述定义的数据，为下一步查询返回做准备；2、前端使用模式查询语言（Schema）来描述需要请求的数据对象类型和具体需要的字段（称之为声明式数据获取）；3、后端GraphQL通过前端传过来的请求，根据需要，自动组装数据字段，返回给前端。GraphQL的这种思考模式是不是完美解决了之前遇到的问题呢？先总结它的好处：在它的设计思想中，GraphQL 以图的形式将整个 Web 服务中的资源展示出来，客户端可以按照其需求自行调用，类似添加字段的需求其实就不再需要后端多次修改了。创建GraphQL服务器的最终目标是：允许查询通过图和节点的形式去获取数据。??GraphQL执行逻辑有人会问：使用了GraphQL就要完全抛弃REST了吗？GraphQL需要直接对接数据库吗？使用GraphQL需要对现有的后端服务进行大刀阔斧的修改吗？答案是：NO！不需要！它完全可以以一种不侵入的方式来部署，将它作为前后端的中间服务，也就是，现在开始逐渐流行的 前端 —— 中端 —— 后端 的三层结构模式来部署！那就来看一下这样的部署模式图：GraphQL执行逻辑也就是说，完全可以搭建一个GraphQL服务器，专门来处理前端请求，并处理后端服务获取的数据，重新进行组装、筛选、过滤，将完美符合前端需要的数据返回。新的开发需求可以直接就使用GraphQL服务来获取数据了，以前已经上线的功能无需改动，还是使用原有请求调用REST接口的方式，最低程度的降低更换GraphQL带来的技术成本问题！如果没有那么多成本来支撑改造，那么就不需要改造！只有当原有需求发生变化，需要对原功能进行修改时，就可以换成GraphQL了。GraphQL应用的基本架构下图是一个 GraphQL 应用的基本架构，其中客户端只和 GraphQL 层进行 API 交互，而 GraphQL 层再往后接入各种数据源。这样一来，只要是数据源有的数据， GraphQL 层都可以让客户端按需获取，不必专门再去定接口了。??GraphQL应用基本架构一个GraphQL服务仅暴露一个 GraphQL Endpoint，可以按照业务来进行区分，部署多个GraphQL服务，分管不同的业务数据，这样就可以避免单服务器压力过大的问题了。GraphQL特点总结声明式数据获取（可以对API进行查询）: 声明式的数据查询带来了接口的精确返回，服务器会按数据查询的格式返回同样结构的 JSON 数据、真正照顾了客户端的灵活性。一个微服务仅暴露一个 GraphQL 层： 一个微服务只需暴露一个GraphQL endpoint，客户端请求相应数据只通过该端点按需获取，不需要再额外定义其他接口。传输层无关、数据库技术无关： 带来了更灵活的技术栈选择，比如我们可以选择对移动设备友好的协议，将网络传输数据量最小化，实现在网络协议层面优化应用。??Part 2 Schema & TypeGraphQL支持的数据操作GraphQL对数据支持的操作有：查询（Query）： 获取数据的基本查询。变更（Mutation）： 支持对数据的增删改等操作。订阅（Subscription）： 用于监听数据变动、并靠websocket等协议推送变动的消息给对方。GraphQL支持的操作GraphQL的核心概念：图表模式（Schema）要想要设计GraphQL的数据模型，用来描述你的业务数据，那么就必须要有一套Schema语法来做支撑。想要描述数据，就必须离不开数据类型的定义。所以GraphQL设计了一套Schema模式（可以理解为语法），其中最重要的就是数据类型的定义和支持。那么类型（Type）就是模式（Schema）最核心的东西了。什么是类型？对于数据模型的抽象是通过类型（Type）来描述的，每一个类型有若干字段（Field）组成，每个字段又分别指向某个类型（Type）。这很像Java、C#中的类（Class）。GraphQL的Type简单可以分为两种，一种叫做Scalar Type(标量类型)，另一种叫做Object Type(对象类型)。那么就分别来介绍下两种类型。标量类型（Scalar Type）标量是GraphQL类型系统中最小的颗粒。类似于Java、C#中的基本类型。其中内建标量主要有：StringIntFloatBooleanEnumIDScalar Type上面的类型仅仅是GraphQL默认内置的类型，当然，为了保证最大的灵活性，GraphQL还可以很灵活的自行创建标量类型。对象类型（Object Type）仅有标量类型是不能满足复杂抽象数据模型的需要，这时候我们可以使用对象类型。通过对象模型来构建GraphQL中关于一个数据模型的形状，同时还可以声明各个模型之间的内在关联（一对多、一对一或多对多）。对象类型的定义可以参考下图：??对象模型引入关联关系是不是很方便呢？我们可以像设计类图一样来设计GraphQL的对象模型。类型修饰符（Type Modifier）那么，类型系统仅仅只有类型定义是不够的，我们还需要对类型进行更广泛性的描述。类型修饰符就是用来修饰类型，以达到额外的数据类型要求控制。比如：列表：[Type]非空：Type!列表非空：[Type]!非空列表，列表内容类型非空：[Type!]!在描述数据模型（模式Schema）时，就可以对字段施加限制条件。例如定义了一个名为User的对象类型，并对其字段进行定义和施加限制条件：??User字段控制那么，返回数据时，像下面这种情况就是不允许的：??错误的表示Graphql会根据Schema Type来自动返回正确的数据：??正确的表示其他类型除了上面的，Graphql还有一些其他类型来更好的引入面向对象的设计思想：接口类型（Interfaces）： 其他对象类型实现接口必须包含接口所有的字段，并具有相同的类型修饰符，才算实现接口。比如定义了一个接口类型：??那么就可以实现该接口：??联合类型（Union Types）： 联合类型和接口十分相似，但是它并不指定类型之间的任何共同字段。几个对象类型共用一个联合类型。??输入类型（Input Types）： 更新数据时有用，与常规对象只有关键字修饰不一样，常规对象时 type 修饰，输入类型是 input 修饰。比如定义了一个输入类型：??前端发送变更请求时就可以使用（通过参数来指定输入的类型）：??所以，这样面向对象的设计方式，真的对后端开发人员特别友好！而且前端MVVM框架流行以来，面向对象的设计思想也越来越流行，前端使用Graphql也会得心应手。??Part 3 GraphQL技术接入架构Graphql 技术接入架构那么，该怎么设计来接入我们现有的系统中呢？将Graphql服务直连数据库的方式： 最简洁的配置，直接操作数据库能减少中间环节的性能消耗。??直连数据库的接入集成现有服务的GraphQL层： 这种配置适合于旧服务的改造，尤其是在涉及第三方服务时、依然可以通过原有接口进行交互。??集成现有服务的GraphQL层直连数据库和集成服务的混合模式： 前两种方式的混合。??混合接入方式可以说是非常灵活了！你都不用担心会给你带来任何的麻烦。服务端实现在服务端， GraphQL 服务器可用任何可构建 Web 服务器的语言实现。有以下语言的实现供参考：C# / .NET、Clojure、Elixir、Erlang、Go、Groovy、Java、JavaScript、Julia、Kotlin、Perl、PHP、Python、R、Ruby、Rust、Scala、Swift... 种类繁多，几乎流行的语言都有支持。客户端实现在客户端，Graphql Client目前有下面的语言支持：C# / .NET、Clojurescript、Elm、Flutter、Go、Java / Android、JavaScript、Julia、Swift / Objective-C、iOS、Python、R。覆盖了众多客户端设计语言，而其他语言的支持也在推进中。
我为什么要放弃 RESTful，选择拥抱 GraphQL
REST作为一种现代网络应用非常流行的软件架构风格，自从Roy Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性，可扩展性，伸缩性受到广大Web开发者的喜爱。REST 的 API 配合JSON格式的数据交换，使得前后端分离、数据交互变得非常容易，而且也已经成为了目前Web领域最受欢迎的软件架构设计模式。??但随着REST API的流行和发展，它的缺点也暴露了出来：滥用REST接口 ，导致大量相似度很高（具有重复性）的API越来越冗余。对于前端而言：REST API粒度较粗 ，难以一次性符合前端的数据要求，前端需要分多次请求接口数据。增加了前端人员的工作量。对于后端而言：前端需要的数据往往在不同的地方具有相似性，但却又不同 ，比如针对同样的用户信息，有的地方只需要用户简要信息（比如头像、昵称），有些地方需要详细的信息，这就需要开发不同的接口来满足这些需求。当这样的相似但又不同的地方多的时候，就需要开发更多的接口来满足前端的需要。增加了后端开发人员的工作量和重复度。那我们来分析一下，当前端需求变化，涉及到改动旧需求时 ，会有以下这些情况：做加法 ：产品需求增加，页面需要增加功能，数据也就相应的要增加显示，那么REST接口也需要做增加，这种无可厚非。做减法 ：产品需求减少，页面需要减少功能，或者减少某些信息显示，那么数据就要做减法。一种通常懒惰的做法是，前端不与后端沟通，仅在前端对数据选择性显示。因为后端接口能够满足数据需要，仅仅是在做显示的时候对数据进行了选择性显示，但接口的数据是存在冗余的，这种情况一个是存在数据泄露风险，另外就是数据量过大时造成网络流量过大，页面加载缓慢，用户流量费白白消耗，用户体验就会下降。另外一种做法就是告知后端，要么开发新的接口，要么，修改旧接口，删掉冗余字段。但一般来说，开发新接口往往是后端开发人员会选择的方案，因为这个方案对现有系统的影响最低，不会有额外的风险。修改旧接口删除冗余数据的方案往往开发人员不会选择，这是为什么呢？这就涉及到了系统的稳定性问题了，旧接口往往不止是一个地方在用，很有可能很多页面、设置不同客户端、不同服务都调用了这个接口获取数据，不做详细的调查，是不可能知道到底旧接口被调用了多少次，一旦改动旧接口，涉及范围可能非常大，往往会引起其他地方出现崩溃。改动旧接口成本太高，所以往往不会被采取。同时做加减法：既有加法，又有减法，其实这种就跟新需求没啥区别，前端需要重做页面，后端需要新写接口满足前端需要，但是旧接口还是不能轻举妄动（除非确定只有这一处调用才可以删除）。往往这个时候，其实用到的数据大多都是来自于同一个DO或者DTO，不过是在REST接口组装数据时，用不同的VO来封装不同字段，或者，使用同样的VO，组装数据时做删减。看到这些问题是不是觉得令人头大？所以需求频繁改动是万恶之源 ，当产品小哥哥改动需求时，程序员小哥哥可能正提着铁锹赶来......那么有没有一种方案或者框架，可以使得在用到同一个领域模型（DO或者DTO）的数据时，前端对于这个模型的数据字段需求的改动，后端可以根据前端的改动和需要，自动适配，自动组装需要的字段，返回给前端呢？如果能这样做的话，那么后端程序猿小哥可能要开心死了，前端妹子也不用那么苦口婆心地劝说后端小哥哥了。所以GraphQL 隆重出世了！那么问题来了！Part 1 What is GraphQLGraphQL简介GraphQL是一种新的API标准，它提供了一种比REST更有效、更强大和更灵活的替代方案。它是由Facebook开发并开源的，现在由来自世界各地的公司和个人组成的大型社区维护。GraphQL本质上是一种基于api的查询语言，现在大多数应用程序都需要从服务器中获取数据，这些数据存储可能存储在数据库中，API的职责是提供与应用程序需求相匹配的存储数据的接口。它是数据库无关的，而且可以在使用API的任何环境中有效使用，我们可以理解为GraphQL是基于API之上的一层封装，目的是为了更好，更灵活的适用于业务的需求变化。简单的来说，它??它的工作模式是这样子的：GraphQL 对比 REST API 有什么好处？REST API 的接口灵活性差、接口操作流程繁琐，GraphQL 的声明式数据获取，使得接口数据精确返回，数据查询流程简洁，照顾了客户端的灵活性。客户端拓展功能时要不断编写新接口（依赖于服务端），GraphQL 中一个服务仅暴露一个 GraphQL 层，消除了服务器对数据格式的硬性规定，客户端按需请求数据，可进行单独维护和改进。REST API 基于HTTP协议，不能灵活选择网络协议，而传输层无关、数据库技术无关使得 GraphQL 有更加灵活的技术栈选择，能够实现在网络协议层面优化应用。举个经典的例子：前端向后端请求一个book对象的数据及其作者信息。我用动图来分别演示下REST和GraphQL是怎么样的一个过程。先看REST API的做法：REST API获取数据再来看GraphQL是怎么做的：GraphQL获取数据可以看出其中的区别：与REST多个endpoint不同，每一个的 GraphQL 服务其实对外只提供了一个用于调用内部接口的端点，所有的请求都访问这个暴露出来的唯一端点。Endpoints对比REST API's EndpointsGraphQL 实际上将多个 HTTP 请求聚合成了一个请求，将多个 restful 请求的资源变成了一个从根资源 POST 访问其他资源的 Comment 和 Author 的图，多个请求变成了一个请求的不同字段，从原有的分散式请求变成了集中式的请求，因此GraphQL又可以被看成是图数据库的形式。??图数据库模式的数据查询那我们已经能看到GraphQL的先进性，接下来看看它是怎么做的。GraphQL 思考模式使用GraphQL接口设计获取数据需要三步：GraphQL获取数据三步骤1、首先要设计数据模型，用来描述数据对象，它的作用可以看做是VO，用于告知GraphQL如何来描述定义的数据，为下一步查询返回做准备；2、前端使用模式查询语言（Schema）来描述需要请求的数据对象类型和具体需要的字段（称之为声明式数据获取）；3、后端GraphQL通过前端传过来的请求，根据需要，自动组装数据字段，返回给前端。GraphQL的这种思考模式是不是完美解决了之前遇到的问题呢？先总结它的好处：在它的设计思想中，GraphQL 以图的形式将整个 Web 服务中的资源展示出来，客户端可以按照其需求自行调用，类似添加字段的需求其实就不再需要后端多次修改了。创建GraphQL服务器的最终目标是：允许查询通过图和节点的形式去获取数据。??GraphQL执行逻辑有人会问：使用了GraphQL就要完全抛弃REST了吗？GraphQL需要直接对接数据库吗？使用GraphQL需要对现有的后端服务进行大刀阔斧的修改吗？答案是：NO！不需要！它完全可以以一种不侵入的方式来部署，将它作为前后端的中间服务，也就是，现在开始逐渐流行的 前端 —— 中端 —— 后端 的三层结构模式来部署！那就来看一下这样的部署模式图：GraphQL执行逻辑也就是说，完全可以搭建一个GraphQL服务器，专门来处理前端请求，并处理后端服务获取的数据，重新进行组装、筛选、过滤，将完美符合前端需要的数据返回。新的开发需求可以直接就使用GraphQL服务来获取数据了，以前已经上线的功能无需改动，还是使用原有请求调用REST接口的方式，最低程度的降低更换GraphQL带来的技术成本问题！如果没有那么多成本来支撑改造，那么就不需要改造！只有当原有需求发生变化，需要对原功能进行修改时，就可以换成GraphQL了。GraphQL应用的基本架构下图是一个 GraphQL 应用的基本架构，其中客户端只和 GraphQL 层进行 API 交互，而 GraphQL 层再往后接入各种数据源。这样一来，只要是数据源有的数据， GraphQL 层都可以让客户端按需获取，不必专门再去定接口了。??GraphQL应用基本架构一个GraphQL服务仅暴露一个 GraphQL Endpoint，可以按照业务来进行区分，部署多个GraphQL服务，分管不同的业务数据，这样就可以避免单服务器压力过大的问题了。GraphQL特点总结声明式数据获取（可以对API进行查询）: 声明式的数据查询带来了接口的精确返回，服务器会按数据查询的格式返回同样结构的 JSON 数据、真正照顾了客户端的灵活性。一个微服务仅暴露一个 GraphQL 层： 一个微服务只需暴露一个GraphQL endpoint，客户端请求相应数据只通过该端点按需获取，不需要再额外定义其他接口。传输层无关、数据库技术无关： 带来了更灵活的技术栈选择，比如我们可以选择对移动设备友好的协议，将网络传输数据量最小化，实现在网络协议层面优化应用。??Part 2 Schema & TypeGraphQL支持的数据操作GraphQL对数据支持的操作有：查询（Query）： 获取数据的基本查询。变更（Mutation）： 支持对数据的增删改等操作。订阅（Subscription）： 用于监听数据变动、并靠websocket等协议推送变动的消息给对方。GraphQL支持的操作GraphQL的核心概念：图表模式（Schema）要想要设计GraphQL的数据模型，用来描述你的业务数据，那么就必须要有一套Schema语法来做支撑。想要描述数据，就必须离不开数据类型的定义。所以GraphQL设计了一套Schema模式（可以理解为语法），其中最重要的就是数据类型的定义和支持。那么类型（Type）就是模式（Schema）最核心的东西了。什么是类型？对于数据模型的抽象是通过类型（Type）来描述的，每一个类型有若干字段（Field）组成，每个字段又分别指向某个类型（Type）。这很像Java、C#中的类（Class）。GraphQL的Type简单可以分为两种，一种叫做Scalar Type(标量类型)，另一种叫做Object Type(对象类型)。那么就分别来介绍下两种类型。标量类型（Scalar Type）标量是GraphQL类型系统中最小的颗粒。类似于Java、C#中的基本类型。其中内建标量主要有：StringIntFloatBooleanEnumIDScalar Type上面的类型仅仅是GraphQL默认内置的类型，当然，为了保证最大的灵活性，GraphQL还可以很灵活的自行创建标量类型。对象类型（Object Type）仅有标量类型是不能满足复杂抽象数据模型的需要，这时候我们可以使用对象类型。通过对象模型来构建GraphQL中关于一个数据模型的形状，同时还可以声明各个模型之间的内在关联（一对多、一对一或多对多）。对象类型的定义可以参考下图：??对象模型引入关联关系是不是很方便呢？我们可以像设计类图一样来设计GraphQL的对象模型。类型修饰符（Type Modifier）那么，类型系统仅仅只有类型定义是不够的，我们还需要对类型进行更广泛性的描述。类型修饰符就是用来修饰类型，以达到额外的数据类型要求控制。比如：列表：[Type]非空：Type!列表非空：[Type]!非空列表，列表内容类型非空：[Type!]!在描述数据模型（模式Schema）时，就可以对字段施加限制条件。例如定义了一个名为User的对象类型，并对其字段进行定义和施加限制条件：??User字段控制那么，返回数据时，像下面这种情况就是不允许的：??错误的表示Graphql会根据Schema Type来自动返回正确的数据：??正确的表示其他类型除了上面的，Graphql还有一些其他类型来更好的引入面向对象的设计思想：接口类型（Interfaces）： 其他对象类型实现接口必须包含接口所有的字段，并具有相同的类型修饰符，才算实现接口。比如定义了一个接口类型：??那么就可以实现该接口：??联合类型（Union Types）： 联合类型和接口十分相似，但是它并不指定类型之间的任何共同字段。几个对象类型共用一个联合类型。??输入类型（Input Types）： 更新数据时有用，与常规对象只有关键字修饰不一样，常规对象时 type 修饰，输入类型是 input 修饰。比如定义了一个输入类型：??前端发送变更请求时就可以使用（通过参数来指定输入的类型）：??所以，这样面向对象的设计方式，真的对后端开发人员特别友好！而且前端MVVM框架流行以来，面向对象的设计思想也越来越流行，前端使用Graphql也会得心应手。??Part 3 GraphQL技术接入架构Graphql 技术接入架构那么，该怎么设计来接入我们现有的系统中呢？将Graphql服务直连数据库的方式： 最简洁的配置，直接操作数据库能减少中间环节的性能消耗。??直连数据库的接入集成现有服务的GraphQL层： 这种配置适合于旧服务的改造，尤其是在涉及第三方服务时、依然可以通过原有接口进行交互。??集成现有服务的GraphQL层直连数据库和集成服务的混合模式： 前两种方式的混合。??混合接入方式可以说是非常灵活了！你都不用担心会给你带来任何的麻烦。服务端实现在服务端， GraphQL 服务器可用任何可构建 Web 服务器的语言实现。有以下语言的实现供参考：C# / .NET、Clojure、Elixir、Erlang、Go、Groovy、Java、JavaScript、Julia、Kotlin、Perl、PHP、Python、R、Ruby、Rust、Scala、Swift... 种类繁多，几乎流行的语言都有支持。客户端实现在客户端，Graphql Client目前有下面的语言支持：C# / .NET、Clojurescript、Elm、Flutter、Go、Java / Android、JavaScript、Julia、Swift / Objective-C、iOS、Python、R。覆盖了众多客户端设计语言，而其他语言的支持也在推进中。
【保姆级教程】Spring Boot 单元测试
一、 单元测试的概念概念：\1. 单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。在Java中单元测试的最小单元是类。\2. 单元测试是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。执行单元测试，就是为了证明这 段代码的行为和我们期望是否一致。单元测试引用：\1. 众所周知，通过spring initialize创建的Spring Boot项目会在Maven中自动携带很多starter依赖：?图片其中包含了一个名为spring-boot-starter-test的依赖，本文是围绕这个依赖展开。\2. Spring Boot中引入单元测试很简单，添加如下依赖（即spring-boot-starter-test依赖）：<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>\3. spring-boot-starter-test有如下几个库：spring-boot-starter-testUML图：?图片图片二、单元测试的作用在没有接触单元测试之前我们是怎么做测试的？一般有两个方法：?图片在时间允许的情况下，编写单元测试是程序员对代码的自测，这是对自己代码的负责。写单元测试的两个动机：\1. 保证或验证实现功能。\2. 保护已经实现的功能不被破坏。三、Spring Boot引入的MockMvc的概念\1. 什么是Mock?在面向对象的程序设计中，模拟对象（英语：mock object）是以可控的方式模拟真实对象行为的假对象。在编程过程中，通常通过模拟一些输入数据，来验证程序是否达到预期结果。\2. 为什么使用Mock对象？使用模拟对象，可以模拟复杂的、真实的对象行为。如果在单元测试中无法使用真实对象，可采用模拟对象进行替代。\3. MockMvc的概念MockMvc是由spring-test包提供，实现了对Http请求的模拟，能够直接使用网络的形式，转换到Controller的调用，使得测试速度快、不依赖网络环境。同时提供了一套验证的工具，结果的验证十分方便。接口MockMvcBuilder，提供一个唯一的build方法，用来构造MockMvc。主要有两个实现：StandaloneMockMvcBuilder和DefaultMockMvcBuilder。?图片\4. MockMVC的基本步骤(1) mockMvc.perform执行一个请求。(2) MockMvcRequestBuilders.get(“XXX”)构造一个请求。(3) ResultActions.param添加请求传值 (4) ResultActions.accept()设置返回类型 (5) ResultActions.andExpect添加执行完成后的断言。(6) ResultActions.andDo添加一个结果处理器，表示要对结果做点什么事情，比如处使用print()输出整个响应结果信息。(7) ResultActions.andReturn表示执行完成后返回相应的结果。四、Service层的单元测试第一步： Spring Boot中单元测试类写在src/test/java目录下，你可以手动创建具体测试类，也可以通过IDEA自动创建测试类，如下图：（注：点选并打开相应代码界面，再点击菜单栏的Navigate）?图片第二步： 按照第一步的方法，点击测试后，出现图一 的对话框（如果想要测试的类已经存在测试类了会被列出来，也可以重新创建一个新的测试类），点击”Create New Test…”会弹出图二 的对话框，可以选择是否生成setUp以及要测试的成员方法等：图一?图片图二?图片第三步： 至此Service层的测试类就创建好了，测试类自动生成到了src/test/java目录下项目的同级目录中 ，如下图：?图片Service层测试代码如下：@SpringBootTest
@RunWith(SpringRunner.class)
public class XXXServiceTest {
@Resource
private XXXService XXXService;
@Test
public void conflictTime() {
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("yyyy-MM-dd");
LocalDate start = LocalDate.parse("2020-10-26", dtf);
LocalDate end = LocalDate.parse("2020-10-31", dtf);
Integer integer = XXXService.ConflictTime("10000001", start, end);
Assert.assertThat(integer, Matchers.notNullValue());//assertThat断言后面介绍
}
}注解解释：@SpringBootTest：获取启动类，加载配置，寻找主配置启动类（被 @SpringBootApplication 注解的） @RunWith(SpringRunner.class)：让JUnit运行Spring的测试环境,获得Spring环境的上下文的支持五、Controller层的单元测试创建测试类步骤见第四部分，此处略。第四部分只是针对Service层做了测试，但是咱么也需要对Controller层（API）做测试，这时候就用到MockMvc了，它使得你无需启动项目工程就能测试这些接口MockMvc实现了对Http请求的模拟，能够直接使用网络的形式，转换到Controller的调用，这样可以使得测试速度快、不依赖网络环境，而且提供了一套验证的工具，这样可以使得请求的验证统一而且很方便。Controller层部分的代码将分为三个代码块讲解，里面有看不懂的代码先不要着急哦😄，会在第五部分结尾处给大家汇总解答的，大家要坚持看到最后哟！😁代码块一：@SpringBootTest
@RunWith(SpringRunner.class)
@AutoConfigureMockMvc
public class DfTaskRecordControllerTest {
@Autowired
private MockMvc mockMvc;
@Before
public void setUp() throws Exception {
System.out.println("---------------start---------------");
save();
get();
System.out.println("================end================");
}注解解释：@SpringBootTest>：获取启动类，加载配置，寻找主配置启动类（被 @SpringBootApplication 注解的）@RunWith(SpringRunner.class)>：让JUnit运行Spring的测试环境,获得Spring环境的上下文的支持 @AutoConfigureMockMvc：用于自动配置MockMvc,配置后MockMvc类可以直接注入,相当于new MockMvc @Before:初始化方法 ,对于每一个测试方法都要执行一次代码块二：@Test
@Transactional
@Rollback()
public void save() throws Exception {
String json"{……}";
//执行一个RequestBuilder请求，会自动执行SpringMVC的流程并映射到相应的控制器执行处理；
mockMvc.perform(MockMvcRequestBuilders
.post("/XXX/save")
.content(json.getBytes()) //传json参数
.accept(MediaType.APPLICATION_JSON)
.contentType(MediaType.APPLICATION_JSON_VALUE)
.header("Authorization","Bearer ********-****-****-****-************")
)
.andExpect(MockMvcResultMatchers.status().isOk())
.andDo(print());
}注解解释：@Transactional:开启事务功能@Rollback(): 事务回滚,默认是true代码块三：@Test
public void get() throws Exception{
ResultActions resultActions = mockMvc.perform(MockMvcRequestBuilders
.get("/XXX/get")
.param("id", "**********")
.header("Authorization", "Bearer ********-****-****-****-************")
);
resultActions.andReturn().getResponse().setCharacterEncoding("UTF-8");
resultActions.andExpect(MockMvcResultMatchers.status().isOk()).andDo(print());
}
}/get运行结果如下：?图片现在将上面的一些琐碎的知识点汇总一下：1. mockMvc.perform：执行一个请求2. MockMvcRequestBuilders.get(“/XXX/get”)：构造一个请求，Post请求使用.post方法3. contentType(MediaType.APPLICATION_JSON_VALUE)：代表发送端发送的数据格式是application/json;charset=UTF-84. accept(MediaType.APPLICATION_JSON)：代表客户端希望接受的数据类型为application/json;charset=UTF-85. header(“Authorization”,“Bearer XXXX”)：代表在报文头添加一些必须的信息，这里添加的是token6. ResultActions.andExpect：添加执行完成后的断言7. ResultActions.andExpect(MockMvcResultMatchers.status().isOk())：方法看请求的状态响应码是否为200如果不是则抛异常，测试不通过8. ResultActions.andDo：添加一个结果处理器，表示要对结果做点什么事情，比如此处使用print()：输出整个响应结果信息六、断言的概念断言（assert），是编程术语，表示为一些布尔表达式，程序员相信在程序中的某个特定点该表达式值为真。可以在任何时候启用和禁用断言验证，因此可以在测试时启用断言而在部署时禁用断言。使用断言是判断一个函数或对象的一个方法所产生的结果是否符合你期望那个结果。七、新断言assertThat使用JUnit 4.4 结合 Hamcrest 提供了一个全新的断言语法——assertThat。程序员可以只使用 assertThat 一个断言语句，结合 Hamcrest 提供的匹配符，就可以表达全部的测试思想。assertThat 的优点：优点 1： 以前 JUnit 提供了很多的 assertion 语句，如：assertEquals，assertNotSame，assertFalse，assertTrue，assertNotNull，assertNull 等，现在有了 JUnit 4.4，一条 assertThat 即可以替代所有的 assertion 语句，这样可以在所有的单元测试中只使用一个断言方法，使得编写测试用例变得简单，代码风格变得统一，测试代码也更容易维护。优点 2： assertThat 使用了 Hamcrest 的 Matcher 匹配符，用户可以使用匹配符规定的匹配准则精确的指定一些想设定满足的条件，具有很强的易读性，而且使用起来更加灵活。优点 3： assertThat 不再像 assertEquals 那样，使用比较难懂的“谓宾主”语法模式（如：assertEquals(3, x);），相反，assertThat 使用了类似于“主谓宾”的易读语法模式（如：assertThat(x,is(3));），使得代码更加直观、易读。assertThat 的基本语法如下：assertThat( [value], [matcher statement] );value ：接下来想要测试的变量值；matcher statement ：使用 Hamcrest 匹配符来表达的对前面变量所期望的值的声明，如果 value 值与 matcher statement 所表达的期望值相符，则测试成功，否则测试失败。八、Postman与Spring Boot 单元测试的区别\1. Spring Boot的单元测试主要针对方法层面，可以测试Service层这类非对外暴露的接口的类中方法，并且可一次性批量测试多个方法、支持事务回滚。\2. Postman针对接口进行http测试，我平时这个比较多，创建的测试接口可保存、分类。九、Postman基本用法Postman是一款功能强大的网页调试与发送网页HTTP请求的工具。Postman能够发送任何类型的HTTP请求(GET, HEAD, POST,PUT..)，附带任何数量的参数和HTTP headers。支持不同的认证机制（basic, digest,OAuth），接收到的响应语法高亮（HTML，JSON或XML）。安装Postman官方网站：https://www.getpostman.com/apps?图片安装后，Postman是介样婶儿滴~~😊?
Google 开源的依赖注入库，比 Spring 更小更快！
Guice是Google开源的一个依赖注入类库，相比于Spring IoC来说更小更快。Elasticsearch大量使用了Guice，本文简单的介绍下Guice的基本概念和使用方式。学习目标概述：了解Guice是什么，有什么特点；快速开始：通过实例了解Guice；核心概念：了解Guice涉及的核心概念，如绑定（Binding）、范围（Scope）和注入（Injection）；最佳实践：官方推荐的最佳实践；Guice概述Guice是Google开源的依赖注入类库，通过Guice减少了对工厂方法和new的使用，使得代码更易交付、测试和重用；Guice可以帮助我们更好地设计API，它是个轻量级非侵入式的类库；Guice对开发友好，当有异常发生时能提供更多有用的信息用于分析；快速开始假设一个在线预订Pizza的网站，其有一个计费服务接口：public interface BillingService {
/**
* 通过信用卡支付。无论支付成功与否都需要记录交易信息。
*
* @return 交易回执。支付成功时返回成功信息，否则记录失败原因。
*/
Receipt chargeOrder(PizzaOrder order, CreditCard creditCard);
}使用new的方式获取信用卡支付处理器和数据库交易日志记录器：public class RealBillingService implements BillingService {
public Receipt chargeOrder(PizzaOrder order, CreditCard creditCard) {
CreditCardProcessor processor = new PaypalCreditCardProcessor();
TransactionLog transactionLog = new DatabaseTransactionLog();
try {
ChargeResult result = processor.charge(creditCard, order.getAmount());
transactionLog.logChargeResult(result);
return result.wasSuccessful()
? Receipt.forSuccessfulCharge(order.getAmount())
: Receipt.forDeclinedCharge(result.getDeclineMessage());
} catch (UnreachableException e) {
transactionLog.logConnectException(e);
return Receipt.forSystemFailure(e.getMessage());
}
}
}使用new的问题是使得代码耦合，不易维护和测试。比如在UT里不可能直接用真实的信用卡支付，需要Mock一个CreditCardProcessor。相比于new，更容易想到的改进是使用工厂方法，但是工厂方法在测试中仍存在问题（因为通常使用全局变量来保存实例，如果在用例中未重置可能会影响其他用例）。更好的方式是通过构造方法注入依赖：public class RealBillingService implements BillingService {
private final CreditCardProcessor processor;
private final TransactionLog transactionLog;
public RealBillingService(CreditCardProcessor processor,
TransactionLog transactionLog) {
this.processor = processor;
this.transactionLog = transactionLog;
}
public Receipt chargeOrder(PizzaOrder order, CreditCard creditCard) {
try {
ChargeResult result = processor.charge(creditCard, order.getAmount());
transactionLog.logChargeResult(result);
return result.wasSuccessful()
? Receipt.forSuccessfulCharge(order.getAmount())
: Receipt.forDeclinedCharge(result.getDeclineMessage());
} catch (UnreachableException e) {
transactionLog.logConnectException(e);
return Receipt.forSystemFailure(e.getMessage());
}
}
}对于真实的网站应用可以注入真正的业务处理服务类：public static void main(String[] args) {
CreditCardProcessor processor = new PaypalCreditCardProcessor();
TransactionLog transactionLog = new DatabaseTransactionLog();
BillingService billingService
= new RealBillingService(processor, transactionLog);
...
}而在测试用例中可以注入Mock类：public class RealBillingServiceTest extends TestCase {
private final PizzaOrder order = new PizzaOrder(100);
private final CreditCard creditCard = new CreditCard("1234", 11, 2010);
private final InMemoryTransactionLog transactionLog = new InMemoryTransactionLog();
private final FakeCreditCardProcessor processor = new FakeCreditCardProcessor();
public void testSuccessfulCharge() {
RealBillingService billingService
= new RealBillingService(processor, transactionLog);
Receipt receipt = billingService.chargeOrder(order, creditCard);
assertTrue(receipt.hasSuccessfulCharge());
assertEquals(100, receipt.getAmountOfCharge());
assertEquals(creditCard, processor.getCardOfOnlyCharge());
assertEquals(100, processor.getAmountOfOnlyCharge());
assertTrue(transactionLog.wasSuccessLogged());
}
}那通过Guice怎么实现依赖注入呢？首先我们需要告诉Guice如果找到接口对应的实现类，这个可以通过模块 来实现：public class BillingModule extends AbstractModule {
@Override
protected void configure() {
bind(TransactionLog.class).to(DatabaseTransactionLog.class);
bind(CreditCardProcessor.class).to(PaypalCreditCardProcessor.class);
bind(BillingService.class).to(RealBillingService.class);
}
}这里的模块只需要实现Module接口或继承自AbstractModule，然后在configure方法中设置绑定 （后面会继续介绍）即可。然后只需在原有的构造方法中增加@Inject注解即可注入 ：public class RealBillingService implements BillingService {
private final CreditCardProcessor processor;
private final TransactionLog transactionLog;
@Inject
public RealBillingService(CreditCardProcessor processor,
TransactionLog transactionLog) {
this.processor = processor;
this.transactionLog = transactionLog;
}
public Receipt chargeOrder(PizzaOrder order, CreditCard creditCard) {
try {
ChargeResult result = processor.charge(creditCard, order.getAmount());
transactionLog.logChargeResult(result);
return result.wasSuccessful()
? Receipt.forSuccessfulCharge(order.getAmount())
: Receipt.forDeclinedCharge(result.getDeclineMessage());
} catch (UnreachableException e) {
transactionLog.logConnectException(e);
return Receipt.forSystemFailure(e.getMessage());
}
}
}最后，再看看main方法中是如何调用的：public static void main(String[] args) {
Injector injector = Guice.createInjector(new BillingModule());
BillingService billingService = injector.getInstance(BillingService.class);
...
}绑定连接绑定连接绑定是最常用的绑定方式，它将一个类型和它的实现进行映射。下面的例子中将TransactionLog接口映射到它的实现类DatabaseTransactionLog。public class BillingModule extends AbstractModule {
@Override
protected void configure() {
bind(TransactionLog.class).to(DatabaseTransactionLog.class);
}
}连接绑定还支持链式，比如下面的例子最终将TransactionLog接口映射到实现类MySqlDatabaseTransactionLog。public class BillingModule extends AbstractModule {
@Override
protected void configure() {
bind(TransactionLog.class).to(DatabaseTransactionLog.class);
bind(DatabaseTransactionLog.class).to(MySqlDatabaseTransactionLog.class);
}
}注解绑定通过一个类型可能存在多个实现，比如在信用卡支付处理器中存在PayPal的支付和Google支付，这样通过连接绑定就搞不定。这时我们可以通过注解绑定来实现：@BindingAnnotation
@Target({ FIELD, PARAMETER, METHOD })
@Retention(RUNTIME)
public @interface PayPal {}
public class RealBillingService implements BillingService {
@Inject
public RealBillingService(@PayPal CreditCardProcessor processor,
TransactionLog transactionLog) {
...
}
}
// 当注入的方法参数存在@PayPal注解时注入PayPalCreditCardProcessor实现
bind(CreditCardProcessor.class).annotatedWith(PayPal.class).to(PayPalCreditCardProcessor.class);可以看到在模块的绑定时用annotatedWith方法指定具体的注解来进行绑定，这种方式有一个问题就是我们必须增加自定义的注解来绑定，基于此Guice内置了一个@Named注解满足该场景：public class RealBillingService implements BillingService {
@Inject
public RealBillingService(@Named("Checkout") CreditCardProcessor processor,
TransactionLog transactionLog) {
...
}
}
// 当注入的方法参数存在@Named注解且值为Checkout时注入CheckoutCreditCardProcessor实现
bind(CreditCardProcessor.class).annotatedWith(Names.named("Checkout")).to(CheckoutCreditCardProcessor.class);实例绑定将一个类型绑定到一个具体的实例而非实现类，这个通过是在无依赖的对象（比如值对象）中使用。如果toInstance包含复杂的逻辑会导致启动速度，此时应该通过@Provides方法绑定。bind(String.class).annotatedWith(Names.named("JDBC URL")).toInstance("jdbc:mysql://localhost/pizza");
bind(Integer.class).annotatedWith(Names.named("login timeout seconds")).toInstance(10);@Provides方法绑定模块中定义的、带有@Provides注解的、方法返回值即为绑定映射的类型。public class BillingModule extends AbstractModule {
@Override
protected void configure() {
...
}
@Provides
TransactionLog provideTransactionLog() {
DatabaseTransactionLog transactionLog = new DatabaseTransactionLog();
transactionLog.setJdbcUrl("jdbc:mysql://localhost/pizza");
transactionLog.setThreadPoolSize(30);
return transactionLog;
}
@Provides @PayPal
CreditCardProcessor providePayPalCreditCardProcessor(@Named("PayPal API key") String apiKey) {
PayPalCreditCardProcessor processor = new PayPalCreditCardProcessor();
processor.setApiKey(apiKey);
return processor;
}
}Provider绑定如果使用@Provides方法绑定逻辑越来越复杂时就可以通过Provider绑定（一个实现了Provider接口的实现类）来实现。public interface Provider<T> {
T get();
}
public class DatabaseTransactionLogProvider implements Provider<TransactionLog> {
private final Connection connection;
@Inject
public DatabaseTransactionLogProvider(Connection connection) {
this.connection = connection;
}
public TransactionLog get() {
DatabaseTransactionLog transactionLog = new DatabaseTransactionLog();
transactionLog.setConnection(connection);
return transactionLog;
}
}
public class BillingModule extends AbstractModule {
@Override
protected void configure() {
bind(TransactionLog.class).toProvider(DatabaseTransactionLogProvider.class);
}
}无目标绑定当我们想提供对一个具体的类给注入器时就可以采用无目标绑定。bind(MyConcreteClass.class);
bind(AnotherConcreteClass.class).in(Singleton.class);构造器绑定3.0新增的绑定，适用于第三方提供的类或者是有多个构造器参与依赖注入。通过@Provides方法可以显式调用构造器，但是这种方式有一个限制：无法给这些实例应用AOP。public class BillingModule extends AbstractModule {
@Override
protected void configure() {
try {
bind(TransactionLog.class).toConstructor(DatabaseTransactionLog.class.getConstructor(DatabaseConnection.class));
} catch (NoSuchMethodException e) {
addError(e);
}
}
}范围默认情况下，Guice每次都会返回一个新的实例，这个可以通过范围（Scope）来配置。常见的范围有单例（@Singleton）、会话（@SessionScoped）和请求（@RequestScoped），另外还可以通过自定义的范围来扩展。范围的注解可以应该在实现类、@Provides方法中，或在绑定的时候指定（优先级最高）：@Singleton
public class InMemoryTransactionLog implements TransactionLog {
/* everything here should be threadsafe! */
}
// scopes apply to the binding source, not the binding target
bind(TransactionLog.class).to(InMemoryTransactionLog.class).in(Singleton.class);
@Provides @Singleton
TransactionLog provideTransactionLog() {
...
}另外，Guice还有一种特殊的单例模式叫饥饿单例（相对于懒加载单例来说）：// Eager singletons reveal initialization problems sooner,
// and ensure end-users get a consistent, snappy experience.
bind(TransactionLog.class).to(InMemoryTransactionLog.class).asEagerSingleton();注入依赖注入的要求就是将行为和依赖分离，它建议将依赖注入而非通过工厂类的方法去查找。注入的方式通常有构造器注入、方法注入、属性注入等。// 构造器注入
public class RealBillingService implements BillingService {
private final CreditCardProcessor processorProvider;
private final TransactionLog transactionLogProvider;
@Inject
public RealBillingService(CreditCardProcessor processorProvider,
TransactionLog transactionLogProvider) {
this.processorProvider = processorProvider;
this.transactionLogProvider = transactionLogProvider;
}
}
// 方法注入
public class PayPalCreditCardProcessor implements CreditCardProcessor {
private static final String DEFAULT_API_KEY = "development-use-only";
private String apiKey = DEFAULT_API_KEY;
@Inject
public void setApiKey(@Named("PayPal API key") String apiKey) {
this.apiKey = apiKey;
}
}
// 属性注入
public class DatabaseTransactionLogProvider implements Provider<TransactionLog> {
@Inject Connection connection;
public TransactionLog get() {
return new DatabaseTransactionLog(connection);
}
}
// 可选注入：当找不到映射时不报错
public class PayPalCreditCardProcessor implements CreditCardProcessor {
private static final String SANDBOX_API_KEY = "development-use-only";
private String apiKey = SANDBOX_API_KEY;
@Inject(optional=true)
public void setApiKey(@Named("PayPal API key") String apiKey) {
this.apiKey = apiKey;
}
}辅助注入辅助注入（Assisted Inject）属于Guice扩展的一部分，它通过@Assisted注解自动生成工厂来加强非注入参数的使用。// RealPayment中有两个参数startDate和amount无法直接注入
public class RealPayment implements Payment {
public RealPayment(
CreditService creditService, // from the Injector
AuthService authService, // from the Injector
Date startDate, // from the instance's creator
Money amount); // from the instance's creator
}
...
}
// 一种方式是增加一个工厂来构造
public interface PaymentFactory {
public Payment create(Date startDate, Money amount);
}
public class RealPaymentFactory implements PaymentFactory {
private final Provider<CreditService> creditServiceProvider;
private final Provider<AuthService> authServiceProvider;
@Inject
public RealPaymentFactory(Provider<CreditService> creditServiceProvider,
Provider<AuthService> authServiceProvider) {
this.creditServiceProvider = creditServiceProvider;
this.authServiceProvider = authServiceProvider;
}
public Payment create(Date startDate, Money amount) {
return new RealPayment(creditServiceProvider.get(),
authServiceProvider.get(), startDate, amount);
}
}
bind(PaymentFactory.class).to(RealPaymentFactory.class);
// 通过@Assisted注解可以减少RealPaymentFactory
public class RealPayment implements Payment {
@Inject
public RealPayment(
CreditService creditService,
AuthService authService,
@Assisted Date startDate,
@Assisted Money amount);
}
...
}
// Guice 2.0
//bind(PaymentFactory.class).toProvider(FactoryProvider.newFactory(PaymentFactory.class, RealPayment.class));
// Guice 3.0
install(new FactoryModuleBuilder().implement(Payment.class, RealPayment.class).build(PaymentFactory.class));最佳实践最小化可变性：尽可能注入的是不可变对象；只注入直接依赖：不用注入一个实例来获取真正需要的实例，增加复杂性且不易测试；避免循环依赖避免静态状态：静态状态和可测试性就是天敌；采用@Nullable：Guice默认情况下禁止注入null对象；模块的处理必须要快并且无副作用在Providers绑定中当心IO问题：因为Provider不检查异常、不支持超时、不支持重试；不用在模块中处理分支逻辑尽可能不要暴露构造器
记录一次用 curl 测试账户登录服务接口
目录问题解决步骤一步骤二步骤三问题后台开发服务接口时，经常会用到很多测试工具，比如 Postman、Apipost、Jmeter 等。这些都是带有图形用户界面的工具，有没有一些显得高大上的方法呢？嗯，是有的。比如今天开发某个账户登陆服务接口时，就想到了先用命令行来测试一下服务接口是否好用。解决话不多说，先亮剑，测试服务接口使用的工具就是 curl。因为自己之前也没有这样搞过事情，接下来，我就一步步尝试使用 curl 登陆对应的服务。步骤一首先，我们知道登陆服务接口地址是 yapi.test.cn/api/user/lo… ，然后，我们直接使用 curl 访问这个地址会有什么现象呢？sh-3.2# curl http://yapi.test.cn/api/user/login_by_ldap
{"errcode":401,"errmsg":"用户名不存在","data":null}可以看出，服务直接返回了错误信息：用户名不存在。大致可知道应该是对应的请求缺少了参数。步骤二查看登陆服务接口说明，我们知道这个接口是一个 POST 类型的接口，同时用两个参数 email 和 password。curl 命令中可以使用 --request POST 来设置请求接口的类型，-d 可以用来设置请求携带的参数，然后，我们使用如下命令来查看请求效果，但是这次我们使用正确的用户名和错误的密码：curl --request POST yapi.test.cn/api/user/lo… -d "email=liuzhen007&password=000"如果使用 --verbose 参数，还可以查看整个请求的交互过程，结果截图如下：步骤三好了，接下来我们使用正确的账户名和密码测试一下登陆服务接口。测试结果如下图所示：哈哈，可以看到，我们登陆成功了！其实，curl 还有很多其他的用法，感兴趣的小伙自己去发现吧！今天就主要介绍一下 curl 的一次入门使用实例！作者简介：😄大家好，我是 Data-Mining（liuzhen007），是一位音视频技术爱好者，前后就职于传统广电巨头和音视频互联网公司，具有丰富的音视频直播和点播相关经验，对 WebRTC、FFmpeg 和 Electron 有非常深入的了解，😄公众号：玩转音视频。同时也是 CSDN 博客专家、华为云社区云享专家、签约作者，欢迎关注我分享更多干货！😄
Elasticsearch-doc基本操作
一、文档基本操作参考文档https://www.elastic.co/guide/en/elasticsearch/reference/7.11/docs.html本文是基于elasticsearch 7.11.2版本1.1 索引文档1.1.1PUTput方式添加文档，如果不存在，则创建，如果存在，则更新，PUT方式添加文档，必须指定id。如果没有ID，提示以下错误。1.1.2 POSTPOST方式添加文档，如果不存在，则创建，如果存在，则更新，POST方式添加文档，可以不指定ID，有Elasticsearch自动生成id。可以使用以下API，仅添加文档，如果ID重复，提示错误1.2 获取文档使用 GET 从特定索引中检索文档及其源或存储字段。 使用 HEAD 验证文档是否存在。 可以使用 _source 资源仅检索文档源或验证它是否存在。从 my-index-000001 索引中检索 _id 为 0 的 JSON 文档：检查是否存在 _id 为 0 的文档，Elasticsearch 返回状态码 200 - 如果文档存在则返回 OK，如果不存在则返回 404 - Not Found。您可以使用源过滤参数来控制 _source 的哪些部分被返回1.3 更新文档使用指定的脚本更新文档，具体语法参照下图，其中<index>和<_id>都是必须的参数。操作分为三个步骤从索引中获取文档（与碎片绑定）运行指定的脚本。重新索引结果索引一个简单的文档 使用以下脚本更新counter字段为文档添加字段删除文档中的字段可以更改从脚本中执行的操作，例如以下例子，如果tag字段包含green，则此请求删除DOC如果文档尚不存在，则将UPSERT元素的内容作为新文档插入。如果存在文档，则执行脚本：1.4 删除文档有几个可选参数routing、timeout。routing可以指定要删除的文档在那个主分片上，timeout可以指定删除的文档的超时时间，默认为1分钟，超过1分钟报异常。删除与指定查询匹配的文档1.5 获取多个文档按照ID检索文档，如果在请求URI中指定索引，则请求正文中只需要文档ID：默认情况下，每个文档（如果存储）返回_source字段。使用_source和_source_include或source_exclude属性来过滤特定文档返回的字段。您可以在请求URI中包含_source，_source_includes和_source_excludes查询参数，以指定在没有每个文档指令时使用的默认值。
声明式事务讲解| 学习笔记
开发者学堂课程【Java Web 开发系列课程：Spring 框架入门：声明式事务讲解?】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：/learning/course/538/detail/7351声明式事务讲解?内容简介：?一、接口 ?Connection二、配置??sqlSessionFactory三、事务的传播特性四、使用?TransactionTemplate五、选择原则??一、接口 Connection所有超级接口:public intertnos Connection extends Wrapper与特定数据库的连接(会话)。在连接上下文中执行?SQL 语句并返回结果。Connection?对象的数据库能够担供述其表、所支持的?SQL?语法、存储过程、此连接功能等等的信息。此信息是使用?getheMetaData?方法获得的。?注:在配置?Connection?时，?JDBC?应用程序应该使用适当的 Connection?方法，比如?setAutoCommit?或 setTransactionIsolation?。在有可用的 ?JDBC?方法时，用程序不能直接调用?SQL?命令更改连接的配置。默认情况下，?Connection 对象处于自动提交模式下，这意味着它在执行每个语句后都会自动提交更改。如果禁用了自动提交模式，那么要提交更改就必须显式调用 commit?方法;否则无法保存数据库更改。?使用?JDBC21?核心?API?创建的新?Connection?对象有一个与之关联的最初为空的类型映射。用户可以为此类型映射中的?UDT?输入一个自定义映射关系。在使用?ResultSet.getObject?方法从数据源中获取?UDT?时，?getObject?方法将检查该连接的类型映射是否有对应该?UDT?的条目。如果有，那么?getObject?方法将该?UDT?映射到所指示的类。如果没有条目，则使用标准映射关系映射该?UDT?。用户可以创建一个新的类型映射，该映射是一个?java.util.Map?对象，可在其中创建一个条目，并将该条目传递给可以执行自定义映射关系的?java.sql 方法。在这种情况下，该方法将使用给定的类型映射，而不是与连接关联的映射。例如，以下代码片段指定??SQL?类型 ATHLETES 将被映射到?Tava 编程语言中的?Athletes?类。该代码片段为?Connection ?对象 con 获取类型映射，并在其中插入条目，然后使用新的条目将该类型映射设置为连接的类型映射。?二、配置 sqlSessionFactoryclass="org.mybatis.spring.SqlSessionfactoryBean">value="classpath.mybatis.cfg.xml"/>class="org.mybatis.spring.SqlSessionTemplate">??三、事务的传播特性I.PROPAGATIONREQUIRED?:如果存在一个事务，则支持当前事务。如果没有事务则开启。2.PROPAGATIONSUPPORTS?:如果存在一个事务，支持当前事务。如果没有事务，则非事务的执行。3.PROPAGATION MANDATORY?:如果已经存在一个事务。支持当前事务。如果没有一个活动的事务，则括出异常。4.PROPAGATION REQUIIRESNEW?:总是开启一个新的事务。如果一个事劳已经存在，则将这个存在的事务持起。5.PROPAGATION NOT SUPPORTED?:总是非事务地执行，并挂起任何存在的事务。6.PROPAGATIONNEVER:总是非事劳地执行，如果存在一个活动事务，那抛出导常。7,PROPAGATION NESTED:如果一个活动的事务存在。则运行在一个嵌套的事务中，如果没有活动事务，则按 TransactionDefinition.PROPAGATION REQUIRED 属性执行。??四、使用 TransactionTemplateTranaaetionTeplate?采用与?Spring?中别的模同样的方法，如 TdheTemplate?。它使用调机制，将应用代码从样板式的造源获取和舞能代码中解放出来，这样写出的代码座目的驱动的，把精力集中在开发者想要做的事情上。注意：效像你马上要在后面的例子中看到的那样使用 TramenctionTenplate?绝对会增加你的代码与?Spring?的事务框架和API间的耦合。到底编程式事务管理是不是适合你的项目需要由你自己来决定。应用的代码必须在一个事务性的上下文中执行，这样就会像这样一样显式的使用?TramactionTenplate?你作为一个应用程序员，会写一个 TransactionCallback?的实现，通常会用名类来实现)这样的实现会包含所以你需要在该事劳上下文中执行的代码。然后你会把一个你自己实现?TransactioeCallback?的实例传运给TransnctionTemplate暴露的excoutel.)?方法。publie class SimpleService implements Service{single TransactionTemplate shared anongst all methods in this instance private finnl TransactionTemplate transactionTemplateuse constructor injectian to supply the PlatformTransactionManager public SimpleService(PlatformTransactionManager transactionMenager)Assert.notNull(transactionManager,"The'transactionManager’ argunent mst not be null.") this.transactionTemplate=new?TransactionTemplate(transactionManager);publie Object someServiceMethod)){return transactionTemplate.execute(new TransactionThe code in this method executes in e transactional context. public Object doInTransaction(TransactionStatus status)( updateOperation1()return resultOfUpdateOperation2();}}}}??五、选择原则选择编程式事务管理还是声明式事务管理当你只有很少的事务操作时，编程式事务管理通常比较合适。例如，如果你有一个?Web?用，其中只有特定的更新操作有事务要求，你可能不用使用?Spring?或其他技术设置事务代理。这种情况下，使用 TransaotionTemplate?可能是个好办法。只有编程式事务管理才能显式的设置事务名称。另一方面，如果你的应用中存在大量事务操作。那么声明式事务管理通常是值得的。它将事务管理与业务逻辑分离，而且在?Spring?中配置也不难。使用?Spring?，而不是?EBCMT?，声明式事务管理在配器上的成本极大地降低了。?
阿里云互联网中间件：让企业实现业务云化持续创新|学习笔记
开发者学堂课程【上云须知 - 全面了解阿里云能为你做什么：阿里云互联网中间件：让企业实现业务云化持续创新】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：/learning/course/381/detail/4772阿里云互联网中间件：让企业实现业务云化持续创新让企业实现业务云化持续创新经过阿里巴巴多年真实场景洗礼的阿里云互联网中间件正式推出，阿里云互联网中间件通过成熟稳定的企业互联网架构平台，高效开发应用程序，无缝实现应用和终端通信，数据存储无限水平扩展，让您的企业轻松面对众多的不确定任务需求，海量并发的用户访问，纵横交错的系统架构，实现业务员化持续创新。阿里云互联网中间件由企业级分布式应用服务以 Darth 分布式关系型数据库服务，BRTS 消息队列 MQ，业务实时监控服务 arms，云服务总线 CSB 这五剑客组成。阿里云 EDAS 基于应用为中心的中间件 pass 平台，为您轻松构建并托管分布式应用，采用分布式服务框架，脱离出相似业务逻辑并单独部署，您只需借助 RPC 框架进行服务的远程调用，EDAS 每天可处理 3000 亿次调用服务，生成万亿条业务调用链，同时拥有完善的健全体系，为您每一次服务调用保驾护航。EDAS 的自动压测通过容量规划，让您从容应对流量高峰，同时对 CPU 内存和负载实时监控，您只需要轻松勾选并能实现对应用的秒级扩容和缩容，更拥有强大的鹰眼监控系统，为您分析每一次系统调用，消息发送和数据库访问，精准发现您系统的瓶颈和隐患，同时针对服务的 qps 响应时间和出错率进行全方位的监控。EDAS 自主研发拥有多项专利的分布式事务服务 TXT，支持大多数关系型数据库，消息等多种事务源和 EDAS 服务调用。在保证 ACID 原则下，长分布式事务性能提升10倍。曾经的单机数据库瓶颈造成的各种问题，让企业苦不堪言。D2DS 将多个单机数据库集成管理起来，以分布式集群方式提供服务，并行处理数据库请求。每天可帮您处理 800 至 1000 亿次数据库请求，DRDS 按需在线平滑扩缩容，只需要动动鼠标选择自己需要的配置即可，而且 DRDS 存储集群节点达 200+，峰值 qps 达 150 万+。同时实现应用透明的读写分离，做到业务零代码改动。全面兼容 MySQL 协议和语法，具备全生命周期的数据库运维管控能力。在双十一狂欢的同时，您是否想过如何在瞬间海量交易请求的冲击之下，保持平台各个电影消息畅通，MQ就是解决的秘方。它实现分布式计算场景中所有异步解耦功能，像一个万能变压器，不管前端多大电流输入，后端出来都是平稳的流量。MQ 更支持消息海量推进，单 Tokyo 就可容纳 100+ 亿条信息。平衡利用处理得到缓冲，确保系统不崩溃。经过双十一严苛场景验证，支持每天流转几千亿条消息，您只需钻研用户需求而不用担心暴涨的应用请求对系统的冲击。随着您的企业的业务增长，数据也将剧增，如何实时处理数据满足您企业业务监控，arms 在业务实时监控领域绝对是你梦寐以求的神器，它经历多年打磨，每秒处理的业务数据值超过 15 GB，后台数据结果每秒峰值写入超过 5 GB，谁说进入新的互联网技术就要彻底抛弃企业原有的以及第三方的系统，CSB 基于高可用分布式集群技术构建的服务 API 开放平台，贴心帮您融合内外新旧系统，兼具服务化 API 的组织和安全管控。与此同时 CSB 支持多实例的级联服务链路，让您从容应对更为复杂的网络结构和隔离策略。阿里云互联网中间件产品，经过阿里内部近10年使用和沉淀，支撑了整个阿里巴巴99% 以上的大规模应用。采用阿里云互联网中间件后，中石化90 天快速搭建了工业品采购平台 100 克，实现了从 0 到 1 的蜕变。近一年累计成交 137 亿。芒果 TV4 四十天完成跨年晚会互动系统构建。互联网+让企业更贴近用户，阿里云互联网中间件配合你的步伐洞，察用户的需求让您轻松拥抱云计算，快速实现业务尝鲜和资源配置效率最大化。
中台辨析：架构的演进趋势（2）
（四）对更快的探索：敏捷开发、DDD和微服务对效率的探索涌现出了更多的软件工程方法、设计方法，不同方法间逐渐形成组合，从单一方法到“组合拳”也是一个很有意思的过程。不满足于软件工程的进步，90年代，敏捷开发的思路开始出现。2001年，在美国犹他州雪鸟滑雪胜地，敏捷方法发起者组织敏捷聚会并起草大名鼎鼎的《敏捷宣言》，“敏捷”开发也在这次聚会上正式定名。虽然目前对敏捷开发的认识还不是很一致，但大体上的开发流程，可以在网上找到很多类似图3的介绍：敏捷开发的矛头可谓直指“瀑布模型”，大多数讲敏捷开发的书几乎都以此开头。笔者并非一个敏捷实践者，因此也无法深入讨论这一方法的优缺点，但是从对其实现过程的介绍来看，企业架构的设计显然没有包含在敏捷过程中，敏捷强调的是产品和用户维度，而且敏捷的“轻文档”理念与企业架构已有的“重文档”方法之间也是有矛盾的。由于研究的人很多，敏捷开发在软件过程管理和软件设计方面都有较快发展。尽管有人质疑其效果，但是据称全球排名第11的资产管理公司——荷兰国际集团（ING）是在全公司推行敏捷开发的，该公司拥有员工113,000人，在全球50个国家为6千多万客户提供金融服务。除了对过程的加速，架构设计方法本身也有创新。2003年，Eric Evans提出了DDD，也即领域驱动设计方法，该方法的特点是在需求分析、软件设计方面的一体化实现，通过领域模型直接形成可以指导到“类”设计的软件架构模型。但是DDD明显只是一个软件架构设计方法，而非企业架构设计，并且，DDD领域的大师级人物Vaughn Vernon认为企业级是无法从顶层直接设计的，只能在领域建模完成后，逐个领域地进行尝试性融合。Eric Evans也在其书的结尾对“总体规划”方法表示了一种委婉的不信任。DDD最经典的架构图如图4和图5所示：Eric Evans曾提出该方法主要面向敏捷过程，二者其实在方法层面有相似之处，都强调快速由需求进入开发过程，也都注重对模式的运用。但是因为DDD方法掌握起来有一定难度，因此并没有真的随着敏捷开发“火”起来，倒是借了另一种架构风格的“东风”，微服务。微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格注重用具备独立数据库的微服务来替代原有的单体应用设计方式，每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是Restful API。这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。从理念上看，极具灵活性、快速响应能力、可复用性和扩展性，案例上更是有传奇公司Netflix做标杆。但是这种架构风格并没有很好地处理它的前身SOA遗留的问题，就是如何确定服务的颗粒度，于是，不温不火快10年的DDD派上用场了。DDD这种可以直接按照限界上下文导出数据和行为相结合的设计结果的方法，很适合推微服务一把。Chris Richardson在其著作《微服务架构设计模式》一书中就专门花了两章来介绍DDD与微服务的结合。在对更快的探索中，敏捷开发、DDD和微服务提供了一种包括软件过程、架构设计和工程实现在内的“组合拳”，当然，这并不意味着所有企业都要这么用，只是一种参考而已。此外，求快的同时，这些方法也都欠缺对企业架构的关注，它们都是可以提升IT开发效能的有力工具，但是，在To B端，仍需要一种可以面向企业级能力建设的方法作为总体导引。（五）小结：行路难架构设计的思路到上个世纪70年代才逐渐开始发展出来，软件行业希望也能像工业、建筑业一样具有行业级的设计原则、标准，从而使高质量软件的产出得到保证。但是，到目前为止，架构之路殊为不易，还没有哪种方法升华为举世公认的原则或者榜样。软件工程到今天才算年过半百，还是个比较年轻的领域。从“瀑布模型”进化到“螺旋模型”大约用了20年；敏捷开发快20岁了，DDD也有17岁；微服务虽然很年轻，才5岁，但是它的前身SOA是1996年诞生的。企业架构从Zachman模型诞生到现在是33岁，而TOGAF到现在也就25岁，只相当于软件工程的一半年纪。如此说来，这些方法以其要服务的目标领域而言，都还是只是刚刚进入“青年”这个水平。然而上述方法我们至今仍在对其某一方面大加挞伐，没有一个是“银弹”，没有一个不曾被人骂做“坑”。但是贵在探索和坚持，这些方法经历时间的洗礼，仍未褪去“稚嫩”，仍需要“呵护”与反复实践才能健康成长。?现代社会的快节奏对架构的积累确实是一个挑战，“快”原本应该是目标，而今成了方法。我们对很多架构方法的理解尚不深入，对其应用也需要对方法创立者的初衷深加体会，比如，敏捷方法的创始人、“敏捷宣言”起草者之一的Jeff Sutherland在《敏捷革命》一书中提到其灵感来源的“OODA”方法，建议在每个冲刺中都要完整使用，但在各类敏捷书籍中却鲜有提及；Vernon也提到，无论是对敏捷方法还是对DDD而言，“知识获取”都至关重要，但是“知识获取”显然需要积累；即便是对口诛笔伐的“瀑布模型”，也一样存在众多误解。抛去这些争议不谈，我们至少可以从软件工程与企业架构的发展历程中看到这样两个个趋势：一是关注点从软件架构向企业架构的进化，也就是对软件设计核心目标的认识，软件设计绝不是“先写了再说”，也不一定是越快越好；二是不同方法之间更明显的结合趋势，面向企业的软件设计是一个很复杂的事情，既然很难由某一个方法自己搞定，那就“抱团取暖”吧。
优秀API的设计原则与实例实现RESTful（6）
HTTP/2和Protobuf的组合——gRPCgRPC源于被称为Stubby的Google内部项目，Google内部大量使用Stubby进行服务间通信。作为gRPC的前身，Stubby大量依赖Google的其他基础服务，所以不太方便开放出来给社区使用。随着HTTP/2的逐步成熟，2015年初Google开源了gRPC框架。截至2017年12月，gRPC已经发布了1.7.3版本，并且被CNCF（云原生计算基金会）所收录。gRPC在ETCD/Kubernetes上得到了大量使用。gRPC是基于HTTP/2设计的，因此也继承了HTTP/2相应的诸多特性，这些特性使得其在移动设备上表现得更好，更节省空间、更省电。gRPC目前提供的C、Java和Go语言版本分别是grpc、grpc-java、grpc-go，其中C版本支持C、C++、Node.js、Python、Ruby、Objective-C、PHP和C#。说了这么多，gRPC到底能够给我们提供哪些优势呢？·?gRPC默认使用Protobuf进行序列化和反序列化，而Protobuf是已经被证明的高效的序列化方式，因此，gRPC的序列化性能是可以得到保障的。·?gRPC默认采用HTTP/2进行传输。HTTP/2支持流（streaming），在批量发送数据的场景下使用流可以显著提升性能——服务端和客户端在接收数据的时候，可以不必等所有的消息全收到后才开始响应，而是在接收到第一条消息的时候就可以及时响应。例如，客户端向服务端发送了一千条update消息，服务端不必等到所有消息接收完毕才开始处理，而是一边接收一边处理。这显然比以前的类HTTP 1.1的方式提供的响应更快、性能更优。gRPC的流可以分为三类：客户端流式发送、服务器流式返回，以及客户端/服务器同时流式处理，也就是单向流和双向流。在我写这本书的时候，Dubbo 3.0正在酝酿中，其中一个显著的变化是新版本将以streaming为内核，而不再是2.0时代的RPC，目的是去掉一切阻塞。·?基于HTTP/2协议很容易实现负载均衡及流控的方案，可以利用Header做很多事情。同时，gRPC也不是完美的。相比于非IDL描述的RPC（例如Hession、Kyro）方式，定义proto文件是一个比较麻烦的事情，而且需要额外安装客户端、插件等。另外HTTP/2相比于基于TCP的通信协议，性能上也有显著的差距。下面通过一个简单的例子来理解一下gRPC的使用方式。假设我们要开发电商中的产品服务，通过id获取产品的信息，主要步骤及实现代码如下。（1）定义proto文件。
syntax = "proto3";//声明支持的版本是proto3
option java_multiple_files = true;//以外部类模式生成
option java_package = "com.cloudnative.grpc";//声明包名，可选
option java_outer_classname="ProductProtos";//声明类名，可选
message ProductRequest{
int32 id = 1;
}
message ProductResponse {
int32 id = 1;
string name = 2;
string price = 3;
}
service ProductService{
rpc GetProduct(ProductRequest) returns(ProductResponse);
}（2）生成相关类。可以采用Protobuf中介绍的方法，在命令行执行protoc生成相关代码。如果使用Maven，则可以通过Maven插件实现。
<build>
<extensions>
<extension>
<groupId>kr.motd.maven</groupId>
<artifactId>os-maven-plugin</artifactId>
<version>1.5.0.Final</version>
</extension>
</extensions>
<plugins>
<plugin>
<groupId>org.xolstice.maven.plugins</groupId>
<artifactId>protobuf-maven-plugin</artifactId>
<version>0.5.0</version>
<configuration>
<protocArtifact>com.google.protobuf:3.5.1:exe:${os.detected.classifier} </protocArtifact>
<pluginId>grpc-java</pluginId>
<pluginArtifact>io.grpc:protoc-gen-grpc-java:1.8.0:exe:${os.detected. classifier}</pluginArtifact>
<protocExecutable>/usr/local/bin/protoc</protocExecutable>
</configuration>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>compile-custom</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>在pom.xml中配置，并且执行mvn compile命令会在target/generated-sources中生成相关类，可以将相关类移到src /main/java目录下备用。（3）服务端实现代码。一是，实现ProductService。
public class GRPCServer{
private static final Logger logger = Logger.getLogger(GRPCServer.class.getName());
private final int port;
private final Server server;
public GRPCServer(int port){
this.port=port;
this.server = ServerBuilder.forPort(port)
.addService(new ProductService())
.build();
}
/** Start serving requests. */
public void start() throws IOException {
this.server.start();
logger.info("Server started, listening on " + port);
Runtime.getRuntime().addShutdownHook(new Thread() {
@Override
public void run() {
// Use stderr here since the logger may has been reset by its JVM shutdown hook.
logger.info("*** shutting down gRPC server since JVM is shutting down");
GRPCServer.this.stop();
logger.info("*** server shut down");
}
});
}
/** Stop serving requests and shutdown resources. */
public void stop() {
if (server != null) {
server.shutdown();
}
}
/**
* Await termination on the main thread since the grpc library uses daemon threads.
*/
private void blockUntilShutdown() throws InterruptedException {
if (server != null) {
server.awaitTermination();
}
}
/**
* Main method. This comment makes the linter happy.
*/
public static void main(String[] args) throws Exception {
GRPCServer server = new GRPCServer(8888);
server.start();
server.blockUntilShutdown();
}
}（4）客户端实现代码。
public class GRPCClient {
private static final Logger logger = Logger.getLogger(GRPCServer.class.getName());
public static void main(String[] args) {
ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 8888)
.usePlaintext(true)
.build();
ProductServiceGrpc.ProductServiceBlockingStub blockStub=ProductServiceGrpc.newBlockingStub(channel);
ProductResponse response=blockStub.getProduct(ProductRequest.newBuilder().setId(111).build());
logger.info(response.getName());
response=blockStub.getProduct(ProductRequest.newBuilder().setId(2).build());
logger.info(response.getName());
}
}上面是一个简单的实现，关于流式RPC可以参考官方的例子。?本文节选自《持续演进的Cloud Native：云原生架构下微服务最佳实践》一书,王启军 著。电子工业出版社出版。
public class ProductService extends ProductServiceGrpc.ProductServiceImplBase{
private static final Logger logger = Logger.getLogger(GRPCServer.class.getName());
@Override
public void getProduct(ProductRequest request, StreamObserver<ProductResponse> responseObserver) {
logger.info("接收到客户端的信息:"+request.getId());
ProductResponse responsed;
if (111==request.getId()){
responsed=ProductResponse.newBuilder().setId(111).setName ("dddd").build();
}else {
responsed=ProductResponse.newBuilder().setId(0).setName("---").build();
}
responseObserver.onNext(responsed);
responseObserver.onCompleted();
}
}二是，实现server代码。
