32service 3.0 架构更变小记

读写分离,热备份,负载均衡。

从 32service 3.0 开始,我们的架构是这样的。

  • Web 服务器在广州数据中心。
  • 选用了全球的 CDN 分发网络,可以动静分离,和隐藏源服务器 IP。
  • 海外代理节点获取用户数据,开放接口,然后通过 CDN 传回流量统计。
  • 考虑到数据安全,数据库进行了热备份和冷备份。

刚起步是这样的架构是因为这样耦合性低,容易部署。但是这也是有缺点的,首先是使用 CDN 会拖慢用户的二次访问速度,CDN 为了考虑用户的兼容性,会牺牲部分性能,不敢采用最新的协议。而且最重要的是,32service Web 端几乎全部都是动态请求,HTTPS 的二次握手会有较大的性能开销,此外 Web API 的设计势必会导致 HTTPS 请求数的极多,CDN 也是一笔不可忽视的费用。

综合了上面的分析,32service 最近已经逐步升级为下面的架构。

  • 首先我们抛弃了 CDN,CDN 并不适合用在这类型的项目。
  • 此外我们自建了服务器,覆盖了中国大陆、亚太地区,美国地区和欧洲地区。
  • 数据库进行了异地热备份,并进行了读写分离,为了保证一致性,所有写入会写入到主数据库,主数据库会把更改同步到从数据库,如果有读取操作,则直接在从库读取。由于我们一开始并没有设计读写分离,我们使用了数据库中间件进行分离读写。
  • 最后是对主库的冷备份。

这样设计的优点有很多。

  • 由于主库的 IP 地址不公开,而且只有我们自建的服务器需要访问,安全性和稳定性可以保障。只要主库可用性保障,只要有一个 Web Server 在线,32service 的服务就不会中断,这样秒级切换通过 CloudXNS 的监控完成。
  • 32service Web 端访问多数是读取操作,这样可以提高海外访问速度
  • 节点通过 Web API 写入需要访问主库,但是这个操作对时效性要求不高,总的来说跨地域的网络对我们影响不大。

具体的配置可以移步 Steven 的博客阅读

最后我们利用私有的 Git 仓库进行了持续集成的上线模式,总体来说体验是很好的,这个迟点另写一篇博客分享一下。