使用Go语言开发一个短链接服务：二、架构设计

  在上一篇中，我们介绍了短链接服务的应用场景、基本原理以及Go的基本代码实现。在这一篇，我们将讨论服务的技术选型和架构设计。

后端Web框架

  就无脑用Go最流行的Web框架Gin。

数据库

  备选方案包括MySQL、PostgreSQL、MongoDB。我们这里的数据存储，基本围绕短链接code和长链接url对应关系的保存和读取。这里我们选择MongoDB，理由有4：

      1、我们不需要用到关系型数据库的事务（MongoDB4.0后也支持事务，惊不惊喜、意不意外）、join查询等特性。绝大多数读写场景是围绕单条数据，短链接code和长链接url两个字段。

      2、MongoDB支持分布式、横向扩展。有朝一日，当我们的短链接服务火得一塌糊涂时，数据量级指数增长，数据库读写性能出现瓶颈、磁盘空间不足，可以直接通过加机器节点解决。

      3、在读取方面，MongoDB相对于MySQL、PostgreSQL具有更高的性能。主要因为MongoDB使用了面向文档的存储方式，可以将相关数据存储在一个文档中，从而减少了数据查询时的磁盘IO。

      4、在适量级的内存的MongoDB的性能非常迅速的，它将热数据存储在物理内存中，热数据的读写十分快。

  Go的MongoDB驱动我们使用MongoDB官方维护的go.mongodb.org/mongo-driver/mongo 。

缓存

  鲁迅说：“诸多策略，缓存为王。”

  备选方案包括Redis、Memcached。我们的服务使用缓存需求，主要为保存和读取短链接code（作为key）和长链接url（作为value）。根据需求，Memcached可能是一个更好选择，但是我还是选择Redis。

  应该选Memchached的理由：

      1、不需要用到Redis丰富的数据类型、数据持久化、事务等特性，只需要简单的单key保存和读取

      2、根据本人以往的认知，100k以上的数据中，Memcached性能要高于Redis

  应该选择Redis的理由：

      1、在新版的Redis 6.x版本中，支持多线程处理io，优化了过期算法和过期处理逻辑。上面说的，以往100k以上的数据中Memcached性能要高于Redis认知，如今不一定成立

   2、更多人熟悉的是Redis

      3、我不会Memcached

　　Go的Redis驱动我们使用MongoDB官方维护的github.com/redis/go-redis/v9 。

架构图

  上一篇中，我们提到了短链接服务的基本原理是，服务维护了短链接和长链接一对一关系，客户端输入短链接，服务端获取到短链接code，到缓存、数据库获取对应的长链接，并http跳转到对应的长链接。

 　　基本架构

　　流程图

总结

  架构基本就设计如此，目前涉及到的组件版本信息如下：

　　    1、Golang 1.22.0

　　　2、Gin github.com/gin-gonic/gin v1.9.1
　　    2、MongoDB 7.0.6； go.mongodb.org/mongo-driver/mongo v1.14 　　   

　　　3、Redis 7.2.4；github.com/redis/go-redis/v9

   下一篇我们将开始项目代码编写。