浅谈架构设计（中）

嘿嘿，我是来这里学习的。

大神，多发点这样的帖子啊，急需

文字很多，但绝对的干货啊！！！

2.2 可扩展性的陷阱：过设计

如果为了一些不必要的场景而做了可扩展性设计，浪费了工作投入，还可能会增加未来学习、沟通或者管理上的难度，那么就属于“过设计”。

比如上文中提到，过度的抽象不可取。我遇到的一个实例：在关系型Oracle数据库中，为了增强表结构的扩展性，有人建议将表结构设计为Key-Value的形式，这种设计的确可以提高扩展性，但是随之而来的破坏了关系型数据库的基本结构，带来的是查询上的不便以及性能等一系列问题。

如之前章节所述，架构师做架构设计的初衷是为了付出一些架构成本，来保证系统的可扩展性，从而达到总体上成本最优的目的。评估一个架构设计是否合理、或者是否值得做，需要对比这个架构设计所付出的成本与未来带来的收益孰轻孰重。但架构成本既有显性的（比如可以直接体现为代码行的开发工作）、也有隐性的（比如学习、沟通、或管理上的）；显性的成本容易衡量，但隐性成本就很难量化，而且往往带有个人的主观意见。对于可扩展性带来的“未来的收益”，就更加难以确定：首先这个收益实际上是一个对未来的估计和判断，是否一定会发生，本来就带有个人的主观判断，第二，即使发生了，收益有多大，经常也很难量化，这些收益也同样有显性的（比如开发工作量下降）和隐性的（比如管理成本降低、沟通效率提升等）。因此，要对比“架构设计所付出的成本与未来带来的收益孰轻孰重”，实际上是很难的，这也是平时工作中最容易有争论的地方。

架构师在平常工作中，经常就“某某设计是否合理”的问题与设计师、开发人员进行讨论和PK，架构师通常要坚持自己的观点去说服别人，在有些情况下也容易由于“过于固执己见”而陷入“过设计”的误区。怎么能避免呢？我也没什么好办法，唯一的建议就是架构师需要仔细倾听设计师和开发人员的意见，兼听则明，固执己见则暗，在争论久持不下的时候也恰恰意味着架构的成本和其带来的收益的性价比不高，或者即使不做这个设计所造成的问题也不严重、是可接受的，所以在架构上妥协一下也未尝不可。这是灰度的艺术。（架构设计既要能在总体上坚持原则，又要能在适当时候灰度妥协，这的确很难）

2.1 架构的成本

“架构成本”的最简单例子就是接口封装：对于首次开发来讲，接口封装的实现一般都比直接实现这个功能要多投入一些工作量，但是接口封装的好处是为后续的功能扩展带来好处（可将一些新增的功能需求的影响封装在模块内部）、降低了工作量，长远来看，接口封装的一次性投入带来后续功能扩展的工作量降低，所以这个投入是划算的。反例：如果两个模块联系很紧密，即使将两个模块之间的接口进行了封装，但是每次新增功能都需要修改这个封装接口，那么这个封装接口的工作量就不划算，本质上是反映出来这个架构设计不合理，要么是这两个模块之间的功能定位没切分清楚，要么是这两个模块应该合并为一模块。

复杂一点的例子：一个系统有两个模块A和B，现在要新增一个功能，A和B都可实现，如果放在A模块实现、比较符合A模块的功能定位、但工作量较大，如果放在B模块实现，不符合模块定位但工作量小，这时选择放在A还是选择放在B？架构上应该选择A，虽然A工作量大，但是符合A的定位，后续更好扩展和维护，总体来看工作量更小。当然还一种情况时，放在A的工作量太大以至于难以接受，那就得考虑架构变更，是否考虑将该新增功能放在B模块实现、并修改A、B模块的定位，以实现自洽。

更复杂的例子是抽象。抽象也是增强扩展性的一种手段（下面章节会详细说明），但抽象的设计在第一次实现时的工作量肯定是相对更大一点，它的目标是便于后续的扩展、使之在后续新增功能时的开发工作量较小。但抽象带来的负面作用是复杂度增加，意味着学习成本和信息传递的成本增加（也可以叫做开发难度的增加），这些成本是隐性的、不直接体现为开发代码的工作量，但的的确确占用着开发人员的工作时间，因此也应当属于架构成本。抽象要适度，过度的抽象也是不可取的。

综上，架构需要在系统的整个生命周期中产生作用，架构的扩展性应该保证：在不断开发新功能的过程中，通过付出一定的架构成本，仍能使整个系统能够达成所期望的质量属性目标，并使总体上的开发成本和管理成本最低。

2、架构的可扩展性设计

