CTICloud 架构说明

1. 架构的重要性

联络中心平台是支撑企业运营和客户服务能力的核心基础设施。我们的架构设计满足企业对联络中心系统提出的严苛标准。架构理念与设计原则代表了一款平台型产品的灵魂，也体现了一家云平台服务商的综合能力。

2. 架构设计目标、理念与原则

在设计云平台架构时，我们将核心目标聚焦于：如何在稳定提供服务的同时，兼顾由场景驱动创新带来的持续演进能力。我们的挑战在于，既要保障大规模、不间断的稳定运行，又要能够随着客户需求与技术发展实现快速的功能演进。

为实现这一目标，我们遵循三项核心架构设计理念：

2.1 分层架构设计与层间隔离

我们将一个既要求极高稳定性、又要求灵活性的复杂实时系统拆分为多个独立层级，每一层分别承载特定的业务需求。这样，原本复杂的一体化系统被转化为结构清晰的四层子系统架构。架构越清晰，越便于理解与管理，也为持续高效的开发奠定基础。

2.2 层内功能解耦

基于对联络中心各类客户触点场景的深度理解，我们能够对功能模块进行充分拆分。模块之间仅通过清晰定义的接口进行交互，从而保障整个业务流程的端到端高可用。

2.3 双云双活设计，保障极致韧性

客户联络系统是企业运营的生命线。长时间的服务中断会对业务造成重大影响。因此，我们从架构层面专门针对自然灾害、区域级基础设施故障等极端场景进行设计。

3. 我们如何实现架构设计目标

3.1 架构分层

我们的分层架构将整体系统划分为四个明确层级：

第 1 层：网络层

IP 网络设备与基础设施
运营商线路网络与连接能力
统一网络管理与控制系统

第 2 层：基础设施层（IaaS）

数据中心设施与资源
云计算平台与服务
云存储方案与备份系统
互联网接入与连接基础设施

第 3 层：API 层（PaaS）

依托多年积累的行业经验，我们将业务场景抽象为丰富的 API 与 SDK，帮助客户开发团队按照自身业务场景快速实现业务逻辑，并将平台能力迅速集成到企业内部业务系统中。

第 4 层：SaaS 层

提供开箱即用的应用功能与完整解决方案，客户无需进行定制开发即可直接部署使用。

这四层彼此独立，通过预定义接口进行连接。每一层都可以独立演进、扩展和运行而不影响其他层。层间解耦使网络团队、基础设施研发团队和应用开发团队能够分别聚焦各自层级，从而最大化提升技术研发效率。

分层架构图

%%{init: {'theme':'base', 'themeVariables': { 'primaryColor': '#ffffff', 'fontFamily': 'arial', 'fontSize': '12px'}}}%%
graph TB
    subgraph L4 ["📱 应用层（SaaS）"]
        A[联络中心应用]~~~
        B[CRM 解决方案]~~~
        C[分析与报表]~~~
        D[坐席工作台]
    end
    
    subgraph L3 ["🔌 API 层（PaaS）"]
        E[开放 API]~~~
        F[异步 API]~~~
        G[Webhook]~~~
        H[服务端 SDK]~~~
        I[坐席 SDK]~~~
        J[RTC SDK]
    end

    subgraph L2 ["☁️ 基础设施层（IaaS）"]
        K[云服务商 A]~~~
        L[云服务商 B]~~~
        M[IDC A]~~~
        N[IDC B]
    end
    
    subgraph L1 ["🌐 网络层"]
        P[IP 网络]~~~
        Q[PSTN 网络]~~~
        R[网络控制系统]
    end
    
    %% Layer-to-Layer Relationships
    L4 -.->|"API 调用"| L3
    L3 -.->|"服务请求"| L2
    L2 -.->|"网络流量"| L1

3.2 层内解耦

3.2.1 网络层解耦

SD-WAN 实施方案：我们采用 SD-WAN 网络方案，将网络硬件与线路资源从控制平台中解耦出来，实现核心网络内所有节点的全面互联。SD-WAN 具备实时网络状态检测能力，当任一节点发生故障时，可在毫秒级完成自动切换。该方案既保证了大规模稳定运行，又实现了集中化、灵活化的流量管理。

多数据中心设计：我们通过战略性的地理分布实现核心数据中心隔离。在北京和上海分别建设两个核心数据中心，四个核心设施之间通过 SD-WAN 实现互联。当任一数据中心出现问题时，业务可以无缝切换到其他核心设施，确保跨区域高可用。

3.2.2 IaaS 层解耦

我们的云平台同时运行在两家领先的云服务商之上。每个核心数据中心通过专用光纤连接到两个云平台，从而打通两家不同的云服务商。当任一云服务商出现问题时，我们可以将业务切换至另一套云基础设施。

通过网络层与 IaaS 层解耦，我们实现了基础设施层面的负载均衡与高可用。当任一数据中心或云服务商不可用时，业务可以快速切换到替代基础设施。业务连续性绝不依赖任何单一数据中心或单一云服务商。

