微服務是這幾年最流行的架構，說起架構不提微服務都不好意思跟人家打招呼。最近想要再梳理一下關于微服務的知識，并且結合本人的一些實踐經(jīng)驗來做一些總結與分享。前面會分享一些概念性的東西，后面也會使用.net來實踐，一步步完成一個簡單的微服務架構的小demo。

什么是微服務

其實微服務并沒有統(tǒng)一的標準定義。微服務是一種軟件架構的風格。它首先由大神martin fowler提出，2014年3月25號在他的博客上發(fā)表了一篇博客來描述了這種微服務的架構。原文地址（https://www.martinfowler.com/articles/microservices.html）。
相對于傳統(tǒng)的單體（Monolithic）架構應用，微服務把單個進程的應用拆分為多個單獨部署的服務。每個服務對外提供一些接口來進行服務間的通訊或者對第三方提供功能。每個獨立的服務甚至使用自己獨立的存儲技術，獨立的語言技術棧。說到底微服務架構還是貫徹了軟件開發(fā)中：單一職責、分而治之、解耦等基本理念，只是它把這種理念從類、類庫級別提升到了進程級別。

圖片引用自https://www.redhat.com/zh/topics/microservices/what-are-microservices

微服務與SOA

微服務架構看起來跟SOA架構非常相似。事實上微服務架構就是SOA的一種現(xiàn)代化的實現(xiàn)方式，一次進化。雖然不能在兩者之間畫等號，但是他們的思想確實是一致的。

圖片引用自https://zato.io/docs/intro/esb-soa-cn.html

微服務與SOA之間的區(qū)別網(wǎng)上有很多，在此不再大段的復制黏貼網(wǎng)上現(xiàn)成的文字，簡單談談自己的一些理解。
首先SOA大多數(shù)情況下是作用于企業(yè)內(nèi)部，它通過ESB等總線技術把企業(yè)內(nèi)的服務（或者稱之為應用）串聯(lián)起來。SOA雖然是在解耦、去中心化，但是它通常跟某種ESB技術強耦合起來，以至于ESB會成為那個最大的中心。微服務的作用范圍是應用而不是龐大的企業(yè)。微服務不在依賴ESB等總線技術，服務間的通訊通過無狀態(tài)、輕量級的接口實現(xiàn)。協(xié)議采用http、json等通用協(xié)議無關開發(fā)語言，誰都可以調(diào)用。所以相比SOA有更好的去中心化意義。

優(yōu)點

上面說了這么多關于微服務的知識，那么實施微服務到底為我們帶來了哪些好處？網(wǎng)上有很多復制黏貼的話其實我不太茍同，比如：部署簡單，如果沒有強大的運維團隊微服務的部署顯然是比傳統(tǒng)單體應用部署難度更大了。比如快速開發(fā)快速迭代：事實上單體應用也不用等到完全開發(fā)完才能上線。下面說下我認為的微服務的幾個優(yōu)點：

技術異構
采用微服務架構可以很方便的在每個服務中使用不同的技術棧。每個團隊可以根據(jù)自身的業(yè)務情況，人員情況安排使用最合適的技術。如果我們服務業(yè)務是AI那就考慮pyhton，如果我們的人員比較熟悉JavaScript，那么可以選nodejs。當然技術的多樣性也是要權衡的，不能說每個服務都擼一種語言每個都試驗一把，這樣未必就是好事情了。

擴展性
當我們的業(yè)務做的越來越大，流量越來越大的時候，需要對計算資源進行擴展。相對于單體應用，微服務可以更好的進行擴展。傳統(tǒng)單體應用水平擴展的時候可能需要把整個應用都擴展多個實例。事實上我們的業(yè)務越來越大的時候，往往只是某個模塊壓力巨大。而采用微服務架構我們只需要對某壓力大的服務進行水平擴展。配合現(xiàn)在的容器化技術能夠更好的利用技術資源。

可靠性
由于每個服務都是獨立部署，當某個服務故障的時候通常不會導致其它服務同時故障，只是喪失了部分能力。再配合服務降級、熔斷等技術可以比單體應用提供更好的可靠性。

強模塊化邊界
這個概念在網(wǎng)上很少出現(xiàn)。我是在B站上楊波老師的一個關于微服務視頻上看到的，對這個觀點比較認同。模塊化是我們軟件開發(fā)常用的模式。原來我們按類、按類庫進行模塊化，現(xiàn)在通過微服務架構直接把模塊服務化了，并且能獨立部署運行。其它模塊不在需要直接引用相關類庫就可以使用它。而且實施微服務架構后會強制團隊進行應用的模塊化，對模塊的邊界進行明確的劃分。當然模塊的邊界劃分是個技術活，如果劃分的不夠好那就是場災難。

