云计算之路-阿里云上：希望从今天开始乌云变蓝天

真没想到云计算之路上的天气如此糟糕，比杭州的交通还要糟糕；今天上海晴空万里，希望从今天开始“云”上的天气也一直晴空万里。

昨天发布了博文云计算之路-柳暗花明：为什么memcached会堵车之后，去参加了阿里云客户交流会，哪知14:00左右会议刚开始，网站又出现访问速度慢的问题。。。

立即采取前天的措施，关闭memcached服务器，立即恢复正常。。。但是，没过多久问题又出现。。。

同样的方法，为什么前天能解决问题而昨天不能？这里的不同之处是前天关闭memcached服务器之后，正在走出访问高峰期，而昨天正在走入访问高峰期。

那为什么关闭memcached服务器之后会立即恢复正常？我们的猜测是：在关闭memcached服务器之前，所有web服务器都与memcached服务器之间保持着很多TCP连接进行大量网络通信，memcached服务器的网络处理能力很可能是瓶颈。关闭memcached服务器之后，直接走数据库（RDS），网络瓶颈不存在了。

但是关闭memcached服务器之后，压力会转嫁给数据库服务器与web服务器的CPU。数据库服务器用的是RDS，刚刚的，这点转嫁过来的压力小case。怎么会转嫁给CPU呢，因为memcached缓存的不是直接数据库查询结果，而是实体对象，这些实体对象不仅包含数据库查询结果，还包含对数据库查询结果的处理，比如一些正则表达式处理。而跑web服务器的云服务器CPU一直是瓶颈，在出问题的期间都伴随着CPU占用大、波动大，所以我们才用了4台4核做负载均衡。我们猜测关闭memcached服务器之后请求处理速度慢可能是CPU处理能力的原因。

于是，我们进行了这样的假设：把云服务器想像成一个黑盒子，黑盒包装着印着“CPU占用不得高于某值，TCP连接数不得高于某值”。（注：这只是假设，不代表虚拟机有这样的限制。这是一种解决问题的手段，做科学研究有时也会先提出假设再证明这个假设）

然后，我们的解决思路就围绕这个假设展开——1. 如何提高单台web服务器的CPU处理能力/减少CPU处理压力；2. 如何减少单台云服务器的网络连接负载（TCP连接数）？

解决方法一

之前，我们有个非常错误的想法——以为通过负载均衡（阿里云SLB）可以减少单台web服务器的CPU处理压力。所以也尝试过在出问题时向负载均衡添加更多云服务器，结果证明解决不了问题。

而事实可能是，对于瞬间的并发请求，SLB无用武之地。我们对SLB的工作方式是这样猜测的：SLB只转发请求，并不拆分请求。假如4台web服务器每台能支撑的并发请求数是500，SLB一次收到了800的并发请求，一股脑儿转发给其中一台web服务器，这台web服务器趴下了（扛不住）；SLB下一次收到了1000的并发请求，一股脑儿转发给另一台web服务器，那台也趴下了；接下来SLB收到了1200的并发请求，第3台web服务器也趴下了。如果把这4台web服务器合并为1台，能支撑的并发请求数是2000，就能轻松应对。

于是，我们把4台web服务器中的2台由4核4G升级为8核8G，把另外2台从SLB中摘掉。负载均衡由原来的4台4核4G变为2台8核8G。

解决方法二

在所有云服务器（虚拟机）中，memcached服务器是网络连接负载最高的，因为所有web服务器都与之通信。数据库用的是RDS，是物理机，不在考虑范围。

我们想到了一个终极方法，将couchbase直接安装在两台web服务器上，web服务器与memcached服务器之间通过127.0.0.1接口进行本地通信，通过couchbase的集群功能让两台memcached服务器的数据保持同步。

web.config中memcached客户端配置变为这样：

<enyim.com>
    <memcached protocol="Binary">
        <servers>
            <add address="127.0.0.1" port="11211" />            
        </servers>
        <socketPool minPoolSize="10" maxPoolSize="300" connectionTimeout="00:00:01" deadTimeout="00:00:01" />
    </memcached>
</enyim.com>

以前我们自己托管服务器时，也是这样部署的，单台8核8G既跑web又跑memcached。

这两个方法是在今天早上睡醒后想到的，然后一跃而起，在早上8点之前完成了部署。

正因为有了这两个解决措施，才敢展望：希望从今天开始乌云变蓝天！