一个 SaaS 项目,技术栈是这样的

作为一名忠于内心的工程师,每当我看到一家公司发布有关它们技术栈的文章时,我都会泡一杯咖啡,坐下来耐心阅读,看看有没有新的发现。了解其他公司业务背后隐藏的一些技术十分有趣。就像娱乐八卦一样,只不过这是技术层面的探索。

 

几个月前,我开始开发另一个 SaaS,该项目经历无数次迭代。幸运的是,尽管项目仍处于早期阶段,但是很多网站已经对其进行了集成。

 

作为一个自负盈亏的独立创业者,我相信正是由于专注于自动化,才让我能为来自 80 多个国家和地区的客户提供可靠服务,并且每周持续提供新功能。当我想要了解服务的运行情况或者其他方面的信息时,我会尝试利用我熟悉的工具。当然,我也明白,在一些特殊情况下这些工具并不会帮到我。

 

现在,我简要地介绍下平时使用的一些工具。

 

非常重要的一点是,虽然工具列表看起来很长,并且有一些是非常规且不常用的选项,但实际上我在基础架构上花费的时间很少,如果有的话,每个月平均下来也就是几个小时。还有一点就是个人推荐就像是开处方一样,我认为对我非常有用的一些工具,可能并不适合你。一定要考虑自己的实际情况,并利用好当下你熟悉的工具。

编程语言

多年来,我学习和使用过好几种编程语言,但是对于独立项目,我特别挑选出两种编程语言。这两种编程语言可以在生产力以及可靠性上取得很好的平衡。

 

  • Python:很多项目的后端代码都是用 Python 实现的。它可以让我能够以较快的速度发布新功能。另外,我使用 mypy 用于类型提示,这方便我进行代码管理。

  • Typescript:我以前会有意地避开前端开发的工作。直到大约 4 年前,我发现并开始使用 Typescript。它让我感觉写前端的工作体验更好了,现在我使用它并结合 React 框架一起构建我的项目。

框架

理论上,我会在这里介绍很多这方面的内容,但是相关论坛上有不少介绍,我也是站在巨人的肩膀上学到很多知识。因此我只想介绍几个非常不错的框架:

 

  • Django:该框架简直就是独立开发者的宝库。你在该行业中工作的时间越长,你越能体会到避免重复造轮子带来的幸福感。这一框架可以让你走的更远,因为它的功能实在是太全面了,应用场景也很广泛。推荐阅读Instagram如何优化Python提高服务性能Sentry项目10大Django构建的网站了解一下 Django 的使用场景。对我来说,该框架不管在性能还是功能方面都能满足我的需求。

  • React:数据展示相关的 Web 应用是使用 React + Webpack 构建的。在长时间使用 Angular 后,我最终切换到 React,因为它是支持可插拔的视图层,不会对其他功能造成影响。我使用性能表现不错的django-react-templatetags将 React 组件嵌入到我的 Django 模板中。

  • NextJS:我使用它进行页面、文档等的加载。它让我能重用各种 React 组件,并且可以提高静态页面的性能以及 SEO 优势。

  • Celery:我使用该框架用于后台/定时任务的管理。该框架的学习成本较高,但是一旦你了解了它的工作原理,并应用到项目中后,你就能体会到该框架的稳定性和可靠性了。

  • Bootstrap 4:我基于 Bootstrap 构建前端应用。它节省了我很多时间,并且文档资料详细丰富。这就是我选择使用它的原因。

数据库

我最初将所有数据都存储在 SQLite 数据库中,对数据进行备份意味着要将副本数据复制到 S3 之类的对象存储中。之前对于测试过的一些小型站点来说,没有什么问题。但是,随着项目的功能及页面越来越多,我需要更多专门的数据库来支持这些功能:

 

  • Clickhouse:我相信 Clickhouse 是为数不多的随着时间的推移而经久不衰的技术之一。说实话,这是一款十分给力的数据库,它能够实现原先在低配置硬件上几乎无法实现的功能。

  • PostgreSQL:我必用的关系数据库。默认配置合理,经历了充分的市场检验并且与 Django 深度集成。在 Panelbear 中,PostgreSQL 主要用于与分析无关的应用数据存储;对于分析用的数据,我使用 Django 实现了一个简单的接口从 Clickhouse 查询数据。

  • Redis:我在很多场景中使用了 Redis,比如缓存、速度限制、任务队列以及作为有生命周期的键值存储。Redis 功能强大且性能稳定,社区文档也十分丰富。

