30天的旅程到了尾聲，首先介紹了微服務的基本概念，然後利用小專案引入Steeltoe使用一些微服務的基本設施，接著用docker小小的打包了一下，勉強也算是有跑完dev的流程了(自以為)，實際上微服務是個非常大的題目包含開發、佈署跟營運，還有許多的基本設施像是CI/CD和其他的概念像是微服務的切割之類的。

微服務的切割

一般書上都會建議依照DDD也就是業務來切割，無奈小弟DDD那本書還沒有消化完，所以無法著墨，但是可以從前面的概念有一些可以考慮進去，微服務的解耦基本上是基於http或是message bus，如果切得太多太細，會消耗很多效能跟管理在各個服務上，尤其是分散式交易的部分複雜度會大幅提高，這也是一個anti-pattern叫nano service，
而切割的粒度太大又會失去微服務的解耦優勢、擴張性跟彈性。

而實務上的舊資料庫更難以切割，因為完全被SQL的transcation思維綁住，關於這部分的議題，個人極度推薦安德魯前輩在與大師對談的分享 https://www.facebook.com/andrew.blog.0928

微服務間的資料一致性 2-phase-commit, Event-sourcing, Saga pattern

這是實務上一定會遇到的問題，跨服務間的交易怎麼確保一致性，2-phase-commit可以較高的確保資料一致性，但是遇到跨三四個服務以上，就會遇到效能跟擴充的問題， 那是否Saga pattern跟Event Sourcing就是最佳的解法呢，還是從架構設計開始就確保可以使用2-phase-commit就好，這個部分上面的影片也有提到。

除了Steeloss框架的其他可能性

選擇SteeltoeOSS來做範例只是因為他整合比較多的服務在裡面，其他像是
Zookeeper: 可用於服務註冊還有負仔平衡
https://github.com/RabbitTeam/zookeeper-client
Ocelot: Api Gateway for .Net
https://github.com/TomPallister/Ocelot
Hystrix.Dotnet
https://github.com/Travix-International/Hystrix.Dotnet
或是使用kubernetes來取代一些服務也是可能的

還有一堆遺珠之憾

像是log紀錄與分析的ELK，Sagas pattern跟2-phase-commit的撰寫，都是接下來仍然要學習的地方

範例的程式碼本來想修一下在放的，但是短時間內應該沒辦法處理，就先放了，命名跟架構的部分就不要太苛求了..
https://github.com/Julian-Chu/MicroService_30Days
ps: 每個branch對應不同天數。

第一次鐵人賽心得，當然希望還有下次~

會參加鐵人賽真的只是一時興起，參加後才知道為什麼時間要安排在年底含跨年跟聖誕節，記得第四還是第五天就把僅有的一天緩衝就用完了，接下來每天的目標是怎麼在12點前想辦法生出一些東西，所以當天的內容都是在休息跟到家後的時間能擠多少是多少，想回頭修前面的文章都沒有時間，本來是有想一些規劃，後來在時間壓力下就放棄了，下次參加緩衝一定要多留一點.....希望30天的文章不只是我個人有所學習，也希望有對讀者的你們有所幫助的地方。

來年鐵人賽見!