Fail to build / run on Ubuntu 20.04

Flare 后台服务开发框架

Flare Backend Service Framework

English Document

腾讯广告是腾讯公司最重要的业务之一，其后台大量采用 C++ 开发。

Flare 是我们吸收先前服务框架和业界开源项目及最新研究成果开发的现代化的后台服务开发框架，旨在提供针对目前主流软硬件环境下的易用、高性能、平稳的服务开发能力。

Flare 项目开始于 2019 年，目前广泛应用于腾讯广告的众多后台服务，拥有数以万计的运行实例，在实际生产系统上经受了足够的考验。

2021 年 5 月，本着回馈社区、技术共享的精神，正式对外开源。

特点

现代 C++ 设计风格，广泛采用了 C++11/14/17/2a 的新的语法特性和标准库
提供了 M:N 的线程模型的微线程实现Fiber，方便业务开发人员以便利的同步调用语法编写高性能的异步调用代码
支持基于消息的流式 RPC支持
除了 RPC 外，还提供了一系列便利的基础库，比如字符串、时间日期、编码处理、压缩、加密解密、配置、HTTP 客户端等，方便快速上手开发业务代码
提供了灵活的扩充机制。方便支持多种协议、服务发现、负载均衡、监控告警、调用追踪等
针对现代体系结构做了大量的优化。比如 NUMA 感知的调度组和对象池、零拷贝缓冲区等
高质量的代码。严格遵守 Google C++ 代码规范，测试覆盖率达 80%
完善的文档和示例以及调试支持，方便快速上手

系统要求

Linux 3.10 或以上内核，暂不支持其他操作系统
x86-64 处理器，也支持 aarch64 及 ppc64le，但是未在生产环境上实际使用过
GCC 8 或以上版本的编译器

开始使用

Flare 是开箱即用的，已经自带了所需的第三方库，因此通常不需要额外安装依赖库。只需要在 Linux 下，拉取代码，即可使用。

thirdparty/下面的压缩包我们通过Git LFS存储，因此在拉取代码之前您需要确保git-lfs已经正确的安装了。

构建

我们使用blade进行日常开发。

编译：./blade build ...，
测试：./blade test ...。

Flare还支持bazel作为构建系统，可以查看bazel support。

之后就可以参考入门导引中的介绍，搭建一个简单的RPC服务了。

调试

我们相信，调试体验也是开发维护过程中很重要的一部分，我们为此也做了如下一些支持：

测试

为了改善编写单测的体验，我们提供了一些用于编写单测的工具。

这包括但不限于：

示例

我们提供了一些使用示例以供参考，下面是一个简单的转发服务（同时包含RPC客户端及服务端的使用）。

#include "gflags/gflags.h"

#include "flare/example/rpc/echo_service.flare.pb.h"
#include "flare/example/rpc/relay_service.flare.pb.h"
#include "flare/fiber/this_fiber.h"
#include "flare/init.h"
#include "flare/rpc/rpc_channel.h"
#include "flare/rpc/rpc_client_controller.h"
#include "flare/rpc/rpc_server_controller.h"
#include "flare/rpc/server.h"

using namespace std::literals;

DEFINE_string(ip, "127.0.0.1", "IP address to listen on.");
DEFINE_int32(port, 5569, "Port to listen on.");
DEFINE_string(forward_to, "flare://127.0.0.1:5567",
              "Target IP to forward requests to.");

namespace example {

class RelayServiceImpl : public SyncRelayService {
 public:
  void Relay(const RelayRequest& request, RelayResponse* response,
             flare::RpcServerController* ctlr) override {
    flare::RpcClientController our_ctlr;
    EchoRequest echo_req;
    echo_req.set_body(request.body());
    if (auto result = stub_.Echo(echo_req, &our_ctlr)) {
      response->set_body(result->body());
    } else {
      ctlr->SetFailed(result.error().code(), result.error().message());
    }
  }

 private:
  EchoService_SyncStub stub_{FLAGS_forward_to};
};

int Entry(int argc, char** argv) {
  flare::Server server{flare::Server::Options{.service_name = "relay_server"}};

  server.AddProtocol("flare");
  server.AddService(std::make_unique<RelayServiceImpl>());
  server.ListenOn(flare::EndpointFromIpv4(FLAGS_ip, FLAGS_port));
  FLARE_CHECK(server.Start());

  flare::WaitForQuitSignal();
  return 0;
}

}  // namespace example

