构建可伸缩,高性能的互联网应用

《构建可伸缩,高性能的互联网应用》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、一应用无状态俗话说，一个系统的伸缩性的好坏取决于应用的状态如何管理。为什么这么说呢？咱们试想一下，假如我们在session中保存了大量与客八端的状态信息的话，那么当保存状态信息的server宕机的时候，我们怎么办？通常来说，我们都是通过集群来解决这个问题，而通常所说的集群，不仅有负载均衡，更重要的是要有失效恢复failover,比如tomcat采用的集样节点广播复制，jboss采用的配对复制等session状态复制策略，但是集群中的状态恢复也有其缺点，那就是严重影响了系统的伸缩性，系统不能通过增加更多的机器来达到良好的水平伸缩，因为集群节点间session的通信会随着节点

2、的增多而开销增大，因此要想做到应用本身的伸缩性，我们需要保证应用的无状态性，这样集群屮的各个节点来说都是相同的,从而是的系统更好的水平伸缩。0K,±面说了无状态的重要性，那么具体如何实现无状态呢？此时一个session框架就会发挥作用了。一般通过cookie來实现，或者也可以采用集中式session悖理來完成,说具体点就是多个无状态的应用节点连接一个session服务器，session服务器将session保存到缓存中，session服务器后端再配有底层持久性数据源，比如数据库，文件系统等等。二有效使用缓存做互联网应用的兄弟应该都清楚，缓存对于一个互联网应用是多么的重耍，

3、从浏览器缓存，反向代理缓存，页面缓存，局部页而缓存，对象缓存等等都是缓存应用的场景。一般来说缓存根据与应用程序的远近程度不同刊以分为：localcache和remotecache。一般系统中要么采川localcache,要么采用remotecache,两者混合使用的话对于localcache和remotecache的数据一致性处理会变人比较麻烦.在大部分情况下，我们所说到的缓存都是读缓存,缓存还冇另外一个类型：写缓存.对于一些读写比不高，同时对数据安全性需求不高的数据，我们可以将其缓存起来从而减少对底层数据库的访问，比如统计商品的访问次数，统计APT的调用量等等，可以采用

4、先写内存缓存然后延迟持久化到数据库，这样可以人人减少对数据库的写压力。三应用拆分首先，在说明应川拆分Z前，我们先來回顾一下一个系统从小变大的过程中遇到的一些问题,通过这些问题我们会发现拆分对于构建一个人型系统是如何的重要。系统刚上线初期，用户数并不多，所冇的逻辑也许都是放在一个系统屮的，所有逻辑跑到一个进程或者一个应用当中，这个时候因为比较用户少，系统访问量低，因此将全部的逻辑都放在一个应用耒尝不可。但是，兄弟们都清楚，好景不长，随着系统用户的不断增加，系统的访问压力越来越多，同时随着系统发展，为了满足用户的需求，原有的系统需要增加新的功能进來，系统变得越來越复杂的时候，

5、我们会发现系统变得越來越难维护，难扩展，同时系统伸缩性和可用性也会受到影响。那么这个吋候我们如何解决这些问题呢？明智的办法就是拆分（这也算是一种解耦），我们需要将原來的系统根据-•定的标准，比如业务相关性等分为不同的子系统，不同的系统负责不同的功能，这样切分以后，我们可以对单独的子系统进行扩展和维护，从而提高系统的扩展性和可维护性，同时我们系统的水平伸缩性scaleout大大的提升了，因为我们可以冇针对性的对压力大的了系统进行水平扩展而不会影响到其它的子系统，而不会像拆分以前，每次系统压力变大的吋候，我们都需要对整个大系统进行伸缩，而这样的成木是比较大的，另外经过切分，了

6、系统与了系统Z间的耦合减低了，当某个子系统暂时不可用的时候，整体系统还是可用的，从而整体系统的可卅性也人大増强了。因此一个大型的互联网应用，肯定是要经过拆分，因为只冇拆分了，系统的扩展性，维护性,伸缩性，可用性才会变的更好。但是拆分也给系统帯来了问题，就是了系统之间如何通信的问题，而具体的通信方式有哪些呢？一•般有同步通信和界步通信，这里我们首先來说下同步通信，卜-面的主题“消息系统”会说到杲步通信。既然需耍通信，这个时候一个高性能的远程调用框架就显得非常总要啦.上面所说的都是拆分的好处，但是拆分以后必然的也会带来新的问题，除了刚才说的子系统通信问题外，最值得关注的问题就

7、是系统之间的依赖关系，因为系统多了，系统的依赖关系就会变得复杂，此时就需耍更好的去关注拆分标准，比如能否将一些有依赖的系统进行垂直化，使得这些系统的功能尽量的垂胃，这也是目前公司正在做的系统垂胃化，同时一定要注意系统Z间的循环依赖，如果出现循环依赖一定要小心，因为这可能导致系统连锁启动失败。从上面可以看出，一个大型系统要想变得可维护，町扩展，可伸缩，我们必须的对它进行拆分，拆分必然也带來系统之间如何通信以及系统之间依赖管理等问题。四数据库拆分在前面“应用拆分”主题屮，我们提到了一个大型互联网应用需要进行良好的拆分,而那里我们仅