7.0 正式推出！此版本代表着来自 861 名核心开发者的 10,000 多个 Pull Request（提取请求），所以首先要向我们的员工和社区成员表示衷心的感谢。
如果您想听一听代码幕后的工作人员对本版本的介绍，我们将于 2019 年 4 月 25 日晚上 11 点（北京时间）举行一场现场网络发布会。欢迎您届时参加发布会，观看 7.0 演示，在 AMA 环节与来自全球各地的 Elastic 工程师对话，活动内容十分丰富。
Elastic Stack 7.0 现在即可下载，或者您也可以在 Elastic Cloud 上的 Elasticsearch Service 中快速部署完全托管式集群；Elasticsearch Service 是唯一在 Elastic Stack 发布当天即可提供最新版本的托管式解决方案。
7.0 版本有那么好处，都有些不知道该从哪里说起了，所以我们直奔主题吧。
Kibana 7.0：全新设计和导航……还有夜间模式！
设计 Kibana 7.0 时，我们决定主要关注内容，所以您会看到整个 UI 都更加轻量化，更富极简主义风格。最重大变动是改用新的全局导航，此导航引入了固定标头以方便用户切换 Kibana 空间、显示面包屑导航路径，以及完成诸如更改密码和退出等用户操作。为了实现这一目标并提高一致性，我们创建了 Elastic UI Framework。去年一整年，我们几乎将整个 Kibana 都切换到了这个框架的组件上。借助这些组件，以及我们设计和开发团队的巨大努力，我们还对样式和样式表的应用方式进行了大幅简化。
由于一致性和样式表均得以改善，这使得我们能够完成 Kibana 有史以来人们呼声最高的一项功能请求：在 Kibana 中支持全局夜间模式。这些变更还带来了另一个好处，即 Kibana 仪表板目前采用响应式设计，这是我们大幅改善移动设备上易用性的第一步。
Elasticsearch 集群协调迎来新时代
从一开始，我们便专注于让 Elasticsearch 可轻松进行扩展，并且拥有弹性以应对灾难性故障。为了满足这些要求，我们采取了多种方法，从提高单个节点的可扩展性和可靠性，到持续改善我们的集群协调层 Zen Discovery。在 7.0 中，我们再一次在这两方面实现了重大改进。
Elasticsearch 包含一个全新的集群协调层，更快捷，更安全，也更易于使用。为了实现这一目的，我们在开始时专注于使用 Formal 模型来对设计进行验证，以确认我们全新分布式一致性算法的理论正确性。尽管已经有很多广为人知的一致性算法，例如 Paxos、Raft、Zab 和 Viewstamped Replication (VR)，但由于 Elasticsearch 集群要求实现更高的集群变更吞吐量，支持轻松扩大或压缩集群，且能够提供无缝的滚动升级策略以允许 6.7 集群滚动升级至 7.0，所以前边提到的算法均无法达到这些要求。新的集群协调层同时还包括很多能够降低人为错误几率的变更，并且从灾难性故障中恢复时可以提供更加明确的选项。要想一下子同时提高可靠性、性能和用户体验，这可不是一件简单的事，在这样一个集中式的组件中尤为如此。我们对新的集群协调层以及自己取得这一成果的过程充满自豪。如需了解详情，请阅读博文。
我们在 Elasticsearch 中构建单独节点时已将弹性考虑在内。如果您向某个节点发送过多请求，或者如果您的请求过大，节点可能会将您的请求推回。我们在 Elasticsearch 中通过采用断路器来实现这一过程，如果断路器确定节点无法处理特定请求，会立即发送响应并要求客户端重试（可能需要换一个节点）。对于 JVM 堆规模较小的节点（随着用户开始改用单租户集群模型，而不再使用大型的多租户集群，此情况越来越普遍），这一点尤其重要。在 7.0 中，我们推出了真正的内存断路器，此工具能够在极大程度上提高针对无法处理请求情况的检测准确性，并防止这些请求导致单个节点不稳定。如果希望深入了解这一变更如何改善整体节点和集群的可靠性，请阅读博文。
提高各种用例的相关度和速度
相关度和速度是良好搜索体验的基石。Elasticsearch 7.0 推出了多项基础功能来对这两方面加以改善。
- Top K 查询的速度更快：在很多用例中，用户在查询时，快速看到排名前 K（Top K，例如排名前 20）的结果比看到准确的匹配条数（亦即符合查询条件的结果总数）要重要得多。举例说明，如果某人正在电商网站上搜索一件商品，他/她可能更关心相关性最高的前 10 条结果，而对符合查询条件的另外 120,897 条结果则可能根本不在乎。Elasticsearch 7.0（以及 Lucene 8.0）采用了新算法 (Block-Max WAND)，该算法在检索前 K 个结果时能够巨幅提高查询速度。
- **间隔查询：**某些搜索用例（例如法律和专利搜索）需要查找单词或短语间距离在特定范围内的记录。Elasticsearch 7.0 中的间隔查询针对此类查询引入了一种全新的构建方式，与之前的方法（span 查询）相比，可极大简化使用和定义过程。与 span 查询相比，间隔查询针对边缘用例的弹性也要出色得多。
- **函数分数 2.0：**自定义评分是高级搜索用例中最基础的内容，因为用户在高级搜索用例中希望更精细地控制相关度和结果排名。Elasticsearch 从早期就实现了这样的功能。7.0 推出了新一代函数分数功能，此功能可以通过更简单、更灵活的模块化方式针对每条记录生成一个排名分数。通过新的模块化结构，用户能够混合和匹配一组算术和距离函数，从而构建任意的函数分数计算方式，进而在更大程度上控制结果的评分和排名方式。
使用 geotile 网格在 Elastic Maps 中更平滑地缩放地图
多年以来，我们针对地理数据的支持一直在不断提升，从早期向 Elasticsearch 首先添加地理数据支持功能，到向 Lucene 中推出 Bkd 树数据结构并通过此结构将地理形状的查询性能提高超过 25 倍，再到在 Kibana 中为全球基础地图提供支持的 Elastic Maps 服务，都是我们的硕硕成果。
在 7.0 中，我们继续投入精力改善这一领域，在 Elasticsearch 中推出了新的聚合来对地图磁贴进行处理，以便让用户能够在不更改结果数据形状的前提下对地图进行缩放。新的 geotilegrid 聚合会将 geopoints 组合到代表网格中单元格的 bucket（桶）中，其中每个单元格均对应至地图中的磁贴。在此次变更之前，由于矩形磁贴在不同缩放级别下会更改方向，所以，形状边缘会随着缩放级别的变化发生轻微改变。7.0 中的 Elastic Maps 业已采用这种新聚合，确保您的视图在缩放过程中会保持稳定。无论您希望保护自己的网络免受攻击，还是调查为何特定地点的应用程序响应时间长，或者跟踪弟弟在太平洋屋脊步道上徒步，实现这种级别的准确性都至关重要。
支持达到纳秒级精度，强化时序型用例
无论是基础设施指标、系统审计日志、网络流量，还是火星漫步者，时序型数据都是很多用户使用 Elastic Stack 完成的中心工作。用户需要能够精准地跨多个系统和多项服务对事件进行排序和相关性分析，这一点至为关键。
截至今日，Elasticsearch 仅支持以毫秒级精度存储时间戳。7.0 则将小数点又往后推了好几位，可以实现纳秒级精度，这样有高频数据收集需求的用户便能实现所需精度以准确地存储和排序相关数据。之所以能够实现这一改进，是因为我们从传统的 JODA 库迁移到了 JDK 8 中官方的 Java time API。