原文链接：https://www.elastic.co/blog/financial-services-trends-seen-at-elastic (需要梯子)
在我 Elastic 公司担任解决方案架构师期间，金融服务（Financial Services）是最令我感到振奋的行业。直到被问到可怕的问题，例如...
这个基础架构要多久才能完成并投入使用？
回答当然是时令人振奋的，要完成这种中端规格的服务，时间只需要从三个月到九个月不等。然后人们想知道为什么多年来在这个 FS 领域缺乏创新，读下去你就会知道答案！
在本文中，我将介绍一些我认为有趣且值得注意的金融服务技术趋势。
谁在使用 Elastic，又是为了什么而使用？
首先，在 Elastic 公司任职期间，让我不禁赞叹的是，Elastic 技术栈在各种各样不用领域和行业里面，都能得到充分的的使用。
对于 Elastic 技术栈的使用方式，可以像Citi(花旗银行)一样，将其作为日志解决方案(logging solution)，或者像Barclays(巴克莱银行)和USAA一样用于安全分析和威胁搜寻。但是，Elasticsearch 对于“搜索”也非常有用，如Rabobank和 Collector Bank等组织通过使用 Elastic 技术栈，来确保像 PSD2 标准(一项欧洲银行业法规)得以一致性地实施。
然而，您是否知道 Elastic 已成为所有金融服务组织的必备技术？以下是一些示例：
-
Goldman Sachs(高盛)使用我们的组件来跟踪和分析股票交易，以提供更好的财务指导。 -
FICO(费埃哲)使用 Elastic 技术栈来确定和保护您的信用评分。 -
Softbank Payment Service(软银)和Wirecard(一家德国银行软件公司)都使用我们的产品来监视交易，服务器性能，以及欺诈行为的发生。 - 我们也有几家投资银行致力于制定解决方案，以帮助缓解新的《欧盟 CSD 法规》（该法规侧重于交易的后期结算）带来的影响。
各种例子不胜枚举，但希望您能理解我的所说的重点。
作为方案解决架构师团队的我们，看了到什么趋势？
在金融服务部门工作的人都知道,各种监管法规总是不停变化的，在过去的几年中，诸如 CSDR，开放银行（PSD2），MiFID II 等法规的增强。诸多变化迫使公司不停发展并适应这些新要求。让我给你举个例子：
由于更加的开放银行法规而产生的变化
顾名思义，更开放银行意味着,“我们”也就是金融产品的消费者有权访问和使用我们认为合适的各种数据。在此之前，您真正能查看到的交易信息，被限制在所银行提供的各种条款中。比如，邮寄中收到的银行对帐单。在引入网上银行业务之后，这种透明度得到了提高，并最终导致了更加开放的银行业务需求的形成。
我们与许多客户的共同讨论点之一是，为了符合开放银行法规，他们如何抵消为支持传统数据存储（主要是大型机），而增加的硬件资源所带来的额外开销。这时，你就可以看到 Elasticsearch 带来的作用。
如您所知道的，自上世纪 50 年代以来，大型机已成为所有金融机构的事实上的记录系统。他们现在面临的问题是，这些系统从未被设计为支持实时客户交互功能，特别是不能支持动态 API 调用。这项新要求允许金融机构的所有客户随时随地访问他们的数据。我们与金融机构进行的一次反复对话是，他们需要购买多少 MIPS(处理器的一种) 才能处理因其 Open Banking API 带来的新工作量。使用 Elastic 技术栈，无需对昂贵的专有技术进行昂贵的投资。
以下是一些关键点，这些点说明了为什么 Elastic 非常适合这些情况：
API 优先 - Elasticsearch 的 RESTful API 允许更快，更简单地采用 PSD2 法规，因为您不必在没有这些功能的系统中，回溯性地重新构建这些功能。
并行操作 - 大型机等传统系统在组织中占有一席之地（高速交易处理），并且短期内不会被取代。但这并不意味着您不能同时运行两者。我们看到了一些组织取得巨大成功，这些组织从其传统系统中获取需要实时处理的数据提要，并使用现代数据存储方式进行保存，使其能够进行更为创新的处理方式，并提供更新的功能。
水平可伸缩性 - Elastic 技术栈可以轻松扩展到任何规模，而无需停机。这些功能是所有现代新系统的关键功能，Elasticsearch 对此都有着丰富的支持，因为我们整个技术栈创建的核心原则是“性能，可伸缩性和相关性”。
易于管理 - IT 部门的预算越来越少，并且被要更线性的管理操作方式。其中，自动化是在不影响技术采用的前提下，降低成本的关键方法之一。
Elastic Cloud企业版和Elastic Cloud on Kubernetes可以让任意规模的组织，在仅需一个熟练的小型团队的情况下，即可管理其 Elastic 技术栈部署。仅仅只需要几个熟练的工程师，机构就可以管理数百（或数千）个 Elasticsearch 集群.
作为一个真实的例子，Rabobank（荷兰合作银行）撰写了一篇很棒的文章，谈论了其基于 Elastic 实现的服务，以保障它们可以满足法规要求的额外需求，并随着需求的增长而增长 。
贸易追踪或/和中央证券存管条例
中央证券存管条例（CSDR）是一项已生效的新条例，我已经对其进行了更深入的讨论，您可以在我以前一篇关于 CSDR 合规性的博客中找到它。从我写的文章中提取一个关键点是：
CSDR 要求参与者在预定的结算日期进行交易结算。为了鼓励及时的结算，CSD 必须监视失败的结算情况并将其报告给有关当局。
该声明的关键部分是旨在，所有投行在结算交易时都需要知道内部发生了什么。组织的收购与合并过程中，除了原组织遗产的重组，也伴随着遗留的技术重组，这导致交易结算中的各种系统相互纠缠。为了弄清内部发生的情况，这意味着在许多情况下，会查询大量不同日志，衡量和审核更多的数据，去了解正在发生的真实情况。
一个成功的交易跟踪系统不仅仅只需要一个记录系统。它需要这个系统更加得快速，健壮，弹性和智能。Elastic 技术栈非常适合这些要求：
可观察性（Observability） - 跟踪和查看正在发生的情况，是此需求的关键点。Elastic 非常理解日志,各种系统性能指标和 APM 数据是这一工作的基础，并且尽力提供相关功能。
灵活性（Flexibility） - Elasticsearch 具有难以置信的灵活性，它不仅可以处理一系列不同的数据源，而且还可以处理多种不同格式的数据。这为团队迭代建立自己的通用数据格式或能够在Elastic Common Schema的基础上实行标准化。
规模（Scale） - 规模至关重要，因为一般情况下，工作需要收集的数据量很大。为了提供连续的。未删减过的交易视图，您需要来自所有结算系统的数据。这些大量数据被要求能快速载入系统中，当然，使用 Elasticsearch 时，这不是问题。我不仅仅是说说，可以参考Uber 是怎么说的，这篇文章介绍了他们
关于如何扩展 Elasticsearch，使其能够每秒处理多达130万个事件的讨论。速度（Speed） - 当您依赖存储的数据来决定关键业务操作时，速度至关重要。这是 Elasticsearch 可以处理的，Uber 在上述讲话中也对此进行了说明。他们运行的集群具有超过 1PB 的数据，而这仅需要亚秒级的响应时间，这意味着系统以每秒多达 40 亿个文档的速度进行着扫描。
机器学习(Machine learning) - 我们正在看到使用 Elastic 机器学习功能来为不正常的结算行为，建立预警系统。这有助于组织在预计的结算日之前解决问题。这使他们有时间解决问题，即使该问题发生在结算周期的早期。
在结算交易时，对内部系统步骤的可见性和理解,正是Goldman（高盛）在构建下一代交易跟踪方案时需要着手解决的问题。 通过观看their presentation from Elastic{ON} 2016，了解有关其系统的更多信息。
结论
希望这可以让您深入了解 Elastic 的解决方案架构师每天在现场讨论的一些关键金融服务用例。 如果上面有一个您感兴趣的话题，请不要犹豫。
