软件架构设计

       软件架构指的是软件系统的基本结构。咋一看软件架构的定义，高度抽象使得我们对其的认识云里雾里。无法认清事物的本质，就没有办法做好这件事，为此必须给软件架构一个落地的定义。在这里借用建筑里的架构来具象化，建筑结构是指在房屋建筑中，由各种构件（屋架、梁、板、柱等）组成的能够承受各种作用的体系。软件表面上看是一堆堆有顺序的逻辑代码（一维空间），但是计算机软件是按照人类指定规则计算和处理各种业务信息的机器逻辑序列，多项业务+业务处理流顺序+多种接入交互（人机交互、软件相互集成）使得软件具备了与建筑一样的三维立体空间，与建筑架构上面支撑各种用途的房间（卫生间、会议室、休息室、办公室、展览室）一样，软件架构之上就是各种业务功能，这些业务功能会随着环境变化迭代，架构的存在就是使得变化改造成本低、改造快速。软件架构应对已有功能和未知功能变化挑战，理想情况下，软件架构里面的各种构件自由且无缝装配、裁剪业务功能达到新业务需求。总的来说，软件架构就是除了业务功能以外的软件代码模块（将零散、分散的代码放在一起变成组件）集合，常见的架构构件有日志构件、通讯构件、缓存构件、存储构件、监控构件。

       软件架构为应对变化和复杂性而生。现实世界每一天都在变化，而软件就是将现实问题通过逻辑语言指挥机器有条不紊执行计算，因此软件也会随着现实世界变化而变化。从价值的角度来讲，软件只有不断实现版本迭代、升级才能实现价值最大化，软件第一期充斥着研发、技术验证、市场推广等成本，注定初始盈利和利润不高，只有通过第二期第三期第n期提升市场占有率，才能获得规模化经济的可观利润，典型软件如windows操作系统、各版本oracle数据库等，高频、四面八方的变化将会给已有软件带来翻天覆地的变革，极大地挑战软件开发、测试、运维、管理能力。随着计算机技术突飞猛进、计算机应用领域不断拓宽，计算机已经从占地170平方米、重达30吨、耗电功率约150千瓦的ENIAC计算机发展到今天的大型机、小型机、PC、Pad、手机、计算器等，甚至iot各种设备，应用也从当初的弹道计算发展到今天的电子日历软件、电子游戏、云计算、AlphaGo围棋、天气预报计算、核弹模拟。软件代码规模从当初的打孔卡到今天数以亿行代码库，软件复杂度呈现指数级增长。高频变化和复杂度使得行业不得不寻求解决方法——软件架构，软件架构的本质就是分类归纳，是高内聚低耦合软件设计方法的体现。通过分类归纳，我们可以将复杂问题分而治之，从而也将整个系统的变化拆分更细，让工作能够并发进行，使得软件利益相关人（用户、项目经理、测试工程师、运维工程师等）根据自己的关注点内的问题制定方案。

       软件架构是软件系统的基本结构，这个基本结构由各种类型的组件及其关系构成：它们如何组合、相互调用、通信、同步，以及进行其他交互。不同的基本结构是架构师为了满足不同业务领域、不同干系人特定关注点的产物，一些公共关注点有功能性、可变性、性能、容量、互通互联性、模块化、可构建性、产品化和安全性。架构设计就是将这些关注点进行组织、编排，从而将代码进行划分，划分成一个个组件，各业务功能模块根据需要调用各个组件与不同功能模块、不同业务系统完成业务流处理，最终软件系统就成为了架构（软件基本结构）与功能模块的顺序组合，这样不仅分而治之降低复杂度（粒度为组件和模块），同时可以快速应对变化。所以软件架构设计步骤为：（1）架构设计与业务无关；（2）架构设计适度关联业务。第一步先把功能性这一关注点放下，把业务对可变性、性能、容量、互通互联性、模块化、可构建性、产品化和安全性等关注点的要求进行分析，然后在业界已经沉淀的架构模式（成熟架构经验）寻找满足自己关注点的架构，一般来说，现代架构不会是架构模式里的单一架构实现，而是几种架构的融合，取多种架构的长处。国外一些架构模式参考资料，有兴趣的读者下载Software architecture patterns PDF参详。第二步在设计好的架构雏形上引入功能性关注点进行针对性的优化与完善，从而制定特定业务领域的软件架构解决方案。软件架构就是为了支撑业务功能而存在的，业务功能组件间的关系决定了架构雏形中组件的具体使用方式，例如通讯组件是本地调用还是采用RPC方式、硬编码还是无侵入实现方式、缓存组件存储设计等。除此之外，把功能性关注点放上去，可以验证已设计架构雏形的完备性，有无疏漏。通常来说软件架构关联业务存在一个哲学问题——度，这个度类似中庸思想一样难以把握，软件架构关联业务程度低，基本组件复用性高，但业务功能组件间关系处理代码稍复杂；软件架构关联业务程度高，基本组件复用性低，但业务功能组件间关系处理代码简单，专注于业务处理，因此软件架构关联业务程度没有统一、唯一的标准，一般是以经验来判断。不过解决该问题的终极方法就是让软件架构进化，软件架构只能解决涉特定业务、特定时期的关注点，满足预期目标已经是一个成功的、好的软件架构设计。软件架构通常的规律是随着业务认识深入，关联程度逐步加强。

       软件架构设计出来之后，要做的事情就就是让架构落地，主要工作包括技术选型、组件协调/处理机制具体实现，其中最重要的就是要架构验证。一个好的架构让程序员专注于业务功能代码实现，较少涉及技术类问题处理，这样的架构实际上扮演了大部分关键路径的角色，在项目后期发现架构不合适，要替换，相当于推倒重来，业务功能组件的代码改造也十分具有挑战性，因此在架构具体实现前，必须要做一个最小模型进行验证。

       软件架构是高度抽象的产物，而软件又不像建筑物一样立体可见，让人感觉云里雾里。鉴于作者水平有限，无法把软件架构设计逻辑如楚河汉界般分明、有条理表达出来，为力求清楚表达作者观点和思路，后续会抽时间推出架构相关博客主题文章，暂定《常见框架架构设计分析》和《分布式微核架构设计》，其中分布式微核架构设计为作者具体产品应用的架构实践，已得到市场验证；常见框架架构设计分析涵盖spring mvc、spring cloud微服务框架。

参考文献:

[1]《架构之美》

[2]《银行信息系统架构》