基础设施抽象层：在软件层面，我们将不同云服务中的组件抽象为通用能力，包括云计算虚机、云对象存储、云数据库、云负载均衡、云缓存服务、云表服务、弹性伸缩能力以及 Serverless 架构等。这样一来，开发人员无需关心底层运行环境细节，也无需了解服务究竟运行在 AWS、阿里云还是其他平台上，云基础设施对开发者而言是透明的。这不仅提升了研发效率，也使软件与 IaaS 基础设施层彻底解耦。

对于 SaaS 服务模式与 VPC 服务模式，软件与 IaaS 的解耦意味着可以通过统一的软件版本实现相同的技术实现路径。这消除了项目级的软件适配工作，也为未来 VPC 模式的发展奠定了架构基础。

两地双云四核心数据中心基础设施拓扑图

%%{init: {'theme':'base', 'themeVariables': { 'primaryColor': '#ffffff', 'fontFamily': 'arial', 'fontSize': '12px'}}}%%
graph TB
    subgraph NETWORK ["🌐 SD-WAN 控制中心"]
        SDWAN[集中管理<br/>& 流量控制]
    end

    subgraph SH ["🏙️ 上海区域"]
        
        subgraph IDCB ["IDC"]
            SH1[上海 IDC A]~~~
            SH2[上海 IDC B]
        end
        Cloud2[云服务商 B]
    end
    
    subgraph BJ ["🏛️ 北京区域"]
        subgraph IDCA ["IDC"]
            BJ1[北京 IDC A]~~~
            BJ2[北京 IDC B]
        end
        Cloud1[云服务商 A]
    end

    %% Inter-region connectivity
    BJ1 <-.->|光纤链路| SH1
    BJ2 <-.->|光纤链路| SH2

    %% Control connections (simplified)
    NETWORK -.->|管理| SH
    NETWORK -.->|管理| BJ
    
    %% Internal connections within regions
    SH1 <-.->|光纤链路| SH2
    BJ1 <-.->|光纤链路| BJ2

    IDCB <-.->|光纤链路| Cloud2
    IDCA <-.->|光纤链路| Cloud1

3.3 API 层：平台能力 API 支撑客户自主开发

我们的 PaaS 层为客户开发团队提供 500+ API 接口 以及多语言开发 SDK，主要包括：

渠道集成 API：多渠道客户触点管理
排队与路由 API：智能话务分配与流程管理
知识库 API：集中式信息与内容管理
人工智能 API：AI 驱动的自动化与洞察能力
CRM API：客户关系管理集成
工单 API：案例与事件管理系统
报表 API：分析与商业智能能力
坐席 SDK：桌面端与移动端坐席应用
软电话 SDK：VoIP 通信能力
配置 API：系统与租户管理
呼叫控制 / 会话管理 API：实时通信控制
录音 API：合规与质检管理
实时统计 API：实时运营指标
系统监控 API：基础设施健康与性能监测
日志 API：审计追踪与故障排查支持

企业客户的开发团队主要通过这些 API 与 SDK，将联络中心能力集成到其内部业务系统中。基于这些 API，客户开发人员可以针对不同业务场景进行定制开发，在系统稳定运行与客户个性化需求之间取得最佳平衡。

企业客户典型 API 集成架构

graph LR
    subgraph "客户内部系统"
        C[CRM 系统]
        A[坐席工作台]
        W[人力管理系统]
        B[商业智能系统]
        O[运维系统]
    end
    
    subgraph "CTICloud API 层"
        API[CTICloud 500+ OpenAPI]
        SDK[坐席端/服务端 SDK]
    end
    
    subgraph CTI ["CTICloud 平台"]
        direction LR
        CC[联络中心核心]
        AI[AI 服务]
        RPT[报表引擎]
        MON[监控系统]
    end
    
    C --> SDK
    A --> SDK
    W --> API
    B --> API
    O --> API
    
    API --> CTI
    SDK --> CTI

3.4 SaaS 层微服务化与快速演进

在 SaaS 层内部，我们进一步对功能模块进行拆分，并全面采用微服务架构。各模块仅通过接口进行交互，可独立运行、独立演进、独立扩展，互不干扰。每个微服务模块都可以构建独立的可扩展集群。

我们将核心通信组件、通信协议控制、基础数据存储与处理、媒体转码与录制、通用消息通道与处理能力、呼叫控制与路由能力，以及数据交互与推送能力等，全部封装为 API，应用通过调用 API 来访问和使用这些能力。

这种方式有效解决了底层通信高稳定性要求与上层应用快速演进需求之间的矛盾。底层通信层专注于稳定性与性能，不承担定制化改造；上层应用则以松耦合方式接入底座能力。基于 10 多年的客户服务经验，我们在应用灵活性与核心系统稳定性之间实现了最佳平衡。

API 层与 SaaS 层解耦架构

