Armeria: A Microservice Framework Well-suited Everywhere

• 簡報連結
• Github
• 官網

前言

大家好我是 Chatbot Developer Taiwan - NiJia，很開心這次能夠以 LINE API Expert 的身份被邀請來參加 LINE Developer Day 2019。

本次議程是由韓國的 open source manager - trustin 為我們帶來議程。

而在今年參加八月舉辦的 COSCUP，並且在第一天的 after party 參加 LINE BoF 上就已經看到 LINE 開發的 Open Source - Armeria，它是基於 Java 所撰寫的一個非同步的專案，支援 Java8, Netty, HTTP/2, Thrift 以及 gRPC，當時聽團隊簡單介紹就覺得這個專案一定是個很不得的專案，只不過當時因為他們快速介紹兒少聽了很多細節，這次就把我聽到的細節告訴各位吧！

據之前的議程的以及講者的分享說這個服務已經被應用於很多 LINE 服務裡頭，因為覺得好用才推出來🤣

如何讓開發者快速使用 Armeria

接下來就用 Java code 來簡單火力展示如何用一個串聯式寫法把服務互叫起來，不管是要用什麼服務只要用串接的方式加入即可，像是 gRPC、Thrift、annotation...等等如下面幾張圖所示。

---

---

---

這邊看到可以這麼簡單就把一個服務叫起來，然後要讓他開發者可以很輕易地理解並上手，LINE 團隊的開發文化真的是令人佩服...

為什麼要做成 async 以及 reactive

首先就先提到若 Queue 裡頭的東西若是都 sync 的話會有什麼問題，這邊就以一個 Call API 常遇到的問題 - Timeout，在大量的 Queue 在排隊時，以 sync 的方式存在時光遇到 Timeout 就會有服務器爆炸的問題，因為彼此不能影響彼此，且這件事會發生在真實世界的每個地方。

---

這邊講者提出的解決方案為：

