什么是微服務(wù)架構(gòu)

微服務(wù)是系統(tǒng)架構(gòu)上的一種設(shè)計風格， 它的主旨是將一個原本獨立的系統(tǒng)拆分成多個小型服務(wù)，這些小型服務(wù)都在各自獨立的進程中運行，服務(wù)之間通過基于HTTP的RESTful API進行通信協(xié)作。 被拆分成的每一個小型服務(wù)都圍繞著系統(tǒng)中的某一項或一些耦合度較高的業(yè)務(wù)功能進行構(gòu)建， 并且每個服務(wù)都維護著自身的數(shù)據(jù)存儲、 業(yè)務(wù)開發(fā)、自動化測試案例以及獨立部署機制。 由千有了輕量級的通信協(xié)作基礎(chǔ)， 所以這些微服務(wù)可以使用不同的語言來編寫。

微服務(wù)與單體系統(tǒng)的區(qū)別

在傳統(tǒng)的項目中我們通常將需求分為三個主要部分： 數(shù)據(jù)庫、 服務(wù)端處理、 前端展現(xiàn)。 在業(yè)務(wù)發(fā)展初期， 由于所有的業(yè)務(wù)邏輯在一個應用中， 開發(fā)、 測試、 部署都還比較容易且方便。 但是， 隨著企業(yè)的發(fā)展， 系統(tǒng)為了應對不同的業(yè)務(wù)需求會不斷為該單體項目增加不同的業(yè)務(wù)模塊； 同時隨著移動端設(shè)備的進步， 前端展現(xiàn)模塊已經(jīng)不僅僅局限于Web的形式， 這對千系統(tǒng)后端向前端的支持需要更多的接口模塊。 單體應用由千面對的業(yè)務(wù)需求更為寬泛， 不斷擴大的需求會使得單體應用變得越來越臃腫。 單體應用的問題就逐漸凸顯出來， 由于單體系統(tǒng)部署在一個進程內(nèi)， 往往我們修改了一個很小的功能， 為了部署上線會影響其他功能的運行。 并且， 單體應用中的這些功能模塊的使用場景、 并發(fā)量、 消耗的資源類型都各有不同， 對于資源的利用又互相影響， 這樣使得我們對各個業(yè)務(wù)模塊的系統(tǒng)容量很難給出較為準確的評估。 所以， 單體系統(tǒng)在初期雖然可以非常方便地進行開發(fā)和使用，但是隨著系統(tǒng)的發(fā)展， 維護成本會變得越來越大， 且難以控制。

?為了解決單體系統(tǒng)變得龐大脯腫之后產(chǎn)生的難以維護的問題， 微服務(wù)架構(gòu)誕生了并被大家所關(guān)注。 我們將系統(tǒng)中的不同功能模塊拆分成多個不同的服務(wù)， 這些服務(wù)都能夠獨立部署和擴展。 由于每個服務(wù)都運行在自己的進程內(nèi)， 在部署上有穩(wěn)固的邊界， 這樣每個服務(wù)的更新都不會影響其他服務(wù)的運行。 同時， 由千是獨立部署的， 我們可以更準確地為每個服務(wù)評估性能容量， 通過配合服務(wù)間的協(xié)作流程也可以更容易地發(fā)現(xiàn)系統(tǒng)的瓶頸位置，以及給出較為準確的系統(tǒng)級性能容量評估。

為什么選擇Spring Cloud

簡單來說，服務(wù)化的核心就是將傳統(tǒng)的一站式應用根據(jù)業(yè)務(wù)拆分成一個一個的服務(wù)，而微服務(wù)在這個基礎(chǔ)上要更徹底地去耦合(不再共享DB、KV，去掉重量級ESB)，并且強調(diào)DevOps和快速演化。這就要求我們必須采用與一站式時代、泛SOA時代不同的技術(shù)棧，而Spring Cloud就是其中的佼佼者。

DevOps是英文Development和Operations的合體，他要求開發(fā)、測試、運維進行一體化的合作，進行更小、更頻繁、更自動化的應用發(fā)布，以及圍繞應用架構(gòu)來構(gòu)建基礎(chǔ)設(shè)施的架構(gòu)。這就要求應用充分的內(nèi)聚，也方便運維和管理。這個理念與微服務(wù)理念不謀而合。