部署工具

这篇文章描述的一样,我不会将我的基础设施视为宝贝一样对待。服务器和集群本来就是一个工具而已。所以如果某一台服务器出现问题,用另外一台正常的服务器替换一下就好了。这意味着所有的操作在 git 仓库中被描述为代码逻辑,并且我不会通过 SSH 登陆服务器进行一些操作。你可以将这个描述视为一个模板,可以通过一个命令将整个基础架构克隆到任何的 AWS 服务中。

 

这在灾难恢复时也会对我有所帮助。我只需要运行一些命令,几分钟后,我的应用服务就可以重建并能正常运行了。当我将应用从 DigitalOcean 迁移到 Linode,以及最近往 AWS 迁移时非常有用。所有的操作都通过代码描述和执行。因此,即使在几年后,我也很容易的跟踪项目的相关部署和运行情况。现在所有的公司都拥有 AWS IAM 策略或者 VPC 子网,这些都是通过一些 UI 界面点击操作完成的,现在所有人都离不开这一功能,因为确实给用户带来了很多便利。

 

  • Terraform:我使用 Terraform 来管理大部分云基础架构。在我的 Terraform 清单中声明了诸如 EKS 集群、S3 存储、角色和 RDS 实例之类的一些配置。这些数据会同步到另外的加密 S3 存储,以避免我开发用的笔记本电脑发生故障而无力回天。

  • Docker:我会将所有服务构建为 Docker 映像。甚至有状态的组件(比如 Clickhouse 或 Redis)也作为 Docker 容器打包并运行在我的集群中。这也让我的应用服务可移植性非常高,因为我可以在能够运行 Docker 的任何地方运行它。

  • Kubernetes:它极大地解放了我繁琐的工作。我并不是盲目地向所有人进行推荐,因为在工作的这些年里,我使用它解决了好几次大型的生产故障。为公司及时解决生产问题,让我感觉十分自豪。我还用它进行容器化应用的管理,这也帮我减轻了工作负担。

  • GitHub Actions:过去,我常常使用的是CircleCI(这个用起来也不错),但是对于这个项目,我更喜欢使用 GitHub Actions,因为它删除了需要访问代码库以及部署密码的一个不必要的服务。但是,CircleCI 同样具有很多不错的功能,我仍然向大家推荐它。

基础设施服务

我从最开始使用月费 5 美元的 DigitalOcean 单实例服务器开始,逐步转向使用 Kubernetes 来管理服务,因为我正在彻底改变 Kubernetes 提供的一些开箱即用的功能(比如:服务发现、TLS 认证、负载均衡、日志滚动管理、滚动发布、容量管理等)。

 

但是,即使在较大的服务器实例上,使用 Kubernetes 管理的 DigitalOcean 也同样存在可靠性问题。集群 API 服务经常会随机地停止工作并且无法恢复,这会破坏包括负载均衡在内的许多集群服务,也就意味着服务停机无法对外提供正常服务。每当发生这种情况时,我会重新创建一个新的集群,尽管使用 Terraform 可以很轻松的实现,但是这并不会增加大家对其托管服务可靠性的信心。我怀疑是他们的资源不是特别充足导致的,考虑到他们的服务收费较低,因此这是可以理解的。

 

不幸的是,几周后,我就无法解决上面提到的问题了。这就是为什么我决定迁移到Linode的原因,在接下来的一个半月的时间里,系统再也没有出现过任何问题。

 

但是,AWS 向我抛来了更加诱人的优惠,所以我最近又做了一次迁移。AWS 还支持使用托管服务比如 RDS 来减轻 PostgreSQL 的压力,这对我来讲是个很大的优势。我的迁移工作没有那么复杂,因为我的所有基础架构都是通过 Terraform 和 Kubernetes 配置清单进行描述的。系统迁移可能会花费或长或短的时间,所以一定要有耐心。这一方面的话题可以在其他文章中找到。

 

  • AWS:提供可预测服务以及大量的托管服务。我主要在全职工作的时候使用过它,所以我没有花费很多时间来处理问题。我使用过的 AWS 服务主要有 EKS、ELB、S3、RDS、IAM 以及专用 VPC,未来我可能会使用 Cloudfront 和 Kinesis 服务。

  • Cloudflare:我主要将其用于 DDoS 保护、DNS 服务以及负载各种静态资源的边缘缓存(目前减少了 AWS 的 80%网络出口带宽费用——它们的带宽定价是在是太贵了!)。

  • Let’s Encrypt:免费的 SSL 证书授权服务。我在 Kubernetes 集群中使用了 cert-manager,它根据我的入口规则自动颁发和更新证书。

  • Namecheap:我常常使用的域名注册服务商。它允许 MFA 登录,这是一个十分重要的安全功能。与其他域名服务商不同,它们不会每隔几年就会突然增加域名的高昂续费费用,十分的良心。