• 增加執行緒的標記(#)並且減少呼叫堆疊(stack)
• 預準備 Tread pools 讓大家互相共享
• 少調用 points
• 使用非同步的好處就是能夠平行呼叫+較少的執行緒

現在他們能用非同步的方式解決系統被鎖住的問題，但今天若遇到一個很肥～的 payload 呢？以範例來說若一個用戶送他 10 MB 的大小，一次送給 100K 個用戶就相當於 1 TB 大小的流量。

這邊使用的方法是用不同的頻寬 & 處理能力，並且只需要足夠的 buffer 來排除 Out of Memory 的錯誤。

聽到這邊看起來是使用相關的工具來讓整個串接服務可以更有效的 Debug，最後透過 Kibana 來讓訊息可視化，讓 Debug 可以更加快速。

若對相關 Debug 工具可以參考我之前寫的 Sentry 文章

Kibana 可參考： 安裝 ElasticSearch + Kibana 實現中文全文搜尋與數據分析

結論

經過了講者一連串的火力展示後感受到 LINE 對於 open source 有多麽的重視，連 Slack 也都愛上 Armeria 這套 Java 函式庫，用於他們的軟體中並公開推薦，讓像我這種喜歡做 open source 的工程師可以燃起新希望繼續為開源做努力。

其實還有很多技術細節的部分在簡報裡，這邊我就不再多家贅述，大家可以參考 GitHub，裡面有更加詳細的用法提供給大家。

這次來 LINE Developer Day 讓我感受到不同於其他大公司的文化，除了精彩的議程外也招待我們這群 LINE API Expert 前來共襄盛舉，若你也想成為 LINE API Expert，不妨拿著你的貢獻來申請看看連結，或許明年我們就能一起去啦！

或是你想面對面直接問問看，也可以來 Chatbot Taiwan 參加我們一個月一次的社群聚會喔！我們時常會邀請 LINE 的資深技術傳教士 - Evan 來為各位帶來第一手 LINE 的資訊，也許可以跟他詢問看看，或許會有意外的收穫喔！

How we continuously delivery LINE TODAY App with high agility and high quality

簡報連結: URL

前言

大家好我是 Chatbot Developer Taiwan - NiJia，很開心這次能夠以 LINE API Expert 的身份被邀請來參加 LINE Developer Day 2019。

這個議程是難得出現的台灣人，一開始只是想說聽看看 LINE TODAY 是如何透過維持高度敏捷以及保持高品質，其實也就是瞎子摸象，結果聽到自我介紹後發現是台灣人來講，感覺就是在異地聽到一個台灣味的口音覺得很親切🤣

接下來就看一下我聽完這場的心得吧!

負責專案

• LINE
• LINE TODAY
• LINE SDK
• LINE MUSIC(Taiwan) 最近常常出現在左上角的那個 LINE MUSIC

流程

從 Pull Request - Code review - Build pipeline - unit test - UI test - deploy

當中提到兩個主要部分：

• Unit test: 覆蓋率最好要多少？
• UI test: 自動化測試的可信度？

且在測試當中會有一種測試叫做 flaky test，有時候測試有過、有時候有沒過，完全讓人摸不著頭緒的測試，這會傷害到軟體品質以及覆蓋率，因此若這種狀況出現時趕快號招團隊的人來討論這個狀態是否處理。

flaky test

UI 自動化測試

在這部分提到說 UI test code 好寫但是難去維護，主要在於 UI 的東西可能會因為裝置、作業系統...等等的問題去影響到，且會很容易出現 flaky test，這邊我詢問講者得到的答案是測試只要確認在當前 UI 上最重要的元件若有出來的話這部分的測試就給過，若太精細的測試時常會影響到整體的開發敏捷度與流暢度。

想想也是有道理，平常聽到人家說測試測試的，只是當今天測試時的究竟是要到多詳細還是要取決於團隊的決定。

這段講者有提到要注意 UI Automation test 是 Smoke test，因此要注意維護成本以及flaky test的問題！

驗收標準 - Acceptance Criteria

接著就提到團隊需要準備各種情境所需要的東西：

• 不一樣的測試資料來讓產品有彈性且是可信賴
• 若有針對類似 Database 這類的測試團隊則更需要去注意測試細節避免導致特異情況 總之就是 Product Owner(PO) 是需要訂定團隊規則並讓大家去遵守，確保品質！

這裡有提到他們經由上述制定好的驗收標準之後，隨著 Release 版本之後的手動測試比率逐漸減少，到後來都是偏向自動化測試去處理，且是有團隊可信度。

Code Coverage

這邊以 iOS 開發為例，首先就是 MVC 框架上所遇到的問題，官網都是以 MVC 下去做範例，但實際上開發起來則是還得以 MVVM 的框架去執行在測試的部分才不會採太多不必要的坑。 接下來提到的部分我覺得是這個議程最重要的一部分，就是如何去取捨覆蓋範圍，像是上圖顯示，可能會有一些 Callback 或是其他的是不可預期的範圍，團隊需要將這些問題一一列出來討論，並且去制定一個最低標準以及 Must have 的標準，促使團隊可以更有規則的去進行開發，如下圖所示。

結論

其實一家公司很願意花成本去讓開發者可以去寫各種測試確認服務品質，若是以普遍環境來說這真的是很難人可貴的地方，此外從中也了解到一個好的流程應該是如何，從談需求到開發中間所要經歷過多少事才能讓一個服務起來，測試這部分真的是很大的一門學問，千萬別寫一堆測試但這個測試只是自己測開心的，而是要讓測試的內容可以讓團隊很放心的將 code 交給測試去驗證，達到這樣子目的的程式我相信在市場上一定是很能接受考驗的！

Seamless device migration using LINE secure backup

簡報連結: LINE Dev Day 2019

前言

大家好我是 Chatbot Developer Taiwan - NiJia，這次被 LINE 邀請來參加 LINE Developer Day 2019。 經由 每位負責人的 Keynote 開場完後就是會眾們開始聽議程的時候了，我選擇跟資安相關的主題來開始我今日的第一場議程，想想在接觸資安時還是大學時期呢(遠望)。

心得

開場不免俗的一定是要自我介紹並說主要大綱，講者本身為一個駭客並是 Side-Channel Marvels 成員之一，在 GitHub 上坐了一個逆向工程的工具 - QBDI。而作為一個 Hacker 破壞當然對他們來說是相對簡單，但換個方向來看，就是透過滲透測試來建立更完整的服務內容，的確在真實世界上要摧毀一個服務是相對容易的！

但講者是在 LINE 這種規模較大的公司裡做滲透測試，在滲透後做完測試報告時需要顧慮到其他開發團隊的工作時程問題，也許這個漏洞在實際服務運轉上的容錯率是相對高的話，就可以讓開發團隊安排時程去修補漏洞而避免延遲產品上線時間。

這邊主要提到一些 加密協定原則 以及傳統訊息傳送都是怎麼做。 接著說到帳號轉移裝置時的問題，今天要從舊的裝置備份到新裝置時，若透過 Server 的話他只有加密過後的資料，如此一來根本無法備份過去，而 end-to-end 的備份的話會遇到以下問題：

• 會受到各種通訊協定的問題(wifi, Bluetooth, NFC...)
• ios - andriod 不同裝置相容性問題
• 需要重新建構訊息模型
• 要怎麼處理來自 parameter 的攻擊
  • Hacker 透過中間人攻擊
  • 會透過各種狀態來找尋漏洞 (BGP, DNS, Certificate PKI...)

UX x Security

前面簡單介紹一些備份上的問題以裝置間的問題，接下來就進入如何在最好的使用者體驗上並擁有資訊安全：

若要最好的使用者體驗 - Best UX

• ✅不需要在意裝置間的問題
• ❌會被駭客透過中間人攻擊去塞有問題的資料
• ❌安全層級等於零

這樣公司就不用運作啦 (笑)

最安全的等級但最差的 UX

• ✅Private key 加密過並且擁有最難破解的密碼
• ❌使用者根本記不得這密碼
• ❌密碼過於複雜

這邊講者有補充若是只有六位數的密碼他大概有 一百萬 種可能性，可以透過暴力破解的方式就解決，且有大約 10% 的密碼是重覆性很高的，因此還是建議擁有大小寫以及特殊符號是相對好！

每天都會有弱密碼出現於生活中

• combination padlock
  • 硬體設備都用很弱的加密協定
• Banking card PIN
  • 很容易出現像是 生日 這類的密碼
• smart phone lock screen
  • 使用者求快
  • ARM trustZone / apple secure

Server Side 相關相關加密元件

• Trusted execution environment(TEE): 保護 process 相關
• Trusted Platform Module(TPM): 微控制器相關加密元件
• Hardware security module(HSM): 一種用於保障和管理強認證系統所使用的數字金鑰，並同時提供相關密碼學操作的電腦硬體裝置。

HSM in backups

接著就介紹是如何透過 HSM 的硬體元件來處理備份資料資安的問題 透過硬體(HSM)來幫忙加密確保每一段上傳下載都是安全且可加解密，使用者在這過程中也不需要輸入一大串的密碼就只顧及資訊安全而放棄 UX，而在 HSM 當中會將私鑰安全的存下來，不用擔心會有被攔取之類的問題。

由於 HSM 經過雙重加密認證達到資訊安全且是安全的儲存下來，因此不會因為被抓到之後就馬上被解開，確保整個資料傳遞上的安全性。

上圖則為 HSM 簽證公鑰的註冊流程，經由一連串的加密把它存成二進制 source code，且裝置還是能使用 public key 來解開這個二進制檔案，如此一來在備份到新裝置上就不用擔心整包資料的安全性了！

結論

我們在實作的網站在沒什麼流量時都不太需要注意資安相關，但當系統請求越來越大或是有金流時在每段的加解密終究都相對重要很多，且在建立 UX 以及 Security 之間要如何平衡也是個重要的議題，如同講者說的，在做這些技術的同時且站在巨人的肩膀上(LINE)對於白帽駭客的成就感是源源不絕的，能夠透過滲透來讓我們每天在用的東西更加完整也是很棒的一個作法😊。

而過往在聽駭客朋友們在聊都是在講 WAF 較多是在講 Web application 相關的，這次聽到的 HSM 功能看起來雖然很相似，但看來是叫專注在資料的加解密當中，或許當中應該還有更深入的功能還未提到，透過這個議程認識到新的東西也是一大收穫😁。