DEV Community: IT演員的自我修養

讀書紀錄 - Building Microservice (Sam Newman)[2]

IT演員的自我修養 — Sat, 06 Jan 2024 17:28:19 +0000

續讀書紀錄 - Building Microservice (Sam Newman)[1]

微服務嘅好處(Advantages of Microservices)

大部分嘅好處都同分佈式系統嘅好處重疊，但更進一步，因為微服務對邊界嘅清晰界定，大大放大咗呢啲好處！

技術多樣性(Technology Heterogeneity)

喺一個由多個微服務組成嘅系統中，我哋可以選擇每一個內部使用唔同嘅技術。

可以更快速咁採納/測試新技術，了解新進展可以點樣幫助我哋。好多組織發現能夠更快速咁吸收新技術係一個真正嘅優勢。內部嘅技術實施對使用者隱藏咗，令到升級技術更容易。例如只係升級一個微服務進行測試，可以更加好咁管理升級嘅風險。

穩健性(Robustness)

要提高程式嘅穩健性，一個重要概念係『隔艙板(好似大船咁隔開唔同嘅船艙)』。一部分系統嘅失敗，唔會引發連鎖反應，就可以隔離問題，而其他部分仍然可以繼續運作。喺Monolith，其中任何一部分失敗，所有嘢就會停晒。喺微服務我哋可以使得更好，但係我哋需要了解分佈式系統需要處理嘅新故障源。網絡可能失效，機器都可能失效，我哋要知道點去處理同了解對我哋用戶嘅影響。

擴展性(Scaling)

喺Monolith，通常擴展就要幾所有嘢一齊擴展。而微服務，我哋可以針對服務需求需擴展/縮減規模。呢個做法令我哋更有效地控制成本。

部署輕易性(Ease of Deployment)

就如前面一直所講，Monolith要更改就需要重新將整個部署多次。微服務可以對單一服務進行修改，獨立部署，而唔影響其他系統。呢個做法令我哋可以更快咁部署我哋嘅代碼。

組織一致性(Organizational Alignment)

微服務令我哋更好地對齊我哋嘅架構同組織，幫助我哋減少參與喺單一個代碼庫嘅人數，以達到團隊規模同產能之間嘅最佳平衡。微服務亦都令我哋可以根據組織嘅變化改變服務嘅擁有權，從而喺將來保持架構同組織之間嘅對齊。

組合性(Composability)

微服務允許我哋嘅功能以不同嘅方式同不同嘅目的去使用。以前我哋係好細嘅範疇內思考，桌面網站定係手機應用程式。而家我哋需要考慮到有好多唔同嘅方式，我哋可能想要將網站、本地應用程式、手機網頁、平板應用程式、或者穿戴裝置嘅功能緊密結合埋一齊。

微服務難處(Microservice Pain Points)

微服務顯然易見係令到系統架構更加複雜，好處跟隨左分佈式嘅好處，相應地，壞處都係同分佈式式式相關。

開發者體驗(Developer Experience)

當有越來越多服務嘅時候，開發者嘅體驗可能會開始受影響。唔可以喺一部機器全面運行整個系統，如果你使用咗唔可以本地運行嘅雲端服務，情況可能會變得更加複雜。限制開發者需要工作嘅系統部分嘅範圍，可能會係一個更加直接嘅方法。

科技過載(Technology Overload)

為咗支持微服務架構嘅採用，出現咗咁多新科技可能會令人感到壓力巨大。微服務俾你選擇，每個微服務可以用唔同嘅程式語言寫、喺唔同嘅執行環境度運行，或者使用唔同嘅數據庫——但呢啲係選擇，唔係要求。你要仔細平衡你使用嘅科技嘅廣度同複雜性，同多樣化科技可能帶嚟嘅成本。
當你開始採用微服務時，有一啲根本嘅挑戰係無法避免嘅：你需要花好多時間去理解關於數據一致性、延遲、服務建模等問題。如果你嘗試理解呢啲概念點樣改變你對軟件開發嘅思考，同時又要學習大量嘅新科技，咁你可能會好辛苦。要理解咁多嘅新科技會減少你用嚟實際推出功能俾用戶嘅時間。
確保你唔會因為呢啲新工具嘅複雜性而負荷過大，逐漸增加嘅方式會更有優勢，令你可以喺日後逐漸掌握新嘅、更好嘅做事方法。

