什么是架构

• 架构没有标准规范，也不是大学课程，也不是某一个学科。架构是在软件研发过程中，为了解决复杂问题，而做出的优化演进，不要为了架构而架构，要看业务在什么阶段？要解决的问题是什么。

• 架构之前要先了解模块、子系统、系统、组件，如果一个系统很小，不需要划分，那么基本上也不怎么需要架构

• 架构设计的目的是解决业务发展阶段的复杂度。如果业务刚开始，那么快就行了。

• 复杂度一般有

1. 高性能
2. 高可用
3. 可扩展
4. 低成本
5. 安全
6. 规模

不是所有系统一上来就要考虑上面所有情况，要识别主要复杂度，开始着手解决，不能眉毛胡子一把抓。

架构设计的原则

1.合适原则 当前业务发展是在哪个阶段，需要处理多少用户规模，适合当下和一段时间的系统设计即可，不要一开始就做淘宝、微信的架构。

2.演化原则 业务规模是不断发展或者萎缩退化，不同阶段做应对即可，不是一成不变，也不是天天推倒重来，要一步一步来。

3.简单原则 好的架构应该很容易理解，维护，拓展

架构理论

高性能

存储高性能

1. 数据库

读写分离 分库分表 分布式事务一致性&最终一致性

1. NoSQL k-v redis 文档 mongodb 列式数据库 hbase 全文索引 ES

3.缓存 缓存穿透-不存在的key 缓存雪崩-同时过期 缓存热点数据

计算高性能

1.单服务器 RPC/Reactor 2.集群高性能 负载均衡

高可用

理论

1.CAP 一致性 可用性 分区容忍性

2.BASE 最终一致性

3.FEMA

存储高可用

主备 主从 主主 分片集群分布式一致性

计算高可用

主备，主从，对称集群

业务高可用

异地多活 接口：降级，限流，熔断，排队

可扩展

1. 分层架构 2.SOA 微服务

架构实战

模板

存储 业务开发层 服务层 网络 用户 业务层 支撑平台：运维，测试，数据，管理

架构重构

说服业务团队人力支持 说服产品，领导支持，理解痛点 项目管理，技术搭建

开源项目的使用

1.引入 2.改造 3.自研开源

总结

整本书介绍的比较通俗易懂，涉及的点面都很全，对于非服务端（前端、测试、运维）或者非架构师的研发而言，是一个很好的入门书籍