(書籤) 微服務的管理

微服務在最近幾年蠻盛行的，嗯…或者該說是非常盛行？不過概念上我目前的認知是，它把本來巨大的服務拆解成很多比較小的服務，以達成讓每個比較小的服務容易維護的目的。但同時這會帶來副作用，也就是微服務之間的管理成本會大幅提昇 [1]。實際上這也是很容易想像的事情，因為本來我們認為巨大的服務內部有混亂的互相呼叫的關係（Spaghetti Code [2] 的一種），讓程式碼變得難以維護；而當我們把它拆解成比較小的服務時，各個微服務內就會比較沒有那麼混亂的關係，進而讓每個微服務變得容易維護。但到這裡其實我們根本沒有解決問題！微服務跟微服務之間依然需要互相呼叫，也就是那些所謂的 Spaghetti Code 的關係並沒有被消除，只是被從程式碼內拿到程式碼外而已。所以雖然每個微服務的維運變容易了，但那些混亂又複雜的關係依然存在，而且變成存在於微服務和微服務之間，從程式碼問題變成是架構問題。這點在 [1] 這本書中開頭就有明確地提到，微服務是一種取捨、而不是 silver bullet，它不會解決所有的問題。當我們選擇微服務時，必須同時意識到它將要帶來的缺陷，並且要明確地確認組織能夠處理這個缺陷，才能夠往微服務發展。

在 TWJUG 的活動 [3] 中聽到 Apache Camel 這個工具，雖然說嚴格來講覺得沒有真的打到點，不過再看到最近社群到處轉貼的文章 [4]，就覺得好像有點靈光一閃 (?)，所以就先做個紀錄 XD。

參考資料

1. 建構微服務｜設計細微化的系統 (Building Microservices)
2. Wikipedia - Spaghetti code
3. Camel & Camel K & Camel K on K native
4. 使用 Workflow Engine 來實作 Microservices SAGA pattern

使用其他工具透過 SSH 連接 GCP 的 VM

網路上其實已經有很多文章在講要怎麼用其他工具 SSH 連進 GCP 的 VM，不過中間大多有個小地方寫得不太清楚。

通常來說，多數文章會講說可以用 PuTTYgen 這個工具來產生 RSA 金鑰，然後這裡要記得選一下演算法和金鑰長度。產生好金鑰以後，PuTTYgen 會直接在介面上顯示出 public key，然後可以選填 key comment 和 passphrase。這時最重要的問題來了！這裡其實輸入的 key comment 就是未來用這個金鑰作為 SSH 登入管道時的使用者帳號，並不是一定要輸入什麼指定的東西，所以不必限定在一定要用 GCP 帳號的名稱、當然也不要直接用 PuTTYgen 預設的字串（雖然說預設字串也蠻不容易被猜到的啦….）。

後面就是一般操作，把 private key 存檔，並且把 public key 貼到 GCP 的 metadata 裡面，稍微等一下下，就可以用這個金鑰去 VM 登入了。

參考資料

1. [教學] Google Compute Engine ( GCE ) 使用 PuTTY SSH 登入實例
2. 使用進階方法連線至執行個體

Java 的 Collection

Java 的 Collection 在現在（指 Java 8）主要還是分成三個大類：List、Set、Map。其中每個大類幾乎都有 Thread-Safe 跟 Non-Thread Safe 的區別。有些實作因為比較少用到，會慢慢從我的記憶中消失（表示為金魚腦）….。另外因為我上一次認真看這些東西是在 Java 6 的時候，到現在有些東西有可能有變化了，所以還是需要定期複習和更新一下認知，以確保在合適的時機使用合適的結構。