从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152571 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

08 | 架构设计三原则

淘宝架构的适用性
MySQL vs MongoDB
Angular vs React
技术选择的后果
先进技术 vs 熟悉技术
复杂算法难以理解、实现和修改
单个组件承担过多功能
定位问题困难
组件改动会影响关联组件
组件越多,故障概率增加
组件数量和关系的复杂性
难以预测业务发展和变化
投入巨大资源和时间进行预测和设计
盲目照搬大公司的方案
功能复杂的组件导致开发效率低下和系统崩溃
复杂架构的开发、维护和定位问题困难
大公司的分工细,小团队难以承担大团队的任务
框架选择
技术选择
架构设计依赖经验和直觉
编程的确定性 vs 架构设计的不确定性
当业务发生变化时,扩展、重构或重写架构
在实际应用中迭代、修复、改正、去除架构
设计满足当时业务需要的架构
软件架构需要根据业务发展不断变化
演化优于一步到位
逻辑的复杂性
结构的复杂性
简单优于复杂
避免生搬硬套大公司的做法
企业当前人力、条件、业务等约束下设计架构
合适优于业界领先
根据业务发展不断调整和演化架构
快速落地并在实际应用中完善架构
设计合理的架构满足业务需求
理解业务特点和问题
一步到位的误区
复杂性带来的问题
选择困难
不确定性
演化原则
简单原则
合适原则
架构设计的实践建议
架构设计的误区和挑战
架构设计的三个原则是什么?

该思维导图由 AI 生成,仅供参考

