Airbnb、Booking.com 和 OYO 等酒店预订应用程序如何提供从酒店列表到预订再到付款的流畅流程？ 而且都没有一个小故障！ 在此博客中，您将获得对此的详细解释。
由于它们非常庞大，以至于它们需要处理大量的用户流量。 所以要管理这些，我们必须遵循微服务架构。 这意味着我们必须为每种类型的任务将系统分成小块。
让我们一一了解流程。 我把它分成了4个部分：
- 酒店管理服务
- 客户服务（搜索+预订）
- 查看预订服务
酒店管理服务
这是将提供给酒店经理/业主的服务。 在此管理人员可以管理他们酒店的相关信息。 在这里，管理者有一个单独的门户来访问和更新数据。
- Hotel Management Service Architecture
每当从酒店管理器应用程序触发 API 时，初始请求都会发送到负载均衡器，然后负载均衡器会将请求分发到所需的服务器进行处理。酒店服务集群有多个服务器，这些服务器具有酒店服务相关 API 的容器。
现在，该酒店服务与遵循主从架构的酒店数据库集群进行交互，以减少数据库中的负载。基本上，在这种方法中，我们创建主数据库的副本，称为从数据库。 Master DB 用于写操作，slave DB 仅用于读操作。每当在主数据库上执行写操作时，它都会将数据同步到从数据库。
每当数据库中的任何数据更新时，API 都会将数据发送到 CDN（内容分布式网络）和消息队列系统（如 Kafka、RabbitMQ）以进行进一步处理。 CDN 是一组地理分布的服务器，它们协同工作以提供 Internet 内容的快速交付。
客户服务（搜索+预订）
这是将提供给客户的服务。在这个客户可以搜索和预订酒店。在这里，客户有一个单独的门户来访问和处理数据。
- Customer Service Architecture
CDN 应用程序向客户显示内容，例如附近的酒店、推荐、优惠等。
正如我们在上一节中讨论的，酒店数据在消息队列系统中发送以进行处理。这里我们有一个消息队列消费者，它从队列中获取数据并将数据存储在弹性搜索中。
客户应用点击 API，然后负载均衡器将请求重定向并将请求分发到相应的服务以处理请求。在这里，我们有两种服务，一种是搜索酒店，另一种是预订服务，用于预订酒店，预订服务还与第三方服务的支付服务进行交互。
搜索服务必须从 Elastic Search 中获取数据。 Elasticsearch 是一个 NoSQL 数据库，最适合其搜索引擎功能。
预订服务与 Redis 和预订数据库集群进行通信。 Redis 是缓存系统，它存储临时数据，因此数据不需要从数据库中获取，最终可以减少数据库的负载，也可以减少 API 的响应时间。
对数据库所做的任何更改都将发送到消息传递队列。然后消费者将从队列中取出数据并将其放入 Casandra。对于存档，我们使用 Casandra，因为随着时间的推移，数据库中的数据大小会增加，这会增加查询时间。这就是为什么我们可能需要从数据库中删除旧数据的原因。而 Casandra 是一个 NoSQL 数据库，擅长处理大量数据。
查看预订服务
此处向用户显示所有当前和旧的预订详细信息。经理和客户都使用此服务。
- View Booking Architecture
Customer/Manager 应用程序将请求发送到负载均衡器，并将请求分发到预订管理服务器。 然后通过 Redis 和 Cassandra 对数据的服务请求。 通过 Redis，它请求最近的数据，因为它是一个缓存服务器。 这可以减少应用程序端的加载时间。
最终设计
- Hotel Booking System Design
正如您在上面的设计中看到的，有一个用于通知的 Kafka 消费者，通知消费者发送通知。 这可能是针对客户/经理的，例如，每当客户预订酒店时，就会向经理发送通知，或者如果有新的优惠来了，就会通知客户。
Apache Streaming 服务从消息队列中获取数据并将其存储在 Hadoop 中，可用于大数据分析以用于多种用途。 比如业务分析、寻找潜在客户、受众分类等。
原文：https://medium.com/nerd-for-tech/system-design-architecture-for-hotel-b…