如何实现高性能可伸缩架构技术

做互联网应用的兄弟应该都清楚，缓存对于一个互联网应用是多么的重要，从浏览器缓存，反向代理缓存，页面缓存，局部页面缓存，对象缓存等等都是缓存应用的场景。

 一般来说缓存根据与应用程序的远近程度不同可以分为：local cache 和 remote cache。一般系统中要么采用local cache，要么采用remote cache,两者混合使用的话对于local cache和remote cache的数据一致性处理会变大比较麻烦。

系统刚上线初期，用户数并不多，所有的逻辑也许都是放在一个系统中的，所有逻辑跑到一个进程或者一个应用当中，这个时候因为比较用户少，系统访问量低，因此将全部的逻辑都放在一个应用未尝不可。但是，兄弟们都清楚，好景不长，随着系统用户的不断增加，系统的访问压力越来越多，同时随着系统发展，为了满足用户的需求，原有的系统需要增加新的功能进来，系统变得越来越复杂的时候，我们会发现系统变得越来越难维护，难扩展，同时系统伸缩性和可用性也会受到影响。那么这个时候我们如何解决这些问题呢？明智的办法就是拆分（这也算是一种解耦），我们需要将原来的系统根据一定的标准，比如业务相关性等分为不同的子系统，不同的系统负责不同的功能，这样切分以后，我们可以对单独的子系统进行扩展和维护，从而提高系统的扩展性和可维护性，同时我们系统的水平伸缩性scale out大大的提升了，因为我们可以有针对性的对压力大的子系统进行水平扩展而不会影响到其它的子系统，而不会像拆分以前，每次系统压力变大的时候，我们都需要对整个大系统进行伸缩，而这样的成本是比较大的，另外经过切分，子系统与子系统之间的耦合减低了，当某个子系统暂时不可用的时候，整体系统还是可用的，从而整体系统的可用性也大大增强了。

上面所说的都是拆分的好处，但是拆分以后必然的也会带来新的问题，除了刚才说的子系统通信问题外，最值得关注的问题就是系统之间的依赖关系，因为系统多了，系统的依赖关系就会变得复杂，此时就需要更好的去关注拆分标准，比如能否将一些有依赖的系统进行垂直化，使得这些系统的功能尽量的垂直，这也是目前公司正在做的系统垂直化，同时一定要注意系统之间的循环依赖，如果出现循环依赖一定要小心，因为这可能导致系统连锁启动失败。

系统刚开始的时候，因为系统刚上线，用户不多，那个时候，所有的数据都放在了同一个数据库中，这个时候因为用户少压力小，一个数据库完全可以应付的了，但是随着运营那些哥们辛苦的呐喊和拼命的推广以后，突然有一天发现，oh,god,用户数量突然变多了起来，随之而来的就是数据库这哥们受不了，它终于在某一天大家都和惬意的时候挂掉啦。此时，咱们搞技术的哥们，就去看看究竟是啥原因，我们查了查以后，发现原来是数据库读取压力太大了，此时咱们都清楚是到了读写分离的时候，这个时候我们会配置一个server为master节点，然后配几个salve节点，这样以来通过读写分离，使得读取数据的压力分摊到了不同的salve节点上面，系统终于又恢复了正常，开始正常运行了。但是好景还是不长，有一天我们发现master这哥们撑不住了，它负载老高了，汗流浃背，随时都有翘掉的风险，这个时候就需要咱们垂直分区啦（也就是所谓的分库），比如将商品信息，用户信息，交易信息分别存储到不同的数据库中，同时还可以针对商品信息的库采用master，salve模式，OK，通过分库以后，各个按照功能拆分的数据库写压力被分担到了不同的server上面，这样数据库的压力终于有恢复到正常状态。但是是不是这样，我们就可以高枕无忧了呢？NO,这个NO，不是我说的，是前辈们通过经验总结出来的，随着用户量的不断增加，你会发现系统中的某些表会变的异常庞大，比如好友关系表，店铺的参数配置表等，这个时候无论是写入还是读取这些表的数据，对数据库来说都是一个很耗费精力的事情，因此此时就需要我们进行“水平分区”了（这就是俗话说的分表，或者说sharding）。