阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 https://juejin.im/post/5b2c6669e51d4558c91ba776 「陈彩华」欢迎转载，保留摘要，谢谢！

• 1. 基本概念和目的
• 2. 架构设计复杂度来源
  • 2.1 高性能
  • 2.2 高可用
  • 2.3 可扩展性
  • 2.4 低成本、安全、规模
• 3. 架构设计三原则
  • 3.1 合适原则
  • 3.2 简单原则
  • 3.3 演化原则
• 4. 架构设计的流程

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

最近学习了阿里资深技术专家李运华的架构设计教程，颇有收获，总结一下。

本文主要介绍架构设计的相关概念，系统复杂度的来源，架构设计的基本原则和流程。

1. 基本概念和目的

架构设计的目的是为了解决系统复杂度带来的问题，并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出实际业务实际情况的复杂点，然后有有针对性地解决问题，即：有的放矢，而不是贪大求全。 在实际情况中，不一定每个系统都要做架构设计，需要结合实际情况。有时候最简单的设计开发效率反而是最高的，架构设计毕竟要投入时间和人力，这部分投入如果用来尽早编码，项目也许会更快。

2. 架构设计复杂度来源

2.1 高性能

2.2 高可用

2.3 可扩展性

2.4 低成本、安全、规模

3. 架构设计三原则

3.1 合适原则

GFS为何在Google诞生，而不是在Microsoft诞生，其中Google有那么庞大的数据是一个主要因素，而不是因为Google的工程师比Microsoft的工程师更加聪明。

真正优秀的架构都是企业在当前人力、条件、业务等各方面约束条件下设计出来的，能够合理地将资源整合一起并发挥出最大功效，并且能迅速落地。这也是很多BAT出来的架构师到了小公司或者创业团队反而做不出成绩的原因，因为没有大公司的平台、资源、积累，只是生搬硬套大公司的做法，失败的效率非常高。

3.2 简单原则

无论是结构的复杂性还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单方案和复杂的方案都可以满足需求，最好选择简单的方案。《UNIX编程艺术》总结的KISS（Keep It Simple,Stupid!）原则一样适用于架构设计。

3.3 演化原则

对于软件系统来说，变化才是主题。软件架构需要根据业务的发展而不断变化。 如果没有把握“软件架构需要根据业务发展不断变化”这个本质，在做架构设计的时候就很容易陷入一个误区：试图一步到位设计一个软件架构，期望不管业务如何变化，架构都稳如磐石。

为了实现这样的目标，要么照搬业界大公司公开发表的方案；要么投入庞大的资源和时间来做各种各样的预测、分析、设计。无论哪种做法，后果都很明显：投入巨大，落地遥遥无期。更让人沮丧的是，就算跌跌撞撞拼死拼活终于落地，却发现很多预测和分析都是不靠谱的。

实践中，架构师要提醒自己不要贪大求全，遵循演化优于一步到位的原则，因为业务的发展和变化总是很快的，无论多牛的团队，都不可能完美预测所有的业务发展和变化路径。实践中可以参考如下建议：

• 首先，设计出来的架构要满足当时的业务需要。
• 其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
• 第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等却可以在新架构中延续。

4. 架构设计的流程