去年花了大半年的时间在Fregata项目上，目前的部署规模在12000个docker的水平。今年上半年打算

对Fregata项目进行一次框架上的升级，目标是提升性能，为上下游生态系统减负。

拓扑

旧拓扑

之前的拓扑是树形拓扑，意味下游节点的并行度不能低于上游的，至少保持一致。

1个Source，3个Parser，3个Sink，Parser和Sink一一对应，数据不会交叉。

1个Source，3个Parser，6个Sink，每个Parser后面对应2个Sink。

新拓扑

新拓扑中的Parser可以将数据分发给任何一个Sink。

1个Source，2个Parser，5个Sink 每个Parser后面都对应5个Sink。

通过控制数据的离散规则可以达到旧拓扑的效果，也就是说，旧拓扑是新拓扑的一种特例。

好处

通过更加合理的配比，达到最小资源和最大性能，举例说明：

老：1×Source +　5×Parser + 5×Sink = 11×Component

新：1×Source +　3×Parser + 6×Sink = 10×Component

在我们的测试中，新拓扑方案比老的快20%，因为整个Stream的瓶颈在Sink，Parser只需要3个就可以。

在减少component的情况下，性能依然得到的提升，减少component，意味着线程数的减少，

buffer区个数会减少，内存预分配的占用也会减少。

Buffer

在这次调优过程中，我们测试了buffer的大小，前后比例对性能的影响。

buffer超过1024后，对性能的提升帮助不大，前提是sink端的性能相对稳定。

source到parser间的buffer设置的更大一下，更有利于性能的稳定。

KafkaSink

老版里我们在Sink上抽象了一层BatchSink，这次重构我们将Batch的逻辑全部交给Kafka的

Client去处理，利用它的linger和batchsize等操作。性能得到20%-30%的提升。

我们对Kafka的Producer也进行了大量的测试，如果我们最大限度的让Producer积攒数据，

会让数据的体积更小，网络和磁盘的开销都会有2-3倍的节约，在消费解压时也会更快。

SpinTime

在老版里，我们就使用SpinTime来进行系统性能的预警，在新版里我们主要使用Spintime来进行

自动伸缩容的评判，目前还在测试中。