envoy源码阅读之线程模型

background

envoy底层使用libevent构建网络IO处理流程。同步代码转换成event based model需要在遇到IO的时候拆分成callback的形式，基本上切换到不同IO对象时都会进行callback切换，很容易形成callback hell，对于开发者来说是件比较痛苦的事情。所以golang这种自带协程的语言，即有开发上的便捷，又能享受性能上的提升，作为后端服务开发大大提高了效率。

但是作为proxy，内存分配回收频率是非常大的，作为关键路径上的核心组件，如果有GC对系统影响还是比较大的，使用c++是最合适的语言。

envoy使用absl作为基本的c++ library，是google开源c++项目的base library，之前看webrtc源码时也有看到。

thread model

envoy由一个main thread、一些（cpu核数个或通过concurrency参数指定）worker thread、辅助线程（file flush）组成。
每个线程拥有自己独立的dispatcher loop，互相之间不干扰，独立运行。代码逻辑写起来很简单，基本不需要考虑加锁的事情。

thread loop

使用libevent中的event_base作为最底层的event scheduler
代码在 source/common/event/dispatcher_impl.h。 可以看到post是线程安全的。

void DispatcherImpl::run(RunType type) {
  run_tid_ = api_.threadFactory().currentThreadId();

  // Flush all post callbacks before we run the event loop. We do this because there are post
  // callbacks that have to get run before the initial event loop starts running. libevent does
  // not guarantee that events are run in any particular order. So even if we post() and call
  // event_base_once() before some other event, the other event might get called first.
  runPostCallbacks();

  if (type == RunType::NonBlock) {
    base_scheduler_.nonBlockingLoop();
  } else {
    base_scheduler_.blockingLoop();
  }
}

在event based model实现中会使用大量的callback引用其它对象，如果直接删除，可能会在callback中使用导致core dump。DispatcherImpl中添加了deferredDelete接口延迟对象的删除，deferred_delete_timer_ enable之后会在下次event loop中进行真正的删除。

main thread的dispatcher_在source/server/server.cc中InstanceImpl constructor中建立。listener_manager_初始化时新建options().concurrency()个worker，每个worker有自己独立的dispatcher。

//source/server/worker_impl.cc
WorkerPtr ProdWorkerFactory::createWorker(OverloadManager& overload_manager) {
  Event::DispatcherPtr dispatcher(api_.allocateDispatcher());
  return WorkerPtr{new WorkerImpl(
      tls_, hooks_, std::move(dispatcher),
      Network::ConnectionHandlerPtr{new ConnectionHandlerImpl(ENVOY_LOGGER(), *dispatcher)},
      overload_manager, api_)};
}

InstanceImpl run()时listener_manager_ startWorkers()把所有的listener添加到worker中。

WorkImpl start()时会创建真正的thread。

// source/server/worker_impl.cc
void WorkerImpl::start(GuardDog& guard_dog) {
  ASSERT(!thread_);
  thread_ =
      api_.threadFactory().createThread([this, &guard_dog]() -> void { threadRoutine(guard_dog); });
}

多线程服务是很容易产生死锁的。在这种event based的thread loop中，所有event的callback都是由dispatcher处理的，在dispatcher中添加一个timer以一定间隔不停地更新touch_time，由另外的线程检测touch_time是否过期，即可检测程序是否发生了死锁或死循环。

inter thread communication

如thread loop一节中所述，dispatcher的post是加锁的，通过post将callback放到其它线程的dispatcher待执行列表中，在dispatcher所在线程的loop中真正被执行。

在ListenerManagerImpl::addListenerToWorker中通过回调中调用post，在main thread中完成listener统计及其它工作。

threadlocal也使用post完成thread_local_data_的link、remove、update等。

thread local storage

实现在source/common/thread_local/thread_local_impl.*中。分配了一个slot vector。

参考

https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310