总结了点 Infra 相关的事

总结下最近做的 Infra 相关的工作。

基础设施

从阿里云迁移到 AWS 并深度使用后，我的感受是 AWS 确实当之无愧是全球最领先的云计算服务商（狗头

我们用到的服务如下:

• DNS: Route 53

• 路由策略、流量管理

• 可用性监控、健康检查

• SSL 证书: Certificate Manager

• AWS 内免费使用、支持通配符、多域名

• 能直接部署在 CloudFront 甚至 ELB 层

注意: ELB 层不支持重定向，所以想要把 HTTP 请求重定向到 HTTPS 的话，需要在服务器上用 Nginx 来处理

• CDN: CloudFront

• Function: 支持在 CDN 层对流量进行处理。例如我们目前重定向 www 到裸域名就是在 CDN 层做的

• EC2

• 需要注意，暂停 EC2 实例也会让 AWS 释放 IP 占用（可以看出 AWS 在资源利用率上做到了极致

• S3

软件/工具

• 版本控制系统: Git / GitLab

• Git 工作流:

• 本地分支: Rebase 优先

• 远程分支: Merge 优先

• 持续集成: GitLab CI

• 自动构建、部署

• Registry: GitLab Registry

• 可以把 Storage 直接挂载到 AWS S3 上

• 支持 Maven, npm, PyPI 等包

• 支持容器镜像

• 部署: Docker, Docker-compose

• 快速、低成本实现部署、迁移

• 环境、过程可编程

• Tunnel 服务: sish

• 用过的最好的 ngrok 开源代替方案

目前所有服务使用 Docker-compose 编排，然后部署在单台专用于 Infra 服务的机器上，使用 nginx-proxy 根据不同域名自动反向代理不同容器

技术栈

• Typescript + Node.js

• 在非计算密集的场景下，使用 Async/Await 更容易写出高性能的代码

• 语言优势：庞大的生态、社区、开发群体，而 TS 有着现代语言里最强大的类型系统

• 依托 V8，是所有脚本语言里运行效率最高的

• 使用 GraphQL 的「无奈之举」: 在目前所有的 GraphQL 的服务端实现里，Node.js 下的是最完善、成熟的

• GraphQL

• 能对通讯数据进行描述、校验。可以根据 Schema 生成不通过语言的类型文件

• 由于前端能感知到数据的形状，所以类似 Apollo 之类的方案可以自动对数据进行精细化处理（局部缓存、更新

• 通过 Query 语句可以在前端控制数据的组合和裁剪

• NestJS, PostgreSQL + TypeORM, Redis, RabbitMQ, RxJS

• TypeScript + React, Next.js

• 出于 TS 支持程度、生态等考虑，并没有选择 Vue.js

其它展望

• K8S

• 目前业务还没有发展到达需要使用集群服务器的规模，但是如果发展顺利的话，应该很快就需要了

虽然我们目前还没有使用 K8S，但是我们迁移到 K8S 的成本不会很大

• 代码上我们使用了微服务架构

• 部署上我们使用了容器技术

• Serverless

• 适合用于处理 CPU 密集、逻辑独立的任务

• 之前有过开发经验，但是目前的业务暂时还没有合适的使用场景

• Node.js + Golang / Rust

• 将计算密集、性能敏感的场景迁移到 Golang 或者 Rust

• Java

• 没有原生支持的协程（非 First-Class 影响了生态的发展

• JVM 太重，不适合微服务、容器化

• Golang

• 原生支持协程

• 目前容器化、微服务架构下的主流选择，占用内存小、镜像小

• 有 GC，性能比不上 Java

• Rust

• 原生支持协程，且支持 Async/Await

• 当前语言界最强的黑马。「只要编译通过了，运行期基本不会出现什么大问题」

• 生态还不完善、编译太慢

本文首发于微信公众号，阅读原文 。