买了一个技术博客，做了一点笔记:
1.架构和框架区别
2.架构的本质
解决复杂度，为了某一个特定的条件内，降低系统的复杂度的一个方案
3.三个因素的复杂度
高可用性，高性能，可扩展达到这三个条件需要解决复杂度，而复杂度来自于需求，比如当前侧重什么？高可用性，我的手机客户端要保证各个平台都可以使用。
达到3中的所有条件是不可能的，只能取舍利弊
4.复杂度其它来源因素（低成本、安全、规模）
5.架构设计遵循的几个原则
架构即决策。架构需要面向业务需求，并在各种资源（人、财、物、时、事）约束条件下去做权衡、取舍。而决策就会存在不确定性。采用一些高屋建瓴的设计原则有助于去消除不确定，去逼近解决问题的最优解。
A.合适性原则（结合实际，不要异想天开），B.简单原则（结构和逻辑的复杂性），C.演化原则（没有一步到位的方案）
合适优于先进>演化优于一步到位>简单优于复杂
为此，从更宏观的视角来看，不断演化是其架构发展的主旋律，而满足适合、追求简单是架构决策的重要依据。需求驱动技术的创新演化；技术反哺业务的发展升级。
6.架构设计第一步:识别复杂度
架构设计由需求所驱动，本质目的是为了解决软件系统的复杂性；为此，我们在进行架构设计时，需要以理解需求为前提，首要进行系统复杂性的分析。具体做法是：
（1）构建复杂度的来源清单——高性能、可用性、扩展性、安全、低成本、规模等。
（2）结合需求、技术、团队、资源等对上述复杂度逐一分析是否需要？是否关键？
“高性能”主要从软件系统未来的TPS、响应时间、服务器资源利用率等客观指标，也可以从用户的主观感受方面去考虑。
“可用性”主要从服务不中断等质量属性，符合行业政策、国家法规等方面去考虑。
“扩展性”则主要从功能需求的未来变更幅度等方面去考虑。
（3）按照上述的分析结论，得到复杂度按照优先级的排序清单，越是排在前面的复杂度，就越关键，就越优先解决。
需要特别注意的是：随着所处的业务阶段不同、外部的技术条件和环境的不同，得到的复杂度问题的优先级排序就会有所不同。一切皆变化。
8.架构设计第二步:设计备选方案
架构设计备选方案的工作更多的是从需求、团队、技术、资源等综合情况出发，对主流、成熟的架构模式进行选择、组合、调整、创新
9.架构设计第三步: 评估备选方案
按优先级选择，即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。
10.架构设计第四步:详细设计
详细方案设计就是将方案涉及的关键技术细节给确定下来。
详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发发现备选方案不可行，一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。
架构师不但要进行备选方案设计和选型，还需要对备选方案的关键细节做深入的了解。
通过分步骤，分阶段，分系统等方式尽量降低方案的复杂度。
11.高性能数据库--读写分离和分库分表
