Slide 1

Slide 1 text

Modern Web Architecture Design Journey Ant [email protected] 2017-08-11

Slide 2

Slide 2 text

2/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 自介

Slide 3

Slide 3 text

3/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 自介 懂一點程式開發

Slide 4

Slide 4 text

4/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 自介 台灣駭客年會 2 次的演講經驗 待過 3 年資訊安全產業

Slide 5

Slide 5 text

5/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 自介 涉獵一點著作權、商標權及專利權 撰寫過數篇發明專利

Slide 6

Slide 6 text

6/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 目前負責四間新創公司的技術選型 協助數間友人新創公司的架構討論 無償 自介

Slide 7

Slide 7 text

7/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 目前負責四間新創公司的技術選型 協助數間友人新創公司的架構討論 無償 自介 血淚史

Slide 8

Slide 8 text

8/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 目前負責四間新創公司的技術選型 協助數間友人新創公司的架構討論 自介

Slide 9

Slide 9 text

9/120 技術選型 技術選型,選擇對公司或團隊最佳的技術組合

Slide 10

Slide 10 text

10/120 技術選型 技術選型,選擇對公司或團隊最佳的技術組合 理想

Slide 11

Slide 11 text

11/120 技術選型 所謂技術選型,大多數情況仍由關鍵人物決定偏好 例如 CTO 或架構師 現實

Slide 12

Slide 12 text

12/120 技術選型 所謂技術選型,大多數情況仍由關鍵人物決定偏好 例如 CTO 或架構師 現實 這是我遇過最多的抱怨!

Slide 13

Slide 13 text

13/120 技術選型 所謂技術選型,大多數情況仍由關鍵人物決定偏好 例如 CTO 或架構師 現實 很多人認為【空降神兵】能解決問題。 但有時解決的反而是《提出問題的人》。 公司內部?顧問?接案 / 外包?

Slide 14

Slide 14 text

14/120 技術選型 所謂技術選型,大多數情況仍由關鍵人物決定偏好 例如 CTO 或架構師 現實 天降神兵: .NET 不行,全部改 Java 。 天降神兵: PHP 開發太慢,全部改 RoR 。 天降神兵: AngularJS 沒人用,全部改 VueJS 。 這些決策未必錯,但問題是《為什麼》 以及更重要的:有無《信服人的理由》

Slide 15

Slide 15 text

15/120 偶爾任性是可愛,一天到晚任性是妖孽 ~ ANT ~

Slide 16

Slide 16 text

16/120 ➊ 架構先決 無視人員、流程只講技術,是耍性子 架構會影響公司文化、商業擴展;思維更要超越程式碼層次 CTO/ 架構師不該只懂技術

Slide 17

Slide 17 text

17/120 ➋ 沒有完美的架構,只有最適的架構 無視場景只講架構,是耍流氓 若無法舉出架構的缺陷,代表你還無法掌握 盲目套用別人的架構,並不會讓你變得跟他一樣好 沒有一個架構能適用所有場景

Slide 18

Slide 18 text

18/120 ➌ 架構是演進的,預想但不過早調優 無視未來只求急行軍,是耍短視 兵馬未動,糧草先行,預想下一步,下下一步,甚至下下下一步 ... 歡迎進入八奇的思考領域

Slide 19

Slide 19 text

19/120 Cost reduction Flexibility Time to market Business debt Premature debt Scalability debt Optimum

Slide 20

Slide 20 text

20/120 Cost reduction Flexibility Time to market Business debt Premature debt Scalability debt Optimum 省 好 快

Slide 21

Slide 21 text

21/120 Cost reduction Flexibility Time to market Business debt Premature debt Scalability debt Optimum Architectural debt { } 省 好 快 架構債

Slide 22

Slide 22 text

22/120 有經驗的技術團隊

Slide 23

Slide 23 text

23/120 有經驗的技術團隊 喜歡採用最新、最好、最大的架構

Slide 24

Slide 24 text

