业务系统要求
一句话目标：建立好负责的项目
项目要达到
| 性能要求 开发要求 效率要求 质量要求 | |
|---|---|
| 应用视角 | 高并发 开发速度快 并行开发 高可用 |
| 底层视角 | 云原生 分布式 微服务 k8s |
| 抽象视角 | 流量治理 服务治理 资源治理 数据治理 |
应用视角
高并发系统
什么是高并发？
高并发是指特定的系统或应用程序可以同时处理大量的并发处理请求，要求其能够同时应付高流量的访问。它的关键在于系统必须能够支持大量的用户在同一时刻发出的处理请求。
高并发的常用手段
三板斧：横向拓展，缓存，异步
Scale-out（横向扩展）：分而治之是一种常见的高并发系统设计方法，采用分布式部署的方式把流量分流开，让每个服务器都承担一部分并发和流量。
缓存：使用缓存来提高系统的性能，就好比用“拓宽河道”的方式抵抗高并发大流量的冲击。
异步：在某些场景下，未处理完成之前我们可以让请求先返回，在数据准备好之后再通知请求方，这样可以在单位时间内处理更多的请求。
关于横向拓展，多说一点
我们在高并发系统设计上也沿用了同样的思路，将类似追逐摩尔定律不断提升 CPU 性能的方案叫做 Scale-up（纵向扩展），把类似 CPU 多核心的方案叫做 Scale-out，这两种思路在实现方式上是完全不同的。
Scale-up 通过购买性能更好的硬件来提升系统的并发处理能力，比方说目前系统 4 核 4G 每秒可以处理 200 次请求，那么如果要处理 400 次请求呢？很简单，我们把机器的硬件提升到 8 核 8G（硬件资源的提升可能不是线性的，这里仅为参考）。
Scale-out 则是另外一个思路，它通过将多个低性能的机器组成一个分布式集群来共同抵御高并发流量的冲击。沿用刚才的例子，我们可以使用两台 4 核 4G 的机器来处理那 400 次请求。
那么什么时候选择 Scale-up，什么时候选择 Scale-out 呢？一般来讲，在我们系统设计初期会考虑使用 Scale-up 的方式，因为这种方案足够简单，所谓能用堆砌硬件解决的问题就用硬件来解决，但是当系统并发超过了单机的极限时，我们就要使用 Scale-out 的方式。
总结起来，针对系统，就是三个提升方向
- 提升系统性能
- 保证系统高可用
- 让系统易于拓展
但是系统的架构变化应该是动态的，适应应用情况的，不能一上来就是要最高性能，对应的应用复杂度也是最高的。符合当前场景的并发能力就行。
提升系统性能
原则
- 性能优化不能盲目，一定是问题导向的
- 遵循二八法则，即20%的经历用于解决80%的性能问题
- 要有数据支撑：知道每次优化步骤带来的效果
- 持续的，优化性能是持续的过程
度量指标
即接口的响应时间，或者吞吐量。
吞吐量=1/接口的响应时间。
接口的响应时间，有
- 平均值（系统整体情况的参考）
- 最大值（极端情况）
- 分位值，比如tp99，性能的最合理度量指标
一般系统的性能指标要求
那么，响应时间究竟控制在多长时间比较合适呢？
这个不能一概而论。从用户使用体验的角度来看，200ms 是第一个分界点：接口的响应时间在 200ms 之内，用户是感觉不到延迟的，就像是瞬时发生的一样。而 1s 是另外一个分界点：接口的响应时间在 1s 之内时，虽然用户可以感受到一些延迟，但却是可以接受的，超过 1s 之后用户就会有明显等待的感觉，等待时间越长，用户的使用体验就越差。所以，健康系统的 99 分位值的响应时间通常需要控制在 200ms 之内，而不超过 1s 的请求占比要在 99.99% 以上。
tp99<200ms，tp999<1s
两种手段
-
提高系统的处理核心数
tp99不变，但是吞吐量翻倍。
有个严重问题注意，不是核心数越多越好，随着核心数提升，并行的任务对于系统资源的争抢也会剧烈
我们似乎找到了解决问题的银弹，是不是无限制地增加处理核心数就能无限制地提升性能，从而提升系统处理高并发的能力呢？很遗憾，随着并发进程数的增加，并行的任务对于系统资源的争抢也会愈发严重。在某一个临界点上继续增加并发进程数，反而会造成系统性能的下降，这就是性能测试中的拐点模型。
分析：
资源利用率在第一区域稳定增长，在第二区域小幅增长，在第三区域呈直线，表示饱和。
响应时间随着并发用户数的增加，在前两个区域基本平稳，小幅递增，在第三个区域急速递增，产生拐点。
同时，吞吐量随着并发用户数的增加，请求增加，在第一区域基本稳定上升，在第二区域处理达到顶点，随后开始下降。
当系统的负载等于最佳并发用户数时，整体效率最高，也没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大用户并发数之间时，系统可以继续工作但用户的等待时间延长；当系统负载大于最大并发用户数时，用户满意度基本为零，甚至放弃访问。
当然不只是拓展核心存在这个问题，只要是并发增加，都有可能。
-
减少单次任务响应时间
先看系统属于哪种任务主导，CPU密集型还是IO密集型
- CPU密集型：大量CPU运算，比如计算Hash值，计算三角函数什么的，抽象一下是各种逻辑判断比较多
- IO密集型：大部分操作是在等IO完成，磁盘IO和网络IO。大部分系统都是IO型的，比如数据库、缓存、web系统等
针对不同类型应用的不同环节出现的问题，做针对性处理
