salesforce 架构设计_架构学习系列：架构设计流程

学习内容来自于《从零开始学架构》。

之前学习了架构的三个共性原则：

1. 合适原则：合适优于业界领先
2. 简单原则：简单优于复杂
3. 演化原则：演化优于一步到位

在架构设计过程中经常会遵循这三个原则，现在学习下架构设计流程的步骤

架构设计流程共分为四步：

1. 识别复杂度
2. 设计备选方案
3. 评估和选择备选方案
4. 详细方案设计

架构设计第一步：识别复杂度

架构设计的本质目的是为了解决软件系统的复杂性。而架构设计的首要步骤则是分析系统的复杂性。

为什么要分析系统的复杂性？

只有正确分析出系统的复杂性，后续的架构设计方案才不会偏离方向；否则，如果对系统的复杂性判断错误，即使后续架构设计方案再完美再先进，都是南辕北辙，做的越好，错的反而越多越离谱。

架构的复杂度主要来源于“高性能”、“高可用”、“高扩展”等几个方面，但是在架构设计时没有必要同时满足这三方面的要求。实际上大部分场景下，复杂度只是其中的某一个，少数情况下包含其中两个，即使真的认为要同时满足这三方面的要求，也得进行优先级排序。

如果同时遇到需要解决多方面架构问题应该怎么做？

将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题。也就是在分析完复杂度后，将问题进行优先级排序，先解决最急需解决的问题。

也就是说，识别复杂度的最终是为了更好的了解当前业务的痛点，而对系统的架构则是为了更好的解决这些痛点，从侧面来说也佐证了“合适原则”。

架构设计第二步：设计备选方案

当我们已经把业务的复杂度罗列出来，并对其进行优先级排序后，我们需要根据对业务的理解，进行挑选合适的架构模式进行组合和调整，也就是需要解决方案。

在这里有几个容易犯的误区：

1、 设计最优秀的方案：每个架构师心里都想做一个“吊炸天”的架构设计方案，但是根据“合适原则”和“简单原则”，我们更需要的是挑选合适自己业务、团队、技术能力的方案。否则，过于“完美”，过于“复杂”反而得不偿失。

2、 只做一个方案：只做一个方案有几个弊端，一心里评估过于简单，过于理想化或者因某个缺点而放弃某个方案，二根据以往固有经验来评估新的架构设计，可能会出现业务不兼容性，三是单一方案设计 会出现过度辩论的情况，情绪大于业务需要。在这里比较合理的做法是，备选方案的数量以3~5个为最佳且备选方案的差异要比较明显。

3、 备选方案过于详细：过于详细会耗费大量的时间和精力，而且过于详细可能会忽略整体的技术设计，并且在评审的时候，容易把其他人绕进细节争论，从而导致评审效果差。在这里，我们更应该关注的是技术选型，而不是技术实现细节。

架构设计第三步：评估和选择备选方案

当我们有3～5个备选方案时，最终选择哪个成为最大的挑战：

1、每个方案都可行

2、没有哪个方案完美，例如A性能不好，B成本高，C新技术不成熟

3、评价标准主观性比较强

选择备选方案的指导思想：

1、最简派：方案实现方式简单，复杂度比较低

2、最牛派：性能最高的，可用性最强的，功能最强大的或者大厂用过的。

3、最熟派：挑选自己最熟悉的方案

4、领导派：让领导来决议。

选择备选方案的方法 “360度环评”：列出我们需要关注的质量属性点，然后从这些质量属性的纬度评估每一个方案，再综合挑选适合当时情况的最优方案。

常见的方案质量属性点：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性。在评估质量属性的时候要遵循合适原则和简单原则，避免贪大求全。

面临选择困难时，看似正确其实错误的方法：

1、数量对比法：简单的看哪个方案优点多就选择哪个方案。这个问题在于把所有的质量属性看做同等重要的位置，没有区分质量属性优先级。

2、加权法：给每个质量属性一个权重，最后汇总权重得分来确定。这个问题在于无法客观地给出每个质量属性的权重得分。人为情感因素更容易掺杂。

正确的做法：按照优先级选择。即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序。

架构设计第四步：详细方案设计

当我们敲定备选方案后，接下来就是将备选方案进行剖析和细化，将方案的关键技术细节确定下来。

比如说，我们需要用到全文搜索技术，那么我们可以选择solr或者es，如果我们选择es，那么需要确定es的索引是按照业务分还是一个大索引即可；副本数量需要几个等。

在这些细节确认过程中，需要架构师根据现有业务急需解决的问题以及团队等综合情况来敲定技术细节

再比如如果使用MySQL来进行分库分表，需要确定哪些表需要分库分表，按什么纬度来分，怎么解决联表查询的问题等等。

我们需要使用nginx的负载均衡，那么我们需要选择nginx的版本，是选择nginx官方版，还是openresty版本，还是Tengine，他们各自的特点有哪些，支持哪几种负载策略，各负载策略的侧重点是哪些。

在详细设计方案阶段可能遇到一种极端的情况，就是在这个过程中发现备选方案不可行，而导致这种情况的发生一般是因为在备选方案阶段遗漏了某个关键技术点或者关键的质量属性。

对于这种情况如何有效的避免呢？

1、架构师不但要进行备选方案的设计和选型，还需要对备选方案的关键细节有较深入的理解。不能道听途说，或者某某大厂使用为依据。

2、通过分步骤、分阶段、分系统等方式，尽量降低方案的复杂度。我们可以将整体方案进行拆分，将拆分后的模块进行细化，虽不需要做到事无巨细，但也需要涵盖重要的技术细节。

3、如果方案很复杂，我们可以采取设计团队的方式来进行设计，博采众长，防止出现技术盲区而忽略某些技术重点。