架构的目的
解决软件系统复杂度带来的问题
架构解决的问题
系统/子系统，模块/组件，框架/架构
系统
一群有关联的个体根据某种方式运作，是多个“个体”的联盟，能提供单个个体不具备的能力。
子系统
系统的一个“个体”
模块/组件
系统的一个“个体”，区别来源于维度，模块更多的是业务面，比如用户登陆模块，用户鉴权模块；组件更多的是物理层面，比如NgInx组件，MySql组件，HBase组件。
架构
便定顶层设计，规定一个系统有哪些 子系统/模块/组件
框架
子系统/模块/组件 的独立运行方式和交互方式
1.高性能：
单机高性能：多线程多进程配合，合理的组件使用。
分布式高性能：通过横向扩充机器和拆分业务可以实现，但是业务拆分会有瓶颈，关键在于每次调用服务会经过网络调用，增加网络调用耗时，其次是复杂度升高，可能出现循环调用等情况。
2.高可用：
本质上都是通过冗余来实现高可用，通俗来说就是一台机器不够用两台，两台不够用四台；一个机房可能断电就部署两个；一条通道故障就两条。
和高性能一样都是通过增加机器来达到目的，但是有本质的区别。高性能增加机器目的在于扩展处理性能，高可用增加机器目的在于冗余处理单元。
2.1.计算高可用
部署起来和高性能没什么区别，只是机器部署的位置发生了变化
2.2.存储高可用
与计算相比有本质的区别：将数据从一台机器搬到另一台机器，经过线路/网络传输。所以无论是正常还是不正常情况下都会导致系统在某个时间段是不一致的，所以存储高可用的难点不在于如何备份数据，而在于如何减少或者规避数据不一致对业务造成的影响。这就需要考虑CAP定理：一致性，可用性，分区容错性。
2.3.ZK高可用分析
基于Paxos算法，民主选举，主备高强度信息交互保证一致性，通过超过半数以上投票者选举避免脑裂，但是如果是真的损坏节点超过半数则无法选出leader，导致系统不可用。
3.可扩展性
正确预测变化、完美封装变化
复杂的地方在于：
- 不能每个设计点都考虑扩展性
- 不能完全不考虑扩展性
- 所有的预测都存在出错的扩展性
- 深入理解业务
可扩展性更多的层面是对代码架构的层次抽象的扩展。分清楚变化层/稳定曾。这里需要有设计模式的基础和经验还有对业务的理解。我想说一点是“不要拿自己刚掌握的一门技术和设计模式当圣经去生搬硬套，我们需要选择性地使用自己所学”。
4.低成本
5.安全
6.规模
编程是确定的，因为我们写出来的代码要保证每次执行后都有同样的结果，但是家狗是不确定的，你的方案和我的方案做出来可能都是能跑下去的。在设计的时候需要做到几个原则：合适原则，简单原则，演化原则。
1 合适原则：“合适优于业界领先”，没有合适的平台、资源、积累、只是生搬硬套大公司的做法，失败的概率很高
2 简单原则：“简单优于复杂”
3 演化原则：“演化优于一步到位”
首先，设计出来的架构要满足当时的业务需要。
其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等（类似生物体内的基因）却可以在新架构中延续。
以上学习来自极客时间李运华老师课程，持续学习总结更新。
