2019獨角獸企業重金招聘Python工程師標準>>>

什么是微服務？

---

微服務（Microservice Architecture）是近幾年流行的一種架構思想，關于它的概念很難一言以蔽之

究竟什么是微服務呢？我們在此引用 ThoughtWorks 公司的首席科學家 Martin Fowler 的一段話：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

看不懂？？？我有什么辦法，反正我能看得懂

我們先來看看傳統的項目模式

這是一個辦公系統示例，里面有好幾個模塊，那么假設有個 low 逼程序員寫了個性能非常差的代碼在財務管理這個模塊里面，導致數據庫崩潰，那么整個項目都會受到影響，這是非常糟糕的情況

所以我們來總結下傳統模式的缺點：

項目過于臃腫當大大小小的功能模塊都集中在同一項目的時候，整個項目必然會變得臃腫，讓開發者難以維護

資源無法隔離，整個系統的各個功能模塊都依賴于同樣的數據庫、內存等資源，一旦某個功能模塊對資源使用不當，整個系統都會被拖垮，耦合度太高

當系統的訪問量越來越大的時候無法靈活擴展，雖然可以進行水平擴展，部署在多臺機器上組成集群，但是這種擴展并非靈活的擴展。比如我們現在的性能瓶頸是支付模塊，希望只針對支付模塊做水平擴展，這一點在單體系統是做不到的

現在對上面的結構圖進行優化

我們將每個功能模塊提取出來單獨去開發部署，客戶端、每個模塊之間都可以互相調用實現解耦，當然這只是一個簡單的示例而已

微服務的特點：

獨立部署，靈活擴展傳統的單體架構是以整個系統為單位進行部署，而微服務則是以每一個獨立組件（例如員工管理服務，財務管理服務）為單位進行部署 用一張經典的圖來表現，就是下面這個樣子（左邊是傳統項目集群，右邊是微服務集群）：

? ? ? ? ?

資源的有效隔離微服務設計的原則之一，就是每一個微服務擁有獨立的數據源，假如微服務A想要讀寫微服務B的數據庫，只能調用微服務B對外暴露的接口來完成。這樣有效避免了服務之間爭用數據庫和緩存資源所帶來的問題

團隊組織架構的調整微服務設計的思想也改變了原有的企業研發團隊組織架構。傳統的研發組織架構是水平架構，前端有前端的團隊，后端有后端的團隊，DBA 有 DBA 的團隊，測試有測試的團隊。而微服務的設計思想對團隊的劃分有著一定的影響，使得團隊組織架構的劃分更傾向于垂直架構，比如用戶業務是一個團隊來負責，支付業務是一個團隊來負責（當然，這種垂直劃分只是一個理想的架構，實際在企業中并不會把團隊組織架構拆分得這么絕對）

網站架構演變過程

---

單體架構

單體架構也稱為傳統架構，說白了就是我們經常寫的 SSM 或者 SSH 應用，特點就是將整個業務都在一個項目中開發，整個項目一般都分控制層、業務邏輯層、數據訪問層，這種項目一般只適合小項目開發

缺點：耦合的太高，一旦某個模塊崩潰，可能會影響到整個項目的運行

分布式架構

分布式架構是基于傳統架構演變過來的，即將傳統的項目以模塊拆分成多個子項目，比如：會員項目、訂單項目、商品項目等。每個項目都有自己獨立的數據庫，注意這里是子項目，代表每個子項目都有完整的 mvc 結構

比較：分布式架構比傳統架構粒度更細，耦合度降低，更適合團隊開發

maven 管理的多模塊項目是分布式架構嗎？？

不一定，如果你僅僅是將項目拆分成 entity、service、dao 幾個子工程，然后通過 maven 依賴引入，那其實最終打包后還是一個 war 包啊，其實依然是一個項目。但是如果你打包成多個項目部署，互相通信，那可以稱為分布式項目

SOA架構

---

SOA:（Service Oriented Architecture） 面向服務的架構。把工程拆分成服務層、表現層兩個工程，服務層中包含業務邏輯，只需要對外提供服務即可。表現層只需處理和頁面的交互，業務邏輯都是調用服務層的服務來實現

SOA 是一個組件模型，它將應用程序的不同功能單元（成為服務），通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，他應該獨立于實現服務的硬件平臺、操作系統、和變成語言。這是的構建在各種各樣的系統中的服務可以從一種統一和通用的方式進行交互

SOA 是把服務分成了若干，表現層分成了若干。表現層和服務層沒有耦合關系，表現層可以用任意一個服務層，開發的時候，僅僅是增加服務層和 web 層2個工程，并不會把服務層和 web 層當成一個整個工程。他們是獨立的。而分布式架構是 web 和服務層緊緊聯系到了一起，一個 web 層對應一個服務層。所以 SOA 比分布式架構更加解耦合，擴展也更容易

標準架構圖：

核心組件：ESB 企業服務總線

ESB 全稱為 Enterprise Service Bus，即企業服務總線。它是傳統中間件技術與 XML、Web 服務等技術結合的產物。ESB 提供了網絡中最基本的連接中樞，是構筑企業神經系統的必要元素。ESB 的出現改變了傳統的軟件架構，可以提供比傳統中間件產品更為廉價的解決方案，同時它還可以消除不同應用之間的技術差異，讓不同的應用服務器協調運作，實現了不同服務之間的通信與整合

特點：

基于 SOA 的架構思想將重復公用的功能抽取為組件，以服務的方式給各各系統提供服務

各各項目（系統）與服務之間采用 webservice、rpc 等方式進行通信

ESB 企業服務總線作為項目與服務之間通信的橋梁

優點：

將重復的功能抽取為服務，提高開發效率，提高系統的可重用性、可維護性

可以針對不同服務的特點制定集群及優化方案

采用 ESB 減少系統中的接口耦合

缺點：

系統與服務的界限模糊，不利于開發及維護

雖然使用了 ESB，但是服務的接口協議不固定，種類繁多，不利于系統維護

抽取的服務的粒度過大，系統與服務之間耦合性高

轉載于:https://my.oschina.net/zhoumj/blog/3044837

總結

以上是生活随笔為你收集整理的springcloud 系列教程一：微服务与网站架构演变过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。