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来确定的。微服务架构模式强制实行模块化，这种在单体应用中是很难去实现的。结果就是，单个服务开发起来更快、也更容易理解和维护。
第二，这个架构使得每个服务可以被独立地开发。开发者可以自由地选择合适的技术，只要这个服务满足API交互规范。当然，大多数组织想通过限制技术选项来避免过于无拘无束。然而，这种自由意味着开发者没必要在开始新工程时继续使用过时的技术。当开发一个新的服务时，他们可以选择使用当前的技术。另外，因为服务相对来说很小，那么使用当前的技术重写旧的服务会更加可行。
第三，微服务架构模式使得每个微服务可以被独立部署。当本地的服务发生变化时，开发者不再需要协调这种变化引起的部署问题。只要被测试通过，这些变化就可以被部署。UI团队可以执行AB测试，并且可以快速地迭代UI的变化。微服务架构模式使得持续部署成为可能。
最后，微服务架构模式使得每个服务可以被独立地扩展。为了满足吞吐量和可用性，你可以对每个服务部署任意的实例数量。另外，你可以使用最能满足服务资源要求的硬件。例如，你可以部署CPU密集型图像处理服务到EC2 Compute Optimized instances，部署内存数据库到EC2 Memory-optimized instances。”
总结下微服务架构几点要素：注册与发现、API Gateway、服务间通讯……
3Gpp制定的5G架构规范也是采用微服务的模式。下图是5G系统的总体架构图。5G系统被拆分为许多个F(Function)，你问为啥不叫Service，哈哈，3Gpp还是要保持自己的个性的吧，我猜。其中NRF(Network Resource Function)负责各个服务的注册与发现。标红的是我们要实现的服务CHF(Charging Function)，与我们打交道的是SMF。各个服务通过定好的协议进行交互，如：NRF的接口协议就叫Nnrf，CHF的接口协议就叫Nchf。
不止于5G的整体架构是微服务架构，每个子服务的内部也都是按微服务的架构重新设计实现的。容器化、微服务架构、服务编排是这两年我们系统的改造重点。相信也是其它子服务的改造重点。5G核心网未来要满足网络切片的要求，NFV和微服务化，服务编排都是实现这一切的基础。
原文地址：https://www.cnblogs.com/cdap/p/11077270.html