1. Modern Web 2017
與會⼼心得分享
2017年年 9 ⽉月 20 ⽇日 PIXNET - Win
與架構設計當朋友

2. Modern Web
Architecture Design Journey
⽤用 Go 語⾔言
打造微服務架構
http://s.itho.me/modernweb/2017/day2/201-K1-Ant.pdf https://www.slideshare.net/mobile/appleboy/go-78757166

3. MODERN WEB ARCHITECTURE
DESIGN JOURNEY

4. 聊聊技術選型
你們怎麼做技術選型？

5. 技術選型
選擇對公司或團隊最佳的技術組合

6. 技術選型
選擇對公司或團隊最佳的技術組合
理理想上是這樣....

7. 技術選型
現實上是這樣....

8. 技術選型
多數情況由關鍵⼈人物決定偏好
e.g. CTO, 架構師 or 天降神兵
現實上是這樣....

9. 技術選型
天降神兵： .NET 不⾏行行，全部改 Java 。
天降神兵： PHP 開發太慢，全部改 RoR 。
天降神兵： AngularJS 沒⼈人⽤用，全部改 VueJS 。

10. 技術選型
天降神兵： .NET 不⾏行行，全部改 Java 。
天降神兵： PHP 開發太慢，全部改 RoR 。
天降神兵： AngularJS 沒⼈人⽤用，全部改 VueJS 。
這些決策未必錯，但問題是《為什什麼》
以及更更重要的是有無《讓⼈人信服的理理由》
戰語⾔言？ 戰框架？

11. PIXNET 的技術選型？

12. (好險) ⼯工程師尋求顧問⾃自⾏行行選型
PIXNET 的技術選型？

13. PIXNET 的技術選型？
(但) ⾃自⼰己的屎⾃自⼰己擦
(好險) ⼯工程師尋求顧問⾃自⾏行行選型

14. Fork From
M
odernW
eb
2016

15. Fork From
M
odernW
eb
2016

16. Fork From
M
odernW
eb
2016

17. 技術選型
Cost
Time to market
Flexibility

18. 技術選型
省 好
快

19. 技術選型 - 架構債
省 好
快
{有經驗的技術團隊}
喜歡採⽤用最新、最好、
最⼤大的架構
別迷失⾃自我

20. 技術選型 - 架構債
省 好
快
{⽋欠缺架構經驗的團隊}
•Non-reusable Code
•Non-HA
•NonScalability
•Legacy Code

21. 技術選型 - 架構債
省 好
快
{( 起初 ) 不缺錢的團隊}
Fund raising !
Burnout !?

22. 老闆選型 - ⽩白話⽂文
From: twMvc#30 | 技術⼈人員與業務團隊的無礙的溝通法則

23. 重構、架構轉型

24. 架構債

25. AGILE, SCRUM, KANBAN, DEVOPS, TDD, BDD, …

26. AGILE, SCRUM, KANBAN, DEVOPS, TDD, BDD, …
DRY
KISS
SOLID

27. AGILE, SCRUM, KANBAN, DEVOPS, TDD, BDD, …

28. 需求永遠是不明確的
但我們能做的是讓架構更更具彈性

29. 需求永遠是不明確的
但我們能做的是讓架構更更具彈性
Dependency inversion principle 依賴反轉原則

30. AGILE, SCRUM, KANBAN, DEVOPS, TDD, BDD, …
Trade-off

31. 微服務

32. Fork From
M
odernW
eb
2016

33. 會員
後台
會
員
中
⼼心
部落落格管理理 MIB
⼀一
帳
通
P I X N E T

34. ⽤用 GO 語⾔言
打造微服務架構

35. 但我們今天不講 GO

36. 那今天講
Microservices vs. Monolithic
拆分法則
導入代價
事前準備

37. Fork From
M
odernW
eb
2016

38. Why Monolithic
集中管理理
開發簡單
容易易上⼿手
除錯簡單

39. But Monolithic
開發效率低
不易易維護
不易易開發
穩定性差
不易易擴充

40. 專案複雜，團隊成長
需求變多

41. 專案複雜，團隊成長
還是我們聊聊 PIXLIBRARY?
註: PINXET 後端⼀一個極⼤大的共⽤用 Library

43. 開發效率低
1. 經常 git pull 確保版本最新
2. 真的衝突了了就先 … X
多⼈人開發容易易衝突

44. 不易易維護
1. 經常 git pull 確保版本最新
2. 真的衝突了了就先 … X
程式碼都在同⼀一包

45. 拆分微服務準則
依照業務區分
⾃自動化部署
⾼高度容錯
可快速置換
可獨立開發
容易易擴充

46. 代價
系統複雜度提升
資料⼀一致化
維運⼯工作複雜化 SA 表⽰示

47. 事前準備
快速建置 (Develop)
監控機制 (Monitor)
快速部署 (Deploy)

48. 微服務
Monolith First
沒有 CI / CD 請勿導入微服務

49. 微服務
Monolith First
沒有 CI / CD 請勿導入微服務
有沒有能⼒力力駕馭微服務？

50. 微服務
有沒有能⼒力力駕馭微服務？
Martin Fowler (ThoughtWorks 的⾸首席科學家 )
1. 成功微服務都是從過⼤大的單體拆分的
2. ⼀一開始就投入微服務的最後都遇到嚴重⿇麻煩
⼀一個網友提出的⾒見見解
當公司很⼩小時，除非技藝超群，否則不建議採⽤用微服務
當公司很⼤大時，採⽤用微服務有助於解耦

51. Fork From
M
odernW
eb
2016

53. 我的結語
思考各種架構實做的可能性
嘗試與隊友做善意的思想衝撞
預想是為了了讓你更更能應變突如其來來的需求
沒有完美的架構，但也不要對⾃自⼰己的架構沒信⼼心，
重點是你知道⾃自⼰己為何如此設計

54. Thank you.
– Win @ PIXNET
https://kylinyu.win

55. 花絮

57. 題外話
我在做投影片的時候發現這個 …..

58. 似乎 87 分像 ….
玩玩看⼤大會的，也玩玩看我的 (點圖傳送⾨門)