成本(Cost)

短期內都好有可能會因為好多因素而增加成本。首先，你可能需要運行更多嘢——多啲進程、多啲電腦、多啲網絡、多啲儲存、以及多啲支援軟件。喺一個團隊或者組織入面引入嘅任何改變，短期內都會令你嘅產出變慢。
如果組織主要關心嘅係降低成本，咁微服務可能唔係一個好選擇，因為一個以降低成本為主嘅心態會不斷地限制你喺呢個架構度嘅發揮。

報告(Reporting)

喺Monolith整報告，通常都有一個單一數據庫，我哋可以直接去分析，因為所有數據都係喺埋一齊。
微服務架構之後，我哋已經拆散咗個Monolith。咁唔代表我哋唔需要橫跨所有數據嘅報告；只不過令到變得更加困難，因為而家我哋嘅數據散佈喺多個邏輯上隔離嘅服務入面。
更現代嘅報告方法，例如使用串流技術以實現對大數據嘅實時報告，可以同微服務架構配合得好，但通常需要採用新嘅概念同相關科技。

監控及排解疑難(Monitoring and Troubleshooting)

對於Monolith，我們可以採用相對簡單的監控方法。我們只需要關心少量的機器，而應用程式的故障模式只係，一係得，一係唔得。對於微服務，如果單個服務實例出現故障，我們是否理解這會帶來什麼影響？

安全(Security)

喺單進程嘅Monolith，我哋嘅大部分資訊係流動係呢個進程內。而家，更多資訊喺服務之間透過網絡流動。呢個情況可能令我哋嘅數據更容易喺傳輸過程中被觀察，同時都更容易受到中間人攻擊（man-in-the-middle attacks)嘅潛在威脅。

測試(Testing)

微服務令端對端測試範圍變得非常大。我哋再唔係喺一個機器上面運行我哋整個產品。需要測試喺多個進程之間，而且所有進程都需要設置做應測試情境。我哋亦都需要準備好應對環境問題帶嚟嘅假陰性，例如服務實例死亡或者網絡超時導致我哋嘅測試失敗。

網絡延遲(Latency)

之前只係流動喺單一個進程度嘅資訊，而家需要被序列化(Serialize)、傳輸(Transmit)，反序列化(Deserialize)。所有呢啲都可能導致你嘅系統延遲加重。

數據一致性(Data Consistency)

喺Monolith，所有數據都係集中存放。但係微服務係分佈式，會引發數據一致性方而嘅挑戰。我哋可能需要以最終一致性(Eventual consistency)來管理和思考你系統內嘅狀態同數據。

咁我地應唔應該用微服務？(Should I Use Microservices?)

睇左咁多微服務同Monolith嘅優缺點，咁我哋應唔應該用？你需要評估自己嘅問題範疇、技能同科技環境，同明白你嘅目標係咩，然後再決定微服務係唔係適合你嘅。微服務係一種架構方法，唔係唯一嘅架構方法。你自己嘅情境應該係你決定揀唔揀呢個路線嘅重要考慮因素。

可能唔適合嘅地方(Whom They Might Not Work For)

考慮到確定穩定嘅服務界限嘅重要性，對於全新產品或初創企業嚟講，微服務架構通常唔係好選擇。服務邊界間嘅協調同更改係高成本行為，等到領域模型穩定咗，先再考慮定義服務邊界會更加合適。尋找產品市場適應嘅過程可能意味住，最終嘅產品同你一開始諗嘅唔同。
另外，如果組織創建由客戶部署和管理嘅系統，客戶可能會面對微服務方面嘅困難。

效果好嘅地方(Where They Work Well)

