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

相關技術配合(Enabling Technology)

當你啱啱開始使用微服務架構時，你唔洗用晒全部新技術。相反，當你慢慢加強你嘅微服務架構，就可以因應日益增多嘅分佈式問題，然後搵可以幫到手嘅技術。

日誌匯總及分佈式追蹤(Log Aggregation and Distributed Tracing)

作者主張實施日誌匯總系統應該作為採用微服務架構嘅先決條件。因為分佈式系統各自運行，如果你需要續個系統去尋找你需要嘅Log，實在是太癈時失事。日誌匯總為你提供一個中央嘅地方，進行日誌分析，甚至可以成為主動警報機制嘅一部分。
主要公用雲供應商(public cloud provider)提供嘅簡單日誌服務可能已經足夠幫你入門。透過實施一個通用ID，令呢啲日誌匯總工具更加有用，單一個ID會用喺一組相關嘅服務調用中。

容器及Kubernetes(Containers and Kubernetes)

虛擬化可以喺現有嘅硬件上創建隔離嘅執行環境，但係一般嘅虛擬化技術喺微服務嘅方面睇，可以太過Overkill。容器提供咗一個更輕量級嘅方式，為服務實例提供隔離，新容器實例嘅啟動時間更快，對架構黎講更加具成本效益。
容器管控平台，例如Kubernetes，俾你分佈容器實例，用以提供服務所需嘅穩健性同吞吐量，同時令你有效咁使用底層嘅機器。
但如果你得幾個微服務，採用容器管控平台就唔係幾合理。如果可以嘅話，盡量用公用雲供應商運行嘅Kubernetes服務。運行自己嘅Kubernetes可能有相當多嘅工作量！

串流(Streaming)

雖然喺微服務下，我哋盡量避免用單塊式數據庫，但我哋都仲需要搵方法喺微服務之間分享數據。例如組織希望由批量處理報告，轉向更即時嘅反饋，令到可以更快速咁反應。唔同產品提供嘅大數據串流和串流處理能力，已經喺微服務架構之間流行。

公用雲同無伺服器運算(Public Cloud and Serverless)

公用雲(特別係指三大頭，Google Cloud, Microsoft Azure, Amazon Web Service AWS)提供大範圍嘅托管服務同管理應用程序嘅選項。當你嘅微服務越黎越強大嘅時候，佢地都可以提供到相應需要嘅服務。
公用雲提供嘅服務中，比較特別值得一提嘅係無伺服器(Serverless)嘅產品。呢啲產品隱藏咗底層嘅機器，容許你喺更高抽象度工作。無伺服器產品嘅例子包括訊息代理(message brokers)、存儲解決方案(storage solution)同數據庫。「Function as a Service（FaaS）」平台提供一個良好嘅抽象化，只係需要考慮代碼。唔需要擔心要用幾多伺服器來運行你嘅服務，你只需部署你嘅代碼，底層嘅平台會自根據需要啟動你嘅代碼實例。

微服務嘅好處(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 完。