数据库

读写分离

目前数据库都是读写分离的，有多个读节点，平时可能只有两三个读节点，但是如果有活动了，会增加读节点，增加数据库的可用性。

数据仓库

采购了阿里云的 AnalyticDB 服务，他支持海量数据亚秒级查询，系统中有个四五千万级别的表，基本上秒出结果，联表的性能也很高，同步数据也很快，基本感知不到延迟，大大提升数据查询速度，对应提升系统性能。

消息队列

多个服务使用消息队列进行异步处理，目前有访问日志、群发通知、支付回调、处理时间长的任务等数十个服务使用消息队列，也对系统稳定运行有很大帮助，比如有次突发流量，持续了一天，当时是抓紧做优化，去掉一些不太重要的逻辑，其中就把访问日志服务改为异步写入了（本来是同步写入的）。

容器化部署

基本上所有服务都在容器上，方便及时扩容。（也是最近一直持续改造的）

负载均衡

本来我们 c 端服务是部署在多台机器上的，负载均衡负责分发流量到各个机器上，但是现在正在改造，所有服务都容器化部署，更需要负载均衡了。

分布式服务

现在有多个 C 端服务，表单、活动、筹款等，都是单独的项目，单独部署，除了共用数据库之外，都是独立的。如果不是数据库原因导致系统崩溃的话，基本上只会影响其中一个服务，不会导致所有服务都不可用。

id加密

来这个公司之前，就有个疑问，用户会对 id 进行递增测试，比如一个商品链接是 xxx?id=1，用户会试一下 id=2 是什么，如果是 saas 系统，那么有可能从 A 商户跳到 B 商户。现在做的是所有参数进入业务代码之前，都有个 id 解密的中间件，把各个 id 配置进去，自动解密后，再放回参数，但是要求在返回前端时，也需要手动加密后返回。

短链服务

这个也是我觉得很好的一个服务。我们现在有自己的短链服务，基本上 B 端用户生成的 C 端链接，分享出去的都是短链，好处是可以控制链接对应的具体内容，比如一个用户传播一个链接后，发现传播错了，本来要传播 a 活动，结果传播了 b，这时候技术上可以做到把短链对应的活动改为 a 的链接，当短链重定向时，就会打开 a 的活动，好处还很多，不一一列举。

日志

系统中的日志也挺完善的，偶尔会感觉缺少日志，不方便查问题，但多数时候还是很够用的。

访问日志

各端都有访问日志，会记录用户的请求和请求参数，当出现问题时，比如用户问xx 数据没动为什么变了，就可以通过访问日志查找处理谁干的

操作日志

操作日志相对不是很完善，因为中间经过某个同事重构后，添加操作日志比较麻烦，所以有一些操作就没加日志。

服务器日志收集

接入阿里云的日志服务，收集服务器的 runtime 日志，有时候服务器一部署，会把日志文件给覆盖掉，虽然有备份，但是还得解压后在查找。使用阿里云这个日志服务收集后，可以直接线上看日志，还是很方便的。

sentry

接入sentry，收集异常日志，当业务出问题可以不用先去查看服务器日志， sentry 会报出来，能快速定位问题原因。

链路日志

支付系统中有完善的链路日志，从下单到支付到支付回调，再到每一步处理，都会记录日志，当发生问题时，可以很方便的看到问题出在哪一步。

这个文章会持续更新，当发现别的优秀的点的时候，会再进行记录。

原文链接：目前维护的 SaaS 系统好的地方，转载请注明来源！