24/120 You Are Not Google Facebook Amazon 別為了高大尚,而迷失自我

Slide 25

Slide 25 text

25/120 欠缺架構經驗的團隊

Slide 26

Slide 26 text

26/120 Non-reusable Code Non-HA / NonScalability Legacy Code 債築債 問題

Slide 27

Slide 27 text

27/120 ( 起初 ) 不缺錢的團隊

Slide 28

Slide 28 text

28/120 Fund raising ! or Burnout !? 利逐債 奔耗

Slide 29

Slide 29 text

29/120 Cost reduction Flexibility Time to market Business debt Premature debt Scalability debt Optimum Architectural debt

Slide 30

Slide 30 text

30/120 Cost reduction Flexibility Time to market Business debt Premature debt Scalability debt Optimum 延展性不足以支撐業務成長 架構升級積重難返 約束 ( 硬限制 ) 未滿足 Architectural debt 徵兆

Slide 31

Slide 31 text

31/120 救世主 ?

Slide 32

Slide 32 text

32/120

Slide 33

Slide 33 text

33/120 Agile? 敏捷教練?

Slide 34

Slide 34 text

34/120 Architect? 架構師? Agile? 敏捷教練?

Slide 35

Slide 35 text

35/120 Agile Architect Agile 與 Architect 是有交集的

Slide 36

Slide 36 text

36/120 Good architecture brings agility 好的架構帶來敏捷 - Saugatuck -

Slide 37

Slide 37 text

37/120 Minimum Viable Product 最小可行產品

Slide 38

Slide 38 text

38/120 MVP 若沒有控制好,技術債將迅速增長 Minimum Viable Product 先前程式少能復用 遺舊程式難以去除 架構變動牽扯不清 最小可行產品

Slide 39

Slide 39 text

39/120 E = mc2

Slide 40

Slide 40 text

40/120 E = mc2 Errors = (more code) 2

Slide 41

Slide 41 text

41/120 E = mc2 錯誤隨著程式碼數量呈平方次成長 Errors = (more code) 2

Slide 42

Slide 42 text

42/120 最後廢碼定理 程式廢碼產生的速率,隨著接近專案最後死線呈等比倍增

Slide 43

Slide 43 text

43/120 真相只有一個,但死相可以有很多個 ~ ANT ~

Slide 44

Slide 44 text

44/120 Minimum Viable Product Debt Time Debt Ceiling 理想與現實 Debt Baseline

Slide 45

Slide 45 text

45/120 Minimum Viable Product Debt Time Debt Ceiling 理想與現實 理想 Debt Baseline

Slide 46

Slide 46 text

46/120 Debt Time Debt Ceiling Minimum Viable Product 理想與現實 現實 Debt Baseline

Slide 47

Slide 47 text

47/120 Debt Time Debt Ceiling Minimum Viable Product Pivot? 理想與現實 現實 Debt Baseline Pivot? Pivot?

Slide 48

Slide 48 text

48/120 Pivot 聽起來很稀鬆平常,就像放屁一樣,但只有蠟筆小新放屁會飛 ~ Ricky Chen ~

Slide 49

Slide 49 text

49/120 Minimum Viable Product 市場驗證成功後,我再拿投資人的錢來技術轉型就好了。 大家可能聽過一些說法: 事實上,迅速成長的公司,沒太多時間進行技術轉型。 再加上之前為了快速驗證 MVP 所遺留的技術債。 只會讓技術轉型變得遙不可及。

Slide 50

Slide 50 text

50/120 Minimum Viable Product 現有團隊不行,我砸錢找大神 ( 大牛 ) 重構系統總可以吧。 於是:

Slide 51

Slide 51 text

51/120 Minimum Viable Product 強烈的既視感?

Slide 52

Slide 52 text

52/120 更重要的是 有考慮過大神 ( 大牛 ) 的感受嗎? 架構重構是個苦工,很多時候他們也是千百個不願意

Slide 53

