今日心得
1 WHAT 对高性能的理解?
性能是软件的一个重要质量属性。衡量软件性能包括了响应时间、TPS、服务器资源利用率等客观指标，也可以是用户的主观感受（从程序员、业务用户、终端用户/客户不同的视角，可能会得出不同的结论）。

在说性能的时候，有一个概念与之紧密相关—伸缩性，这是两个有区别的概念。性能更多的是衡量软件系统处理一个请求或执行一个任务需要耗费的时间长短；而伸缩性则更加关注软件系统在不影响用户体验的前提下，能够随着请求数量或执行任务数量的增加（减少）而相应地拥有相适应的处理能力。

但是，什么是“高”性能？这可能是一个动态概念，与当前的技术发展状况与业务所处的阶段紧密相关。比如，现在在行业/企业内部认为的高性能，站在5年后来看，未必是高性能。因此，站在架构师、设计师的角度，高性能需要和业务所处的阶段来衡量。高到什么程度才能与当前或可预见的未来业务增长相匹配。一味去追求绝对意义上的高，没有太大的实际意义。因为，伴随性能越来越高，相应的方法和系统复杂度也是越来越高，而这可能会与当前团队的人力、技术、资源等不相匹配。但是什么才合适的高性能了？这可能需要从国、内外的同行业规模相当、比自己强的竞争者、终端用户使用反馈中获取答案并不断迭代发展。

软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了高性能带来的复杂度；另一方面是多台计算机集群为了高性能带来的复杂度。

2 WHY 为什么需要高性能？
追求良好的用户体验；
满足业务增长的需要。

3 HOW 如何做好高性能？
可以从垂直与水平两个维度来考虑。垂直维度主要是针对单台计算机，通过升级软、硬件能力实现性能提升；水平维度则主要针对集群系统，利用合理的任务分配与任务分解实现性能的提升。

垂直维度可包括以下措施：
增大内存减少I/O操作
更换为固态硬盘（SSD）提升I/O访问速度
使用RAID增加I/O吞吐能力
置换服务器获得更多的处理器或分配更多的虚拟核
升级网络接口或增加网络接口

水平维度可包括以下措施：
功能分解：基于功能将系统分解为更小的子系统
多实例副本：同一组件重复部署到多台不同的服务器
数据分割：在每台机器上都只部署一部分数据

垂直维度方案比较适合业务阶段早期和成本可接受的阶段，该方案是提升性能最简单直接的方式，但是受成本与硬件能力天花板的限制。

水平维度方案所带来的好处要在业务发展的后期才能体现出来。起初，该方案会花费更多的硬件成本，另外一方面对技术团队也提出了更高的要求；但是，没有垂直方案的天花板问题。一旦达到一定的业务阶段，水平维度是技术发展的必由之路。因此，作为技术部门，需要提前布局 ，未雨绸缪，不要被业务抛的太远。

面试官: 小伙子，说下进程和线程？
我:
1， 早期的计算机是没有操作系统的，只有输入，计算，输出。手工输入速度远低于计算机的计算速度。

2， 于是出现了批处理操作系统，通过纸带，磁带等工具预先写入指令，形成一个指令清单（即任务）交给计算机处理。但批处理系统的缺点是只能有一个任务，而且当计算机在进行I/O处理时，CPU是空闲的。

3， 世人发明了进程，一个进程就代表一个任务，多个进程通过分时操作能让用户认为并行操作多任务，进程间的资源是独立单元，但是可以通过介质进行通信。缺点：进程内只进行串行处理，无法很好地分工合作提高处理效率。

4， 于是就有了操作系统调度的最小单元-线程，线程能够使进程内的子任务能够共享进程内的资源，并并行工作，大大提高操作系统的性能。

区别：
线程是任务调度的最小单元，共用进程内的资源。
进程是资源分配的最小单元，与其他进程资源互相独立。

之前我们的系统是all-in的单系统模式，虽然水平扩展了大量机器，但是仍然存在性能问题，比如类似秒杀之类的活动，几乎会在瞬间把整个系统的数据库连接耗尽，导致其他服务发生卡顿甚至不可用；并且全在一个业务系统中，开发部属效率极低，扩展性也存在问题。

于是我们将系统进行了拆分，起初是按照业务拆分成几个核心系统，同时针对不同业务的负载情况进行了合理的水平扩展，整个系统的性能得到了提升，扩展性得到了保证，并且开发部署效率也得到了极大的提高。

但是随着业务的发展，之前的系统拆分不能满足现有业务，同时随着公司很多老员工的离开，之前的架构设计思路没有人清楚，于是就变成了走一步看一步的推进模式，衍生出了各种独立的服务达40个左右，这样系统之间的边界越来越模糊，甚至出现了服务间的循环调用，白白浪费时间。而且一次调用链路过长，发生问题很难定位。

所以我觉得我们的系统就是一个活生生的，没有搞好架构设计的例子，前期是没有设计导致性能瓶颈，后期是过度设计导致系统复杂。

一、所有的高性能都要针对不同的业务场景:
（1）单机的高性能主要在于多任务处理，让不同或相同的任务能够同时处理。
（2）集群的高性能主要在于任务（业务模块，组件，资源）的拆分和利用，一是分配，二是分解，大规模分配的前提是要合理的分解系统，合理的分解也是为了更好的聚合任务。

二、其实现在针对网络访问，dns，反向代理，web服务，应用服务，缓存，数据库，分布式文件等都有很多的解决方案，但如何把这些方案和当前你的业务结合起来，并且你的业务如何进行设计，如何拆分功能和组件来满足不同时期的业务性能变化。

三、其实老师今天提供了一个渐进性的方案，也是业务性能变化的应对方法论，先单机，再集群，然后拆分再集群，不管什么样的性能问题都能用这个方法论来解决。具体如何集群相应开源的解决方案很多，但是业务系统如何拆分，拆分的粒度，我觉得老师也应该有相应的方法论，期待...

具体到我们公司，涉及到性能要改的地方很多了，包括静态资源处理，业务消息队列多线程处理，数据库现在是单库，如何进行读写分离。。。

说说我的理解，不管是任务分配还是任务分解，都是通过分摊单台机器的流量来提高整个系统的处理性能。

对于任务分解，我认为不但没有性能上的收益，反而有性能上的损耗，本来可以在一个进程内部完成的交互，分解后却需要进行服务器间的网络交互。（分解前后业务逻辑不变的情况下）


不知道我这么理解对不对，但是与楼主说的任务分解一定程度上可以提高性能有些矛盾，求楼主指点迷津😊