[心得] Agile Taipei - 微服務背後的基本能力

又是一場美好的Agile meetup!!
這次的主題和目前工作主軸比較有相關性，
又是近年來很夯的微服務，一看到報名開放就馬上報了!

這次的場地辦在宇匯知識科技，上網查了一下這間公司，
是台灣在地發展的大數據/AI的廣告投放商，是與Facebook/Google國際大牌的合作夥伴，
這聽起來真的超威的~~

微服務的第一步是什麼?

這次的分享者是該公司的首席架構師 - Kim Kao
(他個人謙虛的說因為只有一位架構師，所以是首席 XD)
他以一個問題詢問大家做為開場：
「一進公司，老闆就說要將現有的系統拆分成36個微服務，你會怎麼切?」
大家從不同角度試著回答，從業務需求去切、從不重要的服務開始切、從無狀態的服務開始切、看心情隨你切 ^^||
結果大家掉進了問題的陷阱，其實Kim心中的想法是要反問老闆，為什麼要切微服務?
「切微務是為了擴展公司業務，將業務功能切成36個小服務，當成許多小服務賣出去」
以此為目標，很明確了解切微服務的目的，是將這些小服務變成可賣出去的產品，
也因此，公司裡的開發團隊由20人逐步擴增至50人，來達成這個目標。
這其實就是start with why的具體實現，先問為什麼，才能做出真正要的東西，也才能創造真正的價值，吸引客戶上門。

這同時也給我一個當頭棒喝，當我們一頭栽進技術優先的思考時，我們總是先接受了「要做服務拆分，微服務化」，因為「微服務有水平擴展與高可用度的特性」，等等的這些技術能力，所以我們就直接進入了「要選擇把什麼服務開始切割呢?」，這完全是為了技術而技術啊...在微服務化的過程中，我們也常無法找到做這個的價值在哪，只能從技術去說明這可以達到balabala的能力，但實際上，能達到什麼獲利對公司有什麼幫助，其實還是講不出來。

微服務就是棒!?

微服務確實是有他不錯的特點，將服務切割至剛好的大小，可以獨立提供服務，讓業務邏輯集中化管理，讓系統不會因為龐大複雜而難以變動；反過來說，怎樣的服務才算是剛好呢? 真實世界裡的業務系統就是這麼的複雜，怎麼切割才是對的呢?  這些都是很難有答案命題。

切成多個小服務就是好的嗎?

• 多個小服務之間，就會有許多的溝通與流程串接
• 每個服務切小之後，會有各自的建置成本，像是AP/DB server本身的硬體與授權成本都會增加，但是...功能卻一樣，那有什麼理由叫老闆花錢投資?
• 身分認證服務會需要切出來，並且成為整個系統的重要節點，需要具備高可用度，也是很大的成本
• 如果服務愈長愈多，大家怎麼知道有哪些服務?
• 流程的執行就會出現服務異常的流程處理

Kim提到了林林總總的問題，搞得我也在思考到底為什麼要切微服務? 公司目前在走向微服務也的確是從技術下手，只希望變成跟上技術潮流的船，到處宣揚微服務的好處...

想清楚後，如何下手進行微服務

正當我開始懷疑這堂課是不是叫大家不要採用微服務的時候，Kim開始切入正題了(笑)

1. 先定義商業價值，才能決定怎麼切微服務
   這裡提到很重要的關鍵，就是先找到價值，才知道這樣切好不好，不過這在大部分公司應該都會是個大哉問，很難有答案也很難找到正確的人才討論
2. 採用API Gateway，來解決身分認證與服務發現的問題，算是便宜好用的解決方案
   API GW提供服務註冊功能，透過註冊來達成驗證的程序，可集中管理服務授權的議題；而上面揭露的服務，也是提供企業內部系統可互相發現彼此服務的管道，但回到服務管理的議題，服務揭露內容必須是被規範好的內容，若裡面充斥看不懂的資訊，那就沒什麼實質的效用了

persistence最後會變成瓶頸點，該怎麼辦?

說到最後，stateful的服務依賴的還是persistence。
傳統採用的Database仍是目前最主流的方案，但是其寫入能力是很難透過水平擴展的，目前市場能做到的只有Oracle/SQL Server和宇匯自己的RDS產品(幫打廣告)，但其價格都非常高貴。

替代方案可能是改用NoSQL，dynamoDB可能是便宜好用的選擇之一。
但要面臨的問題有兩個：

1. 是否有能力使用NoSQL? 資料的De-Normalize是很大的學問。
2. NoSQL的執行效能，像是查詢時要使用多種不同條件時，其實就需要多次的full scan，再將資料組裝起來，效能上會比較差

服務串接愈多，錯誤處理的流程愈複雜!?

當3種服務串接時，我們需要考慮：

1. 任1種服務出錯時的錯誤情境
2. 任2種服務出錯時的錯誤情境
3. 全部3種服務都出錯時的錯誤情境

當服務變成5個、10個串接時，要考慮的情境可就做不完啦!
以往在處理這塊議題，可以採用2 Phase Commit的方式，來確保錯誤處理的狀態回復。
不過，這類的服務也常成為效能瓶頸...

好在，出現了Saga這個方案，用編排的方式，串起服務歷程。
其概念是所有服務的呼叫，都是按照一個順序在執行的，所以透過event來驅動呼叫服務，當服務異常時，則可以按順序回復各服務的狀態，效能會比2 Phase Commit的方式來好得多!
而且其提供了獨立的外部仲裁服務，可以讓異常流程管理獨立於原程式之外，大幅提升了服務的獨立性。

怎麼擁抱微服務?

想採用微服務，一定要先找出價值，可以運用impact mapping的技術去分析。
講師也提出了DDD(Doamin Driven Design)的做法，以咖啡店為例，透過event storming來找出主要的業務關鍵：帶位、點餐、付款、製作、客人離開、清桌子
然後從這些關鍵業務找出event trigger，也就是對應的人：服務人員、客人、櫃台、咖啡師、清潔人員
最後找出most valuable/rsiky events，成為公司的業務重點。

DDD也是一門學問，再講下去就說不完了，真的是學海無涯啊!!!