Java大型网站架构

了解Java应用架构,更好地写程序,以架构师为目标

Posted by Wanglizhi on June 2, 2016

Java应用架构的演化之路

不同系统不同语言之间的交互(HTTP)

Web Service,建立在HTTP协议上实现异构系统通讯的工具。最早,使用CXF(Apache CXF 是一个开源的 Services 框架)开发SOAP服务实现Web Service,后面我们使用REST服务实现Web Service,例如Spring MVC框架可以实现REST服务。

不同系统相同语言之间的交互(RPC)

常见的不同系统相同语言之间的交互用RPC(远程过程调用),或者RMI(远程方法调用)实现

单个产品的架构演进

1、初始阶段架构

特征:应用程序、数据库、文件等所有资源都在一台服务器上

描述:通常服务器操作系统使用linux,应用程序使用PHP开发,部署到Apache上,数据库使用Mysql,汇集各种开源软件及一台廉价服务器。

2、应用服务和数据服务分离

特征:应用程序、数据库、文件分别部署在独立的资源上

描述:数据量增加,单台服务器性能及存储空间不足,需要将应用和数据分离,并发处理能力和数据存储空间得到改善

3、使用缓存改善性能

特征:数据库中访问较为集中的一小部分数据存储在缓存服务器中,减少数据库的访问次数,降低数据库的访问压力。

描述:系统访问特点遵循二八定律,即80%的业务访问集中在20%的数据上。缓存分为本地缓存和远程缓存,本地缓存访问速度更快但缓存数量有限,同时存在与应用程序争用内存的情况。

4、使用应用服务器集群

特征:多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题

描述:使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源,提升系统的并发处理能力,使得服务器的负载压力不再成为系统瓶颈

5、数据库读写分离

特征:多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限问题

描述:使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源,使得服务器的负载压力不在成为整个系统的瓶颈。

6、反向代理和CDN加速

特征:采用CDN和反向代理加快系统的 访问速度。

描述:为了应付复杂的网络环境和不同地区用户的访问,通过CDN和反向代理加快用户访问的速度,同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存

7、分布式文件系统和分布式数据库

特征:数据库采用分布式数据库,文件系统采用分布式文件系统。

描述:任何强大的单一服务器都满足不了大型系统持续增长的业务需求,数据库读写分离随着业务的发展最终也将无法满足需求,需要使用分布式数据库及分布式文件系统来支撑。分布式数据库是系统数据库拆分的最后方法,只有在单表数据规模非常庞大的时候才使用,更常用的数据库拆分手段是业务分库,将不同的业务数据库部署在不同的物理服务器上。

8、使用NoSQL和搜索引擎

特征:系统引入NoSQL数据库及搜索引擎。

描述:随着业务越来越复杂,对数据存储和检索的需求也越来越复杂,系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。

####9、业务拆分

特征:系统上按照业务进行拆分改造,应用服务器按照业务区分进行分别部署。

描述:为了应对日益复杂的业务场景,通常使用分而治之的手段将整个系统业务分成不同的产品线,应用之间通过超链接建立关系,也可以通过消息队列进行数据分发,当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。纵向拆分:将一个大应用拆分为多个小应用,如果新业务较为独立,那么就直接将其设计部署为一个独立的Web应用系统纵向拆分相对较为简单,通过梳理业务,将较少相关的业务剥离即可。横向拆分:将复用的业务拆分出来,独立部署为分布式服务,新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务,设计服务接口,规范服务依赖关系。

10、分布式服务

特征:公共的应用模块被提取出来,部署在分布式服务器上供应用服务器调用。

描述:随着业务越拆越小,应用系统整体复杂程度呈指数级上升,由于所有应用要和所有数据库系统连接,最终导致数据库连接资源不足,拒绝服务。

产品线的架构

还有一种就是上面也有提到的业务拆分。现在我们需要做一个产品线,我们只需要一个数据层,一个通用业务逻辑层,前面还有各种应用和界面层,不需要对外部系统(外部公司的系统)提供服务的情况以前我们一般会选择用EJB等来构建分布式应用,但是现在我们可以使用dobbo、thrift、avro、hessian这类RPC框架来构建分布式应用实现不同应用和数据来源的交互。这种结构模式下我们需要对其他公司提供服务,可以专门写一个应用对外部系统提供rest服务。一般大多数互联网服务背后都要访问十几个甚至几百个内部服务,它们之间的通信方式一般都是RPC:就像访问一个远程方法那样,输入参数后等待返回结果。这对于构建复杂系统是最容易理解的方式。

点评架构发展故事

Dianping 1.0

  • 2003-2004
  • www.zsurvey.com
  • ASP
  • Access
  • 虚拟主机
  • 0.4万动态访问量/天

Dianping 2.0

  • www.dianping.com
  • ASP.Net 1.1
  • SQL Server 7台服务器
  • 180万动态访问/天

Dianping 3.0

  • ASP.Net 2.0/ 3.0/ 3.5
  • MySQL + Memcached
  • MogileFS
  • Lucence
  • Hippo

Dianping 4.0

  • J2EE
  • RPC + MQ + ConfigServer + Monitor
  • Mysql + Mongo + Redis + Hive
  • Memcached
  • MogileFS
  • Lucence
  • 1亿+动态访问 / 天

分布式架构必须的基础设施

点评决定一步到位,在平台迁移的同时完成架构重构,站在巨人的肩膀上,打造可伸缩的分布式系统架构,用一年的时间完成淘宝5年完成的工作。

分布式存储

  • 分布式Cache
  • 分布式文件系统
  • 分布式RDBMS
  • 分布式NoSQL
  • 分布式大数据系统

分布式计算

RPC框架(Pigeon开源)

MQ框架(Swallow开源)

配置中心(Lion开源)

性能监控(Cat开源)

参考:大型网站技术架构 核心原理与案例分析

Java应用架构的演化之路

扩展:淘宝大秒系统设计详解

构建需求响应式亿级商品详情页