RFC 定義的 application/problem+json (或是 xml)

剛剛在 Clubhouse 上聽到保哥提到了 RFC 7807 這個東西 (Problem Details for HTTP APIs),剛剛翻瀏覽器累積的 tab,發現原來先前有看到,而且有打算要出新版的消息:

RFC 7807 裡面這樣定義的方式可以讓 client 端直接判斷 Content-Type 知道這個回傳資料是不是錯誤訊息,不然以前都是 JSON 就得再另外包裝。用 Content-Type 的作法可以讓判斷條件變得清晰不少。

除了 application/problem+jsonapplication/problem+xml 以外,在「3.1. Members of a Problem Details Object」裡面則是說明 JSON (或是 XML) 裡面有哪些必要以及可選的資訊要填,然後「3.2. Extension Members」這邊則大概描述一下怎麼擴充。

先有個印象,之後新規劃的東西可以考慮進去...

Kafka 拔掉 ZooKeeper 的計畫

目前 Kafka cluster 還是會需要透過 ZooKeeper 處理不少資料,但眾所皆知的,ZooKeeper 實在是不好維護,所以 Kafka 官方從好幾年前就一直在想辦法移除對 ZooKeeper 的相依性。

這篇算是其中一塊:「Kafka Needs No Keeper」。

真的自己架過 Kafka cluster 就會知道其中的 ZooKeeper 很不好維護,尤其是 Apache 官方版本的軟體與文件常常脫勾,設定起來就很痛苦。所以一般都會用 Confluent 出的包裝,裡面的 ZooKeeper 軟體與 Confluent 自己寫的文件至少都被測過,不太會遇到官方文件與軟體之間搭不上的問題。

另外一個常見的痛點是,因為 Kafka 推動拔掉 ZooKeeper 的計畫推很久了 (好幾年了),但進展不快,所以有時候會發現在 command line 下,有些指令會把 API endpoint 指到 ZooKeeper 伺服器上,但有些指令卻又指到 Kafka broker 上,這點一直在邏輯上困擾很久,直到看到官方的拔除計畫 (但又不快) 才理解為什麼這麼不一致...

給需要的人參考,當初在架設 Kafka cluster 時寫下來的筆記:「Confluent」。

用 Amazon SES 發 Trac 通知信的問題

Trac 在發 ticket 的通知信時,會定義自己的 Message-ID,另外後續變更的通知信件會增加 References 欄位,讓 mail client 可以配對起來 (變成一個 thread)。

Amazon SES 會把原來的 Message-ID 改掉,使用自己的 Message-ID 欄位,可是 References 欄位仍然維持不變... 這就導致 mail client 無法將第一封信 (只有被改過的 Message-ID) 與後續的信件 (References 所指到的信件不存在) 配對起來,只剩下後續的信件因為有相同的 References,所以 mail client 可以正確的配對起來。

所以我就決定生一個 workaround plugin,只要是沒有 References 的信件 (像是每張 ticket 的第一封信),就從 Message-ID 複製一份到 References 裡,這樣就可以讓後續的通知信件與第一封也連結起來了。另外評估這個 workaround 的副作用應該還好,所以就不判斷是不是 ticket 的通知信了...

這就是 trac-references-mail-decorator 這個套件的由來...

Amazon MQ 在 ap-northeast-{1,2} 推出了...

Amazon MQap-northeast-{1,2} 推出了,先前自己架的,現在可以直接拿現成的服務了:「Amazon MQ is Now Available in the Asia Pacific (Seoul) and Asia Pacific (Tokyo) regions」。

不過 AWS 上的開發主要還是以 SQS 之類的服務為主,可以避免 scalability 的問題 (另外一種可能是一開始就打定要搬出來,所以選擇 open protocol 的方案)。在這樣的前提下,Amazon MQ 的定位就變成將現有軟體丟上去跑... (而不想自己管 XD)

AWS 推出用 ActiveMQ 架設的服務,Amazon MQ

