• 微服務是一種架構風格，将單體應用劃分成一組小的服務，盡量符合單一職責的原則，使得服務之間相互協作，實現業務功能；
• 每個服務都運行在獨立的進程、虛拟機、容器、服務器中，服務之間采用輕量級的通信機制（HTTP/JSON）進行協作；
• 每個服務圍繞各自的業務能力進行構建，并且能夠通過自動化機制獨立地部署，相互之間無部署依賴；
• 每個服務可以使用不同的技術棧進行開發；

微服務是一種基于有界上下文的，松散耦合的面向服務的架構。

• 劃分了業務模塊，具有更強的業務邊界；
• 每個微服務都是可以獨立部署的，互不影響；
• 允許技術多樣性；

• 帶來了分布式系統的複雜性；
• 帶來了最終一緻性的難題；
• 帶來了運維的複雜性；
• 帶來了測試複雜性；

什麼場景下适用微服務？什麼階段時适用微服務？

設計的微服務系統的組織，其産生的架構設計應等價于組織間的溝通結構。

這句話的意思是說，原始組織之間的結構最好能映射到設計的微服務系統架構上。比如一個系統包含訂單、商品、用戶等功能，現實中分别由A、B、C三個小組進行開發維護，那麼如果要拆分為微服務的架構，最好就能拆分為訂單服務、商品服務、用戶服務三個微服務，對應A、B、C三個現實的小組結構。

微服務并不是适合任何階段，最好的方式就是随着項目的擴大或者團隊的擴大時，逐步演進到微服務。因為單體應用會随着規模的擴大而逐漸增加内耗，導緻生産力降低。微服務的目标是在規模擴大時，使得生産力能維持在一個穩定的水準之上。

微服務與單體的生産力比較

微服務生産力超過單體的拐點，一般來說是指當團隊人數規模達到百人時。當然，這也不是絕對的，需要團隊負責人自己視情況進行評估。

如果在項目一開始就設計微服務的架構，一路上會遇到極大的困難與風險。比如業務模塊邊界的劃分、無法預估的業務或者技術複雜性，這些都會耗費更多的人力和時間，甚至最終導緻項目失敗。

建議的方式就是由單體演進，我們可以在單體階段不斷摸索和沉澱業務和技術上的問題，随着越來越清晰的認知，再加上日漸增加的複雜度，可以考慮逐步拆分部分服務出來，朝着微服務架構的方向演進。

架構演進

微服務架構中服務與服務各有不同，相互之間也應該按照層級的方式進行編排。有的與業務無關的服務天然屬于底層基礎服務，有的與業務有關聯的服務則屬于聚合了基礎服務的聚合服務。

服務分層

在常見的公司微服務總體架構中，一般的架構表現就如下所示：

微服務總體架構

有了各個層級的服務之後，中台的概念和戰略就顯得很自然。

中台戰略

服務注冊與發現是微服務架構得以運轉的核心功能，它不提供任何業務功能，僅僅用來進行服務的發現和注冊，并對服務的健康狀态進行監控和管理。其核心的工作原理：

• 注冊中心負責維護所有服務的地址信息，包括服務名稱、IP地址、端口等；
• 提供服務方将自己的信息注冊到注冊中心上，并維持一個心跳以此來表明自己一直可用；
• 調用服務方想要調用某個服務時，詢問注冊中心該服務的地址，然後以負載均衡的方式發起調用；

現在注冊中心比較多，主流的有Eureka、Consul、Zookeeper、Nacos等。

網關是整個系統對外暴露的唯一入口，它封裝了系統内的所有微服務，對外看來，别人隻知道也隻能通過網關才可以和系統進行交互。網關對所有請求進行非業務功能的處理，然後再将請求發送給内部指定的微服務進行業務上的處理。總的來說，網關最主要的功能如下：

• 反向路由；
• 安全認證；
• 限流熔斷；
• 日志監控；

現在常見的網關有Kong、Zuul、Spring Cloud Gateway等；

微服務網關

在實際應用中，一個微服務體系架構的系統可以有多個網關用來應對不同的使用場景，比如公司内網網關、外網網關、提供給第三方調用的網關等；

多網關的使用

微服務在啟動和運行的過程中，經常會需要讀取一些配置信息，這些配置信息擁有如下的特點：

• 獨立于程序的隻讀内容；配置與程序應該分離，應用應該隻會去讀取配置，而不應該去修改配置；
• 伴随應用的整個生命周期；配置會被程序讀取用來控制自己的行為邏輯；因此配置是可以被更改的；
• 擁有多種加載方式；可以通過硬編碼、配置文件、環境變量、啟動參數、數據庫存儲等方式被加載到應用内；
• 配置内容需要治理；不同的環境下，配置具有不同的内容，因此需要配置内容的治理；

如上這些特點和需求，催生了配置中心的出現。現在主流的配置中心有Spring Cloud Config、Nacos、Apollo等；

配置中心

RPC和REST

監控體系

監控架構

在微服務架構中，一次調用請求可能貫穿多個服務，這些服務可能是由不同的團隊使用不同的技術開發而成的，如果出現調用失敗需要排查問題時，如何能快速地複現調用現場，發現問題出在哪個服務哪個服務器上就成了全鍊路監控需要解決的問題。

全鍊路監控的基本原理都是：

• 一次請求全過程中隻有一個TraceID保持不變；
• 每貫穿一個服務，SpanID都不同，同時标注上一個SpanID；
• 按照時間序列将監控信息進行報錯和展示；

全鍊路監控主流工具有CAT、Zipkin、Pinpoint、Skywalking等；

在微服務架構體系中，服務之間的調用是很頻繁的，一旦某些服務出現故障或者高延遲，會很可能造成級聯故障，如果客戶端還在不停重試，将會加劇問題的嚴重性，最終導緻整個系統徹底崩潰。

斷路器的設計與實現有助于防止多服務之間的級聯故障，允許我們構建具有容錯性和高彈性的微服務架構系統，當某些服務不可用時，提供服務熔斷和服務降級功能，保證系統的其它部分仍能正常運行。

斷路器的三個狀态和含義如下：

• 關閉；此時所有調用都能訪問到當前的服務。當調用次數或者故障數超過設定的阈值後，斷路器變為打開狀态；
• 打開；不再調用當前服務，而是返回預設的錯誤信息；
• 半開；打開一定時間後，斷路器切換為半開狀态，放一個請求調用當前服務，測試服務是否正常。如果正常，則變為關閉狀态；如果還是異常，再次變為打開狀态。

主流常見的斷路器有Hystrix、Sentinel等；

DevOps

藍綠發布

如果使用了容器技術，那麼容器編排、發布、治理就成了避不開的話題。主流的技術如下：

• Docker、Docker Compose、Docker Swam
• K8s
• Mesos

各大容器雲廠商基本都是使用基于k8s的容器治理方案，k8s也已經成為該領域事實上的标準了。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!