架构六大思维养成记

允许我老生常谈，先从什么是架构说起。

 

当谈到软件架构的时候你不能只想到spirng、springmvc、mysql，你也真不应该想到它们，虽然它们是你落地的载体。至少你不能先想到它们，软件架构不依赖这些框架或者具体的数据库，这些东西统统需要延后，延后。

 

正像《架构整洁之道》序言中余晟老师讲到的，架构设计是一门复杂的学问，要综合考虑编码、质量、部署、运维、排障、升级等各种因素，并作出权衡。所以，架构设计就不是指首先想到的那些框架，那么的简单了。

 

软件架构应该要独立于框架、独立于UI、独立于数据库、独立于任何外部库。

 

如果是想要描述架构的话，可以用4+1视图，这里的4是指逻辑视图、实现视图、进程视图、部署视图，这里的1是指场景。

 

图来自网络

 

刚才我们也提到了软件架构设计是一件比较复杂的事情，包含了很多种因素，同时呢，它不仅要满足用户的功能需求，某个场景的用户需求流程是怎样的，对应到设计中应该是什么样的模式和设计流程。

 

还要满足系统的可靠性、可用性、安全性、性能、容量等架构的质量属性，这往往会涉及到基础平台、框架应用、甚至还有硬件。这就需要多方合作才能最终落地实现架构的设计目标，这中间会有软件研发人员、测试人员、运维人员、产品人员、业务运营人员的参与，也就是说我们设计的软件架构包含了他们所有人员的参与。

 

有这么多角色参与的工程，如果有一个框架或模式能够把它们串起来，是再好不过的了，而4+1视图就可以起到这样的作用。4+1视图可以让架构师自顶向下的去分解架构设计，还可以形成合理的抽象，从而将我们刚才说的这么多角色”拉在一起“。

 

因为要使得架构落地必须有他们的参与和协同工作。另外，在做架构设计的时候，我们也不能仅仅高谈阔论，总聊"高大上"的理论，虽然那些理论可能是有用的。一个被架构设计指导的软件项目总归是要通过一行行的代码实现的，"脱离了一行行的代码，脱离了具体的细节设计，架构设计就无从谈起"。

 

以至于在《架构整洁之道》一书中，提到，软件质量，不但依赖于架构及项目管理，而且与代码质量紧密相关，甚至还有说到，“对于代码，应无情地做重构”。所以你在架构设计的时候还要引入一些模式或者原则性的编码指导，比如SOLID原则。

 

除此之外，我们还要考虑架构的可扩展性，毕竟一个落地的架构，不仅要满足用户、系统的一时的需求，还要满足后面他们持续的需求。如果你要设计一个弹性、"皮实"的架构，至少你要考虑这三方面的事情，避免过度设计，向内依赖设计、面向失败设计。说了以上这么多，到底什么是软件架构设计呢，正像《架构整洁之道》这本书描述的。

 

所谓软件架构，就是你希望项目在一开始就能做对，但是却不一定能够做的对的决策的集合。

 

 

接下来我们讲要具备的六大架构思维。

 

1、演进式思维

为什么这么说呢，架构设计，架构设计，虽然有【设计】俩字，但架构真不是"设计"出来的，而是演进出来的。优秀的软件架构也不是一成不变的，需要经过不断的打磨，迭代改进。

 

 

在《演进式架构》这本书里面，在如何构建可演进式的架构方面给了我们指导性建议，从三方面考虑：适应度函数、增量变化、适当耦合。

 

我们首先来看什么是适应度函数。

 

按照这本书中介绍的，适应度函数是进化计算中的一个概念，进化计算有多种机制，通过对每一代软件进行小的变更使方案逐渐成形。另外书中也给了一个明确的定义：架构的适应度函数为某些【架构特征】提供了客观的完整性评估。那什么是架构特征呢。

 

系统被提的要求可能不太相同，比如有的系统要求高吞吐量和低延迟，有的系统要求安全性要高，有的系统要求自我故障恢复的能力要强，这些呢，都是架构的特征。举一个比较容易理解的适应度函数的例子，就是功能测试，一个测试用例可以看成是某一个单一功能的适应度函数，增量开发应该在测试成功的约束下进行变更。

 

而适应度函数这个概念，则就很好的体现了这些架构特征的保护，有关适应度函数更多的理解大家可以去详细阅读这本书。

 

再来看增量变化。

 

架构应该支持增量开发和增量部署。增量开发也就是，我编写了一个功能的代码，可以立马提交，并可以被进行功能测试，性能测试。增量部署的意思可以理解为AB发布，比如书中举了github的例子，每次功能重构上线，github都先随机挑选1%的用户进行旧功能与新功能同步执行，持续4天输出结果相同时，将用新代码替换掉旧代码。

 

这是一个非常值得借鉴的思路。

 

最后，来看适当耦合。

 

我们反对强耦合，但世界上却没有不耦合的系统，你试想，如果你的系统之间没有一点耦合，企业系统还怎么对外统一提供服务呢。因此，我们才一直强调的是弱耦合，过渡耦合使得架构难以演进，但我们要保持适当耦合。关于适应度函数、增量变化、适当耦合的内容，同时也参考了 知乎上面的这篇文章https://zhuanlan.zhihu.com/p/133517172

 

软件设计如果又从宏观视角来看的话，包括需求、研发、运维，那么其中维护的成本又是最高的。另外呢，还有一条真理性的警句：世上没有不出问题的系统。

 

那么致力于高可用上的成本也是不小的隐性成本，甚至有的公司专门对此有对称职位，比如google就有SRE工程师，全称是 Site Reliability Engineer 网站可靠性工程师。

 

 

2、分合思维

讲到分的时候，就不能不提到读写分离，也就是我们说的写主读从，一般这样的场景都是读多写少，那么读多，就需要更多的从，来分摊读的压力。可是，从的数据是从主上面复制过来的，如果从的数量增多，难免给主带来压力，毕竟主还承担了写的请求，这个时候就需要一个额外的从来负责把数据复制到其它的从上面。

 

也就变成了下面这样的主-从-从结构了。

 

 

在回到我们说的主从上面来，主从结构的数据，主要是通过复制，那么，有的同学就会问到了如果复制存在延迟怎么办。的确，下面这位同学在极客时间上面的课程中就问到了这样的问题。

 

其实，我理解这里问问题的同学是想问，读从的时候，数据延迟了，业务上怎么解决。当然作者的答复也没有错，复制延迟是“天生”的本就没有解。一般的主从架构，是一台主，多台从，适合读多写少的业务场景，大量的读操作请求都落在了从服务器上面。那么如果是写写多的业务场景呢，