欢迎访问悦橙教程(wld5.com),关注java教程。悦橙教程  java问答|  每日更新
页面导航 : > > 文章正文

关于Java应用相关不同产品的架构(1)(2)

来源: javaer 分享于  点击 14585 次 点评:11

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步甚至更多。




相关栏目:

用户点评