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

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

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

一、优雅的代码

1、不产生NULL对象，不需要作NULL对象判断。

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

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

但如果不作这些判断又会容易引起空指针异常。

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

所以除了不返回NULL对象，最好还是建立统一的返回结果，将结果和一些处理封装起来，例如：

Result<T>{

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

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

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

　　T data;//数据

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

　　getData();//可以作一些NULL的处理

}

2、减少重复代码。

二、易扩展

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

2、面向接口或超类编程

三、易修改

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

2、集中管理

例如数据源的管理，对于分布式系统来说业务服务器很容易就可以做到无状态 ，因为让所有的服务器都能提供同一样的计算这并不会造成多大的开销和浪费。但存储却很难做到无状态的，如果所有机器都存储同一份数据，那这个开销将会很庞大，而且数据的一致性也很难去保证。

常见的存储管理策略有：

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

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

四、易维护

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

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

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

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

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

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

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