2.6 总结

综上所述，软件架构工作看似简单，其实不然。系统化思考有助于理清软件架构流程及从客户价值出发，识别用户、设定SLA可以帮助软件架构设计人员和研发人员避免在技术纷繁复杂的跋涉中迷失而陷入“自嗨”。架构是演进而来的，架构包含了一系列的决策和若干组成，进行架构设计时应该从全局视角看问题。

有人说，读完本章还是不知道该如何做。那就再帮帮你：

●对于新项目，请利益相关者进行分析，了解大家的需求；对于老平台，检查利益相关者的需要，规划后续发展方向。

●根据用户、商户的SLA（接入效率、接入成本、用户体验、稳定性、应急处理能力等）度量产品，面向服务对象做规划和设计。

●适当的时候考虑链路级业务监控视图。

●在系统链路调用中加上traceId这样的标识。

●考虑平台沉淀能力时，要考虑业务形态的扩展，确定投入产出比再进行扩展。

●在不同阶段采用不同的架构，说不定在试水期这个阶段选择烟囱型架构是最合适的，因为（业务上）短期的价值是突出产品核心功能，并不求全，先度过生存期是第一要务。

●非功能要素不是加分项，却可能是主体价值的体现。比如商户需要一个批量导入接口，你提供了单笔处理接口，这是严重的信息不对称导致的，批量导入接口看起来是为了提高处理性能，但是它其实也提高了业务处理的便利性，这也是功能特性的一部分。

●非功能要素依据重要程度也可能需要融入日常研发中。比如微软的同仁分享的Office 的故事，Office 产品需要不断校验安装包大小，因为功能增加而变成“巨无霸”可能会影响性能，所以就需要依据重要程度将这些非功能要素融入日常研发中。