软件架构设计的底层逻辑

       从上世纪80年代晚期开始，计算机科学界为了应对大规模系统设计所带来的复杂度，逐渐开始了软件架构的研究工作。如今，为了解决不同的问题，各种软件框架层出不穷。每位软件架构设计人员都在自己的认知及技术水平范围内贡献着自己的力量，为软件事业添砖加瓦。
       任何事情都应该围绕一个底层逻辑展开，否则就会显得毫无方向，结果自然也不会太好。那么软件架构设计的底层逻辑应该是什么呢？不同的设计者可能有不同的答案：有些人可能以技术的新颖性为底层逻辑，有些人以更好的实现系统功能为底层逻辑，还有些人以炫酷的界面为底层逻辑等。从不同的角度来说，以上底层逻辑方向都没有错，只是不同人的不同看法罢了，不过笔者软件架构设计的底层逻辑却是降低成本。
       是的，以降低研发成本作为底层逻辑来开始我们的软件架构设计。首先声明一下，笔者此处所说的软件指的是企业的商业软件，并不是指无成本限制的软件研究。降本增效本来就是企业重点关注的方面，而软件开发作为企业的一种商业行为，降低成本就天然成了其重要的属性。
       那么，我们在软件架构设计时如何以降低成本为底层逻辑呢？下面我们一一道来。
       首先，理解需求。理解需求是软件架构设计的第一步，不看需求的架构设计都是耍流氓，只有了解了需求才能有针对性设计软件架构。假设用户的需求是A，但是我们用于对需求理解不够深入做成了B，那么系统就有可能需要重新设计，各位可以想象这个成本将有多么沉重。
       其次，需要深刻理解及提高项目组成员的技术水平。首先我们要明确一点的是软件架构不仅仅是为了实现系统功能与性能，也是给项目组的开发人员和测试人员使用的，它很大程度上影响着开发人员和测试人员开发和测试效率。如果说项目组的人员都是搞java开发的却搭建一个PHP的框架，结果可想而知；如果框架不易测试，那测试人员估计要骂娘了。这样造成学习成本和沟通成本将会急剧上升。因此我们在设计软件架构时必须考虑当前人员的技术水平，必要时可以引入低代码和零代码思想（低代码和零代码的引进必须根据当前实际整合，一股脑的引入是没有实际意义的）。当然，我们平时也要加强成员技术水平培训，这样在正式的研发中才能降低我们的研发成本。
       再其次，根据实际需求决定软件框架选型。需求主要包括功能需求和性能需求，而性能需求是软件架构设计考虑的重点。那么我们应如何在此环节降低成本呢？笔者就带着这个问题简单漫聊一下。
1）首先根据需求推导用户体量及其访问频次，比如就一个小工厂的管理系统，用户体量和访问频次是肉眼可见的。这就没有高并发、高可用的需求，使用单体系统足以满足。这时如果使用分布式系统就不是一个明智的选择，会带来硬件成本、研发成本、运维成本的急剧上升。当然如果像淘宝商城那种用户体量如果用单体系统可能就是痴心妄想了，反而带来更多的升级成本。
2）系统的读写频率比。如果一个系统读多写少，可以在带宽、缓存、数据异构等上做更多的成本投入而降低其他的成本；如果一个系统写多读少，可以在数据存储等做更多的成本投入而降低其他的成本。
3）存储设备的选择。这里说的存储设备主要是指数据库或者文件存储系统。这里笔者主要讲讲数据库的选择，现在市面上有各种各样的数据库，有开源的也有闭源的，开源的包括mysql、postgreSQL等，闭源的包括oracle。如果不差钱可以选择oracle数据库，安全、方便、性能高而且可专人维护，但这已不是降低成本的讨论范畴了，不做讨论。从成本的角度来说我们当然选择免费开源的，还能实现数据库本身的二次开发，但是前提是开源数据库是否满足我们的需求，如果需要二次开发，本身的研发实力是否可行，否则就会带来更大的成本，此时也可以选择收费的闭源数据库来降低成本，所以说这二者关系并不是一成不变的。
       最后，及早验证。软件框架设计出来了应该及早验证是否可行，这与我们接口调用的FAST FAIL的思想是一致的。及早发现问题，及时解决，是降低研发成本的可行之道。
       当然，以上只是简单说了几个方面，在实际的操作方面需要将降低成本的底层逻辑贯彻到软件架构设计的方方面面，而且各个方面都不是孤立的，需要从总体考虑，从而得到最优的软件架构方案。