互联网应用架构标准模型

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

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

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

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

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

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

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

非功能需求的不同：

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

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

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

分层设计原则

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

首先看下面架构图：

架构原则说明：

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

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

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

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

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

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

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

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

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

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

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

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