这是【一文一点】的第5篇文章，不拘泥于篇幅字数，用一篇文章说清一个知识点。
1、
当谈到软件架构的时候你不能只想到spirng、springmvc、mysql，你也真不应该想到它们，虽然它们是你落地的载体。
至少你不能先想到它们，软件架构不依赖这些框架或者具体的数据库，这些东西统统需要延后，延后。
正像《架构整洁之道》序言中余晟老师讲到的，架构设计是一门复杂的学问，要综合考虑编码、质量、部署、运维、排障、升级等各种因素，并作出权衡。
所以，架构设计就不是指首先想到的那些框架，那么的简单了。
软件架构应该要独立于框架、独立于UI、独立于数据库、独立于任何外部库。
2、
如果是想要描述架构的话，可以用4+1视图，这里的4是指逻辑视图、实现视图、进程视图、部署视图，这里的1是指场景。
图来自网络
刚才我们也提到了软件架构设计是一件比较复杂的事情，包含了很多种因素，同时呢，它不仅要满足用户的功能需求，某个场景的用户需求流程是怎样的，对应到设计中应该是什么样的模式和设计流程。
还要满足系统的可靠性、可用性、安全性、性能、容量等架构的质量属性，这往往会涉及到基础平台、框架应用、甚至还有硬件。
这就需要多方合作才能最终落地实现架构的设计目标，这中间会有软件研发人员、测试人员、运维人员、产品人员、业务运营人员的参与，也就是说我们设计的软件架构包含了他们所有人员的参与。
有这么多角色参与的工程，如果有一个框架或模式能够把它们串起来，是再好不过的了，而4+1视图就可以起到这样的作用。
4+1视图可以让架构师自顶向下的去分解架构设计，还可以形成合理的抽象，从而将我们刚才说的这么多角色”拉在一起“。
因为要使得架构落地必须有他们的参与和协同工作。
3、
另外，在做架构设计的时候，我们也不能仅仅高谈阔论，总聊"高大上"的理论，虽然那些理论可能是有用的。
一个被架构设计指导的软件项目总归是要通过一行行的代码实现的，"脱离了一行行的代码，脱离了具体的细节设计，架构设计就无从谈起"。
以至于在《架构整洁之道》一书中，提到，软件质量，不但依赖于架构及项目管理，而且与代码质量紧密相关，甚至还有说到，“对于代码，应无情地做重构”。
所以你在架构设计的时候还要引入一些模式或者原则性的编码指导，比如SOLID原则。
除此之外，我们还要考虑架构的可扩展性，毕竟一个落地的架构，不仅要满足用户、系统的一时的需求，还要满足后面他们持续的需求。
如果你要设计一个弹性、"皮实"的架构，至少你要考虑这三方面的事情，避免过度设计，向内依赖设计、面向失败设计。
说了以上这么多，到底什么是软件架构设计呢，正像《架构整洁之道》这本书描述的。
所谓软件架构，就是你希望项目在一开始就能做对，但是却不一定能够做的对的决策的集合。
为什么这么说呢，架构设计，架构设计，虽然有【设计】俩字，但架构真不是"设计"出来的，而是演进出来的。
4、
优秀的软件架构也不是一成不变的，需要经过不断的打磨，迭代改进。
在《演进式架构》这本书里面，在如何构建可演进式的架构方面给了我们指导性建议，从三方面考虑：适应度函数、增量变化、适当耦合。
我们首先来看什么是适应度函数。
按照这本书中介绍的，适应度函数是进化计算中的一个概念，进化计算有多种机制，通过对每一代软件进行小的变更使方案逐渐成形。
另外书中也给了一个明确的定义：架构的适应度函数为某些【架构特征】提供了客观的完整性评估。
那什么是架构特征呢。
系统被提的要求可能不太相同，比如有的系统要求高吞吐量和低延迟，有的系统要求安全性要高，有的系统要求自我故障恢复的能力要强，这些呢，都是架构的特征。
举一个比较容易理解的适应度函数的例子，就是功能测试，一个测试用例可以看成是某一个单一功能的适应度函数，增量开发应该在测试成功的约束下进行变更。
而适应度函数这个概念，则就很好的体现了这些架构特征的保护，有关适应度函数更多的理解大家可以去详细阅读这本书。
再来看增量变化。
架构应该支持增量开发和增量部署。
增量开发也就是，我编写了一个功能的代码，可以立马提交，并可以被进行功能测试，性能测试。
增量部署的意思可以理解为AB发布，比如书中举了github的例子，每次功能重构上线，github都先随机挑选1%的用户进行旧功能与新功能同步执行，持续4天输出结果相同时，将用新代码替换掉旧代码。
这是一个非常值得借鉴的思路。
最后，来看适当耦合。
我们反对强耦合，但世界上却没有不耦合的系统，你试想，如果你的系统之间没有一点耦合，企业系统还怎么对外统一提供服务呢。
因此，我们才一直强调的是弱耦合，过渡耦合使得架构难以演进，但我们要保持适当耦合。
关于适应度函数、增量变化、适当耦合的内容，同时也参考了 知乎上面的这篇文章https://zhuanlan.zhihu.com/p/133517172
5、
软件设计如果又从宏观视角来看的话，包括需求、研发、运维，那么其中维护的成本又是最高的。
另外呢，还有一条真理性的警句：世上没有不出问题的系统。
那么致力于高可用上的成本也是不小的隐性成本，甚至有的公司专门对此有对称职位，比如google就有SRE工程师，全称是 Site Reliability Engineer 网站可靠性工程师。
好了，我又写完一个知识点，希望对你有一点帮助。