The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
一个聊天机器人（或者，正如维基百科所说的，闲聊机器人）是一个以聊天格式与你对话的软件。我们在一些（微）服务中使用聊天机器人，并且它们完全替代了用户界面。我认为这种方法没有什么创新，但是在过去的一年左右的时间里，它被证明非常有效。这就是这篇文章的动机。下面是Rultor聊天机器人在我们这里的工作原理及其好处。
让我先举个例子。看看这个GitHub问题：
我们先看看这里发生了什么，然后再讨论它内部的设计。基本上，我在这里与一个聊天机器人对话。聊天机器人的名字是@rultor（我去年写过关于它的文章）。在1处，我要求聊天机器人发布jcabi-http库的一个新版本。在2处，聊天机器人回应，只是确认任务清楚并且正在执行。在3处，机器人说工作已经完成，耗时九分钟。我们的对话结束了。就是这样。
那么，这有什么特别之处呢？
有一点：没有用户界面。嗯，没有传统的基于网页的HTML/CSS用户界面。没有登录、登出、个人资料、菜单或者类似的东西。Rultor是一个没有网页UI的网络服务。与它交流的唯一方式就是与它的聊天机器人对话。
这有什么好处呢？有几个好处。
这是传统的 Web 系统架构的样子：
skinparam componentStyle uml2 用户 -> [服务] [服务] -> [数据库]
用户给服务发送指令并接收响应。这种通信是通过一个用户界面（UI）进行的，它是一堆 HTTP 入口点，接收来自浏览器的请求并返回 HTML+CSS 响应。或者，如果用户在另一个服务上，请求可能包含一些数据，响应将是 XML 或 JSON 格式的。你懂的；用户是客户端，服务是服务器。
就像在餐厅里一样——你说你想要什么，一个服务员去厨房，等待一会儿，几分钟后拿着意大利炒面回来。你是客户，那位可爱的女士是服务员。
在聊天机器人的情况下，情况就不一样了。看看这个架构：
skinparam componentStyle uml2 用户 -up-> [GitHub] [服务] -up-> [GitHub] [数据库] -up-> [服务]
首先，用户通过 GitHub 提供的 Web 用户界面向 GitHub 发送请求。对于我们而言，这是一个通信中心。然后，服务通过其 RESTful API 连接到 GitHub，并检查是否有任何新的请求。如果找到了新的内容，服务会完成工作，准备一个响应并将其发布到 GitHub。客户端会收到一个有关刚刚发布到票务系统的新响应的电子邮件通知。然后客户端会检查 GitHub 并找到响应。
在餐厅里的情况如下：有一个贴有便签的板子。首先，你写下便签上的内容：“我想吃意大利炒面，上面加帕尔玛干酪和新鲜胡椒粉”（该死，我现在饿得要命），然后将其钉在第15号上。然后，你回到你的桌子上。厨房的厨师检查那个板子并找到你的便签。他做那道意大利炒面，加上帕尔玛干酪、新鲜胡椒、一些罗勒叶和初榨橄榄油…是的，他做得很好…然后把它放在板子旁边。你听到有人宣布第15号订单已准备好。你去那里，拿到食物，回到你的桌子上，享受美食。
关键是再也没有可爱的女士参与其中。没有服务员。有两个与便签通信的角色——你和厨房。厨房是我们的微服务，但它不再是一个服务器。
这两个角色现在完全解耦了。他们互不交谈。而且他们都是通信中心的客户端，这个通信中心可以是 GitHub 或餐厅里的一个便签板。
再次强调，微服务不再是一个服务器。相反，它是一个通信中心的客户端。而且位置的翻转为我们开发者提供了很多好处。
首先，我们不需要太关心我们的用户界面的性能。实际上，我们根本不关心，因为我们没有用户界面。我们关心GitHub上的响应速度吗？实际上并不关心。当用户在GitHub上发布留言时，并不期望我们的聊天机器人能在100毫秒内立即回答。（我相信这是任何合理设计的网络系统应该保证的。）
我们在白板上写了一张便条，我们假设厨房此刻可能在忙其他事情。我们会等待几秒甚至几分钟。然而，如果我向女服务员点了菜，她等了五秒钟才回应，我会非常惊讶。如果她每个问题都这样做，我会开始怀疑她是否一切都好。
我期望用户界面是即时的，而在聊天中，我没有问题让机器人花一些时间回答。这是很自然的。当我们与真人交谈时，我们习惯于有延迟。他们需要一些时间来处理我们的信息、思考并回复。
但用户界面没有这种奢侈。它必须快得像子弹一样；否则，我立即感到沮丧。你也是这样吗？
这种无服务器设计的另一个优点是不需要外观漂亮。没有网页界面，没有HTML，没有CSS，也没有平面设计。也许并非每个人都喜欢这样。大多数非专业用户可能仍然更愿意与一个可爱的服务器对话，而不是把一些纸条贴在公告板上。但是，如果我们面对的是专业的计算机工程师，他们不会那么苛刻。
Rultor没有任何网页界面，用户只需知道它是如何“工作”的。它只是与您对话。您唯一能看到的是它在GitHub上的头像。
这样可以节省大量设计工作的金钱和时间，如果您追求高质量，通常会非常昂贵。如果您的网络服务看起来很普通，大多数用户会认为它的工作也是普通的。许多好的想法由于其用户界面不如人们所习惯的那样令人印象深刻，而简单地夭折了，多亏了所有那些Pinterest和Instagram。
外观漂亮的服务器有更大机会获得更多的小费，对吗？如果没有服务器，我们看不见厨师，我们只能通过食物的质量来判断他或她。
同样道理。通过摒弃界面，我们可以把精力集中在我们正在提供的服务的质量上。我们不会在追求友好上浪费时间和金钱。我们把它们花在了有用上。
如果我们在那个板上有太多的便利贴，我们只需要雇更多的厨师，甚至可能建造另一个厨房，问题就解决了。我们可以处理任何必要的顾客。嗯，只要这个板足够强大，能够处理多个并行用户。
GitHub是一个非常大的平台，拥有数十万用户和项目。如果有太多的请求进来，我们可以向Rultor添加更多的处理节点。请记住，我们不再是一个服务器了；我们是GitHub的客户端。我们决定何时连接到GitHub，并在请求提交时创建响应。
创建一个可扩展的客户端要比创建一个可扩展的服务器容易得多，主要是因为没有人真的等着我们快速作出回应。我们所接收到的请求负载可以更容易地管理，因为我们自己决定何时处理它们。
当你站在客户面前时，大多数错误是不可原谅的，主要是因为它们非常明显。另一方面，当你在厨房里做饭时，没有人能看到你的错误。只有当意面加了太多盐时，他们才会注意到。换句话说，他们将通过你的结果来评判你，而不是你的产生方式。
微服务也是一样的道理。当它作为服务器工作时，我们期望它无缝、立即响应，并以结构化、有序的方式呈现一切。如果出现问题，它就会显示在网页上。最好的情况是404错误，而最糟糕的情况是向用户呈现错误的信息。即使在微服务引擎内部，错误可能不是关键性的，但用户并不知道。用户会根据你的外观来评判你，即使是小错误也不会被忘记。
然而，当你们两个都是消息板的客户端时，你们互相看不到。用户与GitHub进行通信，而微服务与GitHub进行交互。错误不那么明显。相信我，过去18个月中Rultor已经公开使用过很多次了。我们经历了停机时间，遇到了严重的逻辑错误，也遇到了数据损坏。但这些问题很少在网上变得可见。我们只是在服务器日志中看到了它们。用户没有看到。嗯，大部分情况是这样。
由于我们之间有一个通信板，很容易看到我们讨论的完整历史记录，这非常直观。就像 Slack 的聊天历史一样。你可以看到我们从哪里开始，谁说了什么，以及得出了哪些结论。
基本上，你无法在 Web 用户界面中获得这种可见性。嗯，你可能可以创建一个特殊页面来显示“操作历史”，但是谁会去查看呢？而且这些信息会有多么可见和简单呢？最重要的是，这些信息如何与用户界面匹配？
在日志中，你会记录“构建已开始”，但是构建是什么，它是如何开始的呢？我该如何重新开始它？使用哪些按钮和 Web 控件？这些都不清楚。
因此，按时间顺序排列的聊天的可追溯性是无与伦比的。
是的，考虑一下这种方法的未来。如果有一个集中的留言板，用户可以与聊天机器人交流，为什么其他聊天机器人不能彼此交流呢？
忘掉RESTful API吧。只需要一个留言板，聊天机器人在上面发布请求并收集回复。它们完全解耦，可替换，并且非常可扩展。而且，它们的通信协议是可见且可追踪的。正如上面刚刚解释的，它们还有许多其他好处。这对我们来说，无论是用户还是程序员，都更方便监控和创建它们。
也许完全摒弃RESTful API有些极端，但在某种程度上，我相信这种方法是可行的。
我没有过于深入这个想法，但是有些事情已经做了。我们有一个消息平台，允许多个聊天机器人与用户进行交流。它叫做Netbout。这是一个非常原始的网络系统，具有独立的讨论区。简单来说，任何人都可以创建一个新的讨论，邀请几个朋友，在那里发布消息。用户和聊天机器人都可以这样做。
所以，当一个新的候选人想要加入Zerocracy时，我们要求该人填写一个在线表格。当候选人点击“提交”按钮时，一个新的讨论开始了，第一个聊天机器人决定谁应该面试这个人。决定是根据表格中列出的技能来做出的。聊天机器人邀请我们的最优秀的程序员之一进行面试。面试结束后，另一个聊天机器人向候选人解释接下来的步骤，将其注册到我们的数据库中，并开始显示工作的进展情况。
从用户的角度来看，他或她好像在与几个只了解一些简单命令的人交谈。这非常直观，而且易于设计。
我认为聊天机器人是与微服务交互的一种好方法。特别是当用户更或多或少是专业人士时。
附注：插图由Kristina Wheat提供。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 09:57