int main(int argc, char** argv) {
  return flare::Start(argc, argv, example::Entry);
}

Flare内部基于M:N的用户态线程实现，因此通过Flare同步的请求外界服务、使用Flare内置的各种客户端的同步接口均不会导致性能问题。如果有更复杂的并发或异步等需求可以参考我们的文档。

另外，示例中*.flare.pb.h通过我们的Protocol Buffers插件生成。这样生成的接口相对于Protocol Buffers生成的cc_generic_services而言，更易使用。

更复杂的示例

实际使用中，往往会面对需要并发请求多种后端的场景，下面的示例介绍了如何在Flare中进行这种操作：

// For illustration purpose only. Normally you wouldn't want to declare them as
// global variables.
flare::HttpClient http_client;
flare::CosClient cos_client;
EchoService_SyncStub echo_stub(FLAGS_echo_server_addr);

void FancyServiceImpl::FancyJob(const FancyJobRequest& request,
                                FancyJobResponse* response,
                                flare::RpcServerController* ctlr) {
  // Calling different services concurrently.
  auto async_http_body = http_client.AsyncGet(request.uri());
  auto async_cos_data =
      cos_client.AsyncExecute(flare::CosGetObjectRequest{.key = request.key()});
  EchoRequest echo_req;
  flare::RpcClientController echo_ctlr;
  echo_req.set_body(request.echo());
  auto async_rpc_resp = echo_stub.AsyncEcho(EchoRequest(), &echo_ctlr);

  // Now wait for all of them to complete.
  auto&& [http, cos, rpc] = flare::fiber::BlockingGet(
      flare::WhenAll(&async_http_body, &async_cos_data, &async_rpc_resp));

  if (!http || !cos || !rpc) {
    FLARE_LOG_WARNING("Failed.");
  } else {
    // All succeeded.
    FLARE_LOG_INFO("Got: {}, {}, {}", *http->body(),
                   flare::FlattenSlow(cos->bytes), rpc->body());
  }

  // Now fill `response` accordingly.
  response->set_body("Great success.");
}

这个示例中，我们：

通过三种不同的客户端（HTTP、腾讯云COS、RPC）发起了三个异步请求；
通过flare::fiber::BlockingGet同步等待所有请求完成。这儿我们只会阻塞用户态线程，不会存在性能问题；
打印日志输出各个服务的响应。

出于展示目的，我们这儿请求了三个异构的服务。如果有必要，也可以通过这种方式请求同构的、或者部分同构部分异构的服务。

参与开发

我们非常欢迎参与共同建设，对于希望了解 Flare 更多内部设计的开发者，或需要对 Flare 进行二次开发的开发者而言，flare/doc/下有更多的技术文档可供参考。

详情请参考CONTRIBUTING.md。

性能

由于业务需求的特点，我们在设计过程中更倾向于优化延迟及抖动的平稳性而非吞吐，但是也在这个前提下尽量保证性能。

出于简单的对比目的，我们提供了初步的性能数据。

致谢

我们的底层实现大量参考了brpc的设计。
RPC部分，grpc给了我们很多启发。
我们依赖了不少开源社区的第三方库，站在巨人的肩膀上使得我们可以更快更好地开发本项目，也因此积极地回馈给开源社区。

