谈谈架构非功能性

架构的功能性要求有：吞吐量、稳定性、业务性等。这些都是架构的基本要求。

那么架构的非功能性要求有哪些呢？

从实践中发现，好的架构有如下这些常见的非功能性要求

1、优雅的代码

一、不产生NULL对象，不须要做NULL对象判断。

代码中最多见的代码多是在使用对象前要先对对象做非NULL的判断，特别是业务代码中。这样的代码重复性高且意义不大，不单形成性能开销，也严重影响了代码的美感。

这就像一遍文章里出现了不少“他说：”，“你说：”等一些重复性高的，没多大涵义的词同样。

但若是不做这些判断又会容易引发空指针异常。

最佳实践是，被调用方不要返回任何NULL对象。这样使用方就能不做判断的直接使用对象，或只需一个简单的询问就能知道返回结果是否是能正常使用，从而决定是否要跳出执行。

因此除了不返回NULL对象，最好仍是创建统一的返回结果，将结果和一些处理封装起来，例如：

Result<T>{

　　private Result<T>();//私有构造函数，外面不能用new来建立

　　static newSuccess(data);//成功结果传入数据

       static newError();//异常结果不需数据

　　T data;//数据

　　isSuccess();//简单询问数据是否正常

　　getData();//能够做一些NULL的处理

}

二、减小重复代码。

2、易扩展

一、不直接使用new来建立对象，可用spring注入或用工厂方法、静态的生成器来建立对象

二、面向接口或超类编程

3、易修改

一、容易发生修改的地方都提供操做类或配置表，例如系统名称、数据规则、权限规则等。

二、集中管理

例如数据源的管理，对于分布式系统来讲业务服务器很容易就能够作到无状态 ，由于让全部的服务器都能提供同同样的计算这并不会形成多大的开销和浪费。但存储却很难作到无状态的，若是全部机器都存储同一份数据，那这个开销将会很庞大，并且数据的一致性也很难去保证。

常见的存储管理策略有：

1）若是存储的是轻量的数据，能够采用集中存储管理，例如会话信息，缓存系统。

2）若是是较重的业务数据，就只有根据业务类型对应到相关的数据源。但获取数据源的方式需集中起来管理，业务方获取数据源时都通过可管理的方式来注入，而不是业务方本身去构建。

4、易维护

一、日志管理，维护通常是经过日志来查错，定位问题。

开发时可能经过打印堆栈信息来快速定位问题，但线上是不可能打印堆栈信息的，只能经过对日志的查找，关键字定位等方式来发现问题。

因此构建好日志的关键字索引，内容格式，输出方式，拦截位置就很重要。

最佳实践有将日志分类输出与管理，只要有如下三类：

1）、方法入参与输出监控，可经过AOP来做切面处理

2）、堆栈日志，某些日志框架提供堆栈日志输出，例如logback

3）、逻辑日志，这部分是最重要也是最容易混乱的，它至关因而在程序中埋下监测点，经过这些点的数据几乎能还原程序的调用过程。但若是没有统一好日志的内容格式，记录方式 ，操做类等便会很容易引发混乱，且较难修改，当日志规则发生改变的时候。