前面几期专栏,我跟你系统的聊了架构设计的主要目的是为了解决软件系统复杂度带来的问题,并分析了复杂度的来源。从今天开始,我会分两期讲讲架构设计的 3 个原则,以及架构设计原则的案例。
成为架构师是每个程序员的梦想,但并不意味着把编程做好就能够自然而然地成为一个架构师,优秀程序员和架构师之间还有一个明显的鸿沟需要跨越,这个鸿沟就是“不确定性”。
对于编程来说,本质上是不能存在不确定的,对于同样一段代码,不管是谁写的,不管什么时候执行,执行的结果应该都是确定的(注意:“确定的”并不等于“正确的”,有 bug 也是确定的)。而对于架构设计来说,本质上是不确定的,同样的一个系统,A 公司和 B 公司做出来的架构可能差异很大,但最后都能正常运转;同样一个方案,A 设计师认为应该这样做,B 设计师认为应该那样做,看起来好像都有道理……相比编程来说,架构设计并没有像编程语言那样的语法来进行约束,更多的时候是面对多种可能性时进行选择。
可是一旦涉及“选择”,就很容易让架构师陷入两难的境地,例如:
是要选择业界最先进的技术,还是选择团队目前最熟悉的技术?如果选了最先进的技术后出了问题怎么办?如果选了目前最熟悉的技术,后续技术演进怎么办?
是要选择 Google 的 Angular 的方案来做,还是选择 Facebook 的 React 来做?Angular 看起来更强大,但 React 看起来更灵活?
是要选 MySQL 还是 MongoDB?团队对 MySQL 很熟悉,但是 MongoDB 更加适合业务场景?
淘宝的电商网站架构很完善,我们新做一个电商网站,是否简单地照搬淘宝就可以了?
还有很多类似的问题和困惑,关键原因在于架构设计领域并没有一套通用的规范来指导架构师进行架构设计,更多是依赖架构师的经验和直觉,因此架构设计有时候也会被看作一项比较神秘的工作。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了架构设计的三大原则——合适原则、简单原则和演化原则。合适原则强调架构设计应根据企业实际情况,避免盲目追求业界领先而忽视实际情况。简单原则则强调架构设计应保持简单,避免过度复杂化,以降低系统复杂度和维护成本。演化原则强调架构设计应具备演化性,能够随着业务发展和技术变化而灵活调整和演进。文章指出,架构设计依赖于架构师的经验和直觉,而遵循这些原则有助于架构师做出最佳选择。此外,文章还详细分析了结构和逻辑的复杂性,以及复杂性带来的问题,强调了在架构设计中选择简单方案的重要性。通过深入的分析和案例阐述,为读者提供了架构设计的重要原则和应用指导。文章以生动的比喻和案例,生动地阐述了软件架构与建筑架构的相似性和本质差异,强调了软件架构需要根据业务发展不断变化的本质特点。最后,文章提出了面对不确定性时架构设计的三原则,即合适优于业界领先、简单优于复杂、演化优于一步到位,鼓励读者深入思考并参与讨论。整体而言,本文为读者提供了深入的技术内容,引人深思,对架构设计有着重要的指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(164)

  • 最新
  • 精选
  • @漆~心endless
    架构设计三原则; 合适原则最适合; 简单原则不简单; 演化原则需推进; 如若脱离三原则; 老板生气你苦逼。

    作者回复: 确认过眼神,你是油菜花的人!!😂😂😂

    2018-05-17
    3
    82
  • 石同享
    合适原则是不是可理解为:确定了一定的系统复杂度之后,能承受其包括性能,可用性,可拓展性,成本,安全方面的最小代价解(简单原则),而演化原则是对上述系统的迭代优化。这样和之前的内容都可以联系起来了。

    作者回复: 是的,我的思路就是这样的,三个原则是一体的,三个原则与架构设计的目的也是一脉相承的

    2018-05-15
    2
    47
  • 桌小洛
    总结的很好,架构设计原则: 合适原则: 有多大的脚(复杂度),穿多大码的鞋。BAT或者业界领先的架构对很多团队和公司来说都是大码的鞋而已,穿上不合适的鞋,团队必定步履蹒跚,很难走的很远,还有可能摔倒(项目失败)。 但是如果能根据自己的业务需求,对BAT或者业界领先的架构进行仔细调研,进行删减,重新取其一部分组合成适合自己的架构,也是非常好的方法。 简单原则: 我感觉改成简洁原则更合适,简单+整洁。360行皆是艺术,架构也是一门艺术。一个复杂的系统,如果能用一个简洁的架构来实现,完全相当于一个艺术品。 相反,如果一个普通的系统,反而被设计成了一个错综复杂的复杂架构,相当于做了一个糟粕品。 演化原则: 通过 简化设计 + 重构 来保证架构的与时俱进。不要前期就对架构进行过度设计,毕竟无论你前期怎么设计,总会有你意想不到的变化产生,唯一不变的就是变化。等你的脚长大了,再去穿大码的鞋。

    作者回复: 你的解读很形象👍👍

    2018-08-11
    46
  • 何磊
    三大原则:合适原则,简单原则,演进原则。 最重要的莫过于合适原则,如果不合适,无意欲削足适履,团队感觉难受,业务不稳定等,因此架构设计的第一原则一定是合适,合适当前的业务,合适当前的团队,合适当前的成本(时间与资本) 其二简单原则,这是一个相对原则,是在合适的基础上进行选择最简单方案,绝不能孤立,并且简单是自己业务的对比,比如:当前淘宝的架构每次迭代,他们选择一个简单方案,但他们的简单不意味着我们的简单。 关于演进原则,系统一定变化的、生长的,但是他们的起跑点肯定不同,比如大公司造的系统都是富二代,他会从微服务开始演进,十个人的小团队会从单体应用演进。 对于上面三个原则,演进原则其实我觉得考不考虑,他都存在,只要你的业务继续,不过好的架构有助于可扩展性,让后续演进更丝滑般流畅,不好的架构到了某个阶段只能重来。

    作者回复: 恰恰“演进原则”很多人不知道,总想一步到位,过度设计

    2018-05-15
    2
    21
  • Geek_5420ac
    深有体会,刚来公司发现现有的项目写的跟shi一样,一直跟组长提出重构,虽然拖了大半年但还是重构了,到了自己负责重构的搭建时,又发现其实之前框架的很多逻辑其实是优于我设计的,最后设计出来的发现其实也不是自己想象中的那么完美,因为设计的同时既要保证原有功能不能丢失,而且还有考虑到后续的拓展,这两者在我看来一般是矛盾的,很难在两者中间取舍,说到底还是自己接触的太少了,加油干饭人!

    作者回复: 你刚来就觉得项目要重构,有点操之过急了,很多时候看起来不合理其实很可能是你不熟悉而已😄

    2021-01-11
    3
    16
  • Loy
    发现这三个选择放在爱情上,也完全没毛病

    作者回复: 爱情怎么演化?😂😂

    2018-05-18
    7
    15
  • 查理
    演进很重要,很多人都喜欢过度设计,简单的东西搞复杂。其实以后系统怎样变化很多过度的预测都不准,还不如让系统在一开始保持精简一点,根据需求慢慢演进

    作者回复: 赞同,预测太长没有意义,也预测不准

    2018-05-17
    4
    15
  • SHLOMA
    题外话,如何说服领导,合适大于先进😂

    作者回复: 人手不够,工期太长,成本太高,没有合适的人才……😃

    2018-05-21
    3
    14
  • Forrest Li
    面对不确定性,架构师始终要做出一个选择,而三个原则遵循着解决问题的思路,提供了选择的依据。首先是合适,能够解决问题,其次是从合适中挑选简单的、能hold住的方案,最后,不要指望一个方案能解决所有问题,总会有弊端、不足,在碰到未来无法预料的情况时再做调整就是。变是永远不变的。

    作者回复: 仅此一家,别无分店的三原则😄

    2018-07-04
    7
  • 十里坡剑神
    非互联网行业的程序猿路过。架构设计得是否复杂,是否高大上,关系到能申请到多少项目预算甚至能否立项

    作者回复: 哈哈,之前有朋友也说过,如果是做外包项目,架构设计无法遵守三原则,必须要高大上;如果在某些事业单位做项目,架构设计的越复杂越好,拿到的经费多。

    2021-01-03
    3
    6
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部