系统架构设计方法指南

1、 系统架构设计方法指南目 录 TOC o 1-3 h z u HYPERLINK l _Toc526847305 1.基本概念和目的 PAGEREF _Toc526847305 h 3 HYPERLINK l _Toc526847306 2.架构设计复杂度来源 PAGEREF _Toc526847306 h 4 HYPERLINK l _Toc526847307 2.1.高性能 PAGEREF _Toc526847307 h 4 HYPERLINK l _Toc526847308 2.2.高可用 PAGEREF _Toc526847308 h 4 HYPERLINK l _Toc5268473

2、09 2.3.可扩展性 PAGEREF _Toc526847309 h 5 HYPERLINK l _Toc526847310 2.4.低成本、安全、规模 PAGEREF _Toc526847310 h 6 HYPERLINK l _Toc526847311 3.架构设计三原则 PAGEREF _Toc526847311 h 7 HYPERLINK l _Toc526847312 3.1.合适原则 PAGEREF _Toc526847312 h 7 HYPERLINK l _Toc526847313 3.2.简单原则 PAGEREF _Toc526847313 h 7 HYPERLINK l

3、_Toc526847314 3.3.演化原则 PAGEREF _Toc526847314 h 8 HYPERLINK l _Toc526847315 4.架构设计的流程 PAGEREF _Toc526847315 h 9基本概念和目的架构设计的基本概念和目的架构设计的目的是为了解决系统复杂度带来的问题，并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出实际业务实际情况的复杂点，然后有有针对性地解决问题，即：有的放矢，而不是贪大求全。 在实际情况中，不一定每个系统都要做架构设计，需要结合实际情况。有时候最简单的设计开发效率反而是最高的，架构设计毕竟要投入时间和人力，

4、这部分投入如果用来尽早编码，项目也许会更快。架构设计复杂度来源高性能高性能高可用高可用可扩展性可扩展性低成本、安全、规模低成本、安全、规模架构设计三原则架构设计三原则合适原则GFS为何在Google诞生，而不是在Microsoft诞生，其中Google有那么庞大的数据是一个主要因素，而不是因为Google的工程师比Microsoft的工程师更加聪明。真正优秀的架构都是企业在当前人力、条件、业务等各方面约束条件下设计出来的，能够合理地将资源整合一起并发挥出最大功效，并且能迅速落地。这也是很多BAT出来的架构师到了小公司或者创业团队反而做不出成绩的原因，因为没有大公司的平台、资源、积累，只是生搬硬

5、套大公司的做法，失败的效率非常高。简单原则软件领域的复杂性无论是结构的复杂性还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单方案和复杂的方案都可以满足需求，最好选择简单的方案。UNIX编程艺术总结的KISS（Keep It Simple,Stupid!）原则一样适用于架构设计。演化原则对于软件系统来说，变化才是主题。软件架构需要根据业务的发展而不断变化。 如果没有把握“软件架构需要根据业务发展不断变化”这个本质，在做架构设计的时候就很容易陷入一个误区：试图一步到位设计一个软件架构，期望不管业务如何变化，架构都稳如磐石。为了实现这样的目标，要么照搬业界大公司公开发表的方案；要么投入庞大的资源和时间来做各种各样的预测、分析、设计。无论哪种做法，后果都很明显：投入巨大，落地遥遥无期。更让人沮丧的是，就算跌跌撞撞拼死拼活终于落地，却发现很多预测和分析都是不靠谱的。实践中，架构师要提醒自己不要贪大求全，遵循演化优于一步到位的原则，因为业务的发展和变化总是很快的，无论多牛的团队，都不可能完美预测所有的业务发展和变化路径。实践中可以参考如下建议：首先，设计出来的架构要满足当时的业务需要。其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