大话系统架构优化项目之交易线优化

天下武功为快不破，首要的就是提高系统的响应时间（响应时间 = 服务处理时间 + 排队时间），如经典的响应时间曲线所示，我们要做的就是通过程序优化减少服务响应时间，通过提高系统的吞吐量减少系统的排队时间。

响应时间曲线（摘自《Oracle性能预测》）

纵轴是响应时间。响应时间是服务时间和排队时间的总和。横轴是到达率。随着每单位时间进入系统事务数的递增，曲线随之向右滑动。随着到达率的继续增加，在某一时候，排队时间将陡然上升。当这种情况发生时，响应时间也将陡然上升，性能下降，而用户感到非常沮丧。

下面通过以往项目中的案例来分析性能优化的具体工作。

3.2.1交易线优化

交易线是从服务的消费者为出发点，看交易在各个层面应该完成的功能，以及功能点之间的关系。功能点之间的关系用有向路径来表示：

交易线优化的原则：

最短路径：减少不必要的环节，避免故障点；
交易完整性：通过冲正或补偿交易等确保交易线各环节的事物一致性;
故障隔离和快速定位：屏蔽异常情况对正常交易的影像，通过交易码或错误码能快速等位问题；
流量控制原则：可以通过对服务通道进行流量控制，并结合优先级设置优先处理级别高的业务；
超时控制漏斗原则：尽量保持交易线上前端系统超时设置应该大于后端系统。
【案例】随着架构的演变，过去一站是构建的竖井式系统，逐步发展为现在的以服务为单元可灵活构建的独立单元：

在服务治理的过程中原来的核心业务系统被打碎为各种独立的业务组件，一些中间层平台型系统基于这些业务组件和流程服务逐渐构建了业务服务，并成为前端应用的快速构建提供业务支撑。在这个过程中服务识别和构建是基础，交易线的规范是保障，通过交易线规范可以确定服务治理有所为，有所不为，这是因为随软件版本迭代，很少有个人能把系统的全部细节都考虑清楚，所以要以规则治理，而不是人治。

要开发一个订单查询功能A，服务整合平台的B和C两个服务都可以完成相同功能，只是B在C的基础上增加了一些额外不需要的校验，按照最短路径原则这个时候A应该直接调用C服务。

当服务提供者D处理能力不足时，应该及时通知服务消费者C或者按照优先级丢弃部分访问通道的请求，前端消费者接收后端流量控制错误码并及时通知用户。这样可以避免在系统达到容量限制后，所有用户级别都被拒绝服务。流量控制的目的之一是保证各系统健康稳定运行。一般使用计数器按照交易类型来检测交易的并发数，不同交易类型，使用不同计数器。当交易请求到达时，计数器加1，当请求响应或者超时，计数器减1。