好多組織採用微服務嘅目的係俾多啲開發者可以喺同一個系統度工作，唔會互相干擾。如果你嘅架構同組織界限設定得當，你可以容許更多人獨立地工作，減少交付競爭。
服務應用程序（SaaS）都係微服務架構嘅好選擇。呢啲產品通常被期望要24-7運作，呢樣特性令佢哋喺推出更改方面面對挑戰。同時，微服務可以根據需要進行擴展或縮小。多啲需要時開多啲，少啲需要時開少啲。
微服務技術多樣性嘅本質確保你可以善用雲平台嘅優勢。能夠輕易嘗試新技術係一個好處。FaaS平台愈來愈受歡迎，對於合適嘅工作，FaaS平台可以大幅減少運營開銷，但目前而言，唔係所有情況都適用。
微服務係一種可以持續演進嘅架構，可以帶嚟好多彈性。當然，呢種彈性有成本，但如果你想保持未來有更多選擇，可能係一個值得付嘅代價。

總結(Summary)

微服務架構可以喺揀技術、穩健性同擴展性、組織團隊等方面提供極大彈性。由於依啲彈性，好多人都支持微服務架構。但微服務同時帶嚟相當程度嘅複雜性，你需要確保呢個複雜性係合理嘅。佢哋係一個架構選擇，需要根據你嘅問題來合理選擇；通常，更簡單嘅方法可以更容易地提供解決方案。
儘管如此，好多組織，特別係大型組織，已經證明咗微服務可以有多麼有效。當微服務嘅核心概念被正確理解同實施嘅時候，佢哋可以幫助建立高生產力嘅架構，可以令系統變得超越各個部分之總和。

CH1 完。

讀書紀錄 - Building Microservice (Sam Newman)[1]

IT演員的自我修養 — Fri, 05 Jan 2024 22:49:00 +0000

前言

依個系列主要係個人讀書紀錄，希望可以達到幾個自我目的。

紀錄自己既讀書進度
之後睇返自己既簡讀從而減少重讀既時間
加強自己閱讀記憶

同時都希望各位不幸讀到既小弟文章既師兄有所裨益，歡迎指導小弟。
注：文章有好大可能會中英夾雜，盡量希望用日常溝通用詞編寫。

正式進入主題！

CH 1 - 什麼是微服務?(What Are Microsevices?)

微服務Microservices 係其中一種服務向架構(service-oriented architecture)

特點：