接下來我們從服務(wù)化架構(gòu)演進的角度來看看為什么Spring Cloud更適應微服務(wù)架構(gòu)。點擊這里查看Spring系列教程集合。

從使用nginx說起

最初的服務(wù)化解決方案是給提供相同服務(wù)提供一個統(tǒng)一的域名，然后服務(wù)調(diào)用者向這個域名發(fā)送HTTP請求，由Nginx負責請求的分發(fā)和跳轉(zhuǎn)。

這種架構(gòu)存在很多問題：

Nginx作為中間層，在配置文件中耦合了服務(wù)調(diào)用的邏輯，這削弱了微服務(wù)的完整性，也使得Nginx在一定程度上變成了一個重量級的ESB。

服務(wù)的信息分散在各個系統(tǒng)，無法統(tǒng)一管理和維護。每一次的服務(wù)調(diào)用都是一次嘗試，服務(wù)消費者并不知道有哪些實例在給他們提供服務(wù)。這不符合DevOps的理念。

無法直觀的看到服務(wù)提供者和服務(wù)消費者當前的運行狀況和通信頻率。這也不符合DevOps的理念。

消費者的失敗重發(fā)，負載均衡等都沒有統(tǒng)一策略，這加大了開發(fā)每個服務(wù)的難度，不利于快速演化。

為了解決上面的問題，我們需要一個現(xiàn)成的中心組件對服務(wù)進行整合，將每個服務(wù)的信息匯總，包括服務(wù)的組件名稱、地址、數(shù)量等。服務(wù)的調(diào)用方在請求某項服務(wù)時首先通過中心組件獲取提供這項服務(wù)的實例的信息(IP、端口等)，再通過默認或自定義的策略選擇該服務(wù)的某一提供者直接進行訪問。所以，我們引入了Dubbo。

基于Dubbo實現(xiàn)微服務(wù)

Dubbo是阿里開源的一個SOA服務(wù)治理解決方案，文檔豐富，在國內(nèi)的使用度非常高。

使用Dubbo構(gòu)建的微服務(wù)，已經(jīng)可以比較好地解決上面提到的問題：

• 調(diào)用中間層變成了可選組件，消費者可以直接訪問服務(wù)提供者。
• 服務(wù)信息被集中到Registry中，形成了服務(wù)治理的中心組件。
• 通過Monitor監(jiān)控系統(tǒng)，可以直觀地展示服務(wù)調(diào)用的統(tǒng)計信息。
• Consumer可以進行負載均衡、服務(wù)降級的選擇。

但是對于微服務(wù)架構(gòu)而言，Dubbo也并不是十全十美的：

?Registry嚴重依賴第三方組件(zookeeper或者redis)，當這些組件出現(xiàn)問題時，服務(wù)調(diào)用很快就會中斷。

?Dubbo只支持RPC調(diào)用。使得服務(wù)提供方與調(diào)用方在代碼上產(chǎn)生了強依賴，服務(wù)提供者需要不斷將包含公共代碼的jar包打包出來供消費者使用。一旦打包出現(xiàn)問題，就會導致服務(wù)調(diào)用出錯。

最為重要的是，Dubbo現(xiàn)在已經(jīng)重新維護了，對于技術(shù)發(fā)展的新需求，需要由開發(fā)者自行拓展升級。這對于很多想要采用微服務(wù)架構(gòu)的中小軟件組織，顯然是相當合適的。

Github社區(qū)上有一個DUBBO的升級版，叫DUBBOX，提供了更高效的RPC序列化方式和REST調(diào)用方式。但是該項目也基本停止維護了。

新的選擇 Spring Cloud

作為新一代的服務(wù)框架，Spring Cloud提出的口號是開發(fā)“面向云環(huán)境的應用程序”，它為微服務(wù)架構(gòu)提供了更加全面的技術(shù)支持。

Spring Cloud與DUBBO對比：

微服務(wù)需要的功能DubboSpring Cloud

服務(wù)注冊和發(fā)現(xiàn)	Zookeeper	Eureka
服務(wù)調(diào)用方式	RPC	Restful Api
斷路器	有	有
負載均衡	有	有
服務(wù)路由和過濾	有	有
分布式配置	無	有
分布式鎖	無	計劃開發(fā)
集群選主	無	有
分布式消息	無	有

?Spring Cloud拋棄了Dubbo的RPC通信，采用的是基于HTTP的REST方式。嚴格來說，這兩種方式各有優(yōu)劣。雖然從一定程度上來說，后者犧牲了服務(wù)調(diào)用的性能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活，服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調(diào)快速演化的微服務(wù)環(huán)境下，顯得更加合適。

