概述

kumo c++ 弹性基础架构开发指南综述。

kumo c++ 弹性基础架构(elastic architecture)

kumo c++ 弹性基础架构 意为 Kumo 可扩展c++开发基础架构，英文为kumo c++ elastic infrastructure architecture。以下 简称 kumo EA或者 EA

EA 是一个开源 C++ 库集合，取自 Kumo 各产品代码库的最基本部分。这些库是支撑 Kumo产品 运行的几乎所有内容的具体细节。 这些 API 的各个部分都嵌入到我们的大多数开源项目中和非开源产品中。

EA的目标是将它们整合到一个综合项目中，并保证它的稳定运行。这些项目包括我们在过去十几年搜索方面积累并在生产环境中运行稳定的源代码，也整合互联网上 比较著名开源实现。

我们发布 EA 的主要目的是更轻松地支持 Kumo 产品接入以及基于 Kumo 开源项目和产品快速构项目。

编码风格

Kumo 代码遵循官方 Google C++ 风格指南。 Kumo 代码中的其他约束/问题与上面的有所不同，如下所示。

Kumo扩展规则

Kumo在其生产代码中不使用异常。我们当然不要求您遵守这样的政策。但是，您应该意识到对代码库的一些影响。

我们不认为移动构造函数抛出异常有充分的工程理由。至多，我们将允许移动构造函数因分配而抛出异常。在 Kumo 代码中， 如果在没有 -DTURBO_ALLOCATOR_NOTHROW 的情况下进行编译，则移动构造函数不会抛出异常，除非是由于分配原因。 使移动构造函数符合此标准可以实现更好的优化，特别是与标准库行为结合使用（std::vector 使用非抛出移动构造函数更有效地调整大小）。

一般来说，我们会尝试在合理的 API 和设计中支持异常。然而，对于性能在哪些方面超越例外灵活性的问题，我们有自己的看法。 我们将尽力弄清楚异常在哪里是一个糟糕的设计选择，并在可能的情况下将事物标记为 noexcept 。不要将对异常的概念支持与所有地方对异常 的认可相混淆——如果你的哈希函子抛出异常，那你就只能靠自己了。

请注意 noexcept 的含义：这不是承诺不会发生异常，而是承诺如果异常逃逸该 API，则进程将以 std::terminate() 结束。

泄漏检查

Kumo 代码旨在与使用 LeakSanitizer (LSan) 构建的目标配合使用，LeakSanitizer (LSan) 是一种内存泄漏检测器， 作为附加组件集成在 AddressSanitizer (ASan) 中，也可以独立使用。所有 ASan 版本中默认启用泄漏检查。有关 LeakSanitizer 的更多信息， 请参阅 Address Sanitizer 文档

类构造

Kumo 除类stl容器之外的类，涉及到分配，系统资源等类的初始化，我们默认的设计是二阶段构建。这是为了在生产环境中，确保我们编程人员能 明确的确认资源，进而保障服务的稳定性和可测性，并设计了Status和Result用于函数的返回值，并携带错误信息给调用者。使得我们的调试工作 能够获得更多的帮助信息。

性能优化

Kumo的核心产品是搜索栏类的产品，搜索类的产品对服务端的性能要求比较高，性能方面我们尽最大可能保持在领先的行列。在不同场景下，我们不能保证 我们的服务和库在任何场景下都是领先的水平，比如服务端IO编程，我们在易用性,QPS,少长尾方面，我们最终的权衡是选择了易用性,少长尾这两个 选项，在QPS测试时，对比QPS标杆产品nginx要低，对于40核心服务器，我们rpc框架能达到40W的QPS,经过优化的nginx可以达到80W以上，这并不 意味我们的性能要nginx要弱，而是在业务业务场景下，我既不能做到每个链接相互无关，也不能不能完全不考虑多线程计算等因素而做出的一些取舍。