Kubernetes 组件

以下组件可以自动完成大部分开发运维工作。我也使用其他的一些组件,但是我最想推荐给大家的是下面几个:

 

  • ingress-nginx:一个性能稳定的使用 NGINX 作为反向代理和负载均衡的网络入口控制器,控制入口流量到集群节点的网络流量负载均衡。

  • cert-manager:该组件可以按照入口规则中的定义自动颁发和更新 TLS 证书。

  • external-dns:借助 DNS 服务(例如 Cloudflare)同步公开 Kubernetes 服务和网络入口。

  • prometheus-operator:可以自动监控大部分的服务,并可以通过 Grafana 对数据进行展示。

  • flux:可以实现在 Kubernetes 中进行连续交付。当我要发布新的 Docker 映像时,可以通过拉取镜像进行部署。

命令行工具

我使用的命令行工具有很多,但经常使用且值得推荐的就下面这几个:

 

  • kubectl:与 Kubernetes 集群进行交互的工具,可以对日志、pod 和服务进行监控,并且可以 SSH 登陆到运行中的容器。

  • stern:Kubernetes 的 pod 日志查看工具,方便易用。

  • htop:交互式系统进程查看工具,真的比系统自带的 top 工具好用。

  • cURL:网络请求工具,可以对请求头进行检查。

  • HTTPie:与 cURL 工具类似,但是对于 JSON API 而言更简单易用。

  • hey:网络负载测试工具,可以提供详细的延迟分布报告。

监控工具

  • Prometheus:可以高效地存储时间序列数据并进行监控。可以追踪所有群集和应用程序的性能指标。比使用 Cloudwatch 进行应用程序监控要便宜得多。

  • Grafana:可以对 Prometheus 监控数据进行展示。所有的展示数据以 JSON 文件进行描述,并在 git 仓库中进行版本控制。

  • Sentry:对应用程序异常情况进行监控。该工具在发现带有其他元数据的未处理错误时进行告警通知。

  • Loki:受 Prometheus 启发而发展出来的一款日志聚合系统。它附带了 prometheus-operator 功能,可以帮助我在整个群集中对海量日志进行搜索。

邮件工具

  • Fastmail:我优先选用的商务电子邮箱,功能齐全且稳定性高。

  • Postmark:我主要将其用于交易电子邮件(电子邮件验证、每周报告、登录安全警报、密码重置等)的收发。他们的电子邮件传输速度非常快,邮件移动应用程序在业界也是一流的。

开发工具

  • GitHub:源代码托管及版本控制工具。

  • PyCharm:可能是 Python 最好的 IDE 工具。使用它可以轻松地重构和导航整个项目代码,而不仅仅是单个代码文件。 即使使用大型动态代码库,该工具的使用表现也很好。

  • VS Code:非常适合 Typescript / React 编程,并且可以用作通用代码编辑器。

  • Poetry:Python 打包及有锁文件的依赖管理工具。

  • Yarn:具有本地缓存的快速 JS 依赖项管理工具。

  • Invoked:我使用它将所有代码库任务包装在可调用的命令中。例如,使用inv build可以准备静态资源,打包前端/后端环境依赖,并生成 docker 映像。这样,就可以在本地执行与 CI 运行的相同的命令。

其他工具

  • Panelbear:当然,除了 Panelbear,还有什么能比 Panelbear 更好的工具来跟踪 Panelbear 的网站分析呢?内部测试是有很大收益的,因为我就是我自己的客户。

  • Healthchecks.io:当计划作业未能正常运行时,就会通过电子邮件或者 whatsapp 通知到我。它也是基于 SaaS 的辅助程序,这个工具我使用了好几年了,非常高兴可以推荐给大家。

  • Trello:我使用它来记录和跟踪一些问题、需求及想法等等。

  • Figma:用于为目标页面快速制作模型、横幅和插图,它取代了Sketch作为我的入门工具。

 

原文链接

 

https://panelbear.com/blog/tech-stack/

posted on 2021-02-20 12:45  关寒融冰  阅读(49)  评论(0编辑  收藏  举报

鲁ICP备07018066号-1