也谈软件架构

一、什么情况下，涉及到软件架构？

软件规模可大可小，功能可复杂可简单。对于多年前的单一功能软件，大部分还不需要上升到软件架构层面。

随着功能越来越多、各功能之间联系越来越紧密、各个功能的实现难度越来越大，如何把这些功能有机的整合到一起才能更合理、更高效、更长久，就变成了一个复杂的课题，也就由此引出了软件架构的概念。

二、软件架构有哪些原则？

在我看来，总的来说，软件架构的原则主要有以下几个：合适、简单、演进。

怎么理解？

对于同一个场景，不同的设计师设计出来的软件架构会各不一样，甚至差别很大，这是为什么？其实是因为大家对软件架构的衡量标准很难统一导致的。软件架构有绝对的对错吗？好像没有。

对于同一个需求，有的设计师考虑的很长远，可能会设计的面面俱到，很复杂；而别的设计师可能会先设计一个可用的较简单的架构，同时保证可持续演进。

只要能够实现需求，能够满足性能要求，没有大的问题，似乎也很难说某种架构就是有大毛病的。

基于以上的分析，要能满足功能和性能的需求，这是软件架构基本的要求。

除此之外，就是一个权衡的过程了，也就是要综合考虑业务发展诉求、如何较经济的满足功能和性能的需求、首版交付周期和软件架构的完整性如何平衡。

由于软件功能的迭代是一个动态的过程，并且会随着公司战略的调整、市场需求的变化、用户数和数据量的变化等相应变化，常常很难在架构搭建初期就考虑的面面俱到和一蹴而就。

所以，软件架构常常就需要有个“演进”的过程。那么在架构搭建初期，就需要满足基本诉求，保证在可用资源的情况下可以落地，也就是要遵循“合适”原则。

除此之外，软件架构的分层分模块需要足够清晰、可理解性强，方便扩展，方便添加新功能，即需要遵循“简单”原则。

三、怎样从0到1搭建一套软件架构？

首先，对业务得有足够的理解，对业务发展得有规划。

其次，对功能和性能指标进行分解和技术摸底，确定可用的技术或者相关组件。当然，这个过程涉及技术或技术组件的选型，需要进行分析、对比和验证。

再次，要熟悉业界一些常用的软件架构模式，根据自身需要，进行内化。如果没有可参考的业界架构模式，则需要根据架构设计原则，按照分层分模块的方式，逐渐搭出合适的框架。

另外， 要综合考虑软件架构的各方面熟悉，包括高可用、高并发、可扩展、安全性等。当然，这些也有一个权衡的过程，看需要做到什么程度。

同时，要考虑软件未来的维护和演进，有哪些维护手段？怎么能更好的演进？如何保证在演进的过程中，软件框架不被泛化？这些都是做架构的过程中要考虑的。

四、软件架构的维护与演进

软件架构搭建好了之后，是不是就万事大吉，只等收割了？当然不是！

随着架构的扩展、模块的增加、功能的叠加，软件架构可能会越来越复杂。如果处理的不好，甚至最初的架构会被泛化掉。

这就需要在架构输出之后，完善相关的文档，让后续的设计、开发和维护人员熟悉架构，明确如何进行扩展、添加模块和叠加功能。

另外，需要制定好软件架构演进的规则，并严格执行，以保证软件的生命周期足够长。