城市导游服务宗旨

城市指南将是允许用户搜索和查找用户位置附近的地方的服务。您可以认为这项服务将类似于 Foursquare。在开始设计系统之前，最好先定义系统的用途。这意味着，在设计流程之前，需求应该是清晰和明确的。城市指南服务的目的是根据用户的位置向用户展示位置。您可以找到任何地方，例如餐厅、剧院、电影院等。建议将从附近位置开始到远处位置，但系统还将支持基于专用位置搜索位置。

要求和系统边界

如果你想设计一个系统，你必须首先定义需求和系统边界。在开始设计之前，您将拥有服务设计文档，并且您将从头开始定义所有需求。由于城市导览服务的目的是打造架构完善的城市导览服务，它必须能够根据您的搜索查询和位置推荐地点。所以我们的系统会支持这些功能；

   – 用户必须能够创建帐户。

   – 用户必须能够登录系统。

   – 用户必须能够从系统中注销。

   – 用户在登录或注销时必须能够搜索餐厅、剧院、咖啡馆、电影院等场所。

   – 用户登录后必须能够向地点添加评论。

   – 用户必须能够喜欢或不喜欢地点。

   – 用户必须能够添加新地点，并且系统管理员应该对其进行审核。

   – 用户必须能够将图片添加到地点。

   – 如果有权限，用户必须能够更新或删除地点。

   – 系统必须能够建议从最相关到不太相关的地点。

   – 系统必须能够根据用户的查询和位置建议地点。

   – 系统必须能够根据人气和用户评论推荐地点。

   – 系统必须能够监控。

   – 系统必须能够通过发送推送通知来推荐新地点。

   – 系统应该是高度可用的。

   – 系统应该是高度可靠的。

   – 系统应该是耐用的。

   – 系统应该是有弹性的。

   – 系统应该具有很高的成本和性能效率。

基本上系统应该支持 5 个重要的支柱：

   – 可用性

   – 可靠性

   – 弹性

   – 耐用性

   – 性价比

这些是我们应该一起考虑的支柱，因为它们是相互耦合的。简而言之，可用性意味着系统应该始终可用。可靠性意味着系统应该按预期工作。弹性意味着如果出现任何问题，系统将如何以及何时恢复自身。持久性是系统的每个部分都应该存在的支柱，直到我们删除为止。性价比也是一个重要的话题，基本上与成本效率下的使用服务有关。可以这样说明，如果系统将构建在 AWS 上并且使用 t2 微型 EC2 实例就足够了，那么就没有任何理由使用更大的 EC2 实例并支付额外费用。

请注意，每个系统都会日益增长，因此系统在未来会变得更加复杂（比如 5 年后），但重要的是如果您有明确定义的需求和结构，那么添加新组件不会有太多工作到您的系统。

定义系统边界和功能要求时，需要考虑云或承诺选项。云服务具有成本效益、高速性能、备份解决方案、维护、无限存储容量等诸多优势。您的系统可以；

   – %100 on-promise（您自己的数据中心/服务器）

   – %100 云（AWS、Google Cloud、Azure）

   – on-promise 和云的混合（您可以在迁移过程中同时拥有两者）

首先，容量估计将很重要（尤其是对于承诺服务），因此您可以估计您需要多少服务器数量或如何分离您的服务以及您将使用哪个数据库？另请注意，您的系统将读取繁重，读取流量将超过写入流量。

假设 5 年内城市指南系统将有 1000 万个名额，每日查询数将达到 10.000。您可以估计系统每年都会增长，并且可以估计缓冲区。这意味着您将保留 1000 万个地点信息及其元数据和图片。如果我们假设照片的平均大小为 25 KB，每个地方平均有 5 张图片；

容量大约等于 1000 万 * 5 * 25 KB +（用户元数据信息）+（位置元数据信息）。建议有数据的复制和备份解决方案以防止数据丢失，因此它将比我们估计的大约 3 倍大。

此计算只是如何定义系统容量的简单示例，我们不会计算每日下载/上传容量和元数据容量，但您应该考虑此计算（以及每日读取/写入容量估计）以进行服务/数据库扩展。

API ESTIMATION

城市指南服务可以同时支持 REST 或 SOAP 策略。您也可以考虑 GRPC，这是来自 Google 的新策略，GRPC 的最大优势是使用更小的带宽和资源。如果我们继续使用 REST，将有四个主要的 API 来设计系统。

  – AddPlace(api_dev_key, name, description, longitude, latitude, category, pictures)：此 API 返回 HTTP 响应以及新添加的地点信息。（如果成功则接受 202）

  – DeletePlace(api_dev_key, placeID)：它可以根据您的响应返回 HTTP 响应 200 (OK) 或 204 (No Content)。

  – UpdatePlace(api_dev_key, updatePlaceRequest)：updatePlaceRequest 将有一个 placeID 来知道我们正在更新哪个地方。

  – GetPlace(search_query, userlocation, categoryfilter = null, sortby = 'distance || popular', page = 1, distanceRadius = 5, maximum_return_count = 20)：返回带有位置元数据的 JSON。结果将根据用户查询和位置进行排序。

设计和数据库模式

