在C++后端服务器开发中，架构设计是决定系统性能、可扩展性和可维护性的关键因素之一。尽管不同的业务需求会导致服务器架构的多样化，但网络通信模块作为所有服务的通用部分，为我们提供了一个抽象和讨论的基础。基于此，我们可以将服务器架构分为两大类：非侵入式架构和侵入式架构。
非侵入式架构：简单高效的内部数据流动
非侵入式架构的核心特点是，所有通信和业务数据的流动都严格限制在网络通信框架的内部。这种架构下，数据的传输和处理完全由网络框架自身完成，无需外部数据源的介入。例如，在即时通讯（IM）服务中，无论是单聊还是群聊，消息的传递都在网络框架内部的连接对象之间完成。这种架构的优势在于其简洁性和高效性，特别适合那些业务逻辑相对独立且数据流动不需要外部干预的场景。
数据流动示例
假设用户A向用户B发送消息，消息从用户A的连接对象传递到用户B的连接对象，然后通过用户B的连接对象发送出去。整个过程都在网络框架内部完成，无需外部介入。这种架构的设计使得系统结构清晰，易于理解和维护。
侵入式架构：灵活应对复杂业务需求
与非侵入式架构不同，侵入式架构允许外部数据流入或流出网络通信模块。这种架构更加灵活，能够适应复杂的业务需求，但同时也带来了更高的复杂性和设计难度。
侵入式架构的两种典型形式
业务线程处理后发送
在这种架构中，业务线程负责数据的处理，处理完成后将数据交给网络通信组件发送。这种方式类似于生产者-消费者模型，业务线程作为生产者，网络线程作为消费者。网络解包后交由业务线程处理
这种架构更为复杂，网络线程在接收到数据并解包后，将任务交给业务线程处理。处理完成后，业务线程再将结果通过网络通信组件发送出去。这种架构适用于业务逻辑与网络通信紧密耦合的场景。
数据发送的两种实现方式
方式一：业务线程直接调用网络组件
在这种方式中，业务线程直接调用网络组件的接口函数发送数据。例如，以下代码展示了如何将数据发送给所有用户：
void WebSocketSessionManager::pushDataToAll(const std::string& dataToPush)
{
std::lock_guard<std::mutex> scoped_lock(m_mutexForSession);
for (auto& session : m_mapSessions)
session.second->pushSomeData(dataToPush);
}这种方式的优点是实现简单，但存在两个主要问题：
性能瓶颈：如果
pushSomeData方法耗时较长，可能会阻塞网络线程对m_mapSessions的访问，影响整体性能。线程安全问题：如果某个连接断开，网络线程可能会销毁对应的
session对象，而业务线程可能还在使用该对象的指针，导致野指针问题。
方式二：业务线程将数据交给网络线程发送
为了避免上述问题，可以将业务线程需要发送的数据交给网络线程处理。以下是一个实现示例：
void EventLoop::runInLoop(const Functor& cb)
{
if (isInLoopThread())
{
cb();
}
else
{
queueInLoop(cb);
}
}
void EventLoop::queueInLoop(const Functor& cb)
{
{
std::unique_lock<std::mutex> lock(mutex_);
pendingFunctors_.push_back(cb);
}
if (!isInLoopThread() || doingOtherTasks_)
{
wakeup();
}
}
void EventLoop::handle_other_things()
{
std::vector<Functor> functors;
doingOtherTasks_ = true;
{
std::unique_lock<std::mutex> lock(mutex_);
functors.swap(pendingFunctors_);
}
size_t size = functors.size();
for (size_t i = 0; i < size; ++i)
{
functors[i]();
}
doingOtherTasks_ = false;
}这种方式通过将任务放入队列并唤醒网络线程来处理，避免了业务线程直接操作网络组件，从而解决了线程安全和性能问题。
总结
非侵入式架构：适用于业务逻辑独立且数据流动完全在网络框架内部完成的场景。这种架构简单高效，易于理解和维护。
侵入式架构：适用于业务逻辑与网络通信紧密耦合的场景。在侵入式架构中，推荐使用方式二（业务线程将数据交给网络线程发送），以避免线程安全和性能问题。