构建互联网高性能WEB系统经验总结

互联网发展至今各种应用层出不穷,用户量动辄上亿。所以如何构建一个优秀的高性能、高可靠的应用系统对每一个开发者至关重要。本文将我所学到和在工作中使用到的一些方法归纳总结,希望给其他同学起到一些借鉴作用,在以后的开发中遇到类似的问题,能快速的找到解决方案。本人主要使用语言是JAVA,所以下面不做特殊说明,都是使用JAVA语言

高性能的关键

要想做到高性能,我总结了三点:

  1. 缓存
    • DNS缓存
    • 数据库缓存
    • 分布式缓存
  2. 拆分
    • 业务拆分
    • 数据库拆分
  3. 异步
    • 网络异步
    • 磁盘异步
    • 使用消息

上面举了一些三点中常见的情况,无论什么地方遇到性能瓶颈,谨记这三点,大多数时候都能找到解决方案。以下分别介绍在整个架构中各个方面对这三点的应用

无状态服务

说无状态服务我们首先要想到无状态对象,无状态对象简单的可以理解为没有Field的对象,比如model/entity对象就不属于无状态对象,因为他含有Field,比如典型MVC场景的**Controller,**Service就是无状态的,他们只含有method。有的也是有状态的,比如Structs2框架的Action,所以Structs2现在用得比较少了。有了无状态对象,我们才有可能构建无状态服务,因为请求链路中不包含有状态对象,所以我们每一次请求都是独立的,这样的架构有助于我们服务进行扩展。

无状态服务有时候不可避免的会遇到一些有状态的对象,比如最常见的就是session。因为http请求本身是无状态的,所以必须cookie和session配合使用,才能识别多次http请求属于同一用户。一般有两种方法解决:

  • 使用cookie存储
  • 使用分布式session服务

第一种就是将对象信息全部存储在cookie中,通过相应的算法等在服务端将cookie中的信息读出来。这些信息一般都会进行加密处理。
第二种方法,就是将session存储在分布式数据库或者分布式缓存中,一般存在redis或者memcache中。那这种服务扩展会依赖第三方数据库或缓存的能力。淘宝有类似的组件,开源世界也有基于memcache和redis的分布式session

无状态服务用到了拆分和缓存

业务拆分

无状态可以使应用服务水平扩展,但是当单个应用太大太臃肿时,有必要对应用进行拆分。垂直拆分即按业务拆分,比如电商系统中,按照订单系统,积分系统等进行拆分。拆分可以方便开发,更方便扩展。系统大了以后,每个业务的访问量是不一样的,比如买家系统肯定比卖家系统访问量大得多,这时候就可以只增加买家系统的机器即可。

除了按照业务的不同拆分成不同的系统以外,针对我们的应用分层也可以进行拆分,一般分为应用层、逻辑层和原子层。应用层就是各种数据、逻辑业务的组装,逻辑层含有大量可重用逻辑,原子层直接操作数据库,一些基本的数据操作包含在其中。

不论以何种形式拆分,拆分以后的系统在物理层面上就分离开来,所以系统间的通信是拆分中最重要的问题所在。

RPC

在RPC服务之前已经许多系统通信的方法,比如RMI、WebService,但是RPC以更方便,更高效,跨平台的方式现在成为主流的通信手段。几乎每个大公司都有自己的RPC框架:淘宝的HSF、58的SCF,也有非常多优秀的开源框架:Dubbo、GRPC、Thrift等等。国内用dubbo的大公司也很多:京东、当当都是。

MQ

RPC调用一般是用在耦合比较重,同步调用的场景下。而MQ作为另一种异步通信的手段也被广泛使用在各个业务中。常用的有:ActiveMQ、RabbitMQ、Kafka、RocketMQ。前两个一般作为企业级应用,主要特点是支持非常多的特性和规范。后两者是互联网级的,拥有更强力的吞吐和更高的性能,但是牺牲了很多MQ的特性。mq一般用在要求最终一直性即可的场景,比如用户注册和发积分这两个动作,可以用户注册以后直接返回前台成功,然后发送注册成功消息给mq系统,发积分动作订阅注册事件,消费mq的事件信息。

MQ最大的好处就是削峰和解耦,在RPC式的同步调用场景中,如果同一个逻辑中调用A和B,那么在扩展的时候,A和B一定是需要同时扩展的,但是有了消息以后,A发送消息给B,及时B暂时处理不了,也可以等到A峰值过后B继续处理,即使B短期无法匹配A的发送消息能力也没有关系。

构建互联网高性能WEB系统经验总结

扫一扫手机访问