江苏龙网

  1. 首页 > 资讯 > 科技 > >

【InfoQ】Zocdoc 的事件驱动架构实践


【InfoQ】Zocdoc 的事件驱动架构实践
本文插图

作者丨Anwesha Das
译者 | 平川
策划 | 万佳
本文最初发布于 Zocdoc 技术博客 ， 经原作者授权由 InfoQ 中文站翻译并分享 。
ZocDoc 成立于 2007 年 ， 是一家在线医生预约平台 。 它根据地理位置、保险状态及医生专业为患者推荐医生 ， 并可在平台上直接完成预约 。 Zocdoc 采取对患者免费 ， 向医生收费的商业模式 。
在 Zocdoc ， 我们提供一个连接病人和医疗服务提供商的平台 。 虽然 ， 大多数访问 Zocdoc 的人都熟悉我们面向病患提供的产品 ， 这些产品确保人们能在网上找到医生并在线预约 ， 但他们可能不太熟悉我们提供的面向服务提供商的工具 。
针对服务提供商 ， 我们负责构建和维护这些系统 ， 让医生能执行各种任务 ， 如确认预约、更新他们的就诊原因或接受的保险 ， 并跟踪他们的表现 。 我们的目标是帮助医生最大限度地利用 Zocdoc 的市场 。
微服务之旅
从 2015 年开始向 AWS 过渡以来 ， Zocdoc 的大多数团队已经从单体应用程序迁移到全新的微服务架构（这里列出了单体应用的缺点） 。
然而 ， 由于我们拥有大量的工具以及单体应用中领域之间的紧密耦合 ， 提供商方面的迁移已经滞后 。
这种新架构在可伸缩性、敏捷性和灵活性方面给我们带来很多好处 ， 因此 ， 今年 ， 我们共同努力加快了微服务的采用 。 这样 ， 随着不断摆脱单体（我们亲切地称之为 OOM 项目） ， 我们最终实现了所提出的“微服务优先”策略 。
Martin Fowler 将其描述为 ， “从几个粗粒度的服务开始 ， 比预期的最终服务要大 。 然后 ， 随着边界的稳定 ， 分解为更细粒度的服务 。 “这个策略很有效 ， 因为它使我们能快速构建新的试验工具和功能 ， 首先从一个简单的版本开始 ， 看看如何回应 ， 然后再致力于开发一个完备的、可扩展的产品或微服务 。 ”
分布式数据的困境
我们继续发展这个微服务架构 ， 但由于其数据访问的分布式特性 ， 遇到了一些复杂性 ， 比如在预约时 ， 我们跟踪的核心数据是归提供商所有 ， 比如医生的网站 。 正确地归因这些数据 ， 以确定会话是从哪里产生的 ， 这对我们来说至关重要 。 无论它是一个医生工作地点的网站还是通过 Zocdoc 提供的像 SEO 这样的渠道 ， 所以我们需要一种方法来将我们的 appointment-attribution 和 practice-website 的数据串联起来 。
然而 ， 在微服务世界中 ， 每个服务拥有的数据是该服务的私有数据 ， 只能通过服务的 API 访问 ， 就像我们的 appointment-attribution-service 和 practice-website-service 一样 。 （注意：这种封装是必要的 ， 可以确保微服务是松耦合的 ， 并且可以独立开发 。 否则 ， 如果多个服务共享同一个数据库 ， 那么任何模式更新都需要对所有服务进行耗时的协同更新——这是我们过去的惨痛教训） 。
此外 ， 我们在 AWS 上运行的不同服务经常使用不同类型的数据库 ， 如 SQL 或类似于 SQL 的 Aurora、DynamoB、ElasticSearch 等 ， 这让数据访问变得更加复杂 。 最后 ， 这导致了两个主要的分布式数据挑战 。
1. 分布式事务
第一个挑战是维护跨多个服务的事务的数据一致性 。 与使用 ACID 数据库的单体应用不同 ， 我们不能简单地使用本地数据库事务 。 在分布式系统中实现一致性的一种方法是使用分布式事务协议 ， 比如两阶段提交（2PC） 。
然而 ， 2PC 通常是非常复杂的 ， 不是现代 Web 服务的一个可行选项 。 本质上 ，CAP 定理强行规定了你要在可用性和一致性之间进行选择 。 在我们的用例中 ， 可用性是更好的选择 ， 因为我们无法承受由于次要操作（如预约归因）而导致的预订流中断 。


推荐阅读


上一篇：【技术】CTP vs 刀片 vs 蜂窝，三种电池技术PK谁会胜出？| 中国汽车报

下一篇：【手机大魔王】小米10：声色影音，想你所想