AWSActiveMQ 包起來賣服務:「Amazon MQ – Managed Message Broker Service for ActiveMQ」。

在 AWS 上已經有 Amazon SQS 這類服務的情況下,應該還是因為 ActiveMQ 的生態更豐富,所以決定支援 ActiveMQ... 光是支援的通訊協定就比自家多很多,有很多應用可以直接接上去:

With Amazon MQ, you get direct access to the ActiveMQ console and industry standard APIs and protocols for messaging, including JMS, NMS, AMQP, STOMP, MQTT, and WebSocket.

不過支援的地區還是有限:

Amazon MQ is available now and you can start using it today in the US East (Northern Virginia), US East (Ohio), US West (Oregon), EU (Ireland), EU (Frankfurt), and Asia Pacific (Sydney) Regions.

另外這個服務有提供 free tier,可以讓使用者測試:

The AWS Free Tier lets you use a single-AZ micro instance for up to 750 hours and to store up to 1 gigabyte each month, for one year. After that, billing is based on instance-hours and message storage, plus charges Internet data transfer if the broker is accessed from outside of AWS.

Amazon SNS 可以發簡訊到全世界了...

Amazon SNS 的新進展,簡訊可以發到全世界了 (之前應該是只能發到美國?):「New – Worldwide Delivery of Amazon SNS Messages via SMS」。

拉台灣的數字出來可以看到即使是最便宜的台灣大哥大 (Taiwan Mobile) 每通也要 NTD$1.35 左右,其他家就貴翻了... (所以應該是跟台哥大合作對接?)

不過對於本來就有用 AWS 服務的人來說,帳單是在同一張,報起來比較省事...

對各類 Message Queue 的效能測試

在「Benchmarking Message Queue Latency」這篇看到作者測了一輪 Message Queue 軟體:

RabbitMQ (3.6.0), Kafka (0.8.2.2 and 0.9.0.0), Redis (2.8.4) pub/sub, and NATS (0.7.3)

測試包括了從一個 9 到六個 9 的 latency (i.e. 90%、99%、99.9%、99.99%、99.999%、99.9999%),另外也測了 message 大小帶來的效能差異。

99.9% 表示 1/1000,而 99.99% 表示 1/10000,如果差距跟 90% 很大,表示系統反應時間會很不一致。另外有些 Message Queue 軟體有 disk persistence 的功能,也因為寫入資料,會看到更大的差距。

善用或是避開這些特性去規劃才能減少問題,像是關掉 disk persistence 之類的方法。

Slack 支援多人討論群組

Slack 宣佈支援多人討論群組了:「Group Messages Come to Slack」。之前要找一群人討論事情必須要開一個 Private Channel,但每次開 channel 都要想一個名字出來很討厭,後來都用 #test_201510290916 這種沒有意義的名字,而現在可以直接拉人進來了:

另外一個是跟著的改變:「Private Groups become Private Channels」。

With the introduction of group DMs, which will cover many of the use cases that previously required private groups, we’ve transformed private groups into the brand new “private channels”. Private channels will be shown mixed in with your existing open channels alphabetically, with small lock icons next to the private ones. When the time comes to create a new channel, you’ll find a new public/private toggle on the configuration screen.

原先的 Private Channel 就跟 Public Channel 混在一起了...

PSR-7:HTTP message interfaces

PHP-FIG 前幾天公告了 PSR-7 (commit d40b64cc4e64e5a5b2fe998bb0a07d0b56e12505),也就是 HTTP message interfaces

由於 PSR 的編號只是提案順序,通過不一定會照順序。只是之前剛剛好都照著順序來 (PSR-0PSR-4),這次跳到 PSR-7 是跳過了 PSR-5 (PHPDoc Standard) 與 PSR-6 (Caching PSR)。

有了對 HTTP request 與 HTTP response 的標準後,可以馬上想到的是 routing library 與 controller library 可以接上去用,測試會變的簡單一些... 之後應該會有其他的想法可以做?