如何识别复杂度
架构设计由需求所驱动，本质目的是为了解决软件系统的复杂性；为此，我们在进行架构设计时，需要以理解需求为前提，首要进行系统复杂性的分析。具体做法是：
（1）构建复杂度的来源清单——高性能、可用性、扩展性、安全、低成本、规模等。
（2）结合需求、技术、团队、资源等对上述复杂度逐一分析是否需要？是否关键？
“高性能”主要从软件系统未来的TPS、响应时间、服务器资源利用率等客观指标，也可以从用户的主观感受方面去考虑。
“可用性”主要从服务不中断等质量属性，符合行业政策、国家法规等方面去考虑。
“扩展性”则主要从功能需求的未来变更幅度等方面去考虑。
（3）按照上述的分析结论，得到复杂度按照优先级的排序清单，越是排在前面的复杂度，就越关键，就越优先解决。
需要特别注意的是：随着所处的业务阶段不同、外部的技术条件和环境的不同，得到的复杂度问题的优先级排序就会有所不同。一切皆变化。
备选方案设计
经过架构设计流程第 1 步——识别复杂度，确定了系统面临的主要复杂度问题，进而明确了设计方案的目标，就可以开展架构设计流程第 2 步——设计备选方案。架构设计备选方案的工作更多的是从需求、团队、技术、资源等综合情况出发，对主流、成熟的架构模式进行选择、组合、调整、创新。
1.几种常见的架构设计误区
（1）设计最优秀的方案。不要面向“简历”进行架构设计，而是要根据“合适”、“简单”、“演进”的架构设计原则，决策出与需求、团队、技术能力相匹配的合适方案。
（2）只做一个方案。一个方案容易陷入思考问题片面、自我坚持的认知陷阱。
2.备选方案设计的注意事项
（1）备选方案不要过于详细。备选阶段解决的是技术选型问题，而不是技术细节。
（2）备选方案的数量以 3~5个为最佳。
（3）备选方案的技术差异要明显。
（4）备选方案不要只局限于已经熟悉的技术。
3.问题思考
可以从开源、自研的角度提出架构设计方案
如果是创业公司的业务早、中期阶段，可直接考虑采用阿里云/腾讯云，性能、HA、伸缩性都有保证。
最大的感悟是：做事情永远都要有B方案。
评估和选择备选方案
1 评估和选择备选方案的方法
列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。常见的质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性。
按优先级选择，即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。
2 RocketMQ 和 Kafka 有什么区别？
（1） 适用场景
Kafka适合日志处理；RocketMQ适合业务处理。
（2） 性能
Kafka单机写入TPS号称在百万条/秒；RocketMQ大约在10万条/秒。Kafka单机性能更高。
（3） 可靠性
RocketMQ支持异步/同步刷盘;异步/同步Replication；Kafka使用异步刷盘方式，异步Replication。RocketMQ所支持的同步方式提升了数据的可靠性。
（4） 实时性
均支持pull长轮询，RocketMQ消息实时性更好
（5） 支持的队列数
Kafka单机超过64个队列/分区，消息发送性能降低严重；RocketMQ单机支持最高5万个队列，性能稳定（这也是适合业务处理的原因之一）
3 为什么阿里会自研RocketMQ？
（1） Kafka的业务应用场景主要定位于日志传输；对于复杂业务支持不够
（2） 阿里很多业务场景对数据可靠性、数据实时性、消息队列的个数等方面的要求很高
（3）当业务成长到一定规模，采用开源方案的技术成本会变高（开源方案无法满足业务的需要；旧版本、自开发代码与新版本的兼容等）
（4） 阿里在团队、成本、资源投入等方面约束性条件几乎没有
详细设计方案
完成备选方案的设计和选择后，接下来需要将确定的备选方案细化，使得备选方案变成一个可以落地的设计方案。
1）架构师不但要进行备选方案的设计和选型，还需要对备选方案的关键细节有较深入的理解。
2）通过分步骤、分阶段、分系统等方式，尽量减低方案复杂度，方案本身的复杂度越高，某个细节推翻整个方案的可能性就越大，适当降低复杂度，可以降低这种风险。
3）如果方案本身就很复杂，那就采取设计团队的方式来进行设计，博采众长，防止可能出现的盲点或经验误区。