认识达内从这里开始

随着互联网的不断发展，越来越多的软件被开发推广上线，珠海达内小编就通过案例分析来了解一下，软件架构开发都需要关注哪些问题。

1、运行态分离

尽管系统项目的启动过程十分的重要，但与按天、月为单位运行的系统运行时间来比，系统的启动过程就不那么重要了。主要是对于启动的过程，我们往往会投入更多的关注，确保启动完成。相比之下，我们更期待程序的运行状态可以稳定地运行。

对于使用Spring框架的后端开发人员来说，Spring已经通过了各种的手段对启动状态进行分离：例如Application上的启动注解、Spring-boot相应的自动装配能力、以及对于Autoware或者Resource的依赖注入等。一方面我们要理解Spring已经很大程度的帮助我们将注意力从启动状态与运行状态分离了，另一方面我们更不应该破坏这种分离状态。

2、统一抽象

我们在实际开发过程中总会有如下需求：对所有指定前缀名称的Service都开启事务、对所有接口调用都打印参数日志。如今，我们很容易就能想到可以使用AOP来实现这样的需求，但是我们经常忽略这个做法背后的思想：对模块的统一抽象。

由于我们对模块之间进行了分层，我们可以以的三层模型来举例。假设当我们在编写Controller层的，当我们希望对我们的下游调用的所有入口进行入参日志的输出，那我们可以有三种处理方式：

在Controller调用前打印

在Service进入后打印

在出Controller与进入Service之间

但不论我们是在Controller中还是在Service中执行，我们都需要在所有实际出发代码的时候增加新的逻辑。而如果我们选择在Controller与Service之间进行功能的增加，我们就可以将这部分逻辑剥离到两层业务逻辑之外，放到编程框架层面的，而这种方法就需要我们对模块进行统一抽象。

前面说了一种AOP的实现方式，其中我们一般是通过注解或者包路径来描述处理对象，除AOP外常用的还有Java代理类的方式(尽管Spring本身就包含大量代理)。

统一抽象的主要目的在于，将所有一层级的模块抽象成一个概念，就可以统一为其增加功能，从而使得下层逻辑不用特别的对该功能进行关心。事实上，对于可以进行统一抽象的模块功能，它极大概率是不与下层逻辑耦合的，所以即便我们没有对其进行统一的抽象，也应将它们分离出来然后单独的维护。

所以，Aop和代理类只是为了达到统一抽象目的一种实现手段。

3、延迟决策

显然，在系统的构建时，所有的功能都应该是经过了设计之后再实施的。但我们很难再一开始就将所有的决策确认完毕。一般来说，如果我们需要进行决策时需要收集到足够的信息，例如：根据具体的TPS值确认是否要增加数据缓存。但如果当前的信息、预备知识不足以支撑我们对问题进行的决策，我们可以延迟我们决策的时间。

延迟决策的优点在于，你可以在你获得了足够的信息后，再进行正确性更高的、更有效的决策，这是你可能有更多的用户反馈、或者更完整的测试数据用来对你的决策进行支撑。

在具体的决策前，我们可以先根据“业界方案”来进行设置，因为这样的好处是可能存在更多的相关经验人员，同时出现问题可能有更多的解决方案。

而为了系统能支持延迟决策，我们需要系统进行模块化设计，并已经基于切面地进行了统一抽象设计。这样才能让我们拥有足够的知识后，具备进行决策的时机后，可以快速地进行业务调整。

【免责声明】本文部分系转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与联系我们，我们会予以更改或删除相关文章，以保证您的权益！