不得不说我是三天打渔两天晒网，烂泥巴糊不上墙。 烂泥巴开始打渔。
上节跟着大佬学习了，架构的复杂度来源，现在回顾下，确实想不起来了。重新开一遍。
回顾
影响架构复杂度的几大因素，追求高性能，高可用，高拓展既然已经知道了复杂度的来源于这些方面，那我们有什么原则可以直接将这些复杂度化难为简呢? 那这这节课，我们就看下架构的三大原则：合适原则，简单原则，演化原则。
架构的三大原则
合适原则
- 合适原则，合适的意思就是合适呗，选择一个中间件，或者一些框架，或者物理机等，都得合适我们所要设计的系统。
- 还有就是合适原则的宣言是：“合适优于业界领先。”，就针对这个宣言，我在工作中也有遇到过，有些架构师为了追求新的技术而耗费大量的资源去达到只是起了替换作用的工作。我说一个我自己遇到的真是例子：公司一直用的0是关系性数据库mysql，现在公司上了一个新的项目，然后有个新来的团队leader他说选用mongDB来做存储，当时由于公司之前没有使用过，运维团队的维护能力也算是跟不上。最终结果是折腾了一会然后最后还是使用了mysql解决了。这里的没有选择mongDB也就是合适原则了，虽然mongDB有很多优势，且相对来说能符合一些项目需求。但是运维能力跟不上这也是问题的。
- 还有的就是大佬所讲的盲目跟风，我现在就是有这样的情节，一方面为了证明自己走在技术最前沿（装逼呗），一方面是自己学了，赶紧用公司的项目实践一下（真TM的自私，说的就是我）。这都是自己之前不成熟的想法，如果我的领导看到我的文章，如果我下次要新的技术栈我会给你充分的理由的，毕竟我们都是专业的开发人员。
- 之前的微服务就很火吗？但是有多少公司真正的微服务落地成功，这里的成功不是拆成功，而是真正的达到最终的目的，降低成本，提高服务的稳定性和复杂度等等了吗？ 现在阿里又要拆中台，不搞了。难道大家又要学阿里合并起来吗？
- 合适是重中之重。不合适的人最终都会分手的。
简单原则
简单原则宣言：“简单优于复杂”。
- 我靠，我的第一反应这不就废话吗？简单优于复杂。是的我的思维方式有点问题，这里的复杂的意思是为了使架构变得精美，无懈可击让架构变得很复杂的意思，其实我个人理解他就是我们所说的：“过度设计”。
- “复杂”在制造领域代表先进，在建筑领域代表领先，但在软件领域，却恰恰相反，代表的是“问题”。
- 软件领域的复杂性体现在两个方面：
- 结构复杂：
- 组成复杂系统的组件数量更多；
- 同时这些组件之间的关系也更加复杂。
- 看看下面的物理架构图够复杂吧，其实再我们很多系统都没有必要这么全，下面的物理架构图也算是现在的主流设计了吧。相当全。但是我们的系统需要这么全吗？？？
- 我们再来看看如果这么复杂了会出哪些问题呢？
- 组件越多，就越有可能其中某个组件出现故障 必然事件
- 某个组件改动，会影响关联的所有组件，不需要缓存，你加了缓存，改了缓存那肯定影响系统的一致性问题
- 定位一个复杂系统中的问题总是比简单系统更加困难。有了缓存，到底是数据库没有没出海㷣事缓存没有刷新呢？
- 结构复杂：
- 简单这件事情 不管是在架构设计，还是在我们写代码的时候都有用到，比如设计模式中的kiss原则，不是打kiss的kiss，是keep Simple yourself 或者 Keep It Simple, Stupid!的意思保证简单单一。生活中我们也应该这样。不然会让我们很累
演化原则
演化原则宣言：“演化优于一步到位”。
- 之前一个老师傅讲的一句话： “我们先简单开发（不过度设计），后面结构什么慢慢迭代重构优化”，这是我在上家公司最后一个项目的架构师说的。这也许就本着演化原则来的，希望我没有充分解读。哈哈哈
- 不高深的讲世间万物都是一步一步演化而来的，没有什么是一生下来就是完美的。生物的进化等等等，所以软件架构设计其实更加类似于大自然“设计”一个生物，通过演化让生物适应环境，逐步变得更加强大：
- 软件架构设计同样是类似的过程：
- 首先，设计出来的架构要满足当时的业务需要。这是必然不然会被产品经理“砍死”！
- 其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。这也是重构的作用之一，重构也是迭代开发中很重要的一步。
- 第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等（类似生物体内的基因）却可以在新架构中延续。
总结
- 主要聊了架构的三大原则：
- 合适原则
- 简单原则
- 演化原则
- 这也是我们生活的原则，选择合适的，做事简单点，不要着急，一步一步的脚踏实地前进。