graph TB
    subgraph "SaaS 应用层"
        APP1[联络中心应用]
        APP2[分析看板] 
        APP3[坐席桌面]
        APP4[管理控制台]
    end
    
    subgraph "API 抽象层"
        API1[通信 API]
        API2[数据处理 API]
        API3[AI 服务 API]
        API4[集成 API]
    end
    
    subgraph "平台核心服务"
        COMM[通信核心]
        DATA[数据处理]
        AI[AI 引擎]
        INT[集成中心]
    end
    
    APP1 --> API1
    APP2 --> API2
    APP3 --> API3
    APP4 --> API4
    
    API1 --> COMM
    API2 --> DATA
    API3 --> AI
    API4 --> INT

通过足够丰富、底层、开放的 API 接口，SaaS 应用层可以快速通过 API 调用实现多样化的应用形态。SaaS 应用层可以围绕具体业务场景独立演进，而不受底层 PaaS 的限制。

4. 双云双活联络平台架构

云平台本质上是一个要求持续不中断运行的系统，稳定运行是其最核心的基础能力。在稳定性方面，我们是国内唯一具备双云双活架构落地能力的服务商。这一能力对企业客户至关重要，因为联络系统是每一家企业运营的生命线。服务中断会带来重大损失，因此系统必须能够应对区域停电、区域网络中断、整家云服务商不可用以及区域自然灾害等极端场景。

我们设计并构建了双云双活系统。这意味着系统会同时部署在两套来自不同供应商的异构云基础设施之上。在中国区，我们将北方区域部署在 AWS，将南方区域部署在阿里云。两套平台同时在线、同时承载业务负载。通过基于 IDC 的实时同步模块，两朵云之间的配置数据实现秒级双向实时同步。客户可以同时使用 A 平台和 B 平台，并能够在极端场景下实现云间快速切换。

4.1 双云双活架构

graph TB
    subgraph "北方区域 - AWS"
        AWS1[北京 AWS DC-1]
        AWS2[北京 AWS DC-2]
        AWSAPP[AWS 应用栈]
    end
    
    subgraph "南方区域 - 阿里云"
        ALI1[上海阿里云 DC-1] 
        ALI2[上海阿里云 DC-2]
        ALIAPP[阿里云应用栈]
    end
    
    subgraph "数据同步"
        SYNC[实时同步<br/>秒级延迟]
    end
    
    subgraph "客户访问"
        CUST[客户应用]
        LB[全局负载均衡]
    end
    
    AWS1 -.-> AWS2
    ALI1 -.-> ALI2
    
    AWSAPP --> SYNC
    ALIAPP --> SYNC
    
    CUST --> LB
    LB --> AWSAPP
    LB --> ALIAPP
    
    AWS1 --> AWSAPP
    AWS2 --> AWSAPP
    ALI1 --> ALIAPP
    ALI2 --> ALIAPP

5. 实时全量运营指标支撑持续快速演进

健康监控是持续快速演进的基础保障。对业务系统运行指标进行实时、多维度监测，可以第一时间发现系统的细微变化，从而为持续演进建立基础。

可持续演进的架构包含三个核心技术要素：

5.1 双维度渐进式发布设计

我们基于客户分组与流量百分比两个维度实施渐进式发布。新模块版本会先在有限范围内灰度部署到部分客户，结合运营指标和客户反馈进行监测。一旦发现问题，可以快速回滚并完成修复。在确认稳定后，再逐步扩大覆盖比例与客户范围。

5.2 实时全面监控设计

我们设计并开发了完整的监控与运维支撑平台。通过细致全面的监控、实时统计和实时告警系统，我们将系统运行指标度量作为重点建设内容。这套监控基础既支撑平台稳定运行，也支撑平台快速演进。监控系统能够分析每个模块的运行状态，并在指标超过预警阈值时主动告警。

5.3 组织结构支撑

我们采用 DevOps 一体化研发运维组织模式，使研发与运维团队紧密协作。我们坚持以更小、更高频的变更来控制演进风险。借助自动化测试技术，我们的公有云 PaaS 平台可以实现按周迭代，全年完成约 45 次版本迭代，同时保持平台稳定运行和客户体验的平滑连续。

我们坚持 “没有度量，就没有改进” 的原则。任何新功能在上线前都必须先完成指标设计与度量定义，并在发布前完成相关监控开发和告警阈值设置。

6. 架构优势与业务价值

6.1 企业级可靠性

通过双云双活架构实现 99.99% 可用性
基于 SD-WAN 技术实现 毫秒级故障切换
全系统组件实现 零单点故障

6.2 可扩展的创新平台

500+ API 支撑无限定制可能
微服务架构 支持独立扩缩容
每周发布周期 实现不停机更新

6.3 全球化基础设施韧性

多区域部署 覆盖中国核心经济区域
双云服务商策略 避免供应商绑定
实时数据同步 保障业务连续性

6.4 以开发者为中心的设计

多语言 SDK 支持快速集成
RESTful API 标准 遵循行业最佳实践
完整文档体系 与开发支持能力

这一架构基础使 CTICloud 成为企业客户在联络中心运营中兼顾稳定性与创新敏捷性的优先选择。