在当今这个充满活力的世界里，数据也是动态的。对于大多数公司都拥有并试图保持最新的客户、潜在客户和潜在客户的数据，这一点尤为明显。当您考虑更新驻留在多个产品（Freshdesk、Freshsales、Freshservice或任何其他第三方插件）的系统中的海量数据时，"同步"变得更加具有挑战性那么我们如何在不同的应用程序之间同步数据呢？在尽可能频繁地保持集成方面有哪些挑战？如何将同步失败降至最低？答案，一句话，就是新鲜管道。Freshpipe是我们的集成平台即服务（IPaaS），它源于我们2017年1月收购的Pipemonk，Pipemonk是一个数据集成解决方案，用于自动化跨多个云产品的数据流。然而，在我们能够为抽到我们的新数据宠儿Freshpipe而自豪之前，我们有些心痛。在收购Pipemonk大约两年之后，由于更多的产品和不断增长的数据量，云服务器购买，同步的数量显著增长，重新命名的《阿凡达》正处于生存危机之中。当面临大量客户流失的Freshsales团队开始从外部供应商那里寻找替代品时，事情几乎到了顶点。他们告诉我们，在Freshdesk和Freshsales之间发生的12%的同步错误并不能减少它这是我们在Freshpipe的所有人都要付出代价的时候。值得庆幸的是，我们不仅将Freshpipe变成了一个蓬勃发展的数据集成平台，而且还通过避免与外部解决方案相关的过高费用而节省了大量资金。通过自动化持续攻击它当时我们所做的是两件事：第一，我们同意评估一家外部供应商，中移物联网有限公司，该供应商可能是Freshsales最好的数据集成赌注（如果他们不得不把目光投向外部）。第二，我们一直致力于降低同步错误率和改进我们的平台。在评估了市场上的一些第三方平台，包括PieSync、Zapier、MuleSoft和Cloud Elements之后，我们向Freshsales团队提出了建议，并重新开始了自己的工作。到2019年第二季度，我们将错误率降低到10%，但仍然相当高我们煞费苦心地记录了当时Freshpipe同步应用程序为我们构建的集成所做的每一件事：Freshsales Hubspot、Freshsales Mailchimp和Freshsales Freshdesk。现在，Freshsales中有"leads"和"contacts"，数据存在于多个字段下。与Freshdesk同步的想法是正确的，这意味着更新一个软件中的任何内容都应该准确地反映在另一个软件中。我们所做的是记录下当一个工具中的每个字段都发生了变化，并且执行了同步，反之亦然。为了理解和解决这个问题，这样的文档是必要的，所以我们创建了一个全面的文档，它允许我们查看我们的数据，看看哪些同步失败以及为什么失败接下来，我们为预期的每个同步编写测试用例。另外，为了加快这个过程，我们编写了使之自动化的代码。例如，如果您在Freshsales中更新联系人的姓名，然后执行同步以检查Freshdesk中是否发生了相同的更新，这是由自动代码执行的自动化使我们能够快速确定发生同步故障最多的区域，我们决定首先解决这些问题。所以这是一种数据驱动的方法来修正错误然后在2019年7月左右，我们还自动化了查看错误日志的过程。这种自动化意味着，我们不必每天去查看前一天发生的错误，我们遵循12小时的同步频率来创建代表错误类别的票据。通过自动化，我们能够提取错误报告，现在可以更好地确定要修复的错误的优先级通过这种持续的自动化、优先级划分和错误修复，我们在相对较短的时间内显著降低了同步失败的数量当我们在5月份开始这个自动化过程时，我们每天创建大约150个错误记录单。到8月底，这一数字已降至每天45人。去年12月底，这一数字还不到15岁左右。所有这些都使得同步精度提高，并且在我们运行的多个集成中稳定在98%左右。我们是如何获得额外利益的2019年11月左右，Freshsales停止了对云元素的审查，并告诉我们，他们对Freshpipe iPaaS的发展很满意。根据我们的计算，如果我们公司与外部供应商合作，我们将额外增加100万美元的成本。有了Freshpipe的续集，我们可以省下这笔钱L2票证的数量急剧下降，这是因为我们现在可以在终端客户发现错误之前就发现错误，并且常常在他们做出反应之前就修复错误，而L2票证是由最终客户提出并请求支持的。在很多情况下，客户可能根本不知道出了什么问题，因为我们已经解决了这是通过教育客户支持团队了解Freshpipe平台的内部结构，并为一些团队成员提供快速解决问题的特权访问来实现的。因此，我们没有把问题从客户到支持，再从客户支持转到工程，然后一直拖到最后，我们取消了一整步我们面临的挑战在我们的数据同步之旅中，我们面临着几个关键的挑战。首先，当必须进行新的集成部署时，通常需要5到6个小时。在此期间，Freshpipe服务中断了15到30分钟。我们不希望这种破坏发生。我们使用一个自动部署脚本。此外，我们还引入了一个"双堆栈系统"，在这个系统中，我们可以在一个堆栈中进行部署，云服务器好还是，而另一个堆栈则可以正常工作。自动化脚本和双堆栈的结合不仅将我们的部署时间缩短到不到一个小时，而且还将停机时间减少到几乎为零执行基于脚本的部署的另一个好处是，团队中的任何人都可以通过一个简单的、单击式的过程来完成，而不是在您需要彻底了解我们的系统时另一个挑战与"会话管理"有关：当您登录时，您只需输入一次用户名和密码，然后您的会话就保存在一个名为会话密钥的密钥中。此密钥用于进一步验证您对平台的任何调用。为了维护会话密钥，我们使用了一种称为Hazelcast的技术现在，这个密钥需要在AWS托管的云中的所有机器上传播，这就是我们面临的一个障碍。不知何故，开心返利，当机器启动时本应发生的"握手"却没有发生为了解决这个问题，我们将会话密钥从集群中单个机器中维护到一个称为Redis的中心点。因此，任何需要密钥的机器现在都可以连接到Redis并从那里获取它。我们在开发Freshpipe时面临的另一个问题与我们使用MongoDB的方式有关，MongoDB是应用程序的文档存储数据库。我们没有旧的代码库，但仍在继续使用该系统（代码是由Pipemonk的前一个团队编写的，他们要么离开了，要么转移到了其他项目中）。而且，在大约两年的时间里，这个数据库的大小已经增长到了3TB左右。数据库没有加载，我们无法向其写入任何内容。在这个问题上，我们在30天内都没有使用过"数据收集"。此外，我们删除了未使用的"索引"。之前，我们的技术堆栈包括五个组件Redis、Hazelcast、MySQL、Mongo和RabbitMQ。在新的架构中，我们将其缩减为两个，MySQL和Redis。这确实简化和加快了系统，是我们在Freshworks遵循的民主设计实践的象征。未来在酝酿中我们计划未来最大的事情是转向实时数据同步。早些时候，我们每12小时进行一次同步。最初，我们考虑将这个时间缩短到三到四个小时，但是为什么不尝试实时同步呢？到第一季度末，物联网水表，我们希望能够实现目前为止构建的五个集成的实时同步：Freshsales Freshdesk、Freshdesk Hubspot、Freshsales Mailchimp、Freshsales Hubspot和Freshteam Freshservice。另一个重要的步骤是向市场开发者开放我们的平台。目前，只有Freshpipe团队编写和发布同步应用程序。但很快，我们将使Freshworks marketplace开发者能够使用Freshpipe创建自己的同步应用程序。我们正在尝试公开restapi，开发人员可以利用它来编写这些应用程序。我们相信，这将真正释放Freshpipe的潜力，因为人们将能够为他们所使用的产品的任何特定用例编写同步应用程序。到今年年底，我们预计将在我们的平台上编写20-30个同步应用程序。我们希望开发人员编写和发布同步应用程序所需的时间不超过一周，该应用程序目前接近一个月。有了新的积木我们已经到位，这应该是轻而易举的。合著者：Vijay Lakshminarayanan撰稿人：桑杰·古普塔相关岗位所有涉及到民主设计帮助小部件的工程Kubernetes收养管理指南