文章目录

系统架构演化历程
- 单体架构
- 应用服务和数据服务分离
- 缓存的使用
- 集群的使用
- 数据库读写分离
- 反向代理和CDN加速
- 分布式文件和分布式数据库
- NoSql和搜索引擎
- 业务拆分
- 分布式服务

现在出去找工作如果不会点分布式和微服务相关的内容，都不太好更面试官扯蛋。但这些架构也不是突然就出现的，而是经过不但演变才出现及流行起来的，本文就给大家来梳理下java项目架构的演变历程。

系统架构演化历程

单体架构

大型网站都是从小型网站发展而来的，网站架构也是一样，是从小型网站架构逐步演化而来的，小型网站最开始没有太多人访问，只需要一台服务器就绰绰有余了，这时的架构如下:

应用程序、数据库、文件等所有的资源都在一台服务器上，通常服务器操作系统使用Linux、应用程序使用java或者其他语句，然后部署在Apache或者Nginx上。数据库使用MySQL，使用开源的技术实现，然后部署在一台廉价的服务器上就开始了网站的发展之路。

应用服务和数据服务分离

好景不长，随着公司业务的发展，一台服务逐渐满足不了需求，越来越多的用户访问导致性能越来越差，数据存储空间开始不足，这时我们需要将应用和数据分离，分离后开始使用三台服务器：应用服务器、文件服务器、数据库服务器。如图:

应用和数据分离后，不同特性的服务器承担着不同的服务角色，网站的并发处理能力和数据存储空间都得到了很大的改善，支持网站业务进一步发展，但是随着用户逐渐增多，数据库压力越来越大，访问延迟，进而影响整个网站的性能，此时需要进一步优化。

缓存的使用

网站访问有个著名的二八定律，即80%的业务集中访问在20%的数据上，如果我们将这一小部分的数据缓存在内存中，能够很好的减少数据库的访问压力，提高整个网站的数据访问速度。

缓存常用的组件可以是Redis,ehcache等

集群的使用

缓存解决了数据库访问量比较大的问题，但是并不能解决随着业务增多造成的服务器并发压力大的问题，这时我们需要增加一台应用服务器来分担原来服务器的访问压力和存储压力。如图:

通过负载均衡调度服务器，可将来自用户的访问请求分发到应用服务器中的任何一台服务器中，这样多台服务器就分担了原来一台服务器的压力，我们只需要注意会话的一致性就可以了。

数据库读写分离

系统正常运行了一段时间后，虽然加的有缓存，使绝大多数的数据库操作可以不通过数据库就能完成，但是任然有一部分的操作(缓存访问不命中，缓存过期)和全部的写操作需要访问数据库，当用户达到一定规模后，数据库因为负载压力过大还是会成为系统的瓶颈，
这时主流的数据库都提供的有主从热备份功能，通过配置两台数据库实现主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。可以利用这一功能来实现数据库读写分离。从而改善数据库的负载压力，如图:

mysql的读写分离可以通过自身自带的从主复制实现，Oracle的话可以通过阿里巴巴的mycat组件来实现。

反向代理和CDN加速

为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。CDN部署在网络提供商的机房。用户请求到来的时候从距离自己最近的网络提供商机房获取数据，而反向代理则部署在网站的中心机房中，请求带来的时候先去反向代理服务器中查看请求资源，如果有则直接返回。如图：

使用CDN和反向代理的目的都是尽早返回数据给用户，一方面加快用户的访问速度，另一方面也减轻后端服务器的负载压力。

分布式文件和分布式数据库

任何强大的单一服务器都满足不了大型网站持续增长的业务需求。数据库经过读写分离后，从一台服务器拆分成两天服务器，但是随着业务的增长后面依然不能满足需求，这时我们需要使用分布式数据库，同时文件系统也一样，需要使用分布式文件系统。
分布式数据库是数据库拆分的最后的手段，只有在表单数据规模非常庞大的时候才使用，不到不得已时，我们更常用的手段是业务分库，将不同的业务数据部署在不同的物理服务器上。

