现在我们假设香港服务器承载100万的需求确实来了。

现在有大规模并发需求的IT系统可以分为两类，一类是淘宝这样的网站，虽然并发大，但是模式简单，交互拓扑是无数客户端围绕服务器云组成的星形模式，交互总是由客户端发起，因为http，本质上没有会话的概念；一类是QQ，微信这样的及时通信系统，交互拓扑是无数客户端互相联系形成的网状模式（香港服务器云基础运行是中间人），有强烈会话的概念，会话的生存期有可能会很长，中间有反复的交互。不知道你的系统更像哪一类？滴滴打车应该是属于第二类的。

如果是第一类，有许多现成的模子可以套

首先，处理简单的静态内容，引入反向代理，动静分离，把静态内容放到专门的服务器上，进一步可以把静态内容部署到CDN；

其次，真正困难的是动态部分。

步骤一，读写分离，利用mysql的主从复制功能，把数据分发到如果服务器，主服务器只管写请求，读请求offload到从服务器；

步骤二，单台主香港服务器扛不住了，水平分表，垂直分库，把写操作按照不同的table，offload到不同的主服务器，现在复杂度蔓延到程序内部了。

步骤三，生意实在太好了，分库分表也搞不定，上服务器集群。

这个过程中，你还有别的不需要增加软件复杂度的辅助手段，比如用SSD来放数据库，加大缓存，但是不知道阿里云是否支持；还有其他软件手段，比如用NoSQL来处理日志之类特殊的数据。

如果是第二类，也有现成的模子可套。如果不想自己架构，可以先找个openfire之类的XMPP套件用起来，等不行了再扩展。

这类系统的挑战是有大量在内存中存活的会话，举个例子把，如果你用TCP来做传输，每一个会话在操作系统的协议栈里面都需要有相应的TCB，如果用UDP，那么为了处理NAT，你需要在应用层自己维护映射表。除了了传输，你在应用层还会维护大量的状态机，这也是一个耗内存和耗CPU的活计。

好在你不是第一个，网上搜索一下MSN,QQ,微信，他们的需求和你类似，一般这么解决scalability问题。

通常是垂直分解，把系统分解为若干认证服务器，会话服务器，和补充服务服务器。比如你上QQ，要先认证，那就有只负责认证的服务器招呼你，认证完了，根据当前负载，在会话服务器farm里挑一台不太忙，离你近的服务器负责你的文字聊天，如果你还想语音或者视频，那么你在发起语音视频的时候又按照前述原则给你分配相应的补充服务服务器。你可以想象，认证服务器是医院的挂号处，会话和特殊服务器就是各个科室。当然认证服务器自己也是可以通过DNS进行扩展的。

这种系统如果遇到数据库瓶颈，也可以参照前面第一类系统解决。

另外，有些系统的数据具有天生的可分区性，比如UBer，香港的司机不会去抢深圳的单，如果按照这种地理特性去分区，一个虚机管一个区域，既解决了可扩展性还解决了可靠性。

互联数据HKT4提供香港服务器租用真实硬件独享，限时首月半价租用，全Tier4认证硬件设备，欢迎用户联系24小时在线工程师咨询。