从 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 仓库进行了持续集成的上线模式，总体来说体验是很好的，这个迟点另写一篇博客分享一下。
