架构设计实践五部曲（五）：技术架构的战略和战术原则.docxVIP

架构设计实践五部曲（五）：技术架构的战略和战术准绳 战略层的设计准绳就是：合适准绳、简约准绳、演化准绳。 1.1 合适准绳 技术人员有一种很强的技术情怀，就是在做设计的过程中，很期望挑战新的技术、在项目中接受最新的框架、或者本人重造一个比业界的还要牛的轮子。这样才能够显示出本人的优秀，以至于不让本人显的那么平凡。比如，在项目中重新造一个能够处理亿万级数据的新的 xx 流式计算技术，比 flink 还要牛一百倍；有或者在项目中使用最新的 xx 技术，能让系统担当亿级用户的访问。 那么现实是，假如在设计过程中一味追求新技术，往往失败的可能性很高。 没有那么多人，却想干那么多活 现实环境中我们一个业务团队可能就十几个人，项目工期短、上线要求快。在这种情况下，假如还要抽调几个人去争辩、搭建、维护新的技术框架，对于项目势必会形成延期的影响。 没有那么多积累，却想一步登天 很多业界领先的方案，不是一帮优秀的开发加在一起，加班加点就能做出来的。而是经过几年时间的进展才逐渐完善和初具规模。假如我们也想本人做一套类似的技术，不是说不行能。我们需要集合当下的技术实力、技术积累，做出适合本人团队情况的技术评估。 没有最新，只需最合适 全部新的技术刚出来都是打着比旧技术拥有愈加精彩的功能、供应愈加优秀的扩展性。是不是使用新技术，就能处理一切问题了？新技术的出道，势必是处理某一场景下的问题，并不是一味万能良药。只要了解清楚每种技术的产生背景，适用场景，才能出一个对本人项目最优的选择。技术选型没有最新，只要最合适。 总结一下，合适准绳就是适合优于业界领先。 1.2 简约准绳 我们总是期望能将我们的软件设计的精致、宏大，这样才能彰显我们系统的简单度和难度。我们是不是会遇到这样的场景，在做设计方案的时候，假如一个处理方案很简约，而且能很快的满足需求。在评审方案时，就会有人觉得这个方案是不是太简约了，没有什么技术含量，是不是需要再设计的简单一点。 系统是不是肯定要设计的简单？在回答这个问题前，我们先看下软件领域的结构简单性和规律简单性。 结构简单性 结构简单的系统有两个特点：第一，组成的组件数量很多；其次，这些组件之间的关系很简单。如下图： 图 1 结构上的简单性存在的第一个问题是，组件越多，就越有可能其中某个组件消灭毛病，从而导致系统毛病。假设组件的毛病概率是 1%（有 1% 的时间不行用），那么 2 个组件的系统可用性是 99%*99%=98%，5 个组件的系统可用性是 99%*99%*99%*99%*99%=95%，两者相差 3%。说明组件越多，系统稳定性就越差。 结构上的简单性存在的其次个问题是，某个组件改动，会影响关联的组件。比如上图中 C 组件发生改动，会影响 A、B、D，而 A 有会影响 E。这样就会构成一连串的多比诺效应。 规律简单性 意识到结构简单性的问题后，只需削减组件就能让系统结构变简约？这样做还是行不通，缘由在于除了结构的简单性，还有规律的简单性，假如一个组件的规律太简单，通用会带来问题。 我们试想一下，把淘宝的全部功能都在一个组件中实现，可以想象这个系统要有多浩大：几百人维护一个系统、代码分支几十个、需求变更应接不暇、不同分支的回归测试、修改一段代码可能影响整个系统的运转等等。这些场景信任大家都不期望看到的。 总结一下，简约准绳就是大道至简。 1.3 演化准绳 软件架构和建筑架构很多相同的地方，架构这个词也是从建筑领域自创过来的。比如，软件架构描述的是系统的结构、以及各模块之间的关系。而建筑结构描述的是一幢建筑的结构，以及建筑内部各部件如何有机的组成。 但是，软件架构和建筑架构有一个本质上的差异：那就是建筑一旦完成就不会再变，而软件却需要依据业务的进展不断的变化。对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。 假如没无意识到“软件架构需要依据业务进展不断变化”这个本质，在做架构设计的时候很简约陷入一个误区：试图一步到位设计一个软件架构，期望不管业务如何变化，架构都稳如磐石。假如是依据这样的目标是设计，一开头上来就做出一套看似是终极的方案，投入浩大的资源做各种猜测、分析。结果是投入巨大的资源、开发周期漫长，最终跌跌撞撞落地的系统，却发觉已经无法很好的满足现有的业务。 所以技术架构设计需要一个过程： 首先，要满足当前的业务需求进行技术架构设计 其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使架构渐渐完善。 第三，当业务发生变化时，架构要扩展、重构、甚至重写；代码或许会重写，但有价值的阅历、教训、规律、设计却可以在新架构中连续。 总结一下，演化准绳就是演化优于一步到位。 2. 战术层设计准绳 战术层的设计准绳分为 3 部分：高并发准绳、高可用准绳、业务设计准绳。这些准绳是