1.3.1 非功能性需求的调整

如前文所述，非功能性需求是指应用的质量属性，如稳定性、可扩展性等，即要实现这些属性所开发的非业务逻辑，也叫控制逻辑。

传统微服务应用想要获得这些属性，通常要以类库的方式引入这些属性。当然，也可以用比较直接和原始的做法，将业务逻辑和控制逻辑写在一起。例如在访问上游服务时，我们希望引入一个重试的功能（控制逻辑）以提高应用的可用性（质量属性）。那么可以在调用上游服务的业务代码外写一个循环语句，有正常返回值就跳出循环，异常返回时就继续尝试，直到完成设定的循环次数。

当服务越来越多时，这样的控制逻辑也越来越多，我们肯定不希望重复去做这件事，因此将它抽取出来变成类库是比较合理的做法。比如在使用Spring框架开发Java应用时，只需要在想要重试的方法上加一个＠Retryable标注即可实现，示例如下。

通过类库实现非功能性需求是一大进步，但依然有一些局限性，比如可以肯定的是，这是与语言绑定的，这对于一个异构的微服务应用而言并不合适。另外，虽然分离了控制逻辑和业务逻辑，但本质上它们依然是耦合的，应用需要引入类库并将它们打包在一起部署。

云原生的方式会在解耦的基础上更进一步，做到使业务逻辑无感知和透明。我们以服务网格为例，要实现上面的重试功能，应用本身不需要做任何代码层面的修改，只需在服务网格的路由配置中增加与重试相关的配置即可，服务代理会根据这个配置在请求失败的时候自动进行重试。这种方式不需要绑定开发语言，不需要引入任何依赖类库，也不需要为应用本身增加配置，是完全透明的。下面的代码展示了如何以声明式配置的方式实现重试功能，应用程序不需要做任何修改。

这就是云原生技术的能力，其理念是将非功能性需求下沉到基础设施，让应用只关注业务实现。因此，在云原生的加持下，微服务应用在这方面的需求和实现是需要调整的，开发团队要认识到这样的转变，在技术选型时充分考虑，尽量以云原生方式去实现，降低开发成本。当然，原本在这方面的实现和维护成本可能会转移一部分到基础设施层面上，这也符合软件开发中的取舍原则，需要在设计时考虑到。