SCF—BSS3.0 的“公路网”

SCF，或者叫做流式计算框架，是 BSS3.0 分布式化、消息化的核心技术，是实现应用与应用、应用与数据解耦的重要工具，是保障系统数据安全的基础框架。

在 BSS3.0 之前，传统的计费系统架构，基于文件作为数据流的承载设施，应用和数据、应用和应用的耦合度较高。应用部署节点对单机的性能和稳定性要求都较高，需要使用成本较高的小型机。扩展很不方便，成本也较为昂贵。

随着电信用户规模的快速增长，对系统承载能力的要求也越来越高。同时电信集团也对硬件成本的控制也越来越严格。为了解决不断增长的用户规模带来的系统扩容的压力，和硬件成本受限的矛盾，计费系统需要进行应用、数据之间的解耦，实现分布式化部署，通过低成本硬件冗余提供高可靠性，还需要支持快速的横向扩展。

通过对业务应用进行分析、对业务数据进行统一抽象。SCF 将应用之间数据流的流转从文件变为消息对象，并且高度可配置，还提供自定义的高效的数据序列化算法，为应用和数据的解耦提供了技术解决方案。在此基础上，针对业务系统分布式化后，业务应用要避免分布式数据库跨库事务、提高分布式内存数据库的本地高速缓存命中率等业务要求，SCF 还允许按分布式数据库分片字段或高速缓存键值字段进行数据发送和消费控制。

同时，SCF 还在数据的安全性、消息的幂等性等方面的都进行了专门设计，以保证计费系统数据的准确性和可靠性。SCF 提供了一组通用、简易的 API，方便应用在不修改业务核心代码的前提下，便捷的接入 SCF。

通过 SCF，BSS3.0 业务应用顺利实现分布式化改造，使得系统的部署方式从集中式变为分布式；数据流的流转从文件模式转为消息模式；系统的扩展方式从垂直扩展变为横向扩展。最终 BSS3.0 成功在湖南等省份上线，运行稳定，得到了客户的高度认可。

用户规模增长带来的挑战

近年来，随着经济和技术的发展，电信的用户规模越来越大。并且由于电信业务越来越偏向数据流量，用户产生的计费话单量级增长速度也在不断加速。与此同时，我们还面临电信对硬件成本越发趋向严格控制的现况。

用户规模和话单量级的增长，以及硬件成本的控制，要求计费系统能够在更便宜的硬件上，理论规模效应，提供更高的性能、更灵活的部署方式，支持快速横向扩展，并且不能降低系统的可靠性和数据的安全性。

传统计费系统的问题

传统的计费系统，存在几个重要问题，制约了系统的弹性扩展能力，使得系统已经难以应对用户和业务量的迅速增长。

应用和应用，应用和数据的高度耦合

传统计费系统，应用之间通过本地文件进行数据传输。应用从哪里取数据，输出的结果存放在哪里都是固定的。这导致应用和数据被绑定在一起，应用和应用之间也由于本地文件数据建立了强关联关系。

昂贵的硬件成本

由于应用和应用，应用和数据之间的耦合过深，需要将计费系统各个业务模块的应用都部署在相同主机上，业务数据也存放在主机上。这就要求主机具备大内存、海量存储、多核心 CPU，同时还需要具备很高的硬件可靠性。为此，通常需要使用小型机来保障服务，而小型机动辄几十上百万的成本非常昂贵。

单点故障风险

即使通过昂贵的小型机提供硬件安全性保证，仍然无法保证硬件的完全安全。由于各模块应用和数据都在相同的主机上，一旦某台主机出问题，这台主机上的所有服务都会受影响，所有数据都存在丢失风险。

为了解决这些问题，新的计费系统需要实现应用和数据的解耦，让各个应用可以独立部署，数据存储可以单独管理；新的计费系统需要使用成本更低的 PC Server，降低系统扩容成本，提高扩容灵活性；新的计费系统需要提供应用和数据的冗余，避免单点故障，保证系统的服务可靠性和数据安全性。

实现应用和数据解耦的典型方案是基于消息中间件，将数据单独管理使用。但是主流的开源消息中间件，如 RabbitMQ，Kafka，RocketMQ 等，无法同时满足计费系统的高可靠、高性能、幂等性和严格时序的要求。

同时从工程实施难度和灵活性的考虑，对旧的计费系统的每个模块进行单独改造，是不安全和不现实的。需要有一个分布式计算框架来提供统一的接入方案，实现这些诉求。但是市面上并没有一个广泛接受的开源的 C++分布式计算框架，且这些框架通常对业务应用有各种限制，比如需要业务应用主动去修改业务框架、要求业务处理完全无状态等。

为此，我们基于消息中间件，结合现有计费系统代码实际情况，设计打造了一套流式计算框架——SCF，来帮助新的计费系统解决旧的计费系统的相关问题。

SCF 面前的困难

SCF 的设计工作并非一帆风顺。虽然找到了旧的计费系统的痛点，明确了新的计费系统的核心诉求，但是 SCF 需要承担怎样的角色，实现哪些功能，采取什么样的技术方案都存在很多困难。

如何实现应用和数据的解耦

应用和数据的解耦是系统分布式的基础。消息中间件是实现应用和数据解耦的典型方案。但是计费系统在数据的使用上有着严苛的要求。不仅要保证数据的安全可靠，访问得高效，还要保证消息消费的幂等性和严格有序。而不管是 Kafka，RabbitMQ，还是 RocketMQ，都在这几个方面各有取舍。不能简单地直接拿消息中间件进行计费系统应用和数据的解耦。

