前言
這星期與DK剛好有討論到，我們在新專案上可能需要一個scalable distributed message queue，由於預期單一個queue的qps 可能會很高，所以效能也會是一個重要的考量點之一；在這個前提下，我們開始去找了一些可能的選項…
我自己的Survey過程
在整個survey的過程中，我主要考量的點會是:
(1) 效能，因為我們的需求就會是需要高效能的queue。
(2) 社群成熟度，畢境若社群不成熟的話，可能遇到很多的坑必需自己想辦法處理。
(3) 相關的生態，對目前團隊的使用上來說，是不是有完整的支援。
(4) 目前有在production上使用的公司，我會去看說目前這套服務是否有知名的公司取用了!?
想當然，上述的考量基礎其實還是很薄弱的；而DK 在這次的討論中分享了他的一些觀點，我覺得蠻適合再記錄一下。
DK提出的一些觀點
首先，他認為可以朝兩個大向來找我們會需要解缺方案：
市場上的成熟方案
成熟的方案通常設計上已經經過驗證，有完整的一套生態系統，相對而言，可能會有很重的dependency。
而Kafka 算是這種方案中的一個選項，除了資源吃了多一點外，其他都很完美 (尤其是 scalability)；不過相對而言，因為Kafka在最初設計時就不是以message queues的出發點來設計，所以一定會需要做些額外的工作才能使用它…
市場上還不夠成熟，還未經過大量使用的方案
這時候會偏向降低依賴性，也就是盡可能讓 dependency 可以抽換，也就是說，我們不希望導入以後這個服務要換成另一個方案時是困難的…
而從我們專案的需求上，他列了下面的考量點：
- Scalability
由於我們原本的需求就是需要可以scale的queue，所以這也會是首要考量之一。
- Data Integrity
當有機器 crash 時是否可以確保資料不掉，保護能力夠強，對於開發者來說用起來會簡單。
(這點我還真的一開始沒想到queue會有可能掉資料這件事，這真的是經驗太少了，又學到一課。)
- High Availability
HA主要在維運上也的是個重要的考量點，如果HA不好做的話，就會大大影響到實際上維運的困難。
- Documentation completeness
文件完整度對使用者來說是非常重要的，這才有辦法知道使用上的一些資訊。
- Community support
如果社群不成熟的話，很有可能會再使用一陣子過後沒有人再維護了；而且，也有可能會遇到問題時，找不到前人的經驗，只能自己解決。
- Commercial support
這也是蠻重要的，對商業使用上的支援度。畢境，若一個好用的方案伴隨著不友善的商業授權的話，我們也無法使用在現有的環境。
如何找尋一個技術方案的相關資訊
這邊我也是覺得蠻值得記下來的地方，DK有提到說可以從 hackernews,slideshare, speakerdeck 上找某一個方案的相關資訊。
像是從hackernews上，可以找到關於某個方案的相關新聞；舉例來說，這個討論串就有提到Apache Pulsar被splunk買走以後的一些資訊。
另外像是slideshare, speakerdeck上，我們可以找到某個技術的一些分享簡報，而從那些簡報的多寡與其中的內容，我們就可以挖到更多趣的資訊；比如說，使用上的一些抱怨…等等。
最後
最後我們重新review了一些我們的架構，發現我們所需要的scalable message queue可能實際上是不需要的，是我之前設計的架構上的缺失，才會衍生出這一個問題；所以回到源頭去重新修正整個專案架構可能才會是一個解決根本的方式…
不過這個討論讓我感覺得受益不少，自己架構方面與技術選型這一塊還是非常的不足!
原本，我覺得Apache Pulsar是蠻符合我的期待，但DK分享了一些對Pulsar的想法，像是：
- 定位上是”Better Kafka”，但可能會影響之後對於Message Queue這功能的發展。
- ZooKeeper + BooKeeper 的架構相對於Kafka目前想要去掉ZooKeeper的方向還是有差，Kafka若沒有ZooKeeper以後又會更為簡潔。所以Pulsar在維運上會需要花更多的心力…
這些點都讓我覺得，有太多面向需要去額外考量一個服務的導入了…