# 2021 JavaConf 心得

###### tags: `JavaConf`

今年的Conf與網年不同，是在線上舉辦。線上最大的優點是可以帶著耳機聽得很清楚講者的內容，因為少的旁人的細小聲音干擾，最大的缺點是少了與講者實際互相討論與陌生人的即時討論會後感想。

今年我參與了下列議題

1. 現代化應用的實作方法 -- Swift Method
2. Java 與 Kubernates API 的互動
3. 如何有效地建構技術方案
4. 玉山微心計畫
5. 玉山銀行如何以 Flink 打造流批一體之數據中台

其中「Java 與 Kubernates API 的互動」這個議題我缺少了實做經驗，我聽不懂。另外幾個議題搭配我工作經驗有反思幾個心得。

## 現代化應用的實作方法 -- Swift Method

這個議題主要是分享在開發上的實踐，偏重於程序人員的「心法」。如果是兩年前剛入職一年多的我，應該會聽不懂他在說什。

整個過程中，印象最深刻的是對於程式設計的方式。

一個系統中最重要的是業務流程，而最好的程式碼是如何簡單呈現業務流程，建單到日後的維護人員或是一年後的自己可以一目了然這系統的業務流程。而且設計系統要避免業務程式對於技術的依賴。例如：目前在Java領域中最流行的框架是Spring全家餐。Spring固然好用，但是往五年、十年後想，這個系統仍然繼續默默的運作，直到第十年這個系統已經因為安全性的關係需要進行翻修。然而不幸的，Spring在這個系統運作的第七年黯然的退出社群的舞台，沒有新的資源注入勢必需要更換框。這還不是最要緊的，最慘的是業務邏輯竟然與Spring框架重疊導致需要重新開發。如果當初業務邏輯是獨立開發，框架的事情也許就不需要在花費人力開發。

這讓我想到之前參與案子有更換資料庫。當時可能考慮效能問題，把很多業務邏輯寫在資料庫的程式中，導致在換資料庫時花費了很多人力成本進行重寫。那時候邊做邊罵，為什麼當時的工程師不多思考這一點，資料庫最終目的是儲存資料，為什麼還要進行天文般的業務邏輯運算，重點是每家的資料庫、不！是新舊版本的資料庫語法本身就有差異！真是TMx 重寫到超想說：不幹了！

心法上，講者提出幾點，印象比較深刻的幾點：

1. Pair Programming(結對程式設計)
2. Strangler Pattern

### Pair Programming(結對程式設計)

這部份我覺得比較新穎。主要概念是兩個工程師在開發維護時，共同操作一部電腦、一人主責打程式碼，另一人在旁監督。在人力資源中表免上好像花費了雙倍的資源，但是在兩個的開發過程中，監督的那一人可以檢視程式碼否有錯或是實做業務邏輯是否超出規劃等等，另外成員也可以互相備援、降低人緣流動風險、避免程式碼淪為個人資產等優點。但是講者有提出實做「結對程式設計」最大的要求是需要能力相等的程序人員搭配比較合適。這樣可以提升交流品質。

### Strangler Pattern

這部份是探討系統的新架構如何替代舊功能。在新舊架構的迭代過程中，我們都希望系統可以如往常一樣正常運作。但是心架構一次到位的風險往往是非常高的，業務越複雜的系統越是如此。因此在這部份講者提出了幾個方案。

1. 新架構逐步替代舊架構，舊架構直到新架構完全替代後停止服務
2. 新架構逐步替代舊架構，舊架構直到新架構完全替代後繼續服務一段時間

我想會提出這兩的方案，主要是考慮到前幾年有保險公司一次換核心業務系統導致大量的金融損失有關。但是也是這一次的事件喚醒台灣資訊業界對於技術代迭是一項需要各方面人員評估測試的工作，不再是僅僅只有資訊團隊的任務。

## 如何有效地建構技術方案

這個議題主要是電商分享他們在雙十一購物節處理高流量、高併發的問題。

我相信：「處理高流量、高併發的問題」詳細是業界的技術機密！？不！因為各家的資訊廠商會面對的議題不一樣，所以相對應的技術也會不一樣。使用技術不是這個議題的重點，重點是如何找出使用技術的方式。

在他們尋找技術的過程中，講者歸納了幾項建議

1. 避免淺層思考
2. 對需求/問題，避免衝突所在
3. 找出核心問題
4. 找工具

講者提出一個例子：搶購優惠券。

需求是這樣的：使用者透過前台點擊購買優惠券，而優惠券是限量500張。

程式開發完後，他們進行壓力測試發現會出現超賣的現象。於是進行解決這個問題。

* sequence

有人提議用DB的sequence，但是DB太慢了，實測發現一個前端API發送後卻無法在8秒內獲得回應，原因是DB太慢了。很顯然這個方式不可行。因為哪個網路消費者願意等這久。

* 先平分給不同的實體服務

將票券分攤在不同的實體服務上進行搶購。這部份的細節我忘記了，但是我記得最後他們也沒有採這個方案。其實我一聽也不敢採這個方案，因為實體服務一旦掛掉，訂單如果來不及存到資料庫，這些訂單瞬間就沒了。

* 先收購後給票

這是我自己想的方式：每個實體服務先收集要購買的買家資訊(假設只接收一秒鐘)，接下來實體服務再將買家資料送給資料庫處理，等所有實體服務都送完成後，依接收到的時間順序、優先權等排序方式排隊買票，買完之後再把票券資訊回傳給買家。

由於時間的關係，講者也沒有細說他們如何面對這次的問題。在結果上他們這次還是超賣了。

面對失敗的原因，他們意識到或許他們見識到的技術不夠廣，導致他們無法在想出更好的原因。

## 玉山微心計畫

