这是我参与「第五届青训营」笔记创作活动的第12天。
今天给大家分享一下我们队伍针对抖声大项目的技术选型历程，分为V1.0和V2.0两个阶段。
技术选型 （ V1.0版本）
背景：队伍内大部分同学对go语言及go框架不是很熟悉。这一方面来说是一件坏事，我们进度可能稍慢，在最开始需要不断探索和不断学习；但是另一方面，我们没有技术负债，选择框架也没有太多负担。所以我们在1.0版本决定使用单体架构设计整体服务端。
- 整体的后端架构为hertz+gorm：
gorm是go后端框架中使用最为广泛的全功能 ORM， 开发者友好的特性，多功能的各类API，可靠的性能和报错处理，都是我们选择它的理由。
hertz作为字节开源的一款十分优秀的Golang 微服务 HTTP 框架，吸收了很多传统框架如gin, fasthttp, echo的优势，并结合字节跳动内部的需求，使其具有高易用性、高性能、高扩展性等特点开发而来，经受了字节内部的企业级项目考验，其可靠性无需多言。在性能方面，Hertz 默认使用自研的高性能网络库 Netpoll，在一些特殊场景相较于 go net，Hertz 在 QPS、时延上均具有一定优势。
- 在数据库选型上，我们采取了最广泛使用的MySQL，处理数据缓存和备份上，我们使用了Redis：
之所以采取mysql+redis，是由于我们根据实际业务需求，发现一些场景下，我们无需多次去查询数据库，而是可以直接通过将数据缓存在Redis中。例如用户的喜欢列表，由于一个视频的点赞操作可能会十分频繁，而对于一个喜欢列表，在一些场景下我们无需实时更新其数据。这种情况下，我们可以采用使用Redis存储喜欢列表查询的数据缓存，定时更新该缓存，而无需每次都去数据库中查询大量的点赞记录。
- 日志记录和存储方面，我们使用了Zap日志库和后端框架自带的log打印。
添加日志库的方案是队内金晨同学提出的。我们在开发项目过程中，有可能遇到一些报错，并没有即时处理和记录，或者并没有当场发现错误产生，导致我们在往往会错过一些很有价值的报错记录和性能异常等记录。作为一款对性能和内存分配做了极致的优化的开源日志库Zap，我们可以利用其强大的日志处理和记录功能来处理我们的运行记录。另一方面，使用hertz和gorm的日志显示功能，我们也可以即时在运行过程中查看到运行过程和请求，数据库处理结果。
- 视频流播放处理模块，队伍中的齐迪同学采用了阿里云OSS对象存储服务。
阿里云对象存储OSS（Object Storage Service）是一款海量、安全、低成本、高可靠的云存储服务，可提供99.9999999999%（12个9）的数据持久性，99.995%的数据可用性。多种存储类型供选择，全面优化存储成本。并且其提供的api调用和相关JDK都十分方便，对开发者友好。我们打算先使用该服务将视频流处理分割出整体服务中去，在后期对项目进行升级优化时进一步处理视频流的上传，下载和播放等功能。
技术选型（ V2.0版本）
在我们的后端架构设计达到最小可用的成果之后，我们再次分析了实际业务中可能会遇到的问题，例如高并发，长时延，海量数据，单节点出错导致整个服务崩溃等问题，以及不同业务服务之间可能会遇到访问比例差异等。
对于上述问题和当前架构中遇到一些性能瓶颈问题，以及考虑到在真实业务场景下会遇到的服务本身消耗资源的情况和购买其他服务（如阿里云OSS）所带来的开销，我们决定：
- 加入微服务架构Kitex，将不同的业务进行分离，并通过api网关管理整体的流量，鉴权，熔断，负载均衡等。
- 使用Kafka， 分离日志处理服务，代替Redis处理用户聊天模块（以适应大量数据来临时Redis的性能瓶颈和资源消耗问题）。
- 加入RabbitMQ， 优化聊天系统并防止某些服务为由于并发太高，导致数据库崩溃 。
- 优化视频处理模块，不再依赖阿里云OSS模块，改为XXX
V2.0版本仍在开发中...
