1. 什么是架构
架构是软件系统的顶层结构。
框架是组件规范，提供基础功能的产品。
组件是从技术维度上的复用。
模块是从业务维度上的职责划分。
系统是相互协同可运行的实体。
2. 架构设计的历史
20 世纪 60 年代第一次软件危机引出了“结构化编程”，创造了“模块”概念。
20 世纪 80 年代第二次软件危机引出了“面向对象编程”，创造了“对象”概念。
到了 20 世纪 90 年代“软件架构”开始流行，创造了“组件”概念。
3. 架构设计的目的
架构设计的主要目的是为了解决软件系统复杂度带来的问题。
架构是为了应对软件系统复杂度而提出的一个解决方案。
4. 高性能
单台系统，通过升级软、硬件能力实现性能提升。
包括：增大内存减少I/O操作、更换为固态硬盘（SSD）提升I/O访问速度、使用RAID增加I/O吞吐能力、置换服务器获得更多的处理器或分配更多的虚拟核、升级网络接口或增加网络接口。
集群系统，利用合理的任务分配与任务分解实现性能的提升。
包括：功能分解：基于功能将系统分解为更小的子系统；
多实例副本：同一组件重复部署到多台不同的服务器；
数据分割：在每台机器上都只部署一部分数据。
5. 高可用
网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。
应用服务器高可用：可通过负载均衡设备将多个应用服务器构建为集群对外提供服务（前提是这些服务需要设计为无状态，即应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行业务逻辑的操作响应），当均衡设备通过心跳检测手段检测到应用服务器不可用时，则将其从集群中移除，并将请求切换到其他可用的应用服务上。
服务层服务器高可用：这些服务器被应用层通过分布式服务框架（如Dubbo）访问，分布式服务框架可在应用层客户端程序中实现软件负载均衡，并通过服务注册中心提供服务的服务器进行心跳检测，当发现有服务器不可用时，立即通知客户端程序修改服务列表，同时移除响应的服务器。
数据服务器高可用：需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份；当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。
6. 可扩展性
可扩展性可以理解为是一种从功能需求方面考虑的软件属性。
一个具备良好可扩展性的架构设计应当符合开闭原则：对扩展开放，对修改关闭。衡量一个软件系统具备良好可扩展性主要表现但不限于：（1）软件自身内部方面。在软件系统实现新增的业务功能时，对现有系统功能影响较少，即不需要对现有功能作任何改动或者很少改动。（2）软件外部方面。软件系统本身与其他存在协同关系的外部系统之间存在松耦合关系，软件系统的变化对其他软件系统无影响，其他软件系统和功能不需要进行改动。反之，则是一个可扩展性不好的软件系统。
在实际软件系统架构设计中，常通过以下技术手段实现良好的可扩展性:（1）使用分布式服务(框架)构建可复用的业务平台。（2）使用分布式消息队列降低业务模块间的耦合性。
7. 低成本、安全、规模
低成本：
低成本是架构设计中需要考虑一个约束条件，但不会是首要目标。低成本本质上是与高性能和高可用冲突的，当无法设计出满足成本要求的方案，就只能协调并调整成本目标。
一般通过“创新”达到低成本的目标。
安全：
功能安全：是一个逐步完善的过程，而且往往都是在问题出现后才能有针对性的提出解决方案，与编码实现有关。
架构安全：传统企业主要通过防火墙实现不同区域的访问控制，功能强大、性能一般，但是成本更高。互联网企业更多地是依靠运营商或者云服务商强大的带宽和流量清洗的能力，较少自己来设计和实现。
规模：
分而治之，各个击破。
8. 架构设计三原则
合适原则
合适原则宣言：“合适优于业界领先”。
简单原则
简单原则宣言：“简单优于复杂”。
演化原则
演化原则宣言：“演化优于一步到位”。
9. 架构设计流程：识别复杂度