文章
Michael Lei · 九月 15 阅读大约需 6 分钟

创建 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微服务的后端,你就拥有了一个非常强大的、高度可扩展的、有弹性的、高性能的应用平台。

0
0 6
讨论 (0)1
登录或注册以继续