Java 应用一般架构

标签: java | 发表时间:2015-11-17 02:23 | 作者:Coding_net
出处:http://segmentfault.com/blogs

原文地址: https://blog.coding.net/blog/General-architecture-for-Java-applications

当我们架设一个系统的时候通常需要考虑到如何与其他系统交互,所以我们首先需要知道各种系统之间是如何交互的,使用何种技术实现。

1. 不同系统不同语言之间的交互

现在我们常见的不同系统不同语言之间的交互使用WebService,Http请求。WebService,即“Web 服务”,简写为 WS。从字面上理解,它其实就是“基于 Web 的服务”。而服务却是双方的,有服务需求方,就有服务提供方。服务提供方对外发布服务,服务需求方调用服务提供方所发布的服务。如果说得再专业一点,WS 其实就是建立在 HTTP 协议上实现异构系统通讯的工具。没错!WS 说白了还是基于 HTTP 协议的,也就是说,数据是通过 HTTP 进行传输的。最早我们是用CXF开发SOAP服务实现WS,后面我们是用REST服务实现WS(这个目前使用比较多,也最我用得最多的这一种)。基于CXF也可以开发REST服务,不过我们一般直接使用springMVC或者其他MVC框架实现REST服务。

但是在很多人的印象中Web service的话一般指十来年前IBM主导的基于XML的各种交互技术,现在除了一些公司在用之外用得人也很少了。广义的话Webservice就是Web 服务了,一切皆服务。

2. 不同系统相同语言之间的交互

常见的不同系统相同语言之间的交互用RPC(远程过程调用),或者RMI(远程方法调用)实现,不用对外部提供服务,当然上面说的也可以使用在相同语言之间的交互,只是我常用的是RPC。

不同产品的架构

3. 单个产品的架构演进

一般我们只是一个产品的情况下的架构演进历程,如果需要对外提供webService,通常使用REST服务实现。

以下一段内容来源于 知乎

1. 分布式架构的演进系统架构演化历程-初始阶段架构

图片

初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP

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

描述:通常服务器操作系统使用linux,应用程序使用PHP开发,然后部署在Apache上,数据库使用Mysql,汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。

2. 系统架构演化历程-应用服务和数据服务分离

图片

好景不长,发现随着系统访问量的再度增加,webserver机器的压力在高峰期会上升到比较高,这个时候开始考虑增加一台webserver

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

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

3. 系统架构演化历程-使用缓存改善性能

图片

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

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

4. 系统架构演化历程-使用应用服务器集群

图片

在做完分库分表这些工作后,数据库上的压力已经降到比较低了,又开始过着每天看着访问量暴增的幸福生活了,突然有一天,发现系统的访问又开始有变慢的趋势了,这个时候首先查看数据库,压力一切正常,之后查看webserver,发现apache阻塞了很多的请求,而应用服务器对每个请求也是比较快的,看来 是请求数太高导致需要排队等待,响应速度变慢

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

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

5. 系统架构演化历程-数据库读写分离

图片

享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始变慢了,这次又是什么状况呢,经过查找,发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈,导致了系统变慢

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

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

6. 系统架构演化历程-反向代理和CDN加速

图片

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

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

7. 系统架构演化历程-分布式文件系统和分布式数据库

图片

随着系统的不断运行,数据量开始大幅度增长,这个时候发现分库后查询仍然会有些慢,于是按照分库的思想开始做分表的工作

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

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

8. 系统架构演化历程-使用NoSQL和搜索引擎

图片

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

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

9. 系统架构演化历程-业务拆分

图片

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

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

10. 系统架构演化历程-分布式服务

图片

特征:公共的应用模块被提取出来,部署在分布式服务器上供应用服务器调用。描述:随着业务越拆越小,应用系统整体复杂程度呈指数级上升,由于所有应用要和所有数据库系统连接,最终导致数据库连接资源不足,拒绝服务。

Q:分布式服务应用会面临哪些问题?

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

4. 产品线的架构

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

如下图的模型,文件系统,缓存那些没有画出来,大家理解就行。

图片

结语:

不管哪种架构我们都需要做好模块化(尽量做到模块复用)。
不要为了架构而架构导致过度设计。
不管何种架构都是为了更好满足业务需求,架构应该跟随业务的发展而发展。
当前的架构如果可以满足当前的业务发展,就可以考虑下一步的扩展了,不用一下子考虑3步4步甚至更多。
以上如果有误,还望大家不吝赐教!

相关 [java 应用 架构] 推荐:

Java 应用一般架构