在此，我们对上述项目一并致以谢意。

	std::uint64_t SetTimer(std::chrono::steady_clock::time_point at,
	std::chrono::nanoseconds interval,
	Function<void(std::uint64_t)>&& cb) {
	// This is ugly. But since we have to start a fiber each time user's `cb` is
	// called, we must share it.
	//
	// We also take measures not to call user's callback before the previous call
	// has returned. Otherwise we'll likely crash user's (presumably poor) code.
	struct UserCallback {
	void Run(std::uint64_t tid) {
	if (!running.exchange(true, std::memory_order_acq_rel)) {
	cb(tid);
	}
	running.store(false, std::memory_order_relaxed);
	// Otherwise this call is lost. This can happen if user's code runs too
	// slowly. For the moment we left the behavior as unspecified.
	}
	Function<void(std::uint64_t)> cb;
	std::atomic<bool> running{};
	};

	auto ucb = std::make_shared<UserCallback>();
	ucb->cb = std::move(cb);

	auto sg = detail::NearestSchedulingGroup();
	auto timer_id = sg->CreateTimer(at, interval, [ucb](auto tid) mutable {
	internal::StartFiberDetached([ucb, tid] { ucb->cb(tid); });
	});
	sg->EnableTimer(timer_id);
	return timer_id;
	}

	template <class... Ts>
	using unboxed_type_t = typename std::conditional_t<
	sizeof...(Ts) == 0, std::common_type<void>,
	std::conditional_t<sizeof...(Ts) == 1, std::common_type<Ts...>,
	std::common_type<std::tuple<Ts...>>>>::type;

	// This lock is held when the fiber is in state-transition (e.g., from running
	// to suspended). This is required since it's inherent racy when we add
	// ourselves into some wait-chain (and eventually woken up by someone else)
	// and go to sleep. The one who wake us up can be running in a different
	// pthread, and therefore might wake us up even before we actually went sleep.
	// So we always grab this lock before transiting the fiber's state, to ensure
	// that nobody else can change the fiber's state concurrently.
	//
	// For waking up a fiber, this lock is grabbed by whoever the waker;
	// For a fiber to go to sleep, this lock is grabbed by the fiber itself and
	// released by `SchedulingGroup` (by the time we're sleeping, we cannot
	// release the lock ourselves.).
	//
	// This lock also protects us from being woken up by several pthread
	// concurrently (in case we waited on several waitables and have not removed
	// us from all of them before more than one of then has fired.).
	Spinlock scheduler_lock;

	struct hostent* he = nullptr;
	int error = 0;
	#ifdef _GNU_SOURCE
	char buf[4096];
	struct hostent he_buf;
	gethostbyname_r(hostname.c_str(), &he_buf, buf, sizeof(buf), &he, &error);
	#else
	he = gethostbyname(hostname.c_str());
	if (!he) error = h_errno;
	#endif
	if (!he) {
	SetErrorCode(error_code, error);
	return false;
	}

	auto msg = factory->Create(MessageFactory::Type::Overloaded,
	corresponding_req.GetCorrelationId(), stream);
	if (msg) { // Note that `MessageFactory::Create` may return `nullptr`.
	WriteMessage(*msg, protocol, controller, kFastCallReservedContextId);
	}

	// Argument `context` (i.e., `this`) is only used the first time the context
	// is jumped to (in `FiberProc`).
	jump_context(&caller->state_save_area, state_save_area, this);

	} else if (msg.msg_or_buffer.index() == 1) {
	auto&& pb = *std::get<1>(msg.msg_or_buffer);
	std::string rc;
	if (content_type_ == ContentType::kApplicationJson) {
	FLARE_CHECK(ProtoMessageToJson(pb, &rc, nullptr));

	std::deque<std::string> owning_strs_2_;
	// For better lookup (which is likely to be done frequently if we're
	// parsing, instead of building, headers) performance, we build this map for
	// that purpose. Values are indices into `fields_`.
	internal::CaseInsensitiveHashMap<std::string_view, std::size_t> header_idx_;
	// Referencing either `buffer_` or `owning_strs_`.
	NonowningFields fields_;

tencent / flare Goto Github PK

flare's Introduction

Flare 后台服务开发框架

特点

系统要求

开始使用

构建

调试

测试

示例

更复杂的示例

参与开发

性能

致谢

flare's People

Contributors

Stargazers

Watchers

Forkers

flare's Issues

编译环境 gcc 版本 11.2.0 (GCC)

这里缺少头文件, 加入头文件 optional 就行

这个我暂时将/usr/include/sys/cdefs.h中的__glibc_has_attribute (const)删了,希望有更好的解决办法

在thirdparty/curl/BUILD的configure_options里加入'--without-librtmp'和'--without-libpsl'

environment

.bazelrc add new configs

future_test tsan coredump

future_test asan coredump

Recommend Projects

Recommend Topics

Recommend Org