這個議題是玉山銀行分享他們核心系統重構的歷程。玉山重構主要的原因是，早期系統是整機式架構，主要程式語言是COBOL。其中使用的程式語言已經日漸少人會使用，漸漸的退出舞台。所以決定於2016年開始重構計畫。

考量到之前在就和新的維運及系統功能擴充不易，在未來的新系統發展會走微服務。

一開始他們是先逆向工程，進行系統分析至2018.08分析完畢開始開發，共費時約兩年。開發的過程中，有在考慮到為了因應未來的業務需求及成長，他們決定走容器化，並在2019.08進入測試，最後在2020.08進行核心系統上線。

### 決定系統未的決策-微服務

在走微服務的過程中，整個資訊技術團隊得先對微服務進行鋪路。其中講者的一句話讓我非常深刻：**沒有DevOps決不做微服務。**。因為以前整機式架構都是把所有的業務功能合併成一個系統，對於維運人員從開發人員拿到更新的程式只須上到唯一的系統中即可。但是導入微服務後，不同的服務可以是在同一個系統中或是不同的系統中。如果這時候維運人員與開發人員缺少溝通，可能會造成程式更新失敗、無法正確找出系統問題原因等等。

再來是定義「微服務」。先說我的定義就是「一大塊屎(主機/服務)分給許多小塊的屎(主機/服務)」，記得幾年前微服務剛熱起來時的經典笑話。回歸正題，講者的團隊在定義與時作微服務的過程中，提到幾個注意事項

1. 服務不是切越多越好

講者有提到，在切服務時，需要針對重點業務切出來就好，不必要將每項業務從原始服務切開，這樣容易造成日後開發/測試/維運 成本上升。

2. 無DevOps，不做微服務
1. CI/CD 監控成本上升
2. 維運/開發人員溝通成本上升，如果不導入自動化管理工具、測試工具，這樣只會增加人工成本。

3. 扁平化的服務依賴關係，例如：不要A 依賴 B 、 B 依賴 C

另外，在實做微服務的過程中，他們發現了一件金融界絕不容許發生的問題：交易一致性問題。因為在以前整機式架構中，資料的交易一致性不會發生，因為只有一台主機工作而已。還好在測試階段有獲得解決，但因為時間關係我無法得知最後的解決方式。不過這也是轉微服務的思考點，單機開發，多主機(容器)進行測試，才能在測試階段找出系統待運行上的問題。

### 開發前對未來系統的期許

* 轉換指標

系統轉換是風險非常高的工作，最輕有可能會影響使用者體驗，嚴重的可能會系統業務邏輯無法如期運作導致企業損失。所以在轉換之前需要針對系統的業務性質打造轉換指標。而講者的方向如下：

1. 穩定轉移
* 筆避免客戶流失
2. 整合精進
* 解決疊床架屋的問題
* 適當重構程式
3. 展望數位
* 迎合未來數位化需求

### 開發完成只是一個開始

* 穩定轉移關鍵

平行測試:新舊服務同時運作

開發完成真的只是一個開始。為了確保新系統如同就系統可以正常運作，講者在測試階段時採同時運行。過程是這樣的：一條API同時打向新舊服務，讓舊服務驗證新服務返回的結果是不是正確。

## 玉山銀行如何以 Flink 打造流批一體之數據中台

這場議題主要是探討玉山銀行是如何處理即時資訊。

### 技術關鍵詞

這個議題「大數據處理」對於我來說算是比較新穎，所以我先用技術關鍵詞的方式記錄下來，以便日後需要時可以方便尋找著手方向。

* Apache Flink
* 無限資料流(unbounded stream)
* 有限資料流(bounded stream)
* Apache Spark
* Apache Kafka
* Apache Hadoop
* Scala

### 定義

在演講的一開始，講者先將資訊流分成兩類:「有限資料流(有點忘了)」、「無限資料流」。

* 有限資料流(bounded stream):在一段時間線上，可以預期資訊流的時間起點與時間終點。
* 無限資料流(unbounded stream):在一段時間線上，無法預期資訊何時需要被處理。

在有限資料流處理上他們採用: Spark

在無限資料流處理上他們採用: Flink

### Flink 研究入門到放棄

在JavaConf 結束後我有試圖接觸這個技術，只能說資料處理領域真的水好深，我已經入門到放棄了。只好先放著這些資源有日需要再想起吧XDD

[Flink从入门到放弃(入门篇1)-Flink是什么](https://zhuanlan.zhihu.com/p/59193593)

[Flink 1.14.0 官方說明文件](https://nightlies.apache.org/flink/flink-docs-release-1.14/zh/docs/try-flink/local_installation/)

[Apache Flink 零基礎入門（一）：基礎概念解析](https://www.itread01.com/content/1566382803.html)

[Streaming data process with Apache Flink 系列](https://ithelp.ithome.com.tw/users/20105229/ironman/1708)

[准备Flink开发环境(2)-使用IntelliJ IDEA+Maven开发Flink项目](https://zhuanlan.zhihu.com/p/132356459)

會想要放棄研究的原因主要是和我未來想走得方向有差異，另外在 apache kafka 與 apache flink 這兩項服務之前，還得先學習scala 雖然我知道它是 JVM 基礎上的語言。

## 參考資料

[玉山徹底實現新核心計畫藍圖，打穩基礎後下一步是邁向場景金融](https://www.ithome.com.tw/news/144021)

[康威定律](https://zh.wikipedia.org/wiki/%E5%BA%B7%E5%A8%81%E5%AE%9A%E5%BE%8B)

[什麼是 DevOps？](https://aws.amazon.com/tw/devops/what-is-devops/)

[CI 從入門到入坑 系列-什麼是 DevOps ？](https://ithelp.ithome.com.tw/articles/10184557)