Slide 53 text

53/120 空中換引擎 落地換引擎 技術難度高。 但迅速成長的公司,仍然有很多需求待開發。 同時還要處理累積的技術債,很可能因債築債而嚴重惡化。 技術難度低。 但商業模式是否能夠允許新功能推進緩慢或無進展? 空中小修 地面重建 資源投入巨大。 不是現行團隊拆分戰力,就是要另招一批團隊開發新引擎。 但若問題本質不解決,新引擎未來也會遭遇一樣的問題。

Slide 54

Slide 54 text

54/120 架構債 非技術上 技術上

Slide 55

Slide 55 text

55/120 架構債 非技術上 技術上 需求的坑

Slide 56

Slide 56 text

56/120 架構債 非技術上 技術上 需求的坑 程式的坑

Slide 57

Slide 57 text

57/120 架構債 非技術上 技術上 需求的坑 程式的坑

Slide 58

Slide 58 text

58/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑

Slide 59

Slide 59 text

59/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑 { Agile, Scrum, Kanban, DevOps, TDD, BDD, ...

Slide 60

Slide 60 text

60/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑 { Conceptual Integrity Conceptual debt Agile, Scrum, Kanban, DevOps, TDD, BDD, ... ( 概念完整性 )

Slide 61

Slide 61 text

61/120 架構之始,在於需求 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑

Slide 62

Slide 62 text

62/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑 我以為你知道! 這本來就是要的,只是我忘了講! 我要的不是這樣! 我要的你應該要替我想到,我又不懂技術 你沒跟我說過。 怪我囉。 可是需求書是這樣 / 需求書不明確 你 !!! 出了問題時 需求方 開發方

Slide 63

Slide 63 text

63/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑 我以為你知道! 這本來就是要的,只是我忘了講! 我要的不是這樣! 我要的你應該要替我想到,我又不懂技術 你沒跟我說過。 怪我囉。 可是需求書是這樣 / 需求書不明確 你 !!! 程式還是要趕, 班還是照加。 出了問題時 需求方 開發方

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

65/120 需求永遠是不明確的 但我們能做的是讓架構更具彈性 被動 主動 需求方 開發方 需求方 開發方

Slide 66

Slide 66 text

66/120 被動 主動 Dependency inversion principle 依賴反轉原則 需求方 開發方 需求方 開發方 需求永遠是不明確的 但我們能做的是讓架構更具彈性

Slide 67

Slide 67 text

Modern Web 2016 恰如其分的 MySQL 設計技巧 Ant [email protected] 2016-08-24 引用去年簡報

Slide 68

Slide 68 text

68/120 Business License Elastic business Workload Technology Scale-up Application Connection Database File system OS Kernel Hardware Scale-out Replication Clustering Sharding Disaster Recovery Multi Regional Resiliency CONSILIENCE Architecture and more ... 引用去年簡報

Slide 69

Slide 69 text

69/120 當業務需求變更程式設計時 預想但不過早調優 總工程師不該把每次新需求都認為獨立需求 ( 多想二分鐘,團隊可以不必自虐 ) Elastic business 引用去年簡報

Slide 70

Slide 70 text

70/120 預想但不過早調優

Slide 71

Slide 71 text

71/120 Premature optimization is the root of all evil. 過早最佳化是萬惡的根源

Slide 72

Slide 72 text

72/120 Premature optimization is the root of all evil. 過早最佳化是萬惡的根源 手拿菜刀砍電線,一路火花帶閃電

Slide 73

Slide 73 text

73/120 Premature optimization is the root of all evil. 過早最佳化是萬惡的根源 手拿菜刀砍電線,一路火花帶閃電

Slide 74

Slide 74 text

74/120 We should forget about small efficiencies, say about 97% of the time: Premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Slide 75

Slide 75 text

75/120 We should forget about small efficiencies, say about 97% of the time: Premature (micro) optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Slide 76

Slide 76 text

76/120 Premature (micro) optimization is the root of all evil. Do some { Architectural optimizations, Algorithms, … } early.

Slide 77

Slide 77 text

77/120 Premature (micro) optimization is the root of all evil. Do some { Architectural optimizations, Algorithms, … } early. 程式與架構需懂得區分 【架構】異動會牽扯組件邊界,影響巨大

Slide 78

Slide 78 text

78/120 Premature (micro) optimization is the root of all evil. Do some { Architectural optimizations, Algorithms, … } early. 即未來需求變更時,屬程式異動,還是架構異動? 程式與架構需懂得區分 【架構】異動會牽扯組件邊界,影響巨大 簡言之,如果需求發生異動,需花多久時間滿足?

Slide 79

Slide 79 text

79/120 狀態 原表格設計 Elastic business id name ... is_deleted 1 Apple ... 0 2 Banana ... 1 引用去年簡報

Slide 80

Slide 80 text

80/120 狀態 新業務需要儲存「鎖定」狀態 Elastic business id name ... is_deleted 1 Apple ... 0 2 Banana ... 1 id name ... is_deleted is_locked 1 Apple ... 0 1 2 Banana ... 1 0 引用去年簡報

Slide 81

Slide 81 text

81/120 狀態 其實若狀態是沒交集的,則可以合併 Elastic business id name ... status 1 Apple ... 2 2 Banana ... 0 id name ... is_deleted is_locked 1 Apple ... 0 1 2 Banana ... 1 0 { 0: deleted, 1: enabled, 2: locked } 引用去年簡報

Slide 82

Slide 82 text

82/120 標籤雲 原表格設計 Elastic business id name tag1 1 Apple admin 2 Banana reporter 3 Cherry reporter SELECT * FROM {Table} WHERE tag1 = ‘admin’ 引用去年簡報

Slide 83

Slide 83 text

83/120 標籤雲 新增標籤 Elastic business id name tag1 tag2 tag3 1 Apple admin reporter programmer 2 Banana reporter programmer NULL 3 Cherry reporter admin NULL SELECT * FROM {Table} WHERE (tag1 = ‘admin’ OR tag2 = ‘admin’ OR tag3 = ‘admin’) AND (tag1 = ‘reporter’ OR tag2 = ‘reporter’ OR tag3 = ‘reporter’) SELECT * FROM {Table} WHERE ‘admin’ IN (tag1, tag2, tag3) AND ‘reporter’ IN (tag1, tag2, tag3) ALTER TABLE !! 引用去年簡報

Slide 84

Slide 84 text

84/120 Tag Elastic business id tag 1 admin 1 reporter 1 programmer 2 reporter ... ... 新增標籤 ( 另他法 ) 標籤雲 id name X X X 1 Apple X X X 2 Banana X X X SELECT * FROM {Table} INNER JOIN ‘Tag’ AS t1 USING (id) INNER JOIN ‘Tag’ AS t2 USING (id) WHERE t1.tag = ‘admin’ AND t2.tag = ‘reporter’ 引用去年簡報

Slide 85

Slide 85 text

85/120 Elastic business 或是 M:N 標籤雲 id name 1 Apple 2 Banana id tag_id 1 1 1 2 1 3 2 2 2 3 tag_id name 1 admin 2 reporter 3 programmer 引用去年簡報

Slide 86

Slide 86 text

86/120 Elastic business 廣告需求 營運有新的需求,受眾在 一天內不要看到相同廣告。 瞭解,預計一個工作天。 第一天 引用去年簡報

Slide 87

Slide 87 text

87/120 Elastic business 廣告需求 營運有新的需求,受眾在 小時內不要看到相同廣告。 瞭解,預計二個工作天。 第二天 時間粒度不同 引用去年簡報

Slide 88

Slide 88 text

88/120 Elastic business 廣告需求 營運有新的需求,受眾在 一天內不要看到同類廣告。 瞭解,預計八個工作天。 第三天 目標粒度不同 不能一次講清楚嗎? 引用去年簡報

Slide 89

Slide 89 text

89/120 Elastic business 廣告需求 受眾在 M 時間內不要看到 N 廣告 預想 該需求的延伸會是什麼? M → 年 / 季 / 月 / 週 / 時 / 分 / 秒 N → 相同 / 同類 看到的次數? 1/2/3... 裝置有別? 區域? 廣告主屬性? 引用去年簡報

Slide 90

Slide 90 text

90/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑 KISS(Keep it simple, stupid!) DRY(Don't repeat yourself) SOLID Principles ... 略過

Slide 91

Slide 91 text

91/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑 設計:權衡需求與實現的藝術

Slide 92

Slide 92 text

92/120 Business License Elastic business Workload Technology Scale-up Application Connection Database File system OS Kernel Hardware Scale-out Replication Clustering Sharding Disaster Recovery Multi Regional Resiliency CONSILIENCE Architecture and more ... 引用去年簡報

Slide 93

Slide 93 text

93/120 Workload Processing Intensive Capacity CPU intensive Memory intensive Storage/IO intensive Bandwidth intensive OLTP OLAP Data warehouse Throughput Latency Memory footprint Service-level agreement Bond Performance Security Cost restriction 引用去年簡報

Slide 94

Slide 94 text

94/120 Workload Processing Intensive Capacity CPU intensive Memory intensive Storage/IO intensive Bandwidth intensive OLTP OLAP Data warehouse Throughput Latency Memory footprint Service-level agreement Bond Performance Security Cost restriction 引用去年簡報

Slide 95

Slide 95 text

95/120 Workload Capacity Latency Memory footprint Trade-off Throughput 引用去年簡報

Slide 96

Slide 96 text

96/120 Workload Capacity High throughput Low latency 引用去年簡報

Slide 97

Slide 97 text

97/120 Workload Capacity High throughput Low latency 重點在於找出需求的【硬限制】 引用去年簡報

Slide 98

Slide 98 text

98/120 遇到瓶頸還不是最慘,慘得是過了瓶頸,還有瓶蓋 ~ Anonymous ~

Slide 99

Slide 99 text

99/120 2015 千萬人同時在線 電子商務、線上出版媒體 低延遲回應 廣告平台 RTB(30ms) 高頻交易 (0.5~3ms) 多人線上遊戲 (30fps: 100~150ms, 60fps: 60~70ms) 醫療等關鍵設備

Slide 100

Slide 100 text

100/120 Workload Capacity Low latency 非指 PHP 無法做到低延遲 ( 例如 30ms) ,而是 我們願意 ( 只能 ) 花多少資源 ( 資金硬限制 ) ,以及 我們手中工程師的數量與實力 ( 人力硬限制 ) 。 很多事情 ( 例如 latency) 不是靠 Scale Out 能解決 高手人數?訓練成本?

Slide 101

Slide 101 text

101/120 Workload Capacity Low latency 此時, PHP 相較 C/C++/Go 通常會更辛苦。 伺服器規格需求較高?較多? 工程師技能要求較高? 徵聘更強的工程師? 案主:不好意思,我只能給你兩台一般的伺服器 PHP Extension ? Swoole ?奇技淫巧?未來徵人的訓練成本? 高手為什麼要來?有無足夠的產品吸引力?足夠的給薪條件?

Slide 102

Slide 102 text

102/120 Ref: http://eugenedvorkin.com/seven-micro-services-architecture-advantages/

Slide 103

Slide 103 text

103/120 Monolith Microservices SOA Nanoservices Picoservices SOA

Slide 104

Slide 104 text

104/120 Monolith Microservices SOA Nanoservices Picoservices SOA 有沒有能力駕馭微服務、奈米服務、微微服務?

Slide 105

Slide 105 text

105/120 MonolithFirst 《單體》優先的技術選型 ~ Martin Fowler (ThoughtWorks 的首席科學家 ) ~ Ref: https://martinfowler.com/bliki/MonolithFirst.html 對於《微服務》,他注意到了這兩種問題, ➊ 幾乎所有成功的微服務案例,都是從過大的《單體》拆分的。 ➋ 幾乎所有他見過一開始就投入《微服務》的案例,最後都遭遇嚴重麻煩。

Slide 106

Slide 106 text

106/120 MonolithFirst 網友提出不同見解 ~ krisdol ~ Ref: https://news.ycombinator.com/item?id=9652893 Fowler 遇到的案例都是出問題的公司。 ThoughtWorks 是一家顧問公司, 也就是說,他們會在某個公司出現問題時提供幫助。 簡言之, Fowler 所見都是不對的組織採用了錯誤的架構,也就是他會見到 一開始採用《微服務》而失敗的公司,但不會見到成功的。

Slide 107

Slide 107 text

107/120 MonolithFirst 網友提出不同見解 ~ room271 ~ Ref: https://news.ycombinator.com/item?id=9652893 當你是顧問時,一開始很容易提倡採用《單體》,因為你會在《單體》出現 問題前,就已經完成專案離開了。 已有兩年《微服務》經驗的他,提出了兩個見解: ➊ 當公司或團隊很小時,除非你們技藝超群,否則不建議採用《微服務》。 ➋ 當公司或團隊很大時,採用《微服務》有助於解隅組織並促進敏捷。

Slide 108

Slide 108 text

108/120 Ref: https://www.slideshare.net/ufried/towards-complex-adaptive-architectures (p37) 組織會影響架構

Slide 109

Slide 109 text

109/120 Monolith Microservices SOA Nanoservices Picoservices SOA

Slide 110

Slide 110 text

110/120 救世主 ?

Slide 111

Slide 111 text

111/120

Slide 112

Slide 112 text

112/120 Serverless Serverless ≠ Architectureless

Slide 113

Slide 113 text

113/120 Serverless Serverless ≠ Architectureless Ref: https://martinfowler.com/articles/serverless.html

Slide 114

Slide 114 text

114/120 Serverless Serverless ≠ Architectureless Ref: https://aws.amazon.com/serverless/

Slide 115

Slide 115 text

115/120 ➊ 架構先決 ➋ 沒有完美的架構,只有最適的架構 ➌ 架構是演進的,預想但不過早調優

Slide 116

Slide 116 text

116/120 Sacrificial Architecture ( 犧牲的架構 ) ~ Martin Fowler ~ 即使捨棄現有架構,重構組件新架構,也未必是一件失敗的事 重點是【為什麼】、【新架構怎麼執行】及【何時執行】 簡言之,如果清楚明白打掉重練比較好,就勇敢執行吧! Ref: http://www.infoq.com/news/2014/11/sacrificial-architecture

Slide 117

Slide 117 text

117/120 Sacrificial Architecture ( 犧牲的架構 ) ~ Martin Fowler ~ 即使捨棄現有架構,重構組件新架構,也未必是一件失敗的事 重點是【為什麼】、【新架構怎麼執行】及【何時執行】 簡言之,如果清楚明白打掉重練比較好,就勇敢執行吧! Ref: http://www.infoq.com/news/2014/11/sacrificial-architecture 但免不了的,還是要面臨這些問題

Slide 118

Slide 118 text

118/120 空中換引擎 落地換引擎 技術難度高。 但迅速成長的公司,仍然有很多需求待開發。 同時還要處理累積的技術債,很可能因債築債而嚴重惡化。 技術難度低。 但商業模式是否能夠允許新功能推進緩慢或無進展? 空中小修 地面重建 資源投入巨大。 不是現行團隊拆分戰力,就是要另招一批團隊開發新引擎。 但若問題本質不解決,新引擎未來也會遭遇一樣的問題。

Slide 119

Slide 119 text

119/120 共 勉 之

Slide 120

Slide 120 text

120/120 [email protected] https://www.facebook.com/yftzeng.tw