缺點

這個世界上的事情都是具有兩面性的。微服務除了有其優(yōu)點，自然也有缺點。我們在做架構的時候要盡量處理好這些缺點，避免踩到巨坑。下面談談我對微服務缺點的一些看法。

運維難度增加
本來只需要部署一個IIS站點或者Tomcat服務、維護一個數(shù)據(jù)庫，現(xiàn)在變成了需要部署N個不同的服務，N個不同類型的數(shù)據(jù)庫。不同的服務甚至可能分散在不同的服務器上。要使這些服務正常的工作，正常的通訊，還要對其進行監(jiān)控顯然比單體架構時代對運維的考驗提高了一個維度。沒有強大的運維團隊、自動化的運維工具的話微服務實施起來出故障的概率顯然會大大增加。

分布式的挑戰(zhàn)
微服務架構天然就是分布式的。但是分布式系統(tǒng)會帶來很多單體架構沒有的問題。比如分布式事務，數(shù)據(jù)一致性問題。本來在進程內(nèi)一個鎖或者在數(shù)據(jù)庫開一個事務就能解決的事情，現(xiàn)在不得不借助分布式鎖、分布式事務、數(shù)據(jù)最終一致性來處理。這些問題對開發(fā)人員寫代碼的時候也是很大的挑戰(zhàn)。除了一致性的問題，微服務架構中服務之間的通信也會有很高的成本。本來進程內(nèi)的方法調(diào)用變成了跨進程、跨服務的通訊。我們知道網(wǎng)絡是不可靠的，出現(xiàn)故障的概率遠遠超過進程內(nèi)調(diào)用。

調(diào)試，測試難度增加
由于服務之間互相依賴，在做集成測試或者調(diào)試的時候需要把所有依賴的服務、數(shù)據(jù)庫等全部都跑起來。出現(xiàn)問題很難一次性定位到確切位置。由于服務器之間網(wǎng)絡帶寬的原因多次測試結果可能會有變動，測試的結果不穩(wěn)定。

溝通成本提高
在采用微服務架構開發(fā)之后，團隊的組織架構都可能跟著變動，團隊免不了被拆分成多個小團隊甚至不同部門。在公司呆過的都知道，跨團隊跨部門之間溝通的成本有多大。本來一天就能修復的bug，很可能變成一周。

模塊劃分困難
我們前面說微服務把每個模塊進行獨立部署，采用獨立的數(shù)據(jù)庫。這么輕描淡寫的一句話，事實上實施起來并沒有那么容易。如果模塊劃分的不好，那么會出現(xiàn)非常多的跨庫查詢，非常多的跨庫事務。本來單體架構上很簡單的事情變得無比復雜。本來一句Transaction就你搞定的事情，現(xiàn)在可能需要先團隊之間進行溝通，然后互相開接口，再使用分布式事務來完成。模塊劃分的一個好的方案就是采用DDD的思想進劃分，但是事實上能把DDD玩好落地也不是一件容易的事。

微服務不是銀彈

微服務這幾年火熱的很。很多公司、架構師言架構必微服務，好像微服務是包治百病的良藥。不管項目大小，項目周期，人員配置，技術實力，一股腦的上微服務。見過3，5人小團隊一個月就能開發(fā)上線的說要進行微服務改造。這么做怕不是微服務真的香，而是為了充實自己的簡歷。
微服務不是銀彈，正如上面所述，微服務在享受它帶來的好處的時候也是有巨大的成本開銷的。它會帶來組織架構上的變動，人員的變動。它大大的提高了系統(tǒng)的復雜性，給運維、開發(fā)、測試、調(diào)試都帶來巨大的挑戰(zhàn)。
在采用微服務架構之前最好先思考一下，真的需要微服務嗎？權衡一下微服務帶來的利弊再下決定。以我個人的經(jīng)驗來看，市面上絕大多數(shù)系統(tǒng)更適合單體架構，或者說沒必要一上來就采用微服務架構。真正好的架構是在滿足當前需求的前提下快速穩(wěn)定的上線，并對后面的擴展、改造留好余地，以應對后面業(yè)務發(fā)展帶來的需求進行架構的升級改造。

總結

通過以上這些鋪墊我們講了微服務的概念、微服務有哪些優(yōu)點、微服務又有哪些缺點給我們帶來了哪些方面的挑戰(zhàn)。以上是我個人的一些淺薄的理解有可能有遺漏或者有錯誤，大家可以一起討論一下。
下一篇將會對微服務架構、微服務使用的常用組件進行詳細介紹，敬請期待。
謝謝閱讀，幫忙點贊。

關注我的公眾號一起玩轉技術

總結

以上是生活随笔為你收集整理的.NET Core with 微服务 - 什么是微服务的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。