Swift on Server Tour 0: 为什么这可能是你的好选择
背景
在使用 Swift on Server 之前，我最熟悉的 Web Framework 是 Ruby on Rails，除此之外，我也使用过 Python，NodeJS，Elixir 和 Go 来编写后端，但给捧读编写后端服务的时候，我权衡再三，最终选择了 Swift on Server.
本章将分享当时我为何做了这个决定，以及这个决定在随后的三年为何被验证是正确的选择，如果你和我的情况类似，那么相信会有所收获。
Hint
捧读——一款基于机器学习技术的日语语法分析 App
Table of Contents
从单机开始
捧读在 2019 年的研发之初，是作为一款单机产品设计的，初衷是希望即使我不在了，这款产品也依旧可以很好的运作，让用户实现真的一次购买，永久使用。
设计为单机产品主要起因于我两个想法
- 教育资源需要足够容易被获取，这样才公平
- 我需要把产品的运行成本降到足够的低，由此这款教育产品就可以被卖的足够便宜，让更多人可以用上
但随着时间的推移，捧读的机器学习模型更新给我带来了麻烦。
在单机的情况下，模型更新完全依赖于用户是否更新了 App，因此，我无法保证每个用户都能及时使用上最新的模型，获得最好的体验，除此之外，用户会逐渐积累很多学习数据，如果不提供云同步功能，用户难以跨设备使用，更是容易产生丢失数据的问题。
因此，为了解决「用户体验」和「单机」之间的冲突，在 2021 年的时候，我决定给捧读设计一个后端。
需求驱动的选择
在调研技术方案前，我们先来看下捧读服务端有哪些需求
- 捧读的算法逻辑已经用 Swift 写完了，能不重写可以极大的加快我的研发效率
- 捧读使用了很多 C 库来支撑算法的实现，因此和 C 库的集成方式要足够简单
- 服务端的性能一定要足够好，让用户几乎不需要等待
- 服务端运行时的资源占用要足够的小，这样我在配置多节点实现高可用的时候，就不需要花大价钱买高配的服务器
Ruby on Rails 的优缺点
以 Ruby on Rails 来说，这是一个我从 2013 年就开始使用的 Web 框架，也一直是它的拥趸，那么，先来看一下它的优劣
优点：
- 可以非常高效的完成业务需求
- 生态完善，常规业务功能都有现成的开源实现
- 很容易找到使用这个技术的小伙伴
- 很容易找到学习资料
缺点：
- 性能一般（可以通过把耗费算力的用其他编译型语言写成模块优化）
- 内存占用比较高
- 和 C 库的互调比较麻烦
- 并发能力弱（可以通过多线程、多实例、多节点的方式优化）
Swift on Server 的优缺点
反观 Swift on Server，它的优缺点有哪些呢？
优点：
- 可以复用 iOS App 和 Swift 生态的代码
- 编译型语言非常稳定
- 和 C 库的集成非常容易自然，今年 Swift 5.9 又完善了和 C++ 的集成
- 性能极好的同时，内存的占用非常低，这意味省大量的钱
- 整个生态都使用了 Non-Blocking I/O 的设计理念，高并发的支持非常好
缺点：
- 作为服务端是一个非主流，大部分服务都没有对应的 SDK
- 很难找到学习 Swift on Server 的小伙伴
- 学习资料很少
除此之外，Swift 对我来说还有三个加分项
- Swift 这门语言写起来愉悦性很强
- Swift 的社区很活跃
- Apple 对其投入足够大，每年都有很多惊喜
因此，Swift on Server 对我来说，只要扬长避短，克服这些缺点，就是一个完美的选择。
克服 Swift on Server 的先天劣势
就像脚本语言借用其他语言来补全自己的短板一样，Swift 也同样可以借助其他语言的生态来补全自己的短板，在这个 Cloud Native 的时代，借助微服务和 Serverless 的帮助，我们可以很轻易的解决这些问题。
解决缺少第三方服务 SDK 的问题
以 Azure 为例，Azure TTS 并没有提供 Swift 的服务端 SDK，但可以很容易的找到其他语言的，比如 Python 和 NodeJS.
我的解决方案是用 JS 把和 Azure TTS 打交道的功能，部署到 AWS 的 Lambda 上，当 Server App 需要和 TTS 打交道的时候，就用 HTTP 请求这个 Lambda Function.
这个方案的优点如下
- Lambda Function 可以写的足够简单，比如在 TTS 这件事上，我只有 60 行代码
- Lambda Function 的运行环境和我们的 Server App 是完全分离的，因此不占用额外资源，运行时相互之间也不会产生影响
- AWS Lambda 的免费额度足够多，你几乎不需要付出金钱
解决技术包容性的问题
我们很容易面临一个这样的问题，我喜欢 Swift，他可能喜欢 Rust，其他人则可能喜欢 Go 或其他语言。
当我选择了 Swift on Server 的时候，是否和其他人的世界就无缘了呢？
当然不是！通过一个精巧且合理设计的微服务架构，你可以很轻松的在不同的业务模块里，使用完全不同的语言和技术，相较于使用一门语言实现一个大单体应用，这样带来的直接好处有两点
- 每个语言都有自己最擅长的领域，借助微服务可以轻松整合不同技术一起工作
- 每个人都可以选择自己最喜欢的技术来完成他的目标，这样会很开心
使用 Swift on Server 的三年
从 2021 年服务器上线至今，已经高效，稳定的运行了 3 年，在这期间，业务从仅有的用户系统和语法分析，拓展到了支付系统，账单系统，以及后来的生词本和学习系统，在未来，我也会继续使用 Swift on Server 完成其他的产品需求。
之所以开启这个系列，是希望将我使用 Swift on Server 的经验系统的分享出来，让更多的人可以从中受益。
诚然，Swift on Server 不会是适合每个人的方案，因此我也列了一个画像，如果你符合这些条件，那么请持续关注这个系列的文章。
谁适合使用 Swift on Server
符合下列任何一条皆可
- 已经在使用 Swift 语言
- 有自己的 iOS App 希望开发后端
- 对 Swift 语言充满热情
- 关注性能和高并发
系列预告
本系列文章的会以一个 Micro Blog Server 为示例，和你一起畅游 Swift on Server 的世界，这个系列主要面向对服务器开发的初学者，因此除了功能的实现外，会写很多概念相关的内容。
总体来说，话题会涉及到以下方面
- 概念：什么是 Server App
- 概念：HTTP 请求的那些事
- Framework：选择你的框架 - Vapor
- Database：设计你的数据模型
- API：设计你的 API
- Auth：用户权限验证
- Test：测试你的 API
- CI：部署你的服务器
- 微服务：和其他语言一起工作
- 微服务：多人同时在线的聊天室
我会利用闲暇的时间，更新这个系列，希望能够完成每 1 - 2 周一更，欢迎持续关注！