互联网应用架构标准模型

随着互联网的普及,越来越多的企业也开始往互联网化转型,相应的企业也要为此构建配套的互联网应用。软件架构方面,很多企业一味求快,而放弃很多需要坚持的原则,这会带来很多风险。接下给大家分享一些我个人的想法,希望能帮助大家少走弯路。

前台应用与后台应用分离原则

前台应用:是指直接供互联网用户使用的应用。

后台应用:是指供企业内部运营人员使用的应用,也有人叫内部管理系统,比如:CMS。

相信很多团队,为了快速完成任务,减少编码工作量,都会把前台应用与后台应用的很多功能是共用代码的,后期重构时,可能就需要完非常多的时间来梳理这些代码。

接下来我们分析一下前台应用与后台应用都有哪些不同之处:

功能需求上的不同:前台应用与后台应用面向的用户不同,其功能需求肯定是不同的,即使有相同的功能需求,也只是其中的一小部分;

非功能需求的不同

从上面的分析我们可以看出前台应用与后台应用差异之处非常之多,所以对它们进行分离是非常必要的,只有分离之后,才能细粒度去控制它们。

前台应用与后台应用耦合,也会带一些稳定性的风险。之前见过一个系统的前台应用与后台应用共用的(代码以及部署都是共用的),后台应用中有个数据导出功能会占用非常多的内存,经常因为这功能把内存占满,造成系统不可用。

前台应用与后台应用耦合,带来的问题是非常多的,在这里也没办法一一列举,比如:增加后期代码梳理的难度;因为前台应用和后台应用在非功能需求上有很多差异,而这些差异不少是由运维来处理的。

分层设计原则

分层设计思想对于程序员来说并不陌生,明确每个层的职责,可以提升代码的条理性。比如数据层,只负责对数据的操作,用于屏蔽对数据操作的复杂性。在应用架构上我们同样可以使用分层的思想来屏蔽复杂性,实现解耦和复用。

首先看下面架构图:

架构原则说明:

1、前台应用与后台应用分离:这里的分离不仅要求部署是分离的,业务相关的代码也是完全分离。

2、前端与后端进行分离:为了满足不同用户的需求,前端可能会有PC Web页面,H5 页面,Android APP, IOS APP,以及各种小程序等。接口层可以依赖多个服务,可以组合多个服务的数据返回给前端应用,使用接口层来屏蔽调用服务的复杂性并实现复用。

3、上图中的服务层,是最简单的情况。服务负责与数据库交互,并实现业务逻辑。在构建服务时,需要坚持以下原则:

一个服务只依赖一个数据库(同一数据库也只被一个前台服务和一个后台服务依赖)。

每个服务只依赖单个缓存服务,使得依赖更简单,也避免相互之间的冲突。

初期由于业务量没有那么大,通常会把数据集中放到一个数据库中,但随着业务的增涨,到不同的阶段要做数据库的垂直及水平拆分。因为调用数据库的地方比较少,所以重构时,相对也容易些。

如果当前数据库被垂直拆分成n个,那么可以把当前服务的代码拷贝出来,也分成n分,还是保持一个服务只依赖一个数据库的原则。而原服务可以改造成调用这个新的n个服务,形成树状结构的依赖关系。

微服务是否能落地的前提条件就是使用领域模型,理清业务边界,对系统进行拆分。使用上述原则,相信也能降低微服务落地的难度。

4、前台应用的服务与后台应用的服务通过MQ进行解耦

架构的最主要的目标是解藕,然后才是复用。“高内聚,低耦合”,这句话必须烙在每个软件从业者的心中。然而现实中很多团队,以时间紧,没有足够资源等原因,把代码的复用放到了第一位,而把解藕抛之脑后了。

随着业务的增涨,系统的架构会变得越来越复杂,前面提到的那些原则如果能坚持执行,相信一定能降低后期维护成本。

互联网应用架构需要遵守的原则还有很多,而前面提到的几个只是一些大原则,也是必须遵守的原则,也是比较容易落地的几个原则。

本文来自企鹅号 - 京西媒体

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏pangguoming

MySQL集群的几种方案

组建MySQL集群的几种方案 LVS+Keepalived+MySQL(有脑裂问题?但似乎很多人推荐这个) DRBD+Heartbeat+MySQL(有一台机器...

3125
来自专栏大数据和云计算技术

初识微服务

微服务架构越来越火,有必要学习一下。 软件开发过程中碰到什么问题 一个简单的应用会随着时间推移逐渐变大。在每次的sprint中,开发团队都会面对新“故事”,然后...

2615
来自专栏即时通讯技术

快速理解高性能HTTP服务端的负载均衡技术原理

在一个典型的高并发、大用户量的Web互联网系统的架构设计中,对HTTP集群的负载均衡设计是作为高性能系统优化环节中必不可少的方案。HTTP负载均衡的本质上是将W...

631
来自专栏SAP最佳业务实践

SAP最佳业务实践:MM–管道资源物料的采购(903)-1业务概览

用途 在化工行业,制造流程需要的一些原材料通过供应商管道资源提供,这是常见情况。 该业务情景显示管道资源物料采购的处理的特性 优点 使用集成数据库:例如...

3214
来自专栏Java技术栈

消息中间件ActiveMQ、RabbitMQ、RocketMQ、ZeroMQ、Kafka如何选型?

最近要为公司的消息队列中间件进行选型,市面上相关的开源技术又非常多,如ActiveMQ、RabbitMQ、ZeroMQ、Kafka,还有阿里巴巴的RocketM...

55112
来自专栏EAWorld

微服务模式系列之二:微服务架构

译者评论: 微服务架构大家已经耳熟能详,但是我认为这篇文章最有价值的是这段: 但这类解决方案中也存在着以下弊端: 开发者必须应对创建分布式系统所产生的额外的复杂...

3175
来自专栏织云平台团队的专栏

自研路由如何解决运维六大挑战?

腾讯内部一些基础服务比如统一鉴权登录、社交关系链、支付被内部很多其他业务调用,调用方往往横跨几个事业群,几十个部门,有数百个模块,上万台设备。

41112
来自专栏H2Cloud

H2Engine服务器引擎介绍

H2Engine服务器引擎介绍 简介   H2Engine服务器引擎架构是轻量级的,与其说是引擎,个人觉得称之为平台更为合适。因为它封装的功能非常精简,但是提供...

4218
来自专栏MessageQueue

2017上海QCon之旅总结(中)

本来这个公众号的交流消息中间件相关的技术的。上周去上海参加了QCon,第一次参加这样的技术会议,感受挺多的,所以整理一下自己的一些想法接公众号和大家交流一下。

1123
来自专栏一名合格java开发的自我修养

交易系统使用storm,在消息高可靠情况下,如何避免消息重复

概要:在使用storm分布式计算框架进行数据处理时,如何保证进入storm的消息的一定会被处理,且不会被重复处理。这个时候仅仅开启storm的ack机制并不能解...

763

扫码关注云+社区