创建 QEWD 微服务

如果你读了我之前介绍QEWD微服务的文章，希望你会渴望了解如何使用它们。  所以在这篇文章中，我将解释你需要知道的东西，以便开始使用。

如果你在QEWD资源库中，你会发现目录: 

  https://github.com/robtweed/qewd/blob/master/example/jwt

在我之前关于JSON网络令牌（JWTs）和QEWD的文章中，我用这个示例应用程序来解释如何使用JWTs。  这个示例应用程序还演示了如何设置一个简单的微服务，在这种情况下是一个处理用户认证的服务。  所以，现在让我深入了解一下这个例子应用程序的这方面内容。

如果你想使用QEWD微服务，你也必须使用JWTs--它们提供了一种方法，用户的认证和会话可以被多个独立的QEWD服务器交叉通信和处理。  因此，请看一下启动文件:

   https://github.com/robtweed/qewd/blob/master/example/jwt/startup_file/qe...

你会看到，它将QEWD配置为使用JWT，并定义了用于签署和加密JWT的加密字符串:

           jwt: {
            secret: 'someSecret123'
          },

而且，你可以看到如何定义微服务:

  u_services: [
    {
      application: 'jwt',
      types: {
        login: {
          url: 'http://192.168.1.97:3000',
          application: 'test-app'
        }
      }
    }
  ]

你使用 "u_services "配置属性来定义一个微服务阵列。  每个数组元素指定传入请求的应用程序名称，在本例中是 "jwt"，然后是该应用程序的一个或多个消息类型。  在这个例子中，我们只是指定了一个单一的请求消息类型。"登录"。  对于每个消息类型，你要指定：

• 你希望处理该消息类型的QEWD系统的URL
• 远程系统上的QEWD应用程序名称，它将处理传入的消息

因此，我们的例子启动文件是说，任何传入的名为 "jwt "和类型为 "login "的应用程序的QEWD请求消息将由QEWD系统上名为 "test-app "的应用程序处理，地址是http://192.168.1.97:3000。

当你启动这个启动文件时，它首先要做的是加载一个名为 "socketClient "的内置QEWD模块，该模块将与u_services数组中指定的每个QEWD系统建立一个Web-Socket连接。  如果你在远程QEWD系统上监视QEWD系统日志，你会看到它接受一个标准的 "ewd-register "消息，就像有人在浏览器中启动了test-app应用程序一样--对它来说，没有什么区别。请注意，远程QEWD服务器的启动文件也必须配置JWTs的使用，使用与主QEWD系统相同的加密字符串，例如:

           jwt: {
            secret: 'someSecret123'
          },

加密字符串的值由你决定，但它在所有QEWD主系统和QEWD微服务系统上必须是相同的。

这就是我们的QEWD系统的配置和运行。  现在让我们来看看应用程序。  请看一下:

    https://github.com/robtweed/qewd/blob/master/example/jwt/index.html

我在上一篇关于JWTs的文章中解释了这个浏览器端逻辑的大部分内容，但请看这个文件的第13-34行：它们处理登录表单的提交。  就这个应用程序而言，它只是向启动它并在其上注册的QEWD系统发送一个 "login "类型的消息--事实上，这将由一个微服务处理，这与浏览器端逻辑的开发者无关--如果你以前使用过QEWD，你会认识到这只是一个标准的QEWD消息调用。

然而，由于我们在QEWD系统的启动文件中加入了u_services的配置映射，这个请求将被自动转发到第二个处理用户认证微服务的QEWD系统。  所以现在让我们看看它的处理模块，如果你还记得，根据u_services的映射，它是由一个名为test-app的模块处理的:

     https://github.com/robtweed/qewd/blob/master/example/jwt/microservice/te...

现在，就这个处理程序而言，一个 "login "类型的传入信息可能来自浏览器，所以它被以标准方式处理。 当这个处理函数被调用时，QEWD已经验证并解压/解密了JWT的内容，并通过会话参数将它们作为一个对象提供给用户:

    login: function(messageObj, session, send, finished) {
      // session contains the decrypted JWT payload
    }

所以现在我们可以处理来自用户登录表格的用户名和密码值--这与你在 "传统 "QEWD应用程序中的做法没有什么区别。 在一个适当的生产应用中，我们会使用某种认证服务或数据库，但在这里，为了简单起见，我只是对一个名为 "Rob "的用户做了一个简单的硬编码测试，他的密码是 "secret":

      var username = messageObj.params.username;
      var password = messageObj.params.password;
      if (username === 'rob' && password === 'secret') {
        // successful login in
      }
      else {
        //  unsuccessful login
      }

让我们来处理不成功的登录问题。 就像在 "传统的 "QEWD应用程序中一样，我们使用finished()函数来返回一个错误信息，并释放工作进程:

        return finished({error: 'Invalid login'});

如果登录成功，我们要在会话中添加一些东西（因此也就是JWT）。

• 设置认证标志（对浏览器用户来说，这是在JWT内是看不见的）
• 改变会话/JWT的超时，可能是一个较长的超时，如3600秒

我们还可能想向浏览器传达一些关于登录用户的信息，例如如何显示用户的名字，例如:

        session.userText = 'Rob';

我们可能还想把用户的身份作为一个加密字段存储在JWT中（即对浏览器不可见，但对后端QEWD处理器可见）:

        session.username = username;
        session.makeSecret('username');

然后返回 "登录成功 "的响应消息，并以标准方式释放worker资源:

        return finished({ok: true});

因此，就“登录”这一微服务的开发者而言，这只是一个标准的基于JWT的QEWD消息处理函数。  你既不知道也不关心响应是否被返回给浏览器用户或作为web-socket客户端的QEWD系统。

自动发生的是，响应+修改后的JWT将被返回给QEWD客户系统，而客户系统又会将响应+修改后的JWT转发给浏览器。  就浏览器而言，它已经从与之通信的QEWD系统中收到了它所期望的响应+JWT--它不知道这实际上是由QEWD微服务处理的。

浏览器中的JWT现在包含了用户的身份，是一个秘密的索赔值。  这将在任何后续请求中传达给后端QEWD系统，而后端QEWD系统可能会将其转发给一些不同的QEWD微服务。  只要所有的QEWD系统共享相同的JWT秘密字符串，JWT及其秘密声称就可以被任何QEWD微服务使用。  秘密认证标志被设置为 "真 "的事实意味着用户必须经过正确的认证（通过登录的微服务），而秘密的用户名JWT请求安全地提供了用户的身份，以便针对数据库等使用。

还有一件很酷的事情要注意--我们在例子中使用了finished()函数，但请记住，QEWD也允许你有选择地使用send()函数来发送中间信息。  你会发现，这些信息在整个QEWD微服务中也是被支持的，并被传达给正确的浏览器客户端。  我相信这是QEWD微服务特有的功能。

所以，从开发者的角度来看，这就是定义QEWD微服务的全部内容。  它实际上只是照常工作，QEWD会自动为你处理一切，只需你在QEWD启动文件中定义u_services映射数组。  所有这些都非常简单明了，但是，正如你可能开始意识到的那样，在定义一个复杂的、高度可扩展的QEWD微服务网方面，允许各种可能性。

有了IRIS/Cache作为QEWD微服务的后端，你就拥有了一个非常强大的、高度可扩展的、有弹性的、高性能的应用平台。