开始学架构 | 笔记2
作者：互联网
如下内容来之https://time.geekbang.org/column/article/6463 学习笔记：
08 | 架构设计三原则
合适原则： “合适优于业界领先”
再好的梦想，也需要脚踏实地实现！
1. 将军难打无兵之仗 没那么多人，却想干那么多活，是失败的第一个主要原因。
2. 罗马不是一天建成的 没有那么多积累，却想一步登天，是失败的第二个主要原因。
3. 冰山下面才是关键 没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因。
简单原则 ：“简单优于复杂”
软件领域的复杂性体现在两个方面：
1. 结构的复杂性
组件越多，就越有可能其中某个组件出现故障 某个组件改动，会影响关联的所有组件 定位一个复杂系统中的问题总是比简单系统更加困难
2. 逻辑的复杂性
系统会很庞大，可能是上百万、上千万的代码规模，“clone”一次代码要 30 分钟。
几十、上百人维护这一套代码，某个“菜鸟”不小心改了一行代码，导致整站崩溃。
需求像雪片般飞来，为了应对，开几十个代码分支，然后各种分支合并、各种分支覆盖。
产品、研发、测试、项目管理不停地开会讨论版本计划，协调资源，解决冲突。
版本太多，每天都要上线几十个版本，
系统每隔 1 个小时重启一次。线上运行出现故障，几十个人扑上去定位和处理，一间小黑屋都装不下所有人，整个办公区闹翻天。
演化原则：“演化优于一步到位”
对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。
软件架构设计其实更加类似于大自然“设计”一个生物，通过演化让生物适应环境，逐步变得更加强大
09 | 架构设计原则案例
淘宝技术发展主要经历了“个人网站”→“Oracle/ 支付宝 / 旺旺”→“Java 时代 1.0”→“Java 时代 2.0”→“Java 时代 3.0”→“分布式时代”。我们看看每个阶段的主要驱动力是什么：
1.个人网站
2003.4.7 马云提出成立淘宝，2003.5.10 日淘宝就上线了，中间只有1个月，怎么办？淘宝的答案就是：买,主要的考虑因素：快！
2.Oracle/ 支付宝 / 旺旺
在2003 年底，MySQL 已经撑不住了,技术的替代方案换成 Oracle。原因除了它容量大、稳定、安全、性能高，还有人才方面的原因.
本地存储不行了买了 NAS（Network Attached
Storage，网络附属存储），NetApp 的 NAS 存储作为了数据库的存储设备，加上 Oracle RAC（Real Application
Clusters，实时应用集群）来实现负载均衡。
第一阶段买的是“方案”，这个阶段买的就是“性能”，这里架构设计和选择主要遵循的还是“合适原则”和“简单原则”
3. 脱胎换骨的 Java 时代 1.0
淘宝切换到 Java 的原因很有趣，主要因为找了一个 PHP 的开源连接池 SQL Relay 连接到 Oracle，而这个代理经常死锁，死锁了就必须重启
Java 是当时最成熟的网站开发语言，它有比较良好的企业开发框架，被世界上主流的大规模网站普遍采用，另外有 Java 开发经验的人才也比较多，后续维护成本会比较低。
4. 坚若磐石的 Java 时代 2.0
随着数据量的继续增长，到了2005年，商品数/注册会员达到千万级，
这给数据和存储带来的压力依然很大，数据量大，性能就慢。原有的方案存在固有缺陷，随着业务的发展，
比如说Oracle再强大，在做like类搜索的时候，也不可能做到纯粹的搜索系统如Solr、Sphinx 等的性能，因为这是机制决定的
Java 时代 2.0，淘宝做了很多优化工作：数据分库、放弃 EJB、引入 Spring、加入缓存、加入 CDN、采用开源的 JBoss，看起来没有章法可循，其实都是围绕着提高容量、提高性能、节约成本来做的。
已经不是靠“买”就能够解决问题了，此时必须从整个架构上去进行调整和优化。
5.Java 时代 3.0 和分布式时代
业务规模急剧上升后，原来并不是主要复杂度的 IOE 成本开始成为了主要的问题，因此通过自研系统来降低 IOE 的成本，去 IOE 也是系统架构的再一次演化
小结:
即使是现在非常复杂、非常强大的架构，也并不是一开始就进行了复杂设计，而是首先采取了简单的方式（简单原则），满足了当时的业务需要（合适原则），随着业务的发展逐步演化而来的（演化原则）。
罗马不是一天建成的，架构也不是一开始就设计成完美的样子。
标签：时代,Java,原则,演化,开始,笔记,淘宝,Oracle,架构 来源： https://www.cnblogs.com/dongxizhen/p/16208049.html