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