前提
架构的本质：
通过合理的内部编排，保证系统高度有序，能够不断扩展，满足业务和技术的变化
一个好的架构设计既要满足业务的可扩展、可复用；也要满足系统的高可用、高性能
和可伸缩，并尽量采用低成本的方式落地。所以，对架构设计来说，技术和业务两手都要
抓，两手都要硬。
什么是好的架构师？
- 必定是一个出色的程序员，写的一手好代码
- 技术广度和深度
- 思维高度，具备抽象思维能力
- 思维深度，透过问题看本质
- 良好沟通能力
- 平衡取舍能力
业务架构
业务架构目标：
可扩展和可复用
可扩展架构
何为系统？即 模块 + 关系
如何打造可扩展架构
通过构建合理的模块体系，有效的控制系统复杂度，最小化业务变化引起的系统跳转
具体方法有通过拆分，实现模块划分；通过整合，优化模块依赖关系
案例一电商平台的架构演化
单体架构->分布式->soa->微服务->中台
可复用架构
分为技术复用、业务复用
技术复用：
代码复用有自己打包的类库，第三方提供的 SDK，还有各种算法封装等
复用有我们自己封装的，更多的是大量开源的中间件比如MQ、redis
业务复用：
业务实体复用、业务流程复用和产品复用
具体方法有先划分基础服务边界，三个原则
完整性原则、一致性原则、正交原则
案例一如何设计一个基础服务
案例二如何对现有系统做微服务改造
案例三中台如何练成
技术架构
系统的物理模型图5大类
- 接入系统：主要包括DNS域名解析、负载均衡、web服务器
- 应用系统：java服务框架比如spring
- 基础平台：jvm、操作系统、网络等
- 核心组件：数据库、缓存、rpc等
- 支撑系统：运维系统比如监控、日志等
技术架构的目标：
解决系统非功能性问题，系统的高可用高性能和低成本等；
高可用架构
系统的故障的解决思路
避免发生：我们可以通过不间断电源来避免服务器断电，可以通过事先增加机器来解决硬件资源不足的问题。
故障转移：冗余部署代替问题节点。
降低影响：流量太大，我们可以通过限流，或者通过业务降级的手段，关闭一些次要功能，保证核心功能仍旧可用。
快速恢复：处理线上事故的首要原则是先尽快恢复业务，而不是先定位系统的问题。
高可用架构原则：
冗余无单点
水平扩展
柔性事务：在很多业务场景中，系统的可用性比数据的实时一致性更重要
系统可降级：限流 降级 功能禁用 熔断
系统可监控
高可用手段：
客户端 -> 接入层
首先要解决网络的可用性问题，可以选择 Nginx、HAProxy、LVS 等负载均衡软件，它们都能很好地支持双节点 +Keepalived 部署（通过冗余和自动切换避免了单点的故障）
接入层 ->Web 应用
部署多个实例，很方便地通过水平扩展的方式，提升系统的处理能力，接入层的负载均衡设备，还可以在接入层做限流（水平扩展、自动故障转移以及系统的可降级）
Web 应用 -> 内部服务
部署多个实例进行水平扩展，请求分发，熔断框架
访问基础资源
关系数据库读写分离，分库分表，使用缓存等
案例一o2o平台24小时在线
案例二如何第一时间知道系统哪里有问题
案例三打造一体化监控
高性能可伸缩架构
高性能策略
优化单个请求处理速度，请求处理异步化。
可伸缩策略
总结
架构原则
- 可回滚/可禁用
- 使用成熟的技术
- 使用同质化硬件
- 本文标题： 架构实战案例解析读书笔记
- 文章作者： sherryriver（木木三可）
- 发布时间： 2020.06.08
- 本文链接： https://sherryriver.github.io/2020/06/08/架构实战案例解析读书笔记/
- 许可协议： "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。