- - SegmentFault 最新的文章
原文地址: https://blog.coding.net/blog/General-architecture-for-Java-applications. 当我们架设一个系统的时候通常需要考虑到如何与其他系统交互,所以我们首先需要知道各种系统之间是如何交互的,使用何种技术实现. 现在我们常见的不同系统不同语言之间的交互使用WebService,Http请求.

Java应用运维

- - BlueDavy之技术blog
对于互联网产品或长期运行的产品而言,运维工作非常重要,尤其是在产品复杂了以后,在这篇blog中就来说下Java应用的运维工作(ps:虽然看起来各种语言做的系统的运维工作都差不多,但细节上还是会有很多不同,so本文还是只讲Java的). 苦逼的码农按照需求开发好了一个全新的Java Web应用,该发布上线给用户用了,要把一个Java Web应用发布上线,首先需要搭建运行的环境,运行的环境需要有JDK、APPServer,在已经装好了os的机器上装上JDK和APPServer,开发好的Java Web应用可以用maven直接打成war或ear,将这个打好的包scp或其他方式到目标机器上,准备妥当,就差启动了.

Java线程池应用

- - CSDN博客架构设计推荐文章
1.减少了创建和销毁线程的次数,每个工作线程都可以被重复利用,可执行多个任务. 2.可以根据系统的承受能力,调整线程池中工作线线程的数目,防止因为消耗过多的内存,而把服务器累趴下(每个线程需要大约1MB内存,线程开的越多,消耗的内存也就越大,最后死机). Java里面线程池的顶级接口是Executor,但是严格意义上讲Executor并不是一个线程池,而只是一个执行线程的工具.

应用架构和技术架构

- - 人月神话的BLOG
在这里再谈下应用架构和技术架构的关系和边界问题,这里的说明和标准的TOGAF会有一些区别,仅为个人理解的一些点滴记录. 首先再说下应用架构,应用架构是和业务架构有强烈的映射关系的一个架构,应用架构要说明的是整体企业内部信息化建设和规划应该分为哪些应用系统去建设,应用系统间的集成关系是如何的. 即我们常说的应用架构和应用集成架构.

企业架构-应用架构构图

- - 人月神话的BLOG
在这里要谈的是在传统的企业架构-应用架构的基础上进一步体现SOA和企业私有云平台的思想,而非传统意义上简单的原有企业各个业务系统功能架构的堆砌. 这个思想包括两个方面的内容,一个是集中化和平台化,一个是SOA服务化和业务能力组件化. 对于该构图模式考虑两种,首先第一种是充分考虑平台层独立和平台层能力的体现:.

再谈应用架构

- - 人月神话的BLOG
前面谈了业务架构和数据架构,接着谈下应用架构,对于应用架构的描述将参考togaf信息系统架构部分的内容,但是不完全相同,总体思路是围绕在IT架构层面来谈应用架构包括的内容. 为了区分高层架构(包括多个应用的总体架构)和底层架构(针对单个业务系统的架构),前者采用企业架构中的应用架构这个词,后者采用系统架构这个词以进行区分.

Java线程池架构原理和源码解析(ThreadPoolExecutor)

- - ImportNew
在前面介绍JUC的文章中,提到了关于线程池 Execotors的创建介绍,在文章:《 java之JUC系列-外部Tools》中第一部分有详细的说明,请参阅;. 使用Executors最常用的莫过于是使用:Executors.newFixedThreadPool(int)这个方法,因为它既可以限制数量,而且线程用完后不会一直被cache住;那么就通过它来看看源码,回过头来再看其他构造方法的区别:.

xssProject在java web项目中应用

- - Java - 编程语言 - ITeye博客
1.项目引入xssProtect-0.1.jar、antlr-3.0.1.jar、antlr-runtime-3.0.1.jar包. * 覆盖getParameter方法,将参数名和参数值都做xss过滤. * 如果需要获得原始的值,则通过super.getParameterValues(name)来获取
.

使用Gradle构建Java Web应用(译)

- - BlogJava-首页技术区
使用Gradle构建Java Web应用. 本文是发布在 java.net上的一篇摘自于一书中的 节选,介绍了使用 Gradle构建Java Web应用的过程. 刚刚接触Gradle,看到了这篇小文,随手译了出来:-) (2014.01.23最后更新). 在职业生涯和私人生活中,我们中间的许多人要同时管理多个项目.

Java-了解注解及其应用

- - BlogJava-qileilove
  注解就是一种标记,在程序中加了注解就等于加了标记,没加,就没有标记. java编译器、开发工具或是其他程序可以通过反射技术了解你的类或各种元素是否有标记,有什么标记就做什么. 比如:子类重写父类的方法,方法上必须有@override标记;若一个方法已过时不用了,就该方法添加注.   解@Deprecated,调用者反射时就明白这方法已过时.