Successfully reported this slideshow.
Your SlideShare is downloading. ×

與設計架構當朋友

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 58 Ad
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (18)

Advertisement

Similar to 與設計架構當朋友 (20)

Advertisement

Recently uploaded (20)

與設計架構當朋友

  1. 1. Modern Web 2017 與會⼼心得分享 2017年年 9 ⽉月 20 ⽇日 PIXNET - Win 與架構設計當朋友
  2. 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. 3. MODERN WEB ARCHITECTURE DESIGN JOURNEY
  4. 4. 聊聊技術選型 你們怎麼做技術選型?
  5. 5. 技術選型 選擇對公司或團隊最佳的技術組合
  6. 6. 技術選型 選擇對公司或團隊最佳的技術組合 理理想上是這樣....
  7. 7. 技術選型 現實上是這樣....
  8. 8. 技術選型 多數情況由關鍵⼈人物決定偏好 e.g. CTO, 架構師 or 天降神兵 現實上是這樣....
  9. 9. 技術選型 天降神兵: .NET 不⾏行行,全部改 Java 。 天降神兵: PHP 開發太慢,全部改 RoR 。 天降神兵: AngularJS 沒⼈人⽤用,全部改 VueJS 。
  10. 10. 技術選型 天降神兵: .NET 不⾏行行,全部改 Java 。 天降神兵: PHP 開發太慢,全部改 RoR 。 天降神兵: AngularJS 沒⼈人⽤用,全部改 VueJS 。 這些決策未必錯,但問題是《為什什麼》 以及更更重要的是有無《讓⼈人信服的理理由》 戰語⾔言? 戰框架?
  11. 11. PIXNET 的技術選型?
  12. 12. (好險) ⼯工程師尋求顧問⾃自⾏行行選型 PIXNET 的技術選型?
  13. 13. PIXNET 的技術選型? (但) ⾃自⼰己的屎⾃自⼰己擦 (好險) ⼯工程師尋求顧問⾃自⾏行行選型
  14. 14. Fork From M odernW eb 2016
  15. 15. Fork From M odernW eb 2016
  16. 16. Fork From M odernW eb 2016
  17. 17. 技術選型 Cost Time to market Flexibility
  18. 18. 技術選型 省 好 快
  19. 19. 技術選型 - 架構債 省 好 快 {有經驗的技術團隊} 喜歡採⽤用最新、最好、 最⼤大的架構 別迷失⾃自我
  20. 20. 技術選型 - 架構債 省 好 快 {⽋欠缺架構經驗的團隊} •Non-reusable Code •Non-HA •NonScalability •Legacy Code
  21. 21. 技術選型 - 架構債 省 好 快 {( 起初 ) 不缺錢的團隊} Fund raising ! Burnout !?
  22. 22. 老闆選型 - ⽩白話⽂文 From: twMvc#30 | 技術⼈人員與業務團隊的無礙的溝通法則
  23. 23. 重構、架構轉型
  24. 24. 架構債
  25. 25. AGILE, SCRUM, KANBAN, DEVOPS, TDD, BDD, …
  26. 26. AGILE, SCRUM, KANBAN, DEVOPS, TDD, BDD, … DRY KISS SOLID
  27. 27. AGILE, SCRUM, KANBAN, DEVOPS, TDD, BDD, …
  28. 28. 需求永遠是不明確的 但我們能做的是讓架構更更具彈性
  29. 29. 需求永遠是不明確的 但我們能做的是讓架構更更具彈性 Dependency inversion principle 依賴反轉原則
  30. 30. AGILE, SCRUM, KANBAN, DEVOPS, TDD, BDD, … Trade-off
  31. 31. 微服務
  32. 32. Fork From M odernW eb 2016
  33. 33. 會員 後台 會 員 中 ⼼心 部落落格管理理 MIB ⼀一 帳 通 P I X N E T
  34. 34. ⽤用 GO 語⾔言
 打造微服務架構
  35. 35. 但我們今天不講 GO
  36. 36. 那今天講 Microservices vs. Monolithic 拆分法則 導入代價 事前準備
  37. 37. Fork From M odernW eb 2016
  38. 38. Why Monolithic 集中管理理 開發簡單 容易易上⼿手 除錯簡單
  39. 39. But Monolithic 開發效率低 不易易維護 不易易開發 穩定性差 不易易擴充
  40. 40. 專案複雜,團隊成長 需求變多
  41. 41. 專案複雜,團隊成長 還是我們聊聊 PIXLIBRARY? 註: PINXET 後端⼀一個極⼤大的共⽤用 Library
  42. 42. 開發效率低 1. 經常 git pull 確保版本最新 2. 真的衝突了了就先 … X 多⼈人開發容易易衝突
  43. 43. 不易易維護 1. 經常 git pull 確保版本最新 2. 真的衝突了了就先 … X 程式碼都在同⼀一包
  44. 44. 拆分微服務準則 依照業務區分 ⾃自動化部署 ⾼高度容錯 可快速置換 可獨立開發 容易易擴充
  45. 45. 代價 系統複雜度提升 資料⼀一致化 維運⼯工作複雜化 SA 表⽰示
  46. 46. 事前準備 快速建置 (Develop) 監控機制 (Monitor) 快速部署 (Deploy)
  47. 47. 微服務 Monolith First 沒有 CI / CD 請勿導入微服務
  48. 48. 微服務 Monolith First 沒有 CI / CD 請勿導入微服務 有沒有能⼒力力駕馭微服務?
  49. 49. 微服務 有沒有能⼒力力駕馭微服務? Martin Fowler (ThoughtWorks 的⾸首席科學家 ) 1. 成功微服務都是從過⼤大的單體拆分的 2. ⼀一開始就投入微服務的最後都遇到嚴重⿇麻煩 ⼀一個網友提出的⾒見見解
 當公司很⼩小時,除非技藝超群,否則不建議採⽤用微服務
 當公司很⼤大時,採⽤用微服務有助於解耦
  50. 50. Fork From M odernW eb 2016
  51. 51. 我的結語 思考各種架構實做的可能性 嘗試與隊友做善意的思想衝撞 預想是為了了讓你更更能應變突如其來來的需求 沒有完美的架構,但也不要對⾃自⼰己的架構沒信⼼心, 重點是你知道⾃自⼰己為何如此設計
  52. 52. Thank you. – Win @ PIXNET https://kylinyu.win
  53. 53. 花絮
  54. 54. 題外話 我在做投影片的時候發現這個 …..
  55. 55. 似乎 87 分像 …. 玩玩看⼤大會的,也玩玩看我的 (點圖傳送⾨門)

×