5G核心网之SBA架构(面向服务)
Posted so~what
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了5G核心网之SBA架构(面向服务)相关的知识,希望对你有一定的参考价值。
前言
随着技术演进和发展,云原生提出的“微服务”概念得到了大家的认可,微服务概念指将原本具有多个功能的集合体分拆为多个具有独立功能的个体,每个个体都具有自己的微服务。5GC将微服务概念引入,构建了面向业务的SBA架构,实现了低耦合+高内聚的技术升级。
SBA概念
5G核心网采用了更方便、灵活的垂直行业架构,即SBA。在面向业务的5G网络架构(SBA)中,控制面的功能进行了融合和统一,同时控制面功能也分解成为多个独立的网络服务,这些独立的网络服务可以根据业务需求进行灵活的组合。每个网络服务和其他服务在业务功能上解耦,并且对外提供同一类型的服务化接口,向其他调用者提供服务,将多个耦合接口转变为同一类型的服务化接口,可以有效地减少接口数量,并统一服务调用方式,进而提升了网络的灵活性。
SBA架构优点
相对于3G/4G的参考点设计,SBA服务化架构使5G核心网各网元的功能模块化,接口统一化,结构简单化以及去中心化。
- 功能模块化是指对网络功能进行细化,不再是一个网元集成多个功能,而是分解为相对独立的功能模块。
- 接口统一化是指各网元之间的通信不再是传统通信的处理机制,即同一设备与其他不同设备间采用不同的接口,服务化架构屏蔽了同一设备与不同设备之间接口的差异,对所有设备提供统一的服务接口,来自不同网元调用统一的服务接口与该网元进行通信。
- 结构简单化是指提供服务的业务模块可以自注册、发布和发现,取消了传统设备间的耦合,简化了不同网元间的复杂联系,进而缩短了业务流程。将整个控制面功能分解为多个独立的网络服务,客户可以根据实际需求灵活选择不同网元进行切片组合,可以方便的进行扩容和缩容,有效降低了系统复杂度,节省了部署成本。
- 去中心化是指让用户面网元摆脱以往4G“中心化”的限制,既可以部署于核心网(中心数据中心),也可部署于接入网(边缘数据中心),实现分布式部署。分布式部署可以缩短用户面数据传输距离,降低传输时延,带来更好的用户体验。
核心网架构介绍
NSSF:Network Slice Selection Function 网络切片选择功能
NEF:Network Exposure Function 网络能力开放功能
NRF:Network Repository Function 网络存储功能
PCF:Policy Control Function 策略控制功能
UDM:Unified Data Management 通用数据管理
AF:Application Function 应用功能
AUSF:Authentication Server Function 鉴权服务功能
AMF:Access and Mobility Management Function 接入与移动性管理功能
SMF:Session Management Function 会话管理功能
SCP:Service Communication Proxy 服务通信代理
UE:User Equipment 用户终端
RAN:RadioAccess Network 无线接入网
UPF:User Plane Function 用户面功能
DN:Data Network 数据网络
在SBA架构中,每个核心网网元的接口统一命名为“N +小写英文功能名缩写”。例如,网络切片选择功能NSSF的接口为Nnssf;5G核心网网元的服务操作名称以接口名开始,例如,Nnssf_NSSelection表示NSSF的网络切片选择操作。除了统一的服务化接口外,5G网络仍然保留了少量的参考点接口,如下:
- N1:NAS接口,用于发送NAS消息
- N2:AN与AMF之间NG接口
- N3:AN与UPF之间对接接口,采用GTP-U协议
- N4:控制面SMF和用户面UPF分离的设备接口
- N6:内部网络侧与外部网络侧协议接口,采用GTP-U协议
- N9:两个UPF之间接口,采用GTP-U协议
转换为传统的大家熟悉的参考点架构,会更容易理解,但要注意实际组网仍然是SBA架构。
核心网网元功能
5GC控制面网元包括AUSF、AMF、SMF、NSSF、NEF、NRF、PCF、UDM,用户面网元为UPF。
- AMF:接入和移动性管理功能实体,AMF可以类比于4G的MME实体。主要功能:
(1)RAN信令接口(N2)的终结点,,NAS(N1)信令的终结点
(2)负责NAS消息的加密和完保
(3)负责注册、接入、移动性、鉴权、透传短信等功能
(4)在和EPS网络交互时负责Eps Bearer Id的分配。
- SMF:会话管理功能实体,可看成MME承载管理部分以及SGW和PGW的控制面功能的组合。主要功能:
(1)NAS消息的SM消息的终结点;
(2)会话(session)的建立、修改、释放
(3)UE IP的分配管理
(4)DHCP功能
(5)ARP代理或IPv6邻居请求代理(Ethnet PDU场景下)
(6)为一个会话选择和控制UPF
(7)计费数据的收集以及支持计费接口
(8)决定一个会话的SSC模式;
(9)下行数据指示
- UPF:用户面功能实体,相当于SGW和PGW用户面功能的集合。主要功能:
(1)负责数据包的路由转发
(2)Qos流映射
(3)流量使用上报
- PCF:策略控制功能实体,相当于4G的PCRF
(1)支持统一的策略框架去管理网络行为
(2)提供策略规则给网络实体去实施执行
(3)访问统一数据仓库(UDR)的订阅信息,PCF只能访问和其相同PLMN的NDR。详见TS 23.503 6.2.1章节。
- UDM:统一数据管理,相当于HSS数据单元。主要功能:
(1)产生3gpp鉴权证书/鉴权参数
(2)存储和管理5G系统的永久性用户ID(SUPI)
(3)订阅信息管理
(4)MT-SMS递交
(5)SMS管理
(6)用户的服务网元注册管理(比如当前为终端提供业务的AMF、SMF等)
- AUSF:鉴权服务器网元
支持3gpp接入的鉴权和untrusted non3gpp接入的鉴权。
- NSSF:网络切片功能,主要功能:
(1)选择服务UE的一组网络切片实例
(2)确定允许的NSSAI,并且如果需要的话,映射到签约的S-NSSAI
(3)确定AMF集合用于服务UE,或者可能基于配置通过查询NRF来确定候选AMF的列表
- NRF:网络存储功能,NF登记、管理、状态检测
(1)支持业务发现功能,接收网元发过来的NF-Discovery-Request,然后提供发现的网元信息给请求方;
(2)维护可用网元实例的特征和其支持的业务能力;一个网元的特征参数主要有:网元实例ID、网元类型、PLMN、网络分片的相关ID(如S-NSSAI、NSI ID)、网元的IP或者域名、网元的能力信息、支持的业务能力名字等。
- NEF:网络开放功能,相当于4G的SCEF
(1)提供安全途径向AF(Application Function,应用功能)暴露3GPP网络功能的业务和能力
(2)提供安全途径让AF向3GPP网络功能提供信息
- AF:应用功能
- DN: 数据网络(DN)
例如运营商服务,互联网接入或第三方服务
想从单体架构演进到分布式架构,SBA 会是一个不错的选择
本文分享自华为云社区《从分层架构到微服务架构(五)之服务化架构》,作者:元闰子。
前言
从本文开始,我们进入了《从分层架构到微服务架构》系列中分布式架构的介绍,本文要介绍的是服务化架构(Service-Based Architecture,SBA)。
SBA 可以看成是单体架构和微服务架构之间的一个折中方案,它也是按照业务领域进行服务划分,但服务划分的粒度相比微服务要更粗。SBA 与微服务架构一大不同是,它允许各个服务间共享同一个数据库实例,这也使得 SBA 在架构上既有单体架构的特点,也有分布式架构的特点,显得更加的灵活。因此,从单体架构演进到 SBA,会比直接演进到微服务架构更加容易。
架构视图
基础视图
SBA 的基础架构视图分成 3 部分:
- User Interface,作为系统的接入口,接收客户端的请求,并转发到业务服务。。
- DomainServices,业务服务按照领域进行划分,分开部署、业务独立。
- Database,服务间共享的数据库实例,因为数据库实例只有一个,所以可以支持 ACID 事务。
使用 SBA 的系统通常只会划分 4 ~ 12 个服务,避免产生过多的数据库连接。服务数量不多,也决定了 SBA 中的服务相比微服务架构中的服务有着更粗的粒度。User Interface 与服务间通过远程通信协议来完成业务往来,常见的通信方式有REST、RPC、消息队列等。需要注意的是,SBA 是不允许服务间通信的,这与微服务架构有着本质的区别。
大多数情况下,SBA 中的服务只有一个或者少量实例,与微服务动辄成百上千个实例有着很大的区别。主要是因为 SBA 服务粒度更粗,无法做到像微服务那样精准的按需扩容,扩容太多反而会导致资源的浪费。
SBA 的另一大特点是允许所有服务共享同一数据库实例,使得它能够直接将传统单体架构的那一套 SQL 查询逻辑、ACID 事务搬过来,让架构的演进更加的平滑。不过,共享数据也会带来一些问题,比如数据模型变更的影响范围更大,后面会在“数据拆分”一节详细讲述。
拆分 User Interface
在大型系统中,单一的 User Interface 可能导致代码耦合、性能瓶颈等问题,这时候我们可以进一步对它进行拆分。拆分的方法可以是基于业务领域的拆分,业务相关的几个服务使用同一个 User Interface;或者基于服务的拆分,为每个服务都配备一个 User Interface。
拆分 Database
类似地,我们也可以对数据库进行拆分,可以拆分成几个服务共享一个实例;也可以像微服务架构中那样,每个服务独享一个实例。数据库拆分的原则就是:确保数据是解耦的,不会被其他服务所依赖,避免出现跨库查询或服务间通信。
增加 API 网关
我们也可以在 User Interface 和 Domain Services 之间增加一个 API 网关层,提供流控、鉴权、指标统计、服务发现等公共能力,进一步提升系统架构的安全性、可靠性、可维护性。
业务服务的设计
SBA 中的服务具有较粗的粒度,因此在业务服务的架构设计上通常也会用到一些单体架构模式,常见的有分层架构和基于领域的组件化架构。
不管是分层架构还是组件化架构,通常都需要增加一个 API 层,负责编排和转发来自 User Interface 的业务请求。下面以订单创建流程作为示例。
假设现在有一个订单服务 OrderService,当它的 API 层接收到来自 User Interface 的订单创建请求时,API 层协调会各个组件依次完成如下的几个业务流程 :
- 调用订单组件,完成订单ID、订单内容的生成。
- 调用支付组件,完成用户的扣款。
- 调用库存组件,更新商品的库存数量。
因为这些业务流程都是在同一个服务内完成,当其中的某个流程异常后,我们很容易通过数据库的 ACID 事务来完成回滚,从而能够确保数据的强一致性。
相比在微服务架构之下,订单创建请求往往需要订单微服务、支付微服务、库存微服务之间协作来完成,这就涉及到分布式事务,也即 BASE(Basic Availability, Soft state, Eventual consistency) 事务。BASE 事务更加的复杂,而且无法保证数据的强一致性。 当然,更粗的服务粒度也会带来服务可用性问题,比如在订单服务例子中,你会因为订单ID生成逻辑的变更而升级整个服务,也会因为库存组件中的一个BUG导致整个服务的故障。
所以,服务粒度的粗与细,实际上也是数据一致性和服务可用性的一次 trade-off。
数据拆分
服务间共享数据库使得系统具有更强的数据完整性和一致性,但简单的单库单表数据模型会带来耦合的问题。
在单库单表的模型下,我们大概率会这么实现,将与数据库操作相关的实体对象、SQL 逻辑全部封装在一个共享的 shared lib 库上,供所有业务服务复用:
这样的实现方式虽然简单,但是会带来“牵一发而动全身”的问题。假设某个服务所用到的某个字段类型需要变化,势必会修改表结构和 shared lib 库,而这两者是所有服务共用的,因此也就会导致所有服务都需要升级重新上线。这样的耦合会给 SRE 带来极大的困扰,一点也不敏捷。
更好的方法是根据业务对数据进行拆分,将相对独立的数据拆分成多个表,每个表都有一个独立的 lib 库,对于公共表,则有一个 common lib 库,各服务按需依赖。对于 common lib 库的变更,我们还可以通过版本控制来尽量降低影响范围,但必须在 common lib 进行版本升级时保持向后兼容。
架构评分
SBA 虽然是分布式架构,但是也保留了单体架构下的一些特点,在架构上具有较高的灵活性,也使得它在各方面的评分都比较高,没有明显的缺点。
SBA 是一个 domain-partitioned 的架构,因此适合使用领域驱动设计来进行领域限界上下文的划分,进而规划出业务独立的服务。服务间业务独立,而且不会相互间通信,也就意味着具有更好的 Testability。
前文有提到过,SBA 虽然支持服务实例扩容,但是更粗的服务粒度会导致扩容的性价比并不高,因此 Scalability 和 Elasticity 得分不高。
Scalability 和 Elasticity的差异:
- Scalability 通常指软件系统在不中断业务的前提下,通过 scale-up 或 scale-out 等手段来应对更高业务负载,强调的是软件系统应对高负载的能力。
- Elasticity 通常指硬件系统能够根据实际的业务负载情况,适时增加或减少硬件资源,强调的是硬件资源的高效利用。
总结
如果你打算从单体架构演进到分布式架构,SBA 会是一个不错的选择:
- 相比单体架构,SBA 按照业务进行服务拆分,在业务解耦、开发流程敏捷等方面有着明显的优势。
- 相比其他分布式架构,SBA 有着更粗的服务粒度,因此也得以减少了服务间的远程调用、网络带宽消耗,受网络故障的影响更小。
- 服务间共享数据库使得 SBA 支持 ACID 事务,在数据一致性方面具有良好的表现,但我们还是应该尽量按照业务进行分表,避免出现严重的数据耦合。
- 在架构评分上,SBA 各方面评分都不错,没有明显的缺点,是典型的“六边形战士”。
参考
- Fundamentals of Software Architecture (Chapter 13. Service-Based Architecture Style), Mark Richards, Neal Ford
- Service-Based Architecture as an Alternative to Microservice Architecture, Matt Fletcher
- What is the difference between scalability and elasticity?, stackoverflow
以上是关于5G核心网之SBA架构(面向服务)的主要内容,如果未能解决你的问题,请参考以下文章