云原生是目前云平台技术架构中非常重要的一个技术话题。当前市场上很多的云计算厂家都在积极推进云原生态的部署。云原生(CloudNative) 在很多的行业和领域开始部署，包括融合通信技术行业。从美国市场来看，无论是运营商级用户和企业级用户都已经开始应用和部署。
随着技术革命的不断演进，特别是我们所在的通信行业，系统软件本身都面临技术转型问题。在VOIP领域，传统的系统平台大部分基于硬件设备开发，缺少灵活性，缺少可扩展性，不能实现资源的弹性伸缩管理，更难实现敏捷开发，缺乏虚拟化完整的支持等问题。Matt Stine在2015年出版了第一本关于云原生技术架构的著作以后，很多开发人员都纷纷在其架构下开发不同的业务场景。在基于SIP网络技术实现的语音视频方案中，SBC，IPPBX，呼叫中心等也从硬件设备类型，虚拟化，包括络功能虚拟化，SD-WAN方面不断扩展。如果读者对网络编排有兴趣的话可以阅读以下文章：
笔者将针对SIP网络技术中会话边界控制器在云原生技术架构中的实现进行讨论分享，笔者读者进一步了解如何在云原生技术架构的基础上实现SBC 高可靠性实现方式，自动测试，软件版本升级和灰度测试环境管理等方面的问题。以下讨论中主要包括：云原生技术背景介绍，关于SIP网络技术和SBC技术架构在云原生中的应用和其迫切性讨论，关于基于云原生的SBC中信令媒体分离，共享数据库状态信息，SBC高可靠性中active/active，active/standby两种机制的HA支持方式，资源自动伸缩，版本管理灰度测试的结果方面的问题进行讨论。
在2017年，
Matt Stine
有针对云原生的技术架构提出来一个新的概念，新的概念包括六大技术特征：
可处理，可替换，可监控观察，可测试，可部署和可模块化。
另外一个云原生的倡导者
Pivotal
也对云原生技术架构做了四点概括，包括：
DevOps+持续交付+微服务+容器，其技术架构部署方式如下：
此图例以及以下图例均来自于互联网资源
诺基亚贝尔实验室的Bessem和其他研究人员针对5GPP项目垂直行业，关于网络中具体应用场景，包括智慧城市，直播娱乐产业如何支持云原生针对具体的应用模块进行了分解部署讨论-Cloud-Native and Verticals' services，特别针对网络功能虚拟化和SD-WAN等边缘终端业务进行了讨论。这些研究成果都对云原生技术有了更进一步的指导。下面，笔者重点从SIP网络，SBC相关业务角度进一步讨论SBC云原生技术的演进。
在以上的分享中，我们可以看到，云平台部署结合云原生技术架构会逐渐在很多领域进行部署。在我们重点关注的领域中，融合通信平台往云平台迁移，呼叫中心迁移往云平台迁移，并且逐渐占据相对比较大的份额。从技术发展的方向来说，在云平台软件技术架构实现的方式上，云原生的各种技术需要满足微服务，容器，自动交付，自动测试和自动伸缩等特点。进一步来说，SBC的技术架构需要支持这些云原生技术特点。
SBC作为SIP网络或者IMS core网络中最核心的管理模块，它可以实现负载均衡处理，智能路由规则处理，实时智能媒体分析等处理，帮助IPPBX或者呼叫中心系统进行灵活控制和强大的路由管理。为了实现基于SIP网络中各种业务需求的处理，SBC需要不断在系统技术架构上满足云部署和现在云原生的技术要求。
通过以上图例我们可以看到，通过云原生SBC实现其主要目的在于云平台架构的自动化处理，包括技术架构底层的自动化部署，产品生命周期管理，自动部署配置自动化实现和产品或者服务上线后自动化测试验证等目标。
根据Exact Ventures的预测，到2024年，很多运营商的SBC都需要往基于云原生的环境中部署。
为了满足终端企业用户的要求和运营商的战略部署，基于云原生SBC部署是一个势在必行的一个业务要求。为了实现基于最新云原生技术架构的要求，SBC也通过技术的演进逐渐满足用户的需求。
为了实现基于 Cloud-Native 技术架构 的SBC的最新功能，SBC必须针对性地解决目前SBC应用环境中的各种要求：
CNF-云原生技术由很多微服务应用构成： 需要向后兼容，支持服务API接口，各种服务需要互相独立。
逻辑和状态分离支持无状态worker共享状态数据: 支持活动/活动worker 工作模式和扩展。
针对每个微服务进行流程开发设计更新等要求支持：能够支持自动更新和均衡负载能力，当必要时，SBC 必须自动启用SBC的均衡负载功能，实现自动化扩展。
为各种云平台提供集成设计，和当前主流云平台实现监控日志排查服务的接口支持
支持通过容器技术实现网络编排：支持SBC回滚更新，自动恢复，手动和自动扩展，支持Kubernetes和支持Helm 3.0 打包。
在接下来的章节中，笔者将重点介绍如何通过具体的逻辑模块的分离来实现以上关于云原生技术的目标。
当前，市场上最新的基于云原生会话边界控制器-SBC的技术架构实现方式完全对各种功能模块进行更深入的分解，媒体和信令解耦，数据库共享，均衡负载，呼叫管理，网络服务等进行主从备份和主主备份方式处理。另外，对用户来说，很多传统架构开发部署的融合通信平台，IPPBX，呼叫中心。在部署和项目调研时，用户都要考虑用户人数，物理服务器资源等，通常按照最大用户数量或者并发数量进行的部署。如果用户数量减少以后，或者某些服务器不再使用以后，他们将要面对公司资源的浪费和闲置，导致极大浪费。因此，基于资源的弹性计算解决方案是一个非常不错的选择。笔者在以下讨论中将针对SBC在基于云原生技术架构中的高可靠性设置，自动弹性收缩，金丝雀软件灰度测试，版本管理方面进行讨论。
通过以上的SBC技术架构就可以实现当前SBC最需要支持的功能，包括信令和会话负载的分离，通过共享数据库来实现状态（会话状态和注册状态）共享，实现高可靠性部署中的active/active方式和active/inactive方式支持，并且可实现广泛的大规模集群部署方式。在关于SIP负载均衡的处理过程中，通过共享数据库会话状态数据和注册状态数据，SIP在会话入口和退出状态中，分别对几台SBC worker进行负载处理，根据其不同状态进行发布时分发机制的均衡负载。例如，如果 worker 3 出现故障，它down 掉以后，LB 负载均衡就会根据共享数据库中当前的状态自动调度到worker 4的示例上。
除了负载均衡的自动化处理以外，SBC还要实现SBC worker的自动伸缩来满足业务功能突发要求增加带来的超载问题。这一功能可以满足呼叫并发突然增加，视频语音会议人员突然爆增时资源的负载均衡支持。
在以上SBC设置场景中，SBC通过评价指标实现自动控制的解决方案。如果评价指标触发了多台worker需要介入到流量处理时，通过阀值计算，SBC worker数量会自动实现扩展功能。如果SBC 评价指标的数据发生更新。如果数据流量降低以后，SBC worker会自动缩减到原来的数量。通过SBC自动扩展解决方案，企业用户或者运营商级用户不仅仅可以增加SBC 实例数量，同时也可以在无需更多空闲资源时，系统自动缩减SBC 示例的数量，这样可以完全避免系统资源的浪费。
在软件行业的开发流程中，
Canary（金丝雀）更新是一个比较先进的软件版本管理手段。用户可以先发布一个
Canary 金丝雀版本，和目前应用环境进行灰度测试。
Canary版本经过一定时间测试，用户可以发现测试版本的bug，然后及时修复发现的bug，或者回滚到以前部署的版本，保证其系统完整的稳定性。SBC测试开发流程也可以使用此手段来控制功能发布的结果。
在以上升级流程中，如果我们要升级 worker 2版本时，我们可以先部署一个worker 2（v2，金丝雀）版本，然后让 worker2的v2 版本处理一定的数据流量。系统经过一段时间运行后，根据系统状态数据，如果我们发现其工作状态正常的话，可以完全对work2 的v1版本进行升级，完全升级到v2版本。如果发现v2版本有问题的话，系统会回滚到原来的v1版本，不再对work2 v1 版本进行升级。通过
Canary升级控制机制可以完全控制SBC软件升级的可控性。
在云部署场景中，特别是需要大规模集群部署环境时，SBC的HA 高可靠性机制是系统稳定性的绝对保证。通过active/active 和active/standby模式支持所有的SBC worker实例。在active/active 环境下，如果以下三个worker 有其中一个down 掉的话，例如worker IP-A出现故障，系统通过共享数据库状态数据，其他的worker（IP-B和IP-C）将自动承担IP-A的工作量，把它的工作量发布到另外两个SBC worker 实例上。
在以上的SBC HA处理流程中，通过获取共享数据库的状态数据，信令服务器出现故障以后，媒体功能或者编码转换功能仍然会继续执行。Active/Active部署方式及时实现故障服务器出现问题以后，通过共享数据库状态消息，重新发送re-INVITE请求分发请求到另外两台SBC worker（IP-B和IP-C的蓝色指示部分）。
SBC的高可靠性部署环境中，通过active/standby也可以轻松实现其高可靠性处理方式。
在以上的处理机制中，其中一个SBC worker 设置为standby模式，如果一个active SBC 出现故障以后，例如IP-A出现故障，standby就会通过其IP接管其媒体地址，保证其媒体流程继续进行处理。standby模式不经过re-INVITE处理，直接通过媒体地址进行媒体通信。
通过章节的以上介绍，读者可以看到，云原生需要一套完整的自动部署框架来实现云原生的这些要求。Ribbon提出了以下这套完整的技术框架（RAF）来帮助运营商级用户和企业用户实现云原生SBC部署的流程。
虽然很多SBC厂家也提出了关于云原生SBC的技术框架。但是一些厂家的SBC产品还不能实现真正的云原生技术架构和部署要求。因为其架构的原因，很多性能指标可能受到了一定的限制。例如，Ribbon 云原生的SBC SWe Lite在SILK转码上，其成本比友商的低40%， 性能是友商的两倍左右。在SBC HA处理上，很多厂家的SBC仍然只能使用的active/standby模式，因为没有共享状态数据的数据库模式，部署模式仍然是传统的active/standby，不是真正的云原生容器工作机制，不能实现自动弹性收缩，这样也会导致系统很多资源浪费。
在当前的云平台环境中，随着技术的不断更新，SIP网络技术的架构也必然发生很大的变化，这是一个SIP技术和业务要求转型时期。虽然目前仍然存在硬件部署方式，虚拟化方式和云平台部署方式，但是，未来很多的应用将需要通过云原生技术架构来实现和管理。在SBC的选型上，用户也一定要考虑云部署的HA处理方式支持，可伸缩的弹性计算功能，部署管理测试等方面的问题。Ribbon SBC在基于云原生技术架构的实现方面已经走在了同行业的前面，完全具备了云原生技术的要求。
云原生技术是当前互联网云计算中比较热门的主流技术架构，我们的客户也会随着技术的变化跟进这种策略。它本身符合了现代云技术发展的潮流。SBC作为SIP网络核心控件，承担着NAT透传功能，呼叫均衡负载功能和兼容性测试等问题。基于云原生SBC的技术通过不断优化，利用云计算各种技术实现了基于云原生SBC的解决方案，这种新的技术彻底实现了SIP网络的HA高可靠性部署，同时满足了大规模集群的配置支持。
在本文章中，笔者首先介绍了关于云原生技术的背景和特点，通过SBC技术架构分解，满足了云原生SBC要求，实现了资源弹性扩展，资源伸缩调整等非常高级的功能。另外，一些厂家虽然也在逐步部署云原生技术，但是其底层架构因为不能共享数据库状态信息，它们仍然不是真正的云原生技术，因此，其性能和管理方式也存在一定的局限性。笔者希望通过市场上领先的Ribbon SBC 云原生技术的实现方式，和读者分享真正的云原生技术是如何满足云原生技术架构要求，并且帮助用户能够实现专业的SIP/SBC解决方案。
参考资料：
www.rbbn.cn
www.hiastar.com
www.rbbn.com
https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/definition
Bessem Sayadi， Cloud-Native and Verticals' services
