架构设计的不确定性
相比编程来说,架构设计并没有像编程语言那样的语法来进行约束,更多的时候是面对多种可能性时进行选择。
合适原则
合适原则宣言:合适优于业界领先。结构设计需要脚踏实地,主要体现在:
- 将军难打无兵之仗
- 罗马不是一天建成的
- 冰山下面才是关键
真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的,能够合理地将资源整合在一起并发挥出最大功效,并且能够快速落地。
简单原则
简单原则宣言:简单优于复杂。
“复杂”在制造领域代表先进,在建筑领域代表领先,但在软件领域代表的是“问题”。软件领域的复杂性体现在:
- 结构的复杂性
- 组成复杂系统的组件数量更多,组件越多,就越有可能其中某个组件出现故障
- 某个组件改动,会影响关联的所有组件
- 定位一个复杂系统中的问题总是比简单系统更加困难
- 逻辑的复杂性
演化原则
演化原则宣言:演化优于一步到位。对于建筑来说,永恒是主题,对于软件来说,变化是主题。软件架构需要根据业务的发展而不断变化。
三者关系是合适原则>简单原则>演化原则。
架构设计流程:识别复杂度
根据当前的实际问题,将主要的复杂度问题列出来,然后根据业务、技术、团队等综合情况进行排序,优先解决当前面临的最主要的复杂度问题。
架构设计流程:设计备选方案
高可用的主备方案、集群方案,高性能的负载均衡、多路复用,可扩展的分层、插件化等技术。
常见错误:
- 设计最优秀的方案
- 只做一个方案
- 备选方案的数量以3·5个最佳
- 备选的方案差异要比较明显
- 备选方案的技术不要局限于已经熟悉的技术
- 备选方案过于详细:备选阶段关注的是技术选型,而不是技术细节,技术选型的差异要比较明显
架构设计流程:评估和选择备选方案
选择备选方案时的指导思想:
- 最简派
- 最牛派
- 最熟派
- 领导派
360度环评
具体的操作方式为:列出我们需要关注的质量属性点,然后分别从这些质量属性的维度去评估每个方案,再综合挑选合适当时情况的最优方案。
按优先级选择,即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素,将质量属性按照优先级排序,首先挑选满足第一优先级的,如果方案都满足,那就等看第二优先级,以此类推。
架构设计流程:详细方案设计
简单来说,详细方案设计就是将方案设计的关键技术细节给确定下来。
详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行,一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。
Note: Cover Picture