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