SONiC系统由两部分组成：
1.彼此交互的模块
2.用于交互的基础设施（集中式，可扩展）
其中用于交互的基础设施主要是一个非关系型数据库Redis引擎：
1.提供了一个无视语言的接口
2.是一种数据保持，复制和多进程交互的手段
每个模块只订阅自己关注的数据
每个模块都存在于各自的Docker容器里形成独立的组件，每个组件都与平台细节完全解耦
SONiC由一下几个容器组成：
- Dhcp-relay
- Pmon
- Snmp
- Lldp
- Bgp
- Teamd
- Database
- Swss
- Syncd
下图描绘出了每个模块中包含的功能，以及它们之间的交互。
不是所有的功能都与Redis服务器交互，其中一些功能与外部实体（netlink，文件系统等）产生交互。
图中蓝色箭头表示与Redis数据库的交互，黑色交投表示与外部实体的交互
不是所有的功能都位于某个容器中，比如CLI和sonic配置模块，就是位于Linux主机上的
SONiC子系统描述
Teamd container:
Pmon container:
Snmp container:
Dhcp-relay container:
Lldp container:
Bgp container:
可以运行Quagga或FRR的路由协议栈
此容器可以进一步分为以下几个部分：
- bgpd :
获取路由状态，并将其通过zebra和fpmsyncd接口下发到转发面 - zebra :
是一个路由管理器。它提供路由表更新，接口查询，不同协议间的路由分发
同时，它会将计算好的FIB下发到内核（通过netlink）和南向转发进程组件（通过Forwarding-Plane-Manager interface也就是FPM） - fpmsyncd:
一个小小的守护进程。主要负责将从zebra处收集到的FIB状态注入到Redis引擎中的APPL_DB表
Database container:
Swss container:
SWitch State Service是一组工具套装，它能有效促使SONiC各个模块之间的交流
它提供了一个机制去促成多方的交流和仲裁
同时，SWSS的几个进程会负责与SONiC应用层的北向交互
其中有三个进程是运行在其他容器里的，包括Fpmsyncd，Teamsyncd和Lldp_syncd
但是无论它们运行在哪个容器里，都有着一个共同的目标：
【提供了 能够使 SONiC应用 和 SONiC的集中式消息基础设施（Redis引擎） 保持连接的途径】
【provide the means to allow connectivity between SONiC applications and SONiC’s centralized message infrastructure (redis-engine).】
这些进程 约定俗成地 命名为 *syncd。下面介绍各种syncd:
- Portsyncd
监听与端口相关的（port-related）netlink事件。在启动期间，portsyncd会通过解析系统的硬件配置文件 获取物理端口的信息。
最终portsyncd将所有收集到的状态信息推送到APPL_DB中。像 端口速率，lanes和MTU将通过此途径传送。
portsyncd还会将状态注入到STATE_DB。 - Intfsyncd
监听与接口相关的（interface-related）netlink事件并将收集到的状态信息推送到APPL_DB。像 新建/修改 的接口IP地址 这样的参数将通过此进程得到处理。 - Neighsyncd
监听与邻居关系相关的（neighbor-related）netlink事件，这种事件通常是 新发现的邻居产生的ARP处理进程 触发的。
像 MAC地址和邻居的地址族信息都是通过这个进程处理的。出于 数据平面的L2重写的目的，最终这个状态信息将用于构建邻接表。再次强调，这个状态信息最终会被传送到APPL_DB中。 - Teamsyncd
在teamd容器中运行，其获取到的状态信息将被传送到APPL_DB中。 - Fpmsyncd
在bgpd容器中运行，其获取到的状态信息将被传送到APPL_DB中。 - Lldp_syncd
在lldp容器中运行。
以上进程都是发布者，根据 发布者/订阅者 模型，SWSS还需要订阅者的角色来完成对接收到的消息的消耗和转移，下面的几个进程就是这样的角色：
- Orchagent
这是SWSS子系统最重要的组件。Orchagent包含一个逻辑处理功能，用来将所有 从其他*syncd进程注入的 状态信息提取出来，然后处理并转发这些信息，最终将这些信息推送至Orchagent的南向接口。这个南向接口就是redis引擎中的ASIC_DB，所以我们可以发现，Orchagent既是订阅者，又是生产者，因为它既从APPL_DB获取数据，也向ASIC_DB提供数据。 - IntfMgrd
处理来自APPL_DB，CONFIG_DB和STATE_DB的状态信息，然后在Linux内核中配置接口信息。只有在被检测的任何数据库中没有发生冲突和不一致的数据时，这一步骤才会执行。 - VlanMgrd
处理来自APPL_DB，CONFIG_DB和STATE_DB的状态信息，然后在Linux内核中配置vlan接口信息。正如IntfMgrd，只有在没有冲突数据存在的情况下才会执行这一步骤。
Syncd container:
Syncd 的主要目标就是提供一种 能让交换机的网络状态信息 和 交换机硬件/ASIC上的实际状态 保持同步的一种机制。这种机制主要包括初始化，配置以及收集交换机ASIC当前的状态。
它包含了几个主要的逻辑模块：
- Syncd:
Syncd执行上述提到的同步机制。在编译时，syncd与 硬件供应商提供的ASIC SDK连接，并且把状态信息注入到ASIC，这个效果是通过引用 被提供的接口 实现的。Syncd订阅ASIC_DB的信息，从SWSS获取信息，与此同时 将自身注册为一个生产者，将从硬件获得的状态信息发布出去。 - SAI API:
SAI(Switch Abstraction Interface)定义了一个API，这个API提供了与厂商无关的方式去控制转发单元，例如交换ASIC，它是一个统一化的NPU或者一个软交换。 - ASIC SDK:
硬件供应商期望能够提供一种SAI友好型的能够驱动他们的ASIC的SDK实现方法。这种实现方式通常通过动态链接库（dynamic-linked-library）的形式实现，这种机制调取驱动程序（在这里是指syncd）来执行它的驱动。
CLI / sonic-cfggen:
SONiC中负责提供命令行和系统配置的功能模块。
CLI组件重度依赖Python的Click库，该库为用户提供了一种灵活的客制化的方式去构建一个命令行工具。
Sonic-cfggen组件被SONIC的CLI调用，来完成 对配置修改 和 任何与SONiC模块交互的配置相关的动作。
SONiC子系统的交互
路由状态交互
在这一部分，我们来看一下在收到一个eBGP路由更新时SONiC的处理流程。我们假设会话已经建立起来了，而且学到的新路由以它的直连接口作为下一跳。
下图展示处理流程，有些不必要的步骤已经被省略：
(0) 在BGP容器初始化时，zebra通过一个常规的TCP套接字连接到fpmsyncd。在稳定状态下，zebra所持有的路由表，Linux内核，APPL_DB和ASIC_DB需要保持高度一致。
(1) 一个新的TCP数据包到达位于内核空间的BGP位。内核的网络栈最终将携带的载荷递送至bgpd进程。
(2) Bgpd解析这个新的数据包，处理这个bgp更新，并且通知zebra这个新前缀的存在和与该协议相关的下一跳。
(3) 根据zebra的可达性判断，zebra生成一个route-netlink状态信息并将其注入到内核。
(4) Zebra 利用 FPM接口 发送这个netlink-route消息至fpmsyncd.
(5) Fpmsyncd处理该netlink消息然后推送该消息至APPL_DB.
(6) 作为订阅APPL_DB的订阅者，orchagentd将接收之前被推送至APPL_DB的信息内容。
(7) 完成对接收信息的处理后，orchagentd将引用sairedis APIs完成对ASIC_DB的路由信息注入。
(8) 作为订阅ASIC_DB的订阅者，syncd将接收 产生于orchagentd的 新状态信息。
(9)Syncd将会处理信息，然后引用SAI APIs，将这个状态信息注入到相应的asic驱动器中。
(10) 最终，新路由信息被推送到硬件。