Modern Web Architecture Design Journey
1 like642 views
本文件讨论现代网络架构设计的旅程，涵盖了技术选型的决策过程及其对公司文化的影响。强调技术架构并非一成不变，需根据场景不断演进，同时提到技术债务和需求变化对架构的挑战。最后，指出在快速发展的公司中，需平衡技术转型与现有团队的能力。
Modern Web Architecture Design Journey
- 1. Modern Web Architecture Design Journey Ant yftzeng@gmail.com 2017-08-11
- 2. 2/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 自介
- 3. 3/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 自介 懂一點程式開發
- 4. 4/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 自介 台灣駭客年會 2 次的演講經驗 待過 3 年資訊安全產業
- 5. 5/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 自介 涉獵一點著作權、商標權及專利權 撰寫過數篇發明專利
- 6. 6/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 目前負責四間新創公司的技術選型 協助數間友人新創公司的架構討論 無償 自介
- 7. 7/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 目前負責四間新創公司的技術選型 協助數間友人新創公司的架構討論 無償 自介 血淚史
- 8. 8/120 程式開發 X 資訊安全 X 智慧財產權 X 創業 目前負責四間新創公司的技術選型 協助數間友人新創公司的架構討論 自介
- 13. 13/120 技術選型 所謂技術選型，大多數情況仍由關鍵人物決定偏好 例如 CTO 或架構師 現實 很多人認為【空降神兵】能解決問題。 但有時解決的反而是《提出問題的人》。 公司內部？顧問？接案 / 外包？
- 14. 14/120 技術選型 所謂技術選型，大多數情況仍由關鍵人物決定偏好 例如 CTO 或架構師 現實 天降神兵： .NET 不行，全部改 Java 。 天降神兵： PHP 開發太慢，全部改 RoR 。 天降神兵： AngularJS 沒人用，全部改 VueJS 。 這些決策未必錯，但問題是《為什麼》 以及更重要的：有無《信服人的理由》
- 21. 21/120 Cost reduction Flexibility Time to market Business debt Premature debt Scalability debt Optimum Architectural debt { } 省 好 快 架構債
- 22. 22/120 有經驗的技術團隊
- 24. 24/120 You Are Not Google Facebook Amazon 別為了高大尚，而迷失自我
- 25. 25/120 欠缺架構經驗的團隊
- 26. 26/120 Non-reusable Code Non-HA / NonScalability Legacy Code 債築債 問題
- 27. 27/120 ( 起初 ) 不缺錢的團隊
- 28. 28/120 Fund raising ! or Burnout !? 利逐債 奔耗
- 29. 29/120 Cost reduction Flexibility Time to market Business debt Premature debt Scalability debt Optimum Architectural debt
- 30. 30/120 Cost reduction Flexibility Time to market Business debt Premature debt Scalability debt Optimum 延展性不足以支撐業務成長 架構升級積重難返 約束 ( 硬限制 ) 未滿足 Architectural debt 徵兆
- 31. 31/120 救世主 ?
- 32. 32/120
- 35. 35/120 Agile Architect Agile 與 Architect 是有交集的
- 36. 36/120 Good architecture brings agility 好的架構帶來敏捷 - Saugatuck -
- 38. 38/120 MVP 若沒有控制好，技術債將迅速增長 Minimum Viable Product 先前程式少能復用 遺舊程式難以去除 架構變動牽扯不清 最小可行產品
- 39. 39/120 E = mc 2
- 40. 40/120 E = mc 2 Errors = (more code) 2
- 41. 41/120 E = mc 2 錯誤隨著程式碼數量呈平方次成長 Errors = (more code) 2
- 44. 44/120 Minimum Viable Product Debt Time Debt Ceiling 理想與現實 Debt Baseline
- 45. 45/120 Minimum Viable Product Debt Time Debt Ceiling 理想與現實 理想 Debt Baseline
- 46. 46/120 Debt Time Debt Ceiling Minimum Viable Product 理想與現實 現實 Debt Baseline
- 47. 47/120 Debt Time Debt Ceiling Minimum Viable Product Pivot? 理想與現實 現實 Debt Baseline Pivot? Pivot?
- 49. 49/120 Minimum Viable Product 市場驗證成功後，我再拿投資人的錢來技術轉型就好了。 大家可能聽過一些說法： 事實上，迅速成長的公司，沒太多時間進行技術轉型。 再加上之前為了快速驗證 MVP 所遺留的技術債。 只會讓技術轉型變得遙不可及。
- 50. 50/120 Minimum Viable Product 現有團隊不行，我砸錢找大神 ( 大牛 ) 重構系統總可以吧。 於是：
- 52. 52/120 更重要的是 有考慮過大神 ( 大牛 ) 的感受嗎？ 架構重構是個苦工，很多時候他們也是千百個不願意
- 58. 58/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑
- 59. 59/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑{ Agile, Scrum, Kanban, DevOps, TDD, BDD, ...
- 60. 60/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑{ Conceptual Integrity Conceptual debt Agile, Scrum, Kanban, DevOps, TDD, BDD, ... ( 概念完整性 )
- 62. 62/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑 我以為你知道！ 這本來就是要的，只是我忘了講！ 我要的不是這樣！ 我要的你應該要替我想到，我又不懂技術 你沒跟我說過。 怪我囉。 可是需求書是這樣 / 需求書不明確 你 !!! 出了問題時 需求方 開發方
- 63. 63/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑 我以為你知道！ 這本來就是要的，只是我忘了講！ 我要的不是這樣！ 我要的你應該要替我想到，我又不懂技術 你沒跟我說過。 怪我囉。 可是需求書是這樣 / 需求書不明確 你 !!! 程式還是要趕， 班還是照加。 出了問題時 需求方 開發方
- 65. 65/120 需求永遠是不明確的 但我們能做的是讓架構更具彈性 被動 主動 需求方 開發方 需求方 開發方
- 66. 66/120 被動 主動 Dependency inversion principle 依賴反轉原則 需求方 開發方 需求方 開發方 需求永遠是不明確的 但我們能做的是讓架構更具彈性
- 67. Modern Web 2016 恰如其分的 MySQL 設計技巧 Ant yftzeng@gmail.com 2016-08-24 引用去年簡報
- 68. 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 ... 引用去年簡報
- 69. 69/120 當業務需求變更程式設計時 預想但不過早調優 總工程師不該把每次新需求都認為獨立需求 ( 多想二分鐘，團隊可以不必自虐 ) Elastic business引用去年簡報
- 70. 70/120 預想但不過早調優
- 71. 71/120 Premature optimization is the root of all evil. 過早最佳化是萬惡的根源
- 72. 72/120 Premature optimization is the root of all evil. 過早最佳化是萬惡的根源 手拿菜刀砍電線，一路火花帶閃電
- 73. 73/120 Premature optimization is the root of all evil. 過早最佳化是萬惡的根源 手拿菜刀砍電線，一路火花帶閃電
- 74. 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%.
- 75. 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%.
- 76. 76/120 Premature (micro) optimization is the root of all evil. Do some { Architectural optimizations, Algorithms, … } early.
- 77. 77/120 Premature (micro) optimization is the root of all evil. Do some { Architectural optimizations, Algorithms, … } early. 程式與架構需懂得區分 【架構】異動會牽扯組件邊界，影響巨大
- 78. 78/120 Premature (micro) optimization is the root of all evil. Do some { Architectural optimizations, Algorithms, … } early. 即未來需求變更時，屬程式異動，還是架構異動？ 程式與架構需懂得區分 【架構】異動會牽扯組件邊界，影響巨大 簡言之，如果需求發生異動，需花多久時間滿足？
- 79. 79/120 狀態 原表格設計 Elastic business id name ... is_deleted 1 Apple ... 0 2 Banana ... 1 引用去年簡報
- 80. 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 引用去年簡報
- 81. 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 } 引用去年簡報
- 82. 82/120 標籤雲 原表格設計 Elastic business id name tag1 1 Apple admin 2 Banana reporter 3 Cherry reporter SELECT * FROM {Table} WHERE tag1 = ‘admin’ 引用去年簡報
- 83. 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 !! 引用去年簡報
- 84. 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’ 引用去年簡報
- 85. 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 引用去年簡報
- 89. 89/120 Elastic business 廣告需求 受眾在 M 時間內不要看到 N 廣告 預想 該需求的延伸會是什麼？ M → 年 / 季 / 月 / 週 / 時 / 分 / 秒 N → 相同 / 同類 看到的次數？ 1/2/3... 裝置有別？ 區域？ 廣告主屬性？ 引用去年簡報
- 90. 90/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑 KISS(Keep it simple, stupid!) DRY(Don't repeat yourself) SOLID Principles ... 略過
- 91. 91/120 架構債 非技術上 技術上 需求的坑 設計的坑 程式的坑 設計：權衡需求與實現的藝術
- 92. 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 ... 引用去年簡報
- 93. 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 引用去年簡報
- 94. 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 引用去年簡報
- 96. 96/120 Workload Capacity High throughput Low latency 引用去年簡報
- 97. 97/120 Workload Capacity High throughput Low latency 重點在於找出需求的【硬限制】 引用去年簡報
- 99. 99/120 2015 千萬人同時在線 電子商務、線上出版媒體 低延遲回應 廣告平台 RTB(30ms) 高頻交易 (0.5~3ms) 多人線上遊戲 (30fps: 100~150ms, 60fps: 60~70ms) 醫療等關鍵設備
- 100. 100/120 Workload Capacity Low latency 非指 PHP 無法做到低延遲 ( 例如 30ms) ，而是 我們願意 ( 只能 ) 花多少資源 ( 資金硬限制 ) ，以及 我們手中工程師的數量與實力 ( 人力硬限制 ) 。 很多事情 ( 例如 latency) 不是靠 Scale Out 能解決 高手人數？訓練成本？
- 101. 101/120 Workload Capacity Low latency 此時， PHP 相較 C/C++/Go 通常會更辛苦。 伺服器規格需求較高？較多？ 工程師技能要求較高？ 徵聘更強的工程師？ 案主：不好意思，我只能給你兩台一般的伺服器 PHP Extension ？ Swoole ？奇技淫巧？未來徵人的訓練成本？ 高手為什麼要來？有無足夠的產品吸引力？足夠的給薪條件？
- 102. 102/120 Ref: http://eugenedvorkin.com/seven-micro-services-architecture-advantages/
- 105. 105/120 MonolithFirst 《單體》優先的技術選型 ~ Martin Fowler (ThoughtWorks 的首席科學家 ) ~ Ref: https://martinfowler.com/bliki/MonolithFirst.html 對於《微服務》，他注意到了這兩種問題， ➊ 幾乎所有成功的微服務案例，都是從過大的《單體》拆分的。 ➋ 幾乎所有他見過一開始就投入《微服務》的案例，最後都遭遇嚴重麻煩。
- 106. 106/120 MonolithFirst 網友提出不同見解 ~ krisdol ~ Ref: https://news.ycombinator.com/item?id=9652893 Fowler 遇到的案例都是出問題的公司。 ThoughtWorks 是一家顧問公司， 也就是說，他們會在某個公司出現問題時提供幫助。 簡言之， Fowler 所見都是不對的組織採用了錯誤的架構，也就是他會見到 一開始採用《微服務》而失敗的公司，但不會見到成功的。
- 107. 107/120 MonolithFirst 網友提出不同見解 ~ room271 ~ Ref: https://news.ycombinator.com/item?id=9652893 當你是顧問時，一開始很容易提倡採用《單體》，因為你會在《單體》出現 問題前，就已經完成專案離開了。 已有兩年《微服務》經驗的他，提出了兩個見解： ➊ 當公司或團隊很小時，除非你們技藝超群，否則不建議採用《微服務》。 ➋ 當公司或團隊很大時，採用《微服務》有助於解隅組織並促進敏捷。
- 110. 110/120 救世主 ?
- 111. 111/120
- 113. 113/120 Serverless Serverless ≠ Architectureless Ref: https://martinfowler.com/articles/serverless.html
- 114. 114/120 Serverless Serverless ≠ Architectureless Ref: https://aws.amazon.com/serverless/
- 115. 115/120 ➊ 架構先決 ➋ 沒有完美的架構，只有最適的架構 ➌ 架構是演進的，預想但不過早調優
- 116. 116/120 Sacrificial Architecture ( 犧牲的架構 ) ~ Martin Fowler ~ 即使捨棄現有架構，重構組件新架構，也未必是一件失敗的事 重點是【為什麼】、【新架構怎麼執行】及【何時執行】 簡言之，如果清楚明白打掉重練比較好，就勇敢執行吧！ Ref: http://www.infoq.com/news/2014/11/sacrificial-architecture
- 117. 117/120 Sacrificial Architecture ( 犧牲的架構 ) ~ Martin Fowler ~ 即使捨棄現有架構，重構組件新架構，也未必是一件失敗的事 重點是【為什麼】、【新架構怎麼執行】及【何時執行】 簡言之，如果清楚明白打掉重練比較好，就勇敢執行吧！ Ref: http://www.infoq.com/news/2014/11/sacrificial-architecture 但免不了的，還是要面臨這些問題
- 119. 119/120 共 勉 之