互联网应用架构标准模型

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

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

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

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

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

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

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

非功能需求的不同

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

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

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

分层设计原则

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

首先看下面架构图:

架构原则说明:

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

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

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

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

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

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

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

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

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

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

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

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

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20171211G03S2I00?refer=cp_1026

相关快讯

扫码关注云+社区