重構 Metric Collector 介面

[chinghongfang]

#1281 我們需要實做一個新的 Metric Collector 介面，但是 Metric Collector 介面和實做綁的太近，有部份方法是新的實做不需要用到的方法，比如說 "registerJmx()", "registerLocalJmx()"。因此需要重新檢視、重構 MetricCollector 使他變得較 "通用"。

(源自 #1369 討論)

[chinghongfang]

這裡提出一個想法，化簡 MetricCollector 內的方法。

---

MetricCollector 的責任

我的想法中 MetricCollector 將負責

1. 回傳 "需要的 metric"
2. 管理蒐集到的 metric
3. 背景中不斷蒐集 metric

和現在介面的不同在於，MetricCollector 不再在意底下的 MBeanClient ，也就是說將移除 MetricCollector#registerJmx 這個方法，不再從外部新增目標。這個目的有兩個 1) 不一定每一種 MBeanCollector 實做都需要 Jmx 連線； 2) 保持物件單純

再來是 MetricSensor (BeanQuery) 的部份，將移除 MetricCollector#addMetricSensor ，不讓外部新增 query 。會有這項修改是為了讓介面變得更單純，純粹只要負責上面提到的三點工作。不過這個限制會比上面的大，所以不確定有沒有必要為了
"讓介面單純，刪除動態增加 MetricSensor"？

---

移除上述兩種方法後 MetricCollectorImpl 將會

將會把 Jmx 的連線放到 Builder 內設定，在建立 MetricCollectorImpl 時就決定好所有 fetch 的目標。
如果要新增新的 Jmx 連線、新增 query 的項目，將要重新建立新的 MetricCollectorImpl 。

會更改到的程式碼包含 Dispatcher、Balancer、Assignor，其中 Dispatcher 的影響應該會是最大的。 Dispatcher 會在每一次決定 partition 前檢查是否需要增加 Jmx 連線，若是我們叢集時常新增節點，我們便要一直重新建立對所有節點的 Jmx 連線。
同樣影響較大的是 Assignor， Assignor 的介面有兩個方法用來新增 Jmx 連線，那麼當這兩個方法被呼叫的時候，將有可能需要重新建立 MetricCollectorImpl (如果新增的 Jmx 連線不存在)。
目前影響最小 (or 沒有影響) 的應該是 Balancer 現在 Balancer 使用 MetricCollector 都是在建立時就已經決定好目標，不會臨時新增目標節點，原因也和實做有關 (Balancer 每一筆 request 建立一個新的 MetricCollector)。

然後目前沒有動態新增 MetricSensor 的用法，都是一開始建立時就決定的。

---

想看看大家有什麼看法？還請不吝分享賜教。

[chia7712]

將會把 Jmx 的連線放到 Builder 內設定，在建立 MetricCollectorImpl 時就決定好所有 fetch 的目標。
如果要新增新的 Jmx 連線、新增 query 的項目，將要重新建立新的 MetricCollectorImpl 。

1. 重新建立的話，如果該物件有快取一些資料就會跟著消失。我們可否用類似"re-configure"的效果取代重新建立？
2. 可否先試著發一隻PR 展開這個項目？也就是先把某些方法移動到建構過程、並且處理上述1的可能