BSS应用程序云原生部署的8大挑战

云原生部署改变了软件开发。根据云原生计算基金会(CNCF)2021年年度调查，96%的组织正在使用或评估Kubernetes。更确切地说，560万开发者在使用Kubernetes，比去年增加了67%。

云原生架构使松散耦合的服务具有弹性、可管理性和可观察性。当与自动化相结合时，云原生功能还可以以最小的中断实现频繁的、影响较大的更改。 

尽管越来越多的开发人员正在接受云原生部署，但该技术在电信业务支持系统（BSS）领域仍然相对较新，而且云原生应用程序部署团队面临着一些挑战，尤其是在有状态应用程序方面，例如BSS中的应用程序。 

下面，让我们看看企业目前在运行云原生部署方面面临的主要挑战。 

云原生挑战#1：运行Helm chart

传统上来说，BSS空间部署和升级一直是一场灾难。因为全面升级通常需要12到18个月的时间，搭建环境又需要几天或几周的时间。但是如果采用正确的方法，云原生应用程序部署有望通过无缝升级完全颠覆这种模式，而这种升级不会中断服务，并且只需要通常所需时间的一小部分。

然而，设置基于云的自动化部署以加速升级的一个重要部分是能够快速启动运行测试甚至全面的生产环境。 

Helm charts是执行此操作的一种方法。借助Helm，你只需按一下按钮就可以将系统启动并运行到所需的大小和规格。但为了使其发挥作用，企业的整个技术栈包括其数据平台需要无缝协作，这可能是一个挑战。

假设你能够应对这一挑战，则可以根据需要使用 Helm 启动开发和测试环境，并在完成后销毁它们。这对于共享硬件和通过仅在使用资源时付费来降低公共云成本非常有用。

云原生挑战#2：CI/CD

使用Helm来管理部署和升级通常只能做到这个程度。为了确保持续服务，还必须管理多个异地冗余群集，并在各个群集之间编排任何更改。持续集成和持续交付（CI/CD）可以通过自动化部署增加显著的业务价值，从而减轻团队设置手动配置的负担。

CI/CD工具可用于自动启动更改（如升级）的一系列步骤，以及在生产部署中执行的其他手动任务。与其让开发人员在凌晨3点通过100步流程来完成升级（并因精疲力竭而犯错误），CI/CD会为您处理这一切。

但是，为了实现CI/CD的承诺，开发团队需要确保他们的工具能够无缝协作。

云原生挑战#3：自动扩展

当公司在公共云上部署应用程序时，他们会为所使用的资源付费（例如，每小时）。 

通常，夜间的收费策略和收费量要远低于白天。更重要的是，流量模式会随着用户群的增长而季节性波动。在这种情况下，通信服务提供商（CSP）不希望从一开始就支付反映未来业务量最繁忙时间和最昂贵资源的价格。相反，他们希望确保以具有成本效益的方式为他们使用的资源付费——不多也不少。

这就是自动扩展特别有用的地方。通过自动扩展，应用程序可以始终根据所需的流量需求调整容量，并且会随着需求的变化而动态地扩大和缩小。

然而，对于有状态的应用程序，这是有问题的。虽然有状态应用程序可以通过添加新的Pod来扩展，但缩小规模是有代价的；你必须要处理存储在要删除的Pod上的数据，这需要时间和精力。根据所涉及的内容，这项工作的成本可能比单独使用解决方案要高。

此外，Kubernetes可能对你数据平台的弹性能力或分布在Pod中的分区一无所知，这意味着Kubernetes不能用于向上或向下扩展Pod，因为需要扩展多个Pod才能保持数据冗余。因此，你可能需要在Operator中管理所有这些，这需要额外的工程设计工作。

云原生挑战#4：服务网格

将单个应用程序（如用于策略和计费的应用程序）拆分为多个微服务会增加它们之间的接口。由于解决方案的每个部分都是根据自己的需求独立扩展的，因此在任何给定时间都将运行多个微服务。

这就是基于云的服务网格特别有用的地方。简而言之，服务网格旨在帮助简化和管理微服务之间的路由流量，因为每个微服务运行的Pod数量是动态的。服务网格还可以加密接口流量，从而使应用程序不必管理加密。在某些情况下，它还可以帮助进行日志记录和事务跟踪。

跟踪只适用于基于HTTP的协议；它适用于5G，但不适用于4G或之前的任何产品。不幸的是，微服务之间的接口不太可能基于HTTP的，因此网格将无法帮助进行跟踪。

然而，有些RFP要求对所有内部和外部接口使用基于Istio的服务网格。如果需要网格来管理系统内部接口，例如集群内和跨数据中心复制 (XDCR)，可能会导致性能问题，这就需要工程人员才能解决。

云原生挑战#5：群集升级

由于5G服务级别协议（SLA）需要个位数毫秒的响应，开发人员没有时间通过XDCR将流量路由到其他数据中心。因此，即使在升级期间，每个集群都应保持服务状态。

群集升级应逐个Pod进行。这意味着你必须管理混合版本的集群，直到每个Pod都升级。虽然这是一个常见问题，但对于有状态的应用程序，它需要产品在单个集群中处理并发的多个版本，这是一个需要解决的复杂问题。

云原生挑战#6：多站点XDCR升级

从软件版本升级到架构改造再到存储过程更改，所有事情都需要在 XDCR 设置中的每个集群保持服务时执行。换言之，你不能关闭一个集群而只留下一个可用集群。 

再一次，正确实现这一点需要大量的产品功能。

云原生挑战#7：安全性

监管机构对部署在公共云上的应用程序的安全和加密越来越严格。由于政策和收费功能包含非常敏感的数据，监管机构越来越多地审查这些领域以保护消费者。

展望未来，当应用程序在公共云中运行时，很可能所有接口——甚至是运行时内存——都必须加密。例如，一些欧洲监管机构已经要求对保存在公共云中的敏感数据的运行时内存进行加密。

随着安全要求的提高，产品将需要在整个应用程序堆栈中更有效地管理密码、用户、角色、访问和加密证书。他们还需要确保在保持预期性能的同时对所有流量进行加密。

云原生挑战#8：操作和故障排除

将应用程序拆分为多个可动态扩展的微服务会使操作和故障排除变得更加困难。当出现问题时，服务失败请求的实例很有可能在有人试图查看发生的情况时不会运行。

例如，自动缩容会终止多个Pod，而当有人解决问题时，导致问题的 pod 可能早已死亡。

Kubernetes设计用于处理自动恢复；Pod是为了失败、终止和被替代而创造的。因此，团队将需要新的监控和追踪工具来帮助了解情况。而这些工具也需要被管理。

云原生仍是未来

尽管存在这些挑战，软件开发的未来仍然是云原生。这是因为该方法带来了很多好处，包括更快的迭代、更低的成本、可扩展性、灵活性、自动化等等。

通过了解云原生部署中固有的挑战并积极努力解决这些问题，开发团队可以充分发挥云原生应用程序的潜力，让其用户和企业满意。