獨立可發佈性 (Independent Releasable/Deployable)
圍繞商業領域(Business Domain)設計
每一個微服務都係可被視為黑盒 (Black Box)
擁抱資訊隱藏，高內聚，低耦合 (High cohesion, Low coupling)
管理及擁有各自嘅狀態
服務由網絡連接(提供/獲取）

獨立可發佈性

獨立可發佈性係微服務最最最重要嘅紀律。重點係可以喺唔需要重新發佈任何其他微服務嘅情況下，進行更改，發佈俾我哋嘅用戶使用。為左獨立可發佈性，我哋要確保微服務係低耦合，同時需要確保服務之間有明確，清晰同穩定嘅合約/接口。
向後兼容亦都重要，令上游服務唔受更新影響。

圍繞商業領域設計

有啲技巧例如領域驅動設計(Domain-driven design，DDD)可以幫到我哋有更好嘅代碼結構，更真實咁反映現實領域。微服務都有同一樣嘅概念去定義服務邊界。如果推出一個新功能，係需要更改超過一個微服務嘅話，會係好高成本！所以針對商業功能去分割服務係嘅話，就可以盡可能高效咁更新商業功能。微服務嘅方向係，比起技術功能嘅高內聚，商業功能嘅高內聚係更優先嘅選擇。

擁有服務自己嘅狀態

微服務應該避免使用共用數據庫。如果一個微服務想要拎到另一個微服務嘅數據，應該去向果個微服務請求。咁微服務就有能力決定有咩係共享，有咩係隱藏，咁樣我們能夠清晰咁去區分可以自由更改嘅內部功能同埋唔可以經常更改嘅外部接口。微服務隱藏內部嘅狀態，就好似面向對像OO編程嘅封裝。

大細

Microservice應該幾Micro?依個問題係冇絕對答案。或者個答案係：盡量細但同時提供到佢自己負責嘅功能。作者覺得係唔洗擔心Microservice嘅大細，反而更家應該關注嘅係2個問題，你可以處理到幾多個微服務? 點樣去界定服務範圍令到服務發揮全部嘅功能，而唔令到所有嘢變得混亂耦合。

靈活性

Jame Lewis話 "Microservice buy you options",「微服務為你提供選擇」。同時Buy係買，係有成本/代價嘅！你要決定值唔值得為你之後可能嘅選擇去付出依個前設成本。當然，佢帶黎嘅靈活性都係多維度嘅，包括組織、技術、規模、穩定性等等。我哋唔會肯定到將來會發生咩事，依個架構理論上可以幫我哋解決將來可能遇到嘅問題。喺開放性同架構成本之間做一個平衡！

對齊組織架構同系列架構

三層式架構係系統設計中係非常普遍，作者認為最主要嘅原因係因為我哋係咁樣去建立我哋嘅組織架構。
康威定律(Conway's law)

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
(自行翻譯本)系統設計受制於製造出黎嘅組織機構，基本上係複製機構嘅對話溝通結構。

因為開發部門通常都係分開前端(Frontend), 後端(Backend)同數據庫管理員(DBA)。所以就自然會出現三層式架構，各職員可以順暢咁進行自己果部份嘅開發工作。依種架構選擇咗一個最佳化嘅方向--技術！我哋將同一樣技術嘅人分類喺一齊。

但係我哋被要求做嘅大部分更改都係同商業功能有關。依個架構有高技術內聚，但商業內聚就相對較低，每一個改動可能都會橫跨三個層面。而微服務方面，每一個服務可能end up都需要依個三層架構，但呢個只係服務內部嘅實作問題。
其實放眼公司其他部門，其實大部分都係商業分類。例如：客服部，倉務部，采購部等都係進行業務分層！

單體架構(The Monolith)

前面已經初步講左微服務，通常都會同Monolith架構作比較。為左更好了解，以下會討論一下咩係Monolith架構

單進程單塊架構(The Single-Process Monolith)

出於穩健性同埋擴展性，Single-Process Monolith都可能有好多個實例(Instances)，即係複雜個程式係多個伺服器上面。但係佢哋嘅本質都係一致，就係將全部代碼打包晒喺一個進程入面。而最終都係喺一個數據庫度讀/寫數目，比其他程式或者人去使用。依個方法簡單，直接，大部分人一睇就明，喺相對較細嘅組織係非常合理同有效。

模塊化單塊架構(The Modular Monlith)

單進程單塊架構嘅變化版，包含左獨立嘅模塊。每個模塊可以獨立運行，但係仍然需要合埋一齊咁去部署。對於好多組織嚟講，模塊化單塊架構可以係一個更好嘅選擇。如果模塊嘅界限定義得好，佢可以容許高度平行工作，同時避免咗分佈式微服務架構嘅挑戰，係一個簡單好多嘅部署方法。

分佈式單塊架構(The Distributed Monolith)

分佈式單塊架構係一個由多個服務組成嘅系統，但由於種種原因，整個系統必須一齊部署。作者認為，依種架構同時擁有分佈式同埋單塊架構嘅缺點，又得唔到兩方面嘅優點！

單塊架構與交付競爭(Delivery Contention)

因為單塊架構嘅問題，當越來越多人同時係同一個系統上面做更改，開發員之間就會越要大量協調。唔同嘅成員係幾時推出功能會有分歧，可能其中一部分已經做完，但另一部分又仲做緊，令到推出時間推遲。喺邊個負責咩嘢同邊個決定嘅問題上，容易產生混淆。

Monolith優點

簡單得多嘅部署方式可以避免唔少分佈式系統嘅陷阱。可以導致更加簡單嘅開發者工作流程，監控、排除故障，以及端對端(end-to-end)測試嘅活動都可以大大簡化。
Monolith亦可以簡化內部嘅代碼重用。如果我哋要喺一個分佈式系統內重用代碼，我哋需要決定係咪要複製代碼、拆個Library出黎、將共享單嘅功能放入一個服務。而對於一個Monolith，就簡單得多，所有代碼都喺度，就直接用啦！
有啲人開始覺得Monolith係需要避免嘅。佢哋覺得『Monolith』呢個詞同『Legacy』係同義詞。作者認為Monolith係一個選擇，而且係一個明智嘅默認選擇(default choice)。

待續；