Eureka相比于zookeeper，更加適合于服務(wù)發(fā)現(xiàn)的場景。

很明顯，Spring Cloud的功能比Dubbo更加強大，涵蓋面更廣，而且作為Spring的拳頭項目，它也能夠與Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring項目完美融合，這些對于微服務(wù)而言是至關(guān)重要的。前面提到，微服務(wù)背后一個重要的理念就是持續(xù)集成、快速交付，而在服務(wù)內(nèi)部使用一個統(tǒng)一的技術(shù)框架，顯然比把分散的技術(shù)組合到一起更有效率。更重要的是，相比于Dubbo，它是一個正在持續(xù)維護的、社區(qū)更加火熱的開源項目，這就保證使用它構(gòu)建的系統(tǒng)，可以持續(xù)地得到開源力量的支持。

Spring Cloud簡介

?Spring Cloud是一個基千Spring Boot實現(xiàn)的微服務(wù)架構(gòu)開發(fā) 工具。 它為微服務(wù)架構(gòu)中涉及的 配置管理、 服務(wù)治理、 斷路器、 智能路由、 微代理、 控制總線、 全局鎖、 決策競選、分布式會話和集群狀態(tài)管理等操作提供了一種簡單的開發(fā)方式。
Spring Cloud包含了多個子項目(針對分布式系統(tǒng)中涉及的多個不同開源產(chǎn)品，還可能會新增)， 如下所述。
Spring Cloud Config: 配置管理工具， 支持使用Git存儲 配置內(nèi)容， 可以使用它實現(xiàn)應用配置的外部化存儲， 并支持客戶端配置信息刷新、 加密／解密配置內(nèi)容 等。

• Spring Cloud Netflix: 核心 組件， 對多個Netflix OSS開源套件進行整合。
  • Eureka: 服務(wù)治理組件， 包含服務(wù)注冊中心、 服務(wù)注冊與發(fā)現(xiàn)機制的實現(xiàn)。
  • Hystrix: 容錯管理組件，實現(xiàn)斷路器模式， 幫助服務(wù)依賴中出現(xiàn)的延遲和為故障提供強大的容錯能力。
  • Ribbon: 客戶端負載均衡的服務(wù)調(diào)用組件。
  • Feign: 基于伈bbon 和 Hystrix 的聲明式服務(wù)調(diào)用組件。
  • Zuul: 網(wǎng)關(guān)組件， 提供智能路由、 訪問過濾等功能。
  • Archaius: 外部化配置組件。
• Spring Cloud Bus: 事件、 消息總線， 用于傳播集群中的狀態(tài)變化或事件， 以觸發(fā)后續(xù)的處理， 比如用來動態(tài)刷新配置等。
• Spring Cloud Cluster: 針對 ZooKeeper、 Redis、 Hazelcast、 Consul 的選舉算法和通用狀態(tài)模式的實現(xiàn)。
• Spring Cloud Cloudfoundry: 與 Pivotal Cloudfoundry 的整合支持。
• Spring Cloud Consul: 服務(wù)發(fā)現(xiàn)與配置管理工具。
• Spring Cloud Stream: 通過 Redis、 Rabbit 或者 Kafka 實現(xiàn)的消費微服務(wù)， 可以通過簡單的聲明式模型來發(fā)送和接收消息。
  Spring Cloud AWS: 用千簡化整合 Amazon Web Service 的組件。
• Spring Cloud Security: 安全工具包， 提供在 Zuul 代理中對 0Auth2 客戶端請求的中繼器。
• Spring Cloud Sleuth: Spring Cloud 應用的分布式跟蹤實現(xiàn)， 可以完美整合 Zip虹n。
• Spring Cloud ZooKeeper: 基于 ZooKeeper 的服務(wù)發(fā)現(xiàn)與配置管理組件。
• Spring Cloud Starters: Spring Cloud 的基礎(chǔ)組件， 它是基于 Spring Boot 風格項目的基礎(chǔ)依賴模塊。
• Spring Cloud CLI: 用于在 Groovy 中快速創(chuàng)建 Spring Cloud 應用的 Spring Boot CLI插件。
• ......

總結(jié)

以上是生活随笔為你收集整理的微服务之基础知识的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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