如果你读了我之前介绍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微服务的后端，你就拥有了一个非常强大的、高度可扩展的、有弹性的、高性能的应用平台。