如何保证数据和应用的安全可靠

由于计费系统的特殊性，对数据的安全性，不仅要求消息中间件保证消息的安全性，对业务系统的消息生产者和消费者也有着很高的要求。

如何满足系统的性能要求

相比本地文件模式，消息中间件采取网络传输，在时延和 IO 上是存在劣势的。同时 SCF 还必需提供额外的数据安全性保证，提供统一的数据序列化接口，都进一步增加了性能开销。如何在更低的硬件成本下，提供更高的性能，也是 SCF 需要考虑的核心问题之一。

如何降低业务代码改动量，保证项目实施进度

计费系统代码规模很庞大，并且包含大量业务代码，对这些代码进行破坏性改动，会有较大的业务风险，也比较难以保证系统的改造进度。

SCF 提供怎样的接口，计费系统如何尽量少的改动来接入 SCF，对项目整体实施进度有着很大影响。

突破难关，SCF 的关键技术特性

>>>>解耦，时序性保障

SCF 将消息中间件作为底层设施之一，将应用通过文件进行数据流转的方式改造为通过消息进行数据流转。每个应用不再需要关心哪些应用会发送过来数据，不需要关心自己要把数据发送给哪个应用，而是通过独立的数据管理集群进行消息的中转和使用。

为了避免业务模块和特定的消息中间件实现耦合，也为了简化业务代码改造，SCF 定义了一个中间层，让业务代码以更抽象的方式进行数据的生产和消费，而不需要关心底层是否是消息中间件，或具体是哪种中间件实现。

SCF 在自己的中间层中，还根据业务需求提供了更严格的消息时序性保证：SCF 不依赖消息中间件，自行管理队列信息以及生产者发送数据时的队列选择算法。可以特定业务字段进行队列选择；支持根据复数字段进行二次队列选择，以满足业务模块更复杂的数据发送要求。

>>>>数据安全

除了消息中间件自身提供的数据安全机制，SCF 在业务端的数据生产和消费流程也增加了额外的数据安全策略。

在消息发送端，通过自动重试+异常数据通过分布式缓存和文件系统的双重持久化机制，辅以异常数据自动回收机制，保证生产端的数据不会丢失。

而在消费端，计费系统要求数据不能重复消费，以免造成重复扣费等。通过归纳分析业务系统发送端和消费端所有可能导致重复消费的场景，SCF 设计了一套幂等性检查流程。SCF 通过分布式缓存系统记录消息消费进度，发送端进行消息发送的连续性编号，消费端进行消息消费连续性检查，最终实现消费排重，达到幂等性的要求，保证了线上系统消息消费 0 重复。

>>>>性能保障

消息中间件自身只提供了单条消息的收发接口，为了满足计费系统的性能要求，SCF 提供了批量消息收发接口，来减少话单的平均处理时延，提高系统的吞吐量。

进行数据的收发时，计费话单和中间件消息之间需要进行序列化和反序列化。在调研测试了 Protocol Buffers 和 JSON 序列化协议后，两者在性能、灵活性、复杂性上各有优劣，Protocol Buffers 虽然性能优异，但是灵活性太差，不易维护。JSON 则是性能和数据压缩率较差。最终 SCF 自行实现了一个二进制序列化协议，在提供 Protocol Buffers 同等级性能的同时，报文字段可弹性添加。

通过这些措施，同等测试场景下，消息中间件单进程性能在 1000 话单/秒左右，而 SCF 可以达到 5000 话单/秒。

>>>>易于接入

SCF 为了实现消息发送消费的有序和幂等，为了数据安全，为了尽可能提高性能，内部包含大量复杂的处理代码。BSS3.0 的业务应用也非常繁多，大量的业务逻辑不能轻易修改。

这就需要 SCF 提供合适的接口，既要简化应用接入方式，又不能牺牲 SCF 的各项功能性以及使用的灵活性。

在分析了业务应用数据使用上的共性，SCF 将话单抽象为事件，话单包含的数据抽象为事件的属性。对数据的读写进行了统一抽象，业务应用只需要在发送和消费时，在内部数据和 SCF 事件对象之间进行一层转换，不触动核心业务逻辑，不关心消息的发送目标和消费来源，就可以快速接入 SCF。

SCF 带来的改变

新计费系统通过 SCF，解决了传统计费系统的诸多问题，为适应用户和业务规模的不断增长打下了良好的基础。

>>>>系统承载规模

传统计费系统每月处理话单在十亿级，基于 SCF 分布式化后的新计费系统，已在多省承担百亿级话单。

>>>>系统性能

新的计费系统处理性能可以达到 40000+TPS，相比旧的计费系统提升超过 50%。并且新的计费系统采取 SCF 实现分布式后，系统可以在不调整业务规则的前提下，继续扩容来提高系统性能。

>>>>系统扩展性

传统计费系统进行扩容时，是垂直扩展的，需要以小型机为单位进行扩容，需要在机器上部署整套计费系统，需要重新规划网元等，需要花费数天时间。而采取 SCF 后，应用之间解耦，可以只对必要的部分应用进行横向扩展，可以采取更廉价的 PC Server 部署应用，扩容只需要重新规划消息中间件和生产消费规则，可以在数小时内完成系统整体扩容。