2019年5月14日 星期二

Vespa 的設定檔用途

Yahoo 的 Vespa 大數據系統 [1],是 Yahoo 開源的系統,主要功能可以想像是 Elasticsearch 的對照。不過在基本使用上,Vespa 跟 Elasticsearch 稍微有點不太一樣的概念。首先 Vespa 包含了整個環境佈署的程序,也就是在討論「設定 Vespa」時,其實是在討論如何在環境中開啟一組 Vespa 的叢集,並且「Vespa 叢集」在 Vespa 的概念當中是被稱為 Application。換言之,在 Vespa 的世界裡,它是假設了我們要先有一整群 IaaS 的伺服器在等待 Vespa 的 Application 被佈署上去,或者說等待將 IaaS 環境中的節點被分配來安裝 Vespa。等到 Vespa Application 成功被佈署了,之後才會開始討論如何操作 Vespa。

要佈署 Vespa 需要指派一些設定檔,簡單紀錄一下其中一些設定檔的用途。其中因為整個 Vespa 佈署的設定除了要定義資料的 schema、叢集的設定以外,還需要 pom.xml 的搭配,所以通常直接開一個 Java 專案專門用來做 Vespa 佈署設定,會比較自然一點點。

Application Package

Application Package [2] 一般指的是 /src/main/application 這個資料夾,資料夾內的東西基本上都是用來指定要如何進行 Vespa 佈署的。

  • services.xml [3]:叢集的配置檔。命名上感覺是說要在這裡定義要佈署的 Vespa 服務是要用來提供什麼服務的,不過具體而言就是在指定一個 Vespa 叢集,例如要用幾個節點建置叢集、叢集的節點當中哪些節點用來存放哪個資料、資料是否需要 replication 等等的。其中,會需要指定哪個資料放在哪個節點,是因為 Vespa 的佈署包含了 nginx,因此這個設定同時會指派 nginx 做資料的路由。
  • searchdefinitions/*.sd [4]:定義在 Vespa 當中存放的資料的 schema。schema 的主要用途是告訴 Vespa 該用什麼方法來處理資料,例如該建立什麼樣的索引、該把什麼欄位放在記憶體中等等。
參考資料
  1. Vespa
  2. Application Package
  3. Services Configuration
  4. Search Definitions

2019年5月9日 星期四

AWS VPC

AWS 的 VPC 最大只能開 /16,最小能開 /28。其中每個 Subnet 會有 5 個保留 IP 不能被使用:

  • .0 是本地路由
  • .1 是路由器位址
  • .2 是DNS保留位址
  • .3 目前沒用到的保留位址
  • .255 廣播,禁止客戶使用廣播

VPC 生成時會建好一個主路由表,建議不要刪除主路由表,因為就算自己手動重建,可能其他資源的識別還是會有問題。

當 Resource 放在 Security Group 裡的時候,Resource 送出的所有封包都會先出 Security Group、尋找目標 Resource、再進目標的 Security Group。所以即使兩個 Resource 放在相同的 Security Group 內,預設也是無法互相存取的,必須要在 Security Group 內設定允許自己存取自己。

2019年4月30日 星期二

Athenz 基本運作概念與相關名詞

在 Athenz 權限系統中,有幾個比較重要的基本概念和名詞,簡單記錄一下。不過在那之前,因為 Athenz 的結構幾乎跟 AWS IAM 一樣,所以可以先討論一下 AWS IAM 的運作方式 [1],再回來看 Athenz 對應的概念。而且其實我覺得 AWS 的文件整體來說寫得比較好 XD。

2019年4月28日 星期日

Athenz 的授權流程

Athenz 是 Yahoo 開源的權限系統 [1],基於 X.509 Certificate 的架構來提供權限認證的功能。運作上跟 AWS IAM 蠻類似的,是以 Role 為基礎,透過指定某個 Role 對某個 Resource 允許或拒絕某些 Action 來達成授權行為。

2019年4月26日 星期五

plugin execution not covered by lifecycle configuration

公司的 Maven Plugin 在 eclipse 上會跑出標題的錯誤訊息,實際上問題好像是出在 m2e plugin。幾種不同的解法可以參考 [1]。比較完整的做法似乎應該在 dependencyManagement 上追加設定,不過因為在公司裡只有我用 eclipse,其他同事都用 Intellij....所以目前是直接從 eclipse 的 Maven 設定處把這個錯誤忽略掉 XD。

具體來說,就是從 Preferences → Maven → Errors/Warnings → 在 plugin execution not covered by lifecycle configuration 處選擇 “ignore”。

參考資料
  1. Maven —— Plugin execution not covered by lifecycle configuration 错误

2019年4月14日 星期日

繼承(Inheritance)與合成(Composition)

在 Design Pattern 的書裡,大概都會提到「多用合成、少用繼承」,不過具體來說到底繼承會產生什麼問題、合成又能解決什麼問題,一直到現在才有比較明確的感覺。但由於不太擅長描述這種有些抽象的問題,所以這裡就簡單地紀錄一些感覺到的重點,細節就請參閱底下的參考資料吧 XD。

首先,一切的源頭都是為了 OCP(Open-Closed Principle),也就是要盡可能滿足「對擴充開放、對修改封閉」這樣的準則。不過要滿足這個準則,其實會讓程式碼變得複雜,所以在選擇的過程也必須謹慎小心,盡可能只在真正需要的地方去滿足,而不要把這個準則套用到整個系統的每個角落 [1]。

在考量 OCP 的前提之下,由於繼承是屬於在編譯期間的關聯,因此很容易會導致使用繼承時,擴充會需要修改既有的程式碼。這就會導致違反了 OCP 當中的「對修改封閉」的要件。

另外繼承在可能性眾多的情況,也很容易導致子類別的數量爆炸,造成日後維護的困難。

反過來說,合成是屬於在執行期間的關聯,因此較有機會可以避免上述的問題。不過依據狀況的不同,合成也有可能形成子類別較多的現象,雖然不至於到數量爆炸的程度,但往往也會使得 API 變得難以掌握。這類的問題就得複合多種 Design Pattern 來隱藏問題,讓呼叫者不需要對細節有太多的了解。

不過同時也需要注意的是,雖然說概念上提到「少用繼承」,但使用合成其實並不表示完全不使用繼承。關鍵在於「不繼承行為」,但合成常常會需要「繼承型別」(然而這或許只限定在像是 Java 這類強型別的語言上)。

參考資料
  1. 深入淺出設計模式
  2. 物件導向程式設計:為何說composition優於inheritance?
  3. 請問,為什麼要『多用合成,少用繼承』? (java程式語言)
  4. 省思物件導向設計 第2回- 物件導向設計方法面臨的問題 

2019年3月19日 星期二

為什麼需要 CI/CD?

Continuous Integration(持續整合)和 Continuous Delivery(持續發佈),有些時候也會用 DevOps 來稱呼,有在關注技術發展的話就會發現這個詞非常火紅,好像每個人都應該要知道的樣子。不過它可以解決什麼問題呢?

2019年3月15日 星期五

(書籤) git 的 flow

之前曾經稍微看過一點關於版本控管流程的資料,不過沒有很認真在深入了解各種流程的訴求和差異。最近正在努力重新學習 git,所以順帶先暫存一下一些跟流程有關的資料。

然後現在才發現我一直用的流程是 GitHub flow。(遮臉)

參考資料
  1. Understanding the GitHub flow
  2. GitHub Flow 及 Git Flow 流程使用時機
  3. git flow 實戰經驗談 part1 - 別再讓 gitflow 拖累團隊的開發速度