NoSql和搜索引擎

随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，这时一些NoSQL(Reids,HBase,mongodb)数据库技术和搜索引擎(Solr,Elasticsearch)的时候就显得很有必要。如下图:

NoSQL和搜索引擎对可伸缩的分布式特性具有更好的支持，应用服务器通过一个统一的数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

业务拆分

当访问量达到一定规模的时候我们可以通过分而治之的手段将整个系统的业务分成不同的产品线，例如我们将系统的首页，商铺，订单，买家，卖家，支付，订单等拆分成不同的产品线。
具体到技术实现上，也可以根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署维护，应用之间通过RPC框架(dubbo,webService,httpClient…)建立连接，也可以通过消息队列实现异步分发处理。来构成一个完整的系统，如下图:

分布式服务

随着业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。

当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？
一个服务有多个业务消费者，如何确保服务质量？
随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？

解决方案：公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。也就是我们将的分布式服务或者微服务。

微服务的设计原则参考此文:
https://dpb-bobokaoya-sm.blog.csdn.net/article/details/87305626

Java项目架构的演变相关推荐

大型Java项目架构演进
为什么80%的码农都做不了架构师?>>> 大型Java项目架构演进过程 1. All-In-One (所有服务在一台服务器上): 也就是所有的服务都在同一个服务器上,包括应用服 ...
Java项目架构演进和SpringCloud总结
Java项目架构演进过程和SpirngCloud知识总结: 技术梳理开发技术栈以SpringCloud为主,单个微服务模块以SpringMVC+SpringBoot/Spring+MyBatis组合 ...
大型Java项目架构演进（小白）
大型Java项目架构演进(小白) 增加服务器大部分的访问都在小部分的数据(缓存)上增加缓存(具有哪种业务特点的数据适合使用缓存) 远程缓存远程单机缓存远程分布式缓存 (集群) 分布式缓存在 ...
JAVA分布式架构的演变及解决方案
JAVA分布式架构的演变及解决方案参考文章: (1)JAVA分布式架构的演变及解决方案 (2)https://www.cnblogs.com/malcome/articles/5909632.htm ...
Java项目架构类型与项目分类
Java项目架构类型 JavaEE企业级应用经过多年的发展,出现了很多不同的架构类型, Java应用架构发展主要经历了一下四段历程,分别是单一应用架构,垂直应用架构,分布式服务架构和流动计算架构单一 ...
Java项目架构演变:单体应用-SOA-微服务
单体应用概览所有功能全部打包在一起.大部分是一个jar包或者war包,随着业务发展功能增多,这个项目会越来越臃肿优点容易开发,测试,部署,适合项目初期试错缺点复杂性高:代码多,十万行,百万 ...
jug java_架构大型企业Java项目–我的虚拟JUG会话
jug java 昨天我很荣幸被邀请参加虚拟JUG . 这是一个很大的荣誉,其原因有很多:首先,我是vJUG董事会的一员,其次,因为这是我第二次向这个对Java感兴趣的伟大团队做演讲. 受到邀请总是很 ...
架构大型企业Java项目–我的虚拟JUG会话
昨天我很荣幸被邀请参加虚拟JUG . 这是一个很大的荣誉,其原因有很多:首先,我是vJUG董事会的一员,其次,因为这是我第二次向这个对Java感兴趣的伟大团队做演讲. 被邀请回来总是很高兴的. 架构大 ...
java kafka分布式_JavaWeb项目架构之Kafka分布式日志队列
架构.分布式.日志队列,标题自己都看着唬人,其实就是一个日志收集的功能,只不过中间加了一个Kafka做消息队列罢了. kafka介绍 Kafka是由Apache软件基金会开发的一个开源流处理平台,由S ...
java达内项目_达内IT学院举办Java互联网架构师项目峰会
12月19日,由达内IT学院主办的"Java互联网架构师项目峰会"在北京成功举办.本次活动是在达内IT学院成立.Java互联网架构课程全面升级之后的首场全国性的项目峰会.活动现场, ...

Java项目架构的演变