这是我参与「第五届青训营 」伴学笔记创作活动的第 7 天
主要是看了些文章进行了解。
微服务场景的特点
Kitex 诞生于字节跳动大规模微服务架构实践，面向的场景自然是微服务场景，因此下面会先介绍微服务的特点，方便开发者深入理解 Kitex 在其中的设计思考。
RPC 通信模型
微服务间的通信通常以 PingPong 模型为主，所以除了常规的吞吐性能指标外，每次 RPC 的平均时延也是开发者需要考虑的点。
复杂的调用链路
一次 RPC 调用往往需要多个微服务协作完成，而下游服务又会有其自身依赖，所以整个调用链路会是一个复杂的网状结构。 在这种复杂调用关系中，某个中间节点出现的延迟波动可能会传导到整个链路上，导致整体超时。当链路上的节点足够多时，即便每个节点的波动概率很低，最终汇聚到链路上的超时概率也会被放大。 所以单一服务的延迟波动 —— 即 P99 延迟指标，也是一个会对线上服务产生重大影响的关键指标。
包体积大小
虽然一个服务通信包的大小取决于实际业务场景，但在字节跳动的内部统计中，我们发现线上请求大多以小包（<2KB）为主，所以在兼顾大包场景的同时，也重点优化了小包场景下的性能。
针对微服务场景进行压测
确定压测对象
衡量一个 RPC 框架的性能需要从两个视角分别去思考：Client 视角与 Server 视角。在大规模的业务架构中，上游 Client 不见得使用的也是下游的框架，而开发者调用的下游服务也同样如此，如果再考虑到 Service Mesh 的情况就更复杂了。
一些压测项目通常会把 Client 和 Server 进程混部进行压测，然后得出整个框架的性能数据，这其实和线上实际运行情况很可能是不符的。
如果要压测 Server，应该给 Client 尽可能多的资源，把 Server 压到极限，反之亦然。如果 Client 和 Server 都只给了 4 核 CPU 进行压测，会导致开发者无法判断最终得出来的性能数据是哪个视角下的，更无法给线上服务做实际的参考。