保存数据将分为两部分。第一个将与保留静态内容（如位置图片）有关。如果我们正在构建我们的服务 AWS，我们可以使用 S3 来保持静态内容，并且在 S3 之前，我们可以使用 Cloudfront 作为 CDN。Cloudfront 将充当缓存，它将帮助系统快速返回响应。如果您将系统构建为一个承诺，那么您需要有图像存储。S3 是 AWS 提供的，它将帮助我们的系统以安全的方式保存静态媒体内容。对于元数据（地点、图片、用户），我们可以使用 SQL 和 NoSQL。NoSQL 是轻松扩展系统的最佳方式。另一方面，如果我们考虑 SQL 的关系和约束，扩展 SQL 数据库是非常困难的。

   –地点： ID、AddedBy、名称、纬度、Lng、类别、描述、AddedDate、LikeCount、DisLikeCount

   –用户： ID、用户名、密码、电子邮件、RegisterDate、LastLoginDate

   –评论： ID、Like、DisLike、评论、评论日期

   – UserPlaceComment : ID, CommentID, UserID, PlaceID

8 个字节足以保存 placeID 和 userID。此外，我们将保留经度和纬度为 8 个字节。数据将根据 placeID、lat 和 lng 进行索引。我们将根据地点位置和用户位置向地点表发送查询。所以查询将评估；

（userLongitude - Radius 和 userLongitude + Radius 之间的 placeLongitude 和 userLatitude - Radius 和 userLatitude + Radius 之间的 placeLatitude 的地方）

这种方式不是最佳方式，因为我们需要同时计算纬度和经度。我们可以使用网格来解决性能问题。我们可以将整个世界划分为更小的网格。这确保了我们只能处理网格的邻居。由于这种方法，我们只关注用户位置网格及其相邻网格。地图是使用网格的最佳选择。键是gridID。值是此网格中的所有位置。所以查询将评估；

（纬度在 userLatitude - Radius 和 userLatitude + Radius 和 GridID 之间的地方（相邻网格）

请注意，我们当然会有更多的数据库表，这些只是示例。遵循数据库设计过程的规范化规则会很好。

我们也可以根据系统对系统进行分区；

   – 用户ID – 区域

   ID

   – 位置ID

使用 userID 和 regionID 会产生分布问题。一些地区可能比其他地区有更多的位置，在这种情况下，系统将不会均匀分布。我们可以根据 locationID 和 regionID 进行分区。

系统设计考虑

如果我们正在设计一个系统，我们需要的基本概念是；

   – 客户端

   – 服务

   – Web 服务器

   – 应用程序服务器

   – 媒体文件存储

   – 数据库

   – 缓存

   – 复制

   – 冗余

   – 负载平衡

   – 分片

正如我们上面提到的，复制过程是提供高可用性、高可靠性和实时体验的宝贵过程。复制和备份是我们之前提到的提供支柱的两个重要概念。复制是处理服务或服务器故障的一个非常重要的概念。复制可以应用于数据库服务器、Web 服务器、应用程序服务器、媒体存储等。实际上我们可以复制系统的所有部分。（某些 AWS 服务，例如 Route53，它们本身就具有高可用性，因此您无需处理 Route53、负载均衡器等的复制。）请注意，复制还有助于系统减少响应时间。你想象一下，如果我们将传入的请求分成更多的资源而不是一个资源，系统可以轻松满足所有传入的请求。此外，每个资源的最佳副本数为 3 个或更多。您可以通过将数据保存在 AWS 的不同可用区或不同区域中来提供冗余。我们可以将相同的数据保存到三个不同的资源上，并且由于这个过程，如果一台服务器死机，系统会自动继续工作副本。复制的另一个优点是系统可以在系统更新时继续运行。在复制过程中，Master server 将负责写入和读取操作；slave负责读操作。系统自动继续工作副本。复制的另一个优点是系统可以在系统更新时继续运行。在复制过程中，Master server 将负责写入和读取操作；slave负责读操作。系统自动继续工作副本。复制的另一个优点是系统可以在系统更新时继续运行。在复制过程中，Master server 将负责写入和读取操作；slave负责读操作。

负载平衡是指在一组服务和服务器之间分配请求。当我们谈到复制和分片时，必须引导传入的请求，这是由负载均衡器完成的。我们可以使用 Round-Robin 方法来重定向传入的请求，但在这种情况下可能会出现问题。Round-Robin 停止向死服务器发送请求，但 Round-Robin 不能停止向暴露于大量流量的服务器发送请求。我们可以准备智能 Round-Robin 算法来解决这个问题。此外，我们可以使用一致的哈希来重定向传入的请求。一致的散列确保系统变得更加均匀分布。

使用负载均衡器进行分片的可能问题是当系统死机时我们如何重建系统。可能的方法是蛮力。这种方法很慢，因为我们需要从头开始重建整个系统。我们可以通过使用反向索引方法来消除这个问题。我们可以有另一个索引服务器来保存有关反向索引的所有信息。反向索引映射所有地方。我们需要构建一个地图，key 是 serverID，value 是所有地方。

对于缓存策略，我们可以通过使用缓存服务器来使用全局缓存机制。我们可以使用 Redis 或 memcache，但缓存策略最重要的部分是如何提供缓存驱逐。如果我们使用全局缓存服务器，我们将保证每个用户将在缓存中看到相同的数据，但如果我们使用全局缓存服务器，则会有时间延迟。作为缓存策略，我们可以使用 LRU（最近最少使用）算法。

对于媒体文件缓存，正如我们之前提到的，我们将使用 CDN。CDN 位于不同的边缘位置，因此响应时间将小于直接从 AWS S3 获取媒体内容。

我们可以拥有最流行、最相关、最新等的各种排名机制……如您所知，我们可以拥有许多服务器，我们需要从这些服务器获取数据。由于这个原因，我们需要聚合函数来组合所有这些数据以获得最理想的解决方案。