5G 融合计费系统架构设计与实现(一)
随着5G商用临近，5G的各个子系统也在加紧研发调试，本人有兴全程参与5G中的融合计费系统(CCS)的设计、开发、联调工作。接下来将用几篇文章介绍我们在CCS实现过程遇到的挑战与架构设计的考量。相信这些宝贵的经验可以适用于更广的软件系统，免于重复地陷入软件开发的焦油坑。
5G系统由3Gpp定制统一的架构和协议规范，这也是电信行业一直以来通行的作法。不同的是，5G以前的规范3Gpp总是喜欢独树一帜，比如最出名的DCC(Diameter Credit Control)协议。虽然二进制的格式封装可以带来极佳的性能，但这个协议应用的范围也十分有限，仅限于电信行业。
5G规范从一开始，3Gpp就一改以往的风格，极力与目前主流的技术进行匹配，甚至不惜重构整个通信系统。接下来我们会听到很多熟悉的词汇，包括：微服务、注册与发现、Http2、JSON、RESTFul、容器化、微服务编排等等。没错，新5G系统在尽一切可能拥抱最新的技术潮流。正由于这个原因，在设计新的5G CCS时，我们发现以前的技术储备全都用上了。这对于一个新系统来说极大地降低了原始开发的风险，在真正动手写代码之前，我们就已经知道项目一定会成功。这点对于新系统的研发至关重要！
一切从微服务架构说起……在微服务架构兴起前，大部分应用软件系统都采用单体应用架构。如下图所示，单体应用有他的优势——简单。但也有他的缺点，下面这段引自Introduction to Microservices，作者 Chris Richardson。
"迈向单体应用的地狱，不幸的是，这个简单的方法有巨大的限制。成功的应用会随着时间推进，变得越来越大。在每次需求更改或者功能增加时，你的开发团队会实现更多的业务功能，这意味要增加很多行代码。在几年后，你的简单的应用将会成长为一个巨大的单体应用。为了提供一个极其简单的例子，我（指作者）最近和一个开发者进行了交流，这个开发者正在写一个工具来分析他们的应用使用的JAR彼此之间的依赖，但是这个应用竟然有数以百万行的代码，我确信一定很多的开发者经过很多年的辛苦努力才创造出来了这样的巨无霸。
一旦你的应用成为一个巨大的、复杂的单体应用，你的开发团队一定会陷入痛苦的泥淖不能自拔，任何对于敏捷开发和交付的尝试最终都会陷入挣扎之中。一个主要的问题是这个应用过于复杂了。它太大以至于对于任何一个开发者都无法完全理解。结果就是，修复bug和正确地实现新功能变得非常困难，并且会消耗大量的时间。更重要的是，这将会趋向于一个向下的螺旋。如果代码库理解起来很困难，那么也就不会给出恰当的改善方案。你最终会得到一个巨大的、难以理解的big ball of mud."
单体应用给我带来更直观的感受是当系统规模达到一定程度时，维护这个系统不断更新、接受新需求是一个恶梦。首先系统的稳定性会受到挑战：一个微不足道的错误，就可能导致整个系统瘫痪，对此可能一点办法没有。其次，系统的可扩展性不够：对于一个应用系统，不断接受千奇百怪的新需求是这个系统具有生命力的向征，但对于一个庞大的旧系统而言，这点又是每个程序员的恶梦。你不知道在一个几十万行代码的系统里面改几行的后果会是什么，也许什么事也没有，也许错误从此埋下，等发现的时候已经造成不可挽回的损失。想像一下因为你改的几行代码，给电信带来几百上千万的费用计算错误，并且不可回退。
解决之道就是微服务架构，同样引用上面同一篇文章的观点：
“微服务架构有很多重要的优点。首先，它解决了复杂性的问题。它将一个本会成为巨大的单体应用分解成一系列服务。在保证整体的功能没有改变的前提下，应用被分成很多的模块或者服务。每个服务都有明确的边界，这种边界是通过远程调用（RPC）或者消息驱动的API来确定的。微服务架构模式强制实行模块化，这种在单体应用中是很难去实现的。结果就是，单个服务开发起来更快、也更容易理解和维护。