这是我参与12月更文挑战的第25天，活动详情查看：2021最后一次更文挑战
架构设计原则
合适原则
合适优于业界领先。
开发是一件比较复杂的事情，一个项目最终的成功与否涉及到很多方面。每个不同的架构设计方案都需要有相应的条件。不顾实际，盲目选择业界领先的方案，最终的结果很可能是一地鸡毛。
做一个好的方案设计，需要考虑到：
- 团队人员的技术水平与专长，能否hold住方案相关技术点
- 能够投入的资源，包括人力资源、硬件资源等
- 根据业务场景，判断方案是否适合该业务场景
对业务来说，只有合不合适，没有先不先进，最重要的是在当前的约束场景下，将业务快速落地，这才是一个架构方案的最大价值。
简单原则
简单优于复杂。
复杂方案会带来很多问题。不仅开发起来比较耗时，定位问题，后续迭代，都会有非常高的成本。所以我们做架构设计的时候，能用简单方案，尽量不要用复杂方案。
演化原则
演化优于一步到位。
对于软件开发而言，变化是永恒的主题。软件架构需要根据业务发展不断变化。我们无法遇见到后期可产生的所有业务变化，所以也无法设计一个能适应一切的架构。
所以我们应该优先满足眼前的需求，在开发过程中不断迭代，在必要的时候对业务进行重构，重写，不断优化满足新的业务需求。
架构设计流程
识别复杂度
我们需要先将业务中最复杂的部分找出来，有针对的进行方案设计。比如高性能、高可用、可扩展性，大部分情况下只需要满足其中一到两个。
识别复杂度需要从不同角度对需求进行分析。
设计备选方案
只做一个方案是一个常见的误区。没有哪个方案是完美的，并且可能会对现状进行误判，个人的知识也有局限性，而且只设计一个方案可能会导致钻牛角尖。
多设计几套差异较为明显的备选方案，并且不局限于熟悉的技术，这样评审的时候才会更加客观。
评估和选择备选方案
选择备选方案场景的误区是：选择最简单的、选择最熟悉的、选择技术上最先进的。这个选择维度过于单一，比较好的方式是，进行全面评估。
列出系统的复杂度，设计出系统的关键指标，从这些指标入手去评估每个方案。如：性能、可用性、成本、时间、复杂度、安全、可扩展性等。最后按评估结果的按优先级进行排列，综合考虑选出方案。
本文转载自: 掘金