聊天服务项目公告和概述
聊天服务项目公告和概述
原文：https://medium.com/hackernoon/chat-service-project-announcement-and-overview-92283fe80d93
这篇文章是一个关于 聊天服务项目的设计和目标的简短概述。它在 ES6 中被写成 Node.js 模块，并通过 npm 提供 。这个软件本质上是一个额外的语义层 ，通过一个集成 插件为任意发布/订阅系统服务。顾名思义，它使用基于房间 的聊天中的熟悉概念。聊天服务项目的主要目标是让实时 API 的创建与 REST API 一样。因此，就像任何 REST 服务器一样， 被设计成首先在你自己的环境中运行，并且像 一样可定制和可扩展。现代网络技术，如 SPA 框架，具有惰性加载和/或服务器端渲染，允许 为任何 网络项目轻松使用和集成基于后台连接的 API。
使用这种系统的主要原因是它们能够在一个应用程序中提供各种实时交互信息。(当 REST 架构专注于提供对单个资源的访问或修改时)。一个常见的使用示例 是各种社交互动的实现，如谁在好友列表上在线、谁正在查看特定页面、关于新内容何时可用的通知等。从 T21 的商业角度来看，更好的社会化最终意味着更好的保留。
概观
大多数消息传递系统可以分为两个逻辑部分，即 前端客户端到服务器通道实现和后端 代理。聊天服务被设计成介于这两个部分之间，做类似“连线”的事情。它实现了一个应用层消息传递 协议，在该协议之上，应用数据可以作为 消息进行交换。这与许多其他 应用和低层网络协议中使用的方法相同，它允许 创建定义良好的公共和私有 API。包括 Socket.io 传输 支持，但是由于可插入的集成 架构，可以添加对其他消息传递解决方案的支持。
聊天服务提供的第一件也是最重要的事情是 可靠的房间消息。这是通过一个有序的历史记录来完成的，因此即使 一个以前没有订阅(加入)的客户端也能够获得 消息历史记录。第二层是实时存在和许可层。此外，聊天服务提供了与连接无关的独特用户概念，因此完全支持来自单个用户的独立多个连接。这实质上提供了 自省和可管理性属性。
大多数消息传递解决方案都是为大规模水平伸缩 而设计的，所以主要的挑战是在 实现额外的语义时不要引入瓶颈。聊天服务是作为无状态的微服务 实现的，所以也支持水平扩展。 存储层使用 Redis(或者可选的用于测试的内存存储) ，并且也设计为可通过 Redis 集群扩展。所有数据都 安排在桶中，并且使用 Redis 事务或细粒度锁定 (仅在单个用户状态的一部分上)。这种方法确保了 数据的一致性，而不会在 store 端引入瓶颈。此外，还提供了额外的操作和事件，以便 报告和修复由于各种 后端基础设施故障导致商店无法更新的情况。
另一件重要的事情是扩展和/或定制的能力，因为聊天室模式是一个很好的起点，但绝对不是终点。定制可以通过聊天服务 协议事件处理程序的钩子或者通过调用服务器端 API 来完成。因此，可以使用其他 模式，如将服务器作为消息发射器的只听房间 。例如，当添加新内容或修改旧内容时，POST/PATCH 处理程序可以通过服务器端 API 发出房间消息。钩子只是返回承诺的 JavaScript 函数，所以 可以实现任意复杂的异步逻辑。一般来说 可以从客户端做出的每个动作都可以通过 API 从 服务器做出。而且每个动作都有前后挂钩，让 在里面运行一个定制的逻辑。
初速电流状态
这是一个麻省理工学院许可的开源项目。至于 0.10 版本， 项目有 99.5%行的良好测试覆盖率，定义良好的公共 API 文档和合理的内部架构。这么多的 突破性的改变在 1.x 发布之前不太可能发生。但是按照 semver 的定义，它仍然处于测试阶段。也欢迎任何反馈 。
黑客中午是黑客们下午的开始。我们是 @AMI 家庭的一员。我们现在接受投稿并乐意讨论广告&赞助机会。
要了解更多信息，请阅读我们的“关于”页面 , 喜欢/在脸书给我们发消息，或者简单地，发推文/DM @HackerNoon。