前文已经总结了高并发系统一般的设计方法，本文接着总结高并发系统设计目标
高性能
优化原则
- 性能优化一定不能盲目，一定是问题导向的
- 遵循"八二原则"：用 20% 的精力解决 80% 的性能问题，抓住主要矛盾解决主要问题
- 数据支撑：了解响应时间和吞吐量优化指标
- 持续优化：持续不断地寻找性能瓶颈，制定优化方案，直到达到目标为止
度量指标
度量性能的指标一般是系统接口的响应时间，主要包括
- 平均时间
- 最大时间
- 分位值：包括90 分位、95 分位、75 分位
性能优化方法
- 提高系统的处理核心数
- 减少单次任务响应时间
- CPU 密集型系统：需要处理大量的 CPU 运算，那么选用更高效的算法或者减少运算次数就是这类系统重要的优化手段
- IO 密集型系统：通过采用工具和监控来发现性能瓶颈点
优化三板斧
- 数据优先，做一个新的系统在上线之前一定要把性能监控系统做好
- 掌握一些性能优化工具和方法，需要在工作中不断的积累
- 计算机基础知识很重要，比如说网络知识、操作系统知识等等，掌握了基础知识才能让你在优化过程中抓住性能问题的关键，也能在性能优化过程中游刃有余
高可用
高可用性（High Availability，HA）：系统具备较高的无故障运行的能力
可用性度量指标
MTBF（Mean Time Between Failure） 是平均故障间隔的意思，代表两次故障的间隔时间，也就是系统正常运转的平均时间。这个时间越长，系统稳定性越高。
MTTR（Mean Time To Repair） 表示故障的平均恢复时间，也可以理解为平均故障时间。这个值越小，故障对于用户的影响越小。
可用性与 MTBF 和 MTTR 的值息息相关，我们可以用下面的公式表示它们之间的关系：
Availability = MTBF / (MTBF + MTTR)
主要通过几个9来描述，正常系统比如电商系统可通过系统重要程度区分1级应用，2级应用，3级应用。1级应用重要性最高，一般需要四个九保障，2级和3级应用一般三个九就可以了 
设计思路
精炼总结主要如下：
- 系统层面
- failover（故障转移）
- 超时控制
- 降级
- 限流
- 运维层面
- 灰度发布：包括灰度发布方案兼容性尤其是数据库、缓存操作的影响
- 故障演练
开发和运维角度
提升可用性的方法是不同的：
- 开发注重的是如何处理故障，关键词是冗余和取舍。冗余指的是有备用节点，集群来顶替出故障的服务，比如文中提到的故障转移，还有多活架构等等；取舍指的是丢卒保车，保障主体服务的安全。
- 从运维角度来看则更偏保守，注重的是如何避免故障的发生，比如更关注变更管理以及如何做故障的演练。
两者结合起来才能组成一套完善的高可用体系。
取舍这块可以参考之前写的一篇文章，架构权衡
高可扩展性
不仅仅看应用服务本身，更需要从整个系统层面考虑，包括数据库、缓存、依赖的第三方、负载均衡器、交换机带宽
设计思路：拆分
主要设计思路就是拆分，会把庞杂的系统拆分成独立的，有单一职责的模块。将复杂的东西简单化，电商系统就是一个比较好的案例，拆成用户系统、订单系统、促销系统、购物车系统等等
- 存储扩展性：比如将电商系统数据库拆成多个库，如用户库、订单库等（垂直拆分 ），做到隔离故障，某一个库"挂了"不会影响到其它的数据库；如果数据量很大，将用户库拆成多个数据库，比如用户库1、用户库2，叫做水平拆分
- 业务扩展性：包括业务纬度，重要性纬度和请求来源纬度
根据业务接口的重要程度，把业务分为核心池 和非核心池