ZWS在《架构与模块设计》中指出：软件架构设计的焦点在于可扩展性，为了达到此目的，甚至愿意付出性能的些微下降来达到总体性能的不变，因为通常硬件性能一直在提升。

实际上，架构设计在考虑扩展性时，除了性能些微降低之外，还愿意额外进行一些设计和些许工作量，来保证整个架构的稳定和模块边界的清晰，从而使该系统在后续还能够持续的简单的添加新功能需求，使系统在生命周期内的总体上的工作量最低（这里的工作量不仅仅是包含开发工作量，还包含信息传递和沟通等隐性的管理成本）。为架构设计的长期可扩展性所付出的额外代价，只要这个代价与带来的收益相比具有好的性价比，有助于降低总体上的工作量，那么这个代价就是值得的，我将这个代价称为“架构的成本”。

1.4 小结

综上，架构师需要在系统的整个生命周期内来综合考虑、权衡方案，以保证系统的架构稳定和高质量、有效的交付。架构师要对产品的生命周期内的架构设计负总责：在产品第一个版本开发时，架构设计很重要，在后续维护过程中的架构的看护和演进工作也很重要。这就要求架构师不但不能短视，还必须要识别短视的设计、并与其斗争。

1.3 在时间维度上，好的架构要能够在系统的整个生命周期内都能达到以上两个目标

一般来说，软件系统的成本大约有80%发生在初次部署之后的维护阶段，发生的开发工作大部分在这个阶段，也就是说，大部分设计和开发人员的大部分工作都是在已有系统或代码的基础上工作而不是全新的开发。这个道理应该算是软件工程领域中的常识，但随着系统的不断演进和新需求的不断开发，系统可能会变得越来越复杂、越来越笨重，新需求的开发和现有功能的维护工作量逐渐攀升，进而占用很多开发人力。

在《网络能源OSS开发部-架构设计原则》中给出了“设计腐烂”的现象和如下4种征兆：由不明显并不被管理者关注，最后演变到系统最简单的修改都需要付出很大代价，最后管理者感知深陷开发泥沼，整天陷入问题单海洋中。

l 僵化：软件变得越来越难于改变，甚至简单的改变也很困难。每次改变都导致后续一系列依赖模块的改变。从开始简单的花两天对一个模块的修改到数周一个模块一个模块持续的修改，工程师要在应用程序中跟踪改变的线索。当管理者的这种害怕变得非常厉害，他们会拒绝允许对软件进行修改，正式的僵化就开始了。设计的不足会引起管理策略的不利。

l 脆弱：与僵化紧密联系的就是脆弱。脆弱就是这样一种趋势：每次修改后，软件的很多地方被破坏。这种破坏通常发生在与被修改的地方在概念上没有关系的地方。这种现象往往体现在层出不穷的问题单，往往让管理者对系统的稳定性感觉茫然，脆弱往往打击项目经理对系统质量的信心。

l 硬化：硬化就是无法重用已有的组件。当某个工程师发现他要的模块与另一个工程师写的模块类似时，这种情况通常就发生了。而且，当模块有太多依赖的包袱时，这种情况也会发生。往往设计者或开发者希望重新写一块代码“另起炉灶”的心理使得系统更加庞大，最终没有谁愿意去重构。

l 粘性：粘性有两种形式：设计的粘性和环境的粘性。当正式的方案和零散的方案混在一起，设计者对归并到正式方案感觉非常难以入手时，继续另起零散方案的粘性设计就出现了。环境粘性是，当开发者面对修改任意一点就引发大量编译时，开发者不得不面对小的修改就耗用大量时间在编译和代码提交上时，这就是环境的粘性。

防止上述情形发生的方法，是需要在架构上通过某种原则控制模块间的依赖、不允许任其不断衍生。

综上，架构设计不能短视。架构设计“能够给出一个框架能够更好的实现所有需求”，这里的“所有”，不仅包含当前系统可见的需求，也要包含未来的可能发生的需求。换句话说，架构设计在完成功能目标和质量属性的前提下，不能仅仅考虑当前的成本最低，而是要追求在系统在整个生命周期内的成本最低。

这个目标的达成，一方面要依靠架构师在设计之初就要考虑通过一些架构原则来控制模块间的依赖，另一方面，还需要架构师在后续的系统演进过程中能够看护整个架构。对于后者，还有两种情况：对于需求或者设计不合理、违背了架构原则的情况，架构师要敢于坚持原则，引导需求、指导正确的设计；对于需求本身合理、但是架构需演进的场景，架构师要善于了解需求和对需求进行归类，对架构原则进行演进，以便适应新的场景需要。在看护架构的过程中，架构师既要能坚持原则，又要避免僵化执行。