Squbs （与“立方体”押韵）是一个开源项目，能在大规模的级别上实现 Akka 应用程序的标准化和运维。它遵循响应式原则，使应用程序每天处理数十亿次交易的同时消耗最少的资源，并且对故障更具弹性。
在过去几年中，应用程序的需求发生了巨大的变化。能处理 GB 级数据、秒级响应的应用程序都 已经过时了。今天，用户期望亚秒级的响应，而数据量则需要以 PB 来衡量。因此，陈旧、低效的软件构建方式正在被响应式编程所取代。
Squbs （与“立方体”押韵）是一个开源项目，能在大规模的级别上实现 Akka 应用程序的标准化和运维。它遵循响应式原则，使应用程序每天处理数十亿次交易的同时消耗最少的资源，并且能更具弹性地应对故障。
Squbs 是一种异步编程模型，以流作为应用程序的核心，视所有输入和输出为事件流。对于近实时地收集和处理大量数据的场景，以及那些侧重数据处理和编排的应用程序，它都非常适合。
Akara Sucharitakul 是 PayPal 首席工程师，也是 Squbs 项目创始人之一。最近 InfoQ 对他进行了采访，探讨了 Squbs 所解决的问题以及迄今为止收到的反馈。
InfoQ: Squbs 适用的理想场景有哪些？
Akara Sucharitakul: Squbs 适用于几乎所有后端场景以及部分前端场景。因此，从一个非理想场景开始更好。如果你要开发一个 CRUD 服务，用来读或写数据库，尤其是同步类型的数据库，那么使用 Squbs 收效甚微。学习新编程范式的成本，再加上处理异步系统的同步接口的成本，会超过你从 CRUD 服务获得的性能增益。当然，如果你已经熟练掌握这种编程模型，那就另当别论了。
Squbs 0.9 中新增的端到端流媒体模型大大助力了高速数据流相关的场景 。从这个意义上讲，无论是作为数据收集器从互联网收集海量数据，还是作为数据处理器以近实时、逐事件的方式处理巨大的数据流，Squbs 都很成功。但这只是 Squbs 的部分适用场景。许多侧重数据处理和编排的应用程序受益于 Squbs 的异步特性，尤其是与 Akka HTTP 的集成。该集成使服务请求可以用纯异步方式执行，同时使资源开销最小并且严格遵循 Akka 的调度模型。
此外，我们看到越来越多的应用程序采用流与事件处理相结合的方式来更新数据存储，这种方式把我们导向了以分布式事件溯源和 CQRS 为特征的现代应用程序设计。
InfoQ: 使用 Squbs 来构建微服务的开发人员提供了什么样的反馈？
Sucharitakul: 我想从两个方面来回答这个问题。首先是关于 Squbs 开发者体验的反馈，其次是关于使用效果的反馈。对于第一个方面，我们必须承认，对于习惯了命令式编程的传统开发人员来说，异步编程就像一头外星野兽。你必须重新学习编程概念，忘掉 20 年前被认为是正确的开发方式，并学习那时被认为是不可理解的新方法。因此，培训、强化和支持成为非常重要的因素。这其实是一个关于人的问题。可能有些开发人员无法成功地完成这个转换。一旦开发人员习惯了这种新的范式，他们通常会变得更加高效，编写的代码中错误更少，而且同一个功能需要维护的代码也大大减少。
对于第二个方面，使用 Squbs 都取得了非凡的效果。根据反馈，所有使用 Squbs 的应用程序都在生产环境中具有了更高水平的弹性。除非出现系统故障，否则应用程序会持续正常运行。此外，我们通常会看到节省约 50％至 80％的成本。在一个案例中，处理时间缩短了 80％。但更为常见的是，应用程序处理相同的数据流量大约仅需要原先 80％的计算资源。这通常意味着节省 80％的基础设施成本。
因此，总的来说，尽管开发人员开始会遇到困难，但最终会很高兴，因为他们的辛勤工作都取得了良好的结果。
InfoQ: Squbs 是基于 Akka 工具包构建的，对于 Akka 和 Squbs 的集成，您打算推荐一些最佳实践吗？
Sucharitakul: 是的，但答案可能会很长。我们有一个包含最佳实践以及规则的完整列表，用于开发人员的培训。其中常见的是诸如“不可变第一”或“阻塞就是犯罪”之类的时髦用语。但还有更多其它内容。我们很快就会在 Github 上发布 Squbs 的培训模块。第一章将会讨论许多这类注意事项。
除了基础内容，我还会推荐一些关于流和 Actor 的指导原则。简而言之，除非有其它正当理由，否则应用程序的核心应该使用流，周边工作使用 Actor。虽然有人会争辩说流在 Actor 上执行，并且在 Squbs 中流总是被包含在 Actor 中，但我们不能用这种方式思考应用程序。一个系统会接受输入、处理数据并产生输出。只要允许，流始终应当作为与集成点对接的应用程序的核心。Actor 依然非常有用，它可以持有状态，也可以作为通用组件进行非流方面的处理，比如作为多个流之间通信的模式之一。
更多信息请参考项目的 GitHub 库
评论