.NET Core with 微服務 – 什麼是微服務
- 2021 年 5 月 10 日
- 筆記
- .NET Core, microservice
微服務是這幾年最流行的架構，說起架構不提微服務都不好意思跟人家打招呼。最近想要再梳理一下關於微服務的知識，並且結合本人的一些實踐經驗來做一些總結與分享。前面會分享一些概念性的東西，後面也會使用.net來實踐，一步步完成一個簡單的微服務架構的小demo。
什麼是微服務
其實微服務並沒有統一的標準定義。微服務是一種軟體架構的風格。它首先由大神martin fowler提出，2014年3月25號在他的部落格上發表了一篇部落格來描述了這種微服務的架構。原文地址（//www.martinfowler.com/articles/microservices.html）。
相對於傳統的單體（Monolithic）架構應用，微服務把單個進程的應用拆分為多個單獨部署的服務。每個服務對外提供一些介面來進行服務間的通訊或者對第三方提供功能。每個獨立的服務甚至使用自己獨立的存儲技術，獨立的語言技術棧。說到底微服務架構還是貫徹了軟體開發中：單一職責、分而治之、解耦等基本理念，只是它把這種理念從類、類庫級別提升到了進程級別。
圖片引用自//www.redhat.com/zh/topics/microservices/what-are-microservices
微服務與SOA
微服務架構看起來跟SOA架構非常相似。事實上微服務架構就是SOA的一種現代化的實現方式，一次進化。雖然不能在兩者之間畫等號，但是他們的思想確實是一致的。
圖片引用自//zato.io/docs/intro/esb-soa-cn.html
微服務與SOA之間的區別網上有很多，在此不再大段的複製黏貼網上現成的文字，簡單談談自己的一些理解。
首先SOA大多數情況下是作用於企業內部，它通過ESB等匯流排技術把企業內的服務（或者稱之為應用）串聯起來。SOA雖然是在解耦、去中心化，但是它通常跟某種ESB技術強耦合起來，以至於ESB會成為那個最大的中心。微服務的作用範圍是應用而不是龐大的企業。微服務不在依賴ESB等匯流排技術，服務間的通訊通過無狀態、輕量級的介面實現。協議採用http、json等通用協議無關開發語言，誰都可以調用。所以相比SOA有更好的去中心化意義。
優點
上面說了這麼多關於微服務的知識，那麼實施微服務到底為我們帶來了哪些好處？網上有很多複製黏貼的話其實我不太苟同，比如：部署簡單，如果沒有強大的運維團隊微服務的部署顯然是比傳統單體應用部署難度更大了。 比如快速開發快速迭代：事實上單體應用也不用等到完全開發完才能上線。下面說下我認為的微服務的幾個優點：
- 技術異構
採用微服務架構可以很方便的在每個服務中使用不同的技術棧。每個團隊可以根據自身的業務情況，人員情況安排使用最合適的技術。如果我們服務業務是AI那就考慮pyhton，如果我們的人員比較熟悉JavaScript，那麼可以選nodejs。當然技術的多樣性也是要權衡的，不能說每個服務都擼一種語言每個都試驗一把，這樣未必就是好事情了。 - 擴展性
當我們的業務做的越來越大，流量越來越大的時候，需要對計算資源進行擴展。相對於單體應用，微服務可以更好的進行擴展。傳統單體應用水平擴展的時候可能需要把整個應用都擴展多個實例。事實上我們的業務越來越大的時候，往往只是某個模組壓力巨大。而採用微服務架構我們只需要對某壓力大的服務進行水平擴展。配合現在的容器化技術能夠更好的利用技術資源。 - 可靠性
由於每個服務都是獨立部署，當某個服務故障的時候通常不會導致其它服務同時故障，只是喪失了部分能力。再配合服務降級、熔斷等技術可以比單體應用提供更好的可靠性。 - 強模組化邊界
這個概念在網上很少出現。我是在B站上楊波老師的一個關於微服務影片上看到的，對這個觀點比較認同。模組化是我們軟體開發常用的模式。原來我們按類、按類庫進行模組化，現在通過微服務架構直接把模組服務化了，並且能獨立部署運行。其它模組不在需要直接引用相關類庫就可以使用它。而且實施微服務架構後會強制團隊進行應用的模組化，對模組的邊界進行明確的劃分。當然模組的邊界劃分是個技術活，如果劃分的不夠好那就是場災難。
缺點
這個世界上的事情都是具有兩面性的。微服務除了有其優點，自然也有缺點。我們在做架構的時候要盡量處理好這些缺點，避免踩到巨坑。下面談談我對微服務缺點的一些看法。
- 運維難度增加
本來只需要部署一個IIS站點或者Tomcat服務、維護一個資料庫，現在變成了需要部署N個不同的服務，N個不同類型的資料庫。不同的服務甚至可能分散在不同的伺服器上。要使這些服務正常的工作，正常的通訊，還要對其進行監控顯然比單體架構時代對運維的考驗提高了一個維度。沒有強大的運維團隊、自動化的運維工具的話微服務實施起來出故障的概率顯然會大大增加。 - 分散式的挑戰
微服務架構天然就是分散式的。但是分散式系統會帶來很多單體架構沒有的問題。比如分散式事務，數據一致性問題。本來在進程內一個鎖或者在資料庫開一個事務就能解決的事情，現在不得不藉助分散式鎖、分散式事務、數據最終一致性來處理。這些問題對開發人員寫程式碼的時候也是很大的挑戰。除了一致性的問題，微服務架構中服務之間的通訊也會有很高的成本。本來進程內的方法調用變成了跨進程、跨服務的通訊。我們知道網路是不可靠的，出現故障的概率遠遠超過進程內調用。 - 調試，測試難度增加
由於服務之間互相依賴，在做集成測試或者調試的時候需要把所有依賴的服務、資料庫等全部都跑起來。出現問題很難一次性定位到確切位置。由於伺服器之間網路頻寬的原因多次測試結果可能會有變動，測試的結果不穩定。 - 溝通成本提高
在採用微服務架構開發之後，團隊的組織架構都可能跟著變動，團隊免不了被拆分成多個小團隊甚至不同部門。在公司呆過的都知道，跨團隊跨部門之間溝通的成本有多大。本來一天就能修復的bug，很可能變成一周。 - 模組劃分困難
我們前面說微服務把每個模組進行獨立部署，採用獨立的資料庫。這麼輕描淡寫的一句話，事實上實施起來並沒有那麼容易。如果模組劃分的不好，那麼會出現非常多的跨庫查詢，非常多的跨庫事務。本來單體架構上很簡單的事情變得無比複雜。本來一句Transaction就你搞定的事情，現在可能需要先團隊之間進行溝通，然後互相開介面，再使用分散式事務來完成。模組劃分的一個好的方案就是採用DDD的思想進劃分，但是事實上能把DDD玩好落地也不是一件容易的事。
微服務不是銀彈
微服務這幾年火熱的很。很多公司、架構師言架構必微服務，好像微服務是包治百病的良藥。不管項目大小，項目周期，人員配置，技術實力，一股腦的上微服務。見過3，5人小團隊一個月就能開發上線的說要進行微服務改造。這麼做怕不是微服務真的香，而是為了充實自己的簡歷。
微服務不是銀彈，正如上面所述，微服務在享受它帶來的好處的時候也是有巨大的成本開銷的。它會帶來組織架構上的變動，人員的變動。它大大的提高了系統的複雜性，給運維、開發、測試、調試都帶來巨大的挑戰。
在採用微服務架構之前最好先思考一下，真的需要微服務嗎？權衡一下微服務帶來的利弊再下決定。以我個人的經驗來看，市面上絕大多數系統更適合單體架構，或者說沒必要一上來就採用微服務架構。真正好的架構是在滿足當前需求的前提下快速穩定的上線，並對後面的擴展、改造留好餘地，以應對後面業務發展帶來的需求進行架構的升級改造。
總結
通過以上這些鋪墊我們講了微服務的概念、微服務有哪些優點、微服務又有哪些缺點給我們帶來了哪些方面的挑戰。以上是我個人的一些淺薄的理解有可能有遺漏或者有錯誤，大家可以一起討論一下。
下一篇將會對微服務架構、微服務使用的常用組件進行詳細介紹，敬請期待。
謝謝閱讀，幫忙點贊。
關注我的公眾號一起玩轉技術
