ToTalk分布式架构之海内外跨机房

    随着最近我们的应用在海外的访问量，很多海外用户反应整体的体检比较差，每次电话的拨打都要消耗很长时间，带来了很多用户反馈。

    综合自己对网络和架构近几年的了解，自己总结了几个经验：

    1）：节点的访问DNS优化

    2）：不同节点的内容缓存

    3）：内容压缩

    4）：应用程序的性能优化

接下来对不同的方案进行详细说明一下：

 1）：节点的访问DNS优化

       类似于万网的DNS解析一般分为，中国移动、中国电信、中国联通和百度以及境外等配置，可以对不通的网络类型进行单独配置解析服务器，如果要对境外进行细分的话，一般提供了VIP服务，可以对境外的不同州的不同地区进行配置，此步能够在DNS的解析上可以节省一段时间。

    一般一些企业可能还会购买godaddy的国际域名，godaddy不提供海外的细分解析，不过godaddy上可以配置到阿里云的dns，然后采用阿里云的配置进行细分，这点阿里云做的还是很好的。

2）：不通节点的内容缓存

    不通节点的应用服务器分别部署自己的内容缓存，将常用的用户数据缓存到节点服务器。对于很多有管理系统的，可以采用Redis的主从模式，在不通的节点部署redis的从节点，负责从主节点同步数据到本地。管理系统对用户数据的修改通过修改redis的主节点，然后同步到各个节点进行同步，然后对从节点的写功能也要打开，以便可以对不同区域的节点做独立数据而不影响主节点。

3）：内容压缩

    http请求和响应的内容不易太长，由于网络上对单个包是有长度限制的，然后超过之后会进行拆包，必然会带来性能的消耗，所以有必要对内容进行压缩，压缩的访问有很多中。body部分采用gzip等压缩

 4）：应用程序的性能优化

      对访问量比较多的数据以及不经常改动的，进行内容缓存，对常见的系统配置进行一级缓存（静态Map等），其余可以Redis、Memcached等缓存方式。

    确定系统的是属于消耗内存型还是消耗CPU型还是属于IO型，将消耗cpu部分进行拆分，使用cpu比较好的机器，消耗内存型的系统使用内存配置比较大的机器进行部署，将IO密集型的采用SSD硬盘，或者使用Node等适合io密集型的语言进行开发

    mysql等这种关系型数据，对于一般小公司没有数据库运维的人来说，大表就不要使用分表和分库了，太麻烦，但是主从读写分离是一定需要做的，对于读写分离，一般应用系统决定使用哪台机器进行读写也是比较麻烦的，可以采用mysql proxy或者360提供的数据库代理工具，可以很大程度上降低系统的复杂性，系统架构上也要该很多东西，采用mongo等nosql数据库。

    异步处理的尽可能的使用消息队列

    当然程序方面的优化还有很多

    总结以上几点，做起来还是比较容易的，但是我们失败了，阿里云的海外节点到国内的节点的网络不稳定，经常丢包导致很多到国内的请求都是失败的，痛苦不堪啊。

    最后使用稳定的具有海外和国内的专线服务的云服务厂商， 增加代理服务，代理到国内服务器。国内服务器做跨机房部署，避免单机房故障。