系统性能优化策略 — 持续优化更新

【开篇词】
     无论是传统行业还是互联 行业，一个优秀的软件产品，必须兼顾产品的质量和性能。这二者也可以反映出从业者的技术能力、思维方式以及格局！故性能优化应该是我们所有猿类共同的追求。

【策略】
      业界衡量一个软件系统性能的三个指标：TPS(Transactions Per Second)，QPS(Query Per Second)以及RT(Response Time)，其实前二者可以等价于写操作和读操作。如此说来，系统性能优化无非是提升读写的效率，对应到实际应用场景就是增加系统的吞吐量，最终对于用户的直观感受就是较低的响应时延。

2. 业务流程
     众所周知，一个Http(POST)请求的完整路径如下：
     表单数据提交 -> 浏览器发送Post请求 ->服务端解析Post请求 -> 服务端执行业务逻辑组装Response数据 ->服务端发送响应给浏览器 -> 浏览器解析返回的Html数据 -> 浏览器页面渲染请求其他资源(CSS/JS/图片链接等)。

• 单次请求
  在这个过程中我们需要注意以下三点：
    1. Request请求Body与Response响应Body的数据应该尽可能少
        在客户端和服务端之间往返传输较大量级的数据不仅需要耗费较多的带宽，也会占用更多的CPU资源（数据的加解密/编码/运算），也就在某种程度上影响了系统的性能。此外，将数据体保持在一个合适的大小，在一定程度上与博文《谈谈代码重构》中接口设计的“单一职责”原则吻合——一个接口应该仅仅实现某一个特定功能。
        为了减小单次请求所携带的数据体与请求应答所返回的数据体的量级，需要合理设计请求和应答所需要的数据，避免无用数据被传输，可以考虑避免向服务器请求不经常变动的数据(静态数据，包括页面渲染时依赖的CSS样式、JS脚本、图片等)。
    2. 请求链路应该尽可能短/依赖尽可能少
        一个完整的请求链路如上图所示，始于一个POST请求的发起，终于一个Response应答的接收。这条链路的时延取决于服务端的业务逻辑，一个简单的业务逻辑可能仅仅是一次数据库的读(HTTP-GET)或者写(HTTP-POST/UPDATE/DELETE)操作，中间不存在任何计算环节或者其他依赖。相反，一个复杂的业务逻辑难免需要进行复杂的逻辑运算或者依赖于其他业务的中间结果，此时，请求的链路势必增加，请求的依赖也极可能增加。
        在单体应用中，一次请求所依赖的业务逻辑最复杂的情况是需要本地不同进程间通信协作完成；但对于一个分布式系统而言，一个请求所依赖的业务服务是分开部署的，此时业务服务之间的协作将会采用远程过程调用RPC来完成。如此，一次请求除去链路增加，依赖增加之外，也更容易受到 络状况的影响，最终请求时延必然有所增加，随之而来的负面效应是用户体验下降。
        为了缩短请求链路，可以考虑合理利用缓存（服务端缓存/CDN缓存/客户端缓存）；为了减少依赖，需要合理进行接口设计——高内聚低耦合。
    3. Response的Body中应该尽可能减少额外的依赖
        这一点算是客户端性能优化的策略之一，更好的考虑用户体验。在页面渲染的过程中，因为过多的外部依赖将导致页面数据加载缓慢，影响用户体验。如何减少额外请求呢多个外部请求合并为一次请求或者采用缓存策略来保存部分不常变更的数据到距离用户最近的地方。
• 并发请求
    1. 将不存在顺序依赖的多个请求合并为单次请求
        前端开发中，某一页面数据经常依赖于多个后端数据的组合结果，若多个后端数据的获取没有严格的顺序依赖，则可以将这些后端请求合并为一个请求，一次性发送到后端。在JS开发中，我们可以采用Promise对象来实现这一优化，具体用法可以参考：https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Promise/all
    2. 限制最大并发请求量
  服务端应该采取某种措施来限定并发请求的数量，通过设置一个合理的阈值，来避免服务端资源被过多的并发连接消耗；