什么是架构
-
架构没有标准规范，也不是大学课程，也不是某一个学科。架构是在软件研发过程中，为了解决复杂问题，而做出的优化演进，不要为了架构而架构，要看业务在什么阶段？要解决的问题是什么。
-
架构之前要先了解模块、子系统、系统、组件，如果一个系统很小，不需要划分，那么基本上也不怎么需要架构
-
架构设计的目的是解决业务发展阶段的复杂度。如果业务刚开始，那么快就行了。
-
复杂度一般有
- 高性能
- 高可用
- 可扩展
- 低成本
- 安全
- 规模
不是所有系统一上来就要考虑上面所有情况，要识别主要复杂度，开始着手解决，不能眉毛胡子一把抓。
架构设计的原则
1.合适原则 当前业务发展是在哪个阶段，需要处理多少用户规模，适合当下和一段时间的系统设计即可，不要一开始就做淘宝、微信的架构。
2.演化原则 业务规模是不断发展或者萎缩退化，不同阶段做应对即可，不是一成不变，也不是天天推倒重来，要一步一步来。
3.简单原则 好的架构应该很容易理解，维护，拓展
架构理论
高性能
存储高性能
- 数据库
读写分离 分库分表 分布式事务一致性&最终一致性
- NoSQL k-v redis 文档 mongodb 列式数据库 hbase 全文索引 ES
3.缓存 缓存穿透-不存在的key 缓存雪崩-同时过期 缓存热点数据
计算高性能
1.单服务器 RPC/Reactor 2.集群高性能 负载均衡
高可用
理论
1.CAP 一致性 可用性 分区容忍性
2.BASE 最终一致性
3.FEMA
存储高可用
主备 主从 主主 分片集群分布式一致性
计算高可用
主备，主从，对称集群
业务高可用
异地多活 接口：降级，限流，熔断，排队
可扩展
- 分层架构 2.SOA 微服务
架构实战
模板
存储 业务开发层 服务层 网络 用户 业务层 支撑平台：运维，测试，数据，管理
架构重构
说服业务团队人力支持 说服产品，领导支持，理解痛点 项目管理，技术搭建
开源项目的使用
1.引入 2.改造 3.自研开源
总结
整本书介绍的比较通俗易懂，涉及的点面都很全，对于非服务端（前端、测试、运维）或者非架构师的研发而言，是一个很好的入门书籍
