前言

一直對微服務非常感興趣，因為公司的架構改造正好有機會能夠接觸微服務，買來一些書，請教了很多微服務大牛同時自己也做了很多總結，寫成了80頁ppt，算是我對微服務的一個認識吧，微服務本身不同的人有不同的理解，而我就從我自己的角度來談談微服務是什麼。

目前市面上的不少書或者不少相關文章寫的都是框架的使用，或者架構的介紹，其實對於剛入門不久的同學來說很容易造成微服務就是一堆框架和元件的堆砌，於是今天我將從理論和實踐的角度來說說微服務。

現代網際網路的方向是當企業發展到一定規模後，一定是大規模、雲端計算和大資料的三者的結合，從而形成平臺，那麼微服務就是基於此而提出的。

一、什麼是微服務

1、常見的系統架構

目前我們經常接觸的網路架構主要有三種，如下圖：

從圖中可以看到，共有三種模式，第一種是集中式架構也是單塊應用最常使用的架構模式。第二種是分散式架構，最常見的應用是將一個大的任務拆分到不同的機器中進行計算，最終有一臺伺服器合併計算結果就是分散式架構的一個好的體現。第三種就是微服務架構。

2、現實遇到的挑戰

• 擴容困難
  我們之前開發專案用的是虛擬機器，每次上線專案需要加機器總會遇到資源不足的情況，還要走非常複雜工單審批流程，還要與運維人員不斷PK，才能申請下來資源，整個流程冗長，機器受限於資源申請困難。
• 部署困難
  每次上線採用專門的人進行佈署，上線之前需要與上線人員溝通上線的環境，防止上線出錯。
• 釋出回滾困難
  每次上線發現問題後，需要重新從svn主幹上面進行程式碼編譯，但是有時候會因為各種問題回滾失敗，而且重新編譯很耗時導致回滾緩慢。
• 適配新技術困難
  如果打算在不同的模組採用不同的語言開發，或者想在架構中做技術升級都很困難或者不支援。
• 快速開發困難
  專案中採用單體應用，裡面集成了太多功能模組，無法快速進行功能開發並且很容易牽一髮動全身。
• 測試困難
  測試人員沒有自動化測試框架，或者Mock系統，導致只能採用簡單的人工測試流程，而且還經常發生功能覆蓋不全面等問題。
• 學習困難

於是我們把專案中遇到上述問題的專案稱為單體應用。

3、微服務的定義

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.

總結了一下共有四點特性：

• 一些列的獨立的服務共同組成系統
• 單獨部署，跑在自己的程序裡
• 每個服務為獨立的業務開發
• 分散式的管理

4、微服務和SOA的區別

• 微服務只是一種為經過良好架構設計的SOA解決方案，是面向服務的交付方案。

• 微服務更趨向於以自治的方式產生價值。

• 微服務與敏捷開發的思想高度結合在一起，服務的定義更加清晰，同時減少了企業ESB開發的複雜性。

• 微服務是soa思想的一種提煉！

• SOA是重ESB，微服務是輕閘道器。

5、微服務定義小結

二、關於微服務的建模

我們在談建模，首先想到的是領域驅動設計的內容，沒錯，微服務的建模思想也是基於建模的思想，下面我將給簡單給與介紹什麼樣的服務才算是好服務。

1、鬆耦合和高內聚

鬆耦合：修改一個服務不需要同時修改另一個，每個微服務都可以單獨修改和佈署。
高內聚：把相關的事務放在一起，把不相關的排除出去，聚集在一起的事務只能幹同一件事。

用如下圖可以清晰的表示：

2、限界上下文

限界：就是劃分、規定，界限、邊界。
上下文：是業務的整個流程。

當我們檢查已有的系統時，經常會發現系統中存在混雜在一起的模型，他們之間的邊界是非常模糊的。此時你應該為整個系統繪製一個邊界，然後將其歸納在大泥球範圍之內。往往在我們所在的專案中，經常是專案版本的迭代的時候出現這樣的情況，導致後期維護程式碼越來越困難。

3、逐步上下文

• 劃分方法：一開始識別粗粒度的限界上下文、這些粗粒度的上下文可能包括一些套嵌的限界上下文，這些套嵌的上下文不直接對外可見。

• 暴露原則：使用粗粒度上下文還是套嵌上下文暴露服務，哪個更合理，應該有組織結構來決定的。

正如上面二個圖的示例所示，左邊的訂單處理，貨物接收和庫存管理三個模組在專案研發初期被歸集到了倉庫服務中，財務服務獲取庫存管理的資料，直接訪問倉庫服務的庫存管理介面就可以了。隨著這三個模組的不斷演進和壯大，單個服務已經不能滿足業務和團隊發展的需求，這時候將這三個模組分別拆分演變成右邊的結構圖，這時候訂單管理，貨物接收和庫存管理分別以服務的形式對應不同的團隊，財務服務只需請求庫存管理服務就可以得到相應的資料。

三、關於微服務的整合

1、整合原則

微服務的整合做到好，可以保持自治性、可以獨立釋出修改和釋出。

• 避免破壞性修改
  服務的一些修改不能導致該服務的消費方發生改變。
• 保證API與技術的無關性
• 保證API的易用性
• 隱藏內部實現細節

2、編排與協同

編排：同步呼叫一組服務，等待各個服務的返回結果。優點知道業務流程中每一步跨服務呼叫結果，缺點容易承擔太多的呼叫，太耗時，導致呼叫方的不穩定性。

協同：非同步呼叫一組服務或服務呼叫加入佇列中，降低服務之間的耦合度，帶來的額外工作業務流程跨服務的監控，不過可通過消費方處理完成後，回撥服務方告知處理結果。

（編排）

（協同）

3、版本管理

• 儘可能推遲破壞性修改
  寬進嚴出的原則

• 儘早發現破壞性的修改
  按照契約，通過測試及早發現是服務方還是消費方破壞性的修改

• 不同的介面版本共存
  最好共存兩個版本

4、案例分析

案例一：如何拆分單塊系統結構

當我們看到一個單塊系統時，往往首先要從資料庫入手進行拆分，規劃好哪些是財務程式碼的表，哪些是客戶程式碼的表，將二者進行分離，這時候單塊系統的應用結構並沒有拆分，這還需要我們在進行設計單塊系統的時候，客戶代表和財務程式碼的表字段不能混在一起，還是要設計成不同的表才能方便我們將來拆分，雖然系統是在一起的，但是卻為未來做了拆分準備，最後將應用系統拆分獨立佈署，這個過程就結束了。

案例二：如何跨系統訪問資料表

有二個服務，分別是產品目錄和財務，左圖的場景是財務服務直接呼叫產品目錄的資料表進行資料獲取，這種跨服務的資料獲取方式是有問題的，首先我們無法把控財務服務是如何獲取資料的，是否對我們的資料表造成影響，其次從設計的角度來說無疑又增長了系統之間呼叫的耦合度，系統之間的依賴又增強了。於是演變成右圖這樣，左圖只需提供服務介面給右圖呼叫即可。

案例三：服務設計中的壞味道

在這樣的系統中，ABCD四個系統進行了串聯，這樣也就要求這四個系統分別都是高可用，如果其中任何一個系統掛了或者發生問題，都會直接影響其他所有系統，所以我們設計微服務架構的時候要儘量避免這種集中式的架構。

四、如何大規模的使用微服務

我們真正使用微服務的時候，有很多需要注意和關注的點：

1、故障無所不在
網路是不可靠，只能盡力限制引起故障的因數，達到一定規模後，故障不可避免。

2、跨功能需求
服務吞吐量、可用性和資料永續性等這些需求需要持續測量，並保證服務滿足可接受的目標。

3、功能降級
構建彈性系統，因微服務功能分散，在有可能down機的微服務上，能夠安全的降級以保證彈性

4、反服務脆弱
為了不會引起嚴重級聯影響，需要正確的設定超時、實現艙壁隔離或斷路層等以避免在第一時間呼叫一個不健康的服務。

• 超時
  設定超時時間對於呼叫下游服務十分重要，超時時間設定太長有可能把下游系統拖慢，設定太短可能下游服務未處理完成。最好設定一個預設的超時時間，當超時發生時後，記錄到日誌裡看看發生了什麼，並且做響應的調整。

• 斷路器
  使用斷路器，當請求下游服務發生一定數量的失敗後，短路器開啟，接下來的請求快速失敗。一斷時間後，檢視下游服務是否已服務，重置斷路器。

• 艙壁
  為每個下游服務建立單獨的連線池。超時和斷路器資源受限時釋放資源，艙壁第一時間確保它不成為限制。還有一個拒絕請求的艙壁，用以避免資源飽和，稱之為減載。

• 隔離
  當下遊服務離線，上游服務不受影響。設定成為服務間隔離。

5、冪等

冪等操作，多次執行所產生的影響，均與一次執行影響相同。可以把某些特定業務操作設計成冪等的，比如客戶下單送積分。

6、擴充套件

增加負載、減少延遲。

• 更強大的主機：垂直擴充套件，更好的機器。
• 拆分負載：按業務拆分成不同的微服務
• 分散風險：資料跨機房，異地備份等
• 負載均衡：避免服務單點故障
• 作業分離：Job獨立服務執行
• 重新設計：一般設計系統需要考慮10倍容量增長。重新設計系統應對規模化，是成功的標誌。

7、擴充套件資料庫

• 服務的可用性
• 服務的永續性：多副本
• 讀取資料擴充套件：讀寫分離
• 寫操作擴充套件：分表分庫
• 共享資料庫設施：容易形成單點故障
• CQRS：命令查詢職責分離

8、快取的使用

通過儲存之前的操作結果，以便後續請求使用這個結果，而無需花重新計算或查詢。

• 客戶端快取
  客戶端快取獲取的結果，客戶端決定何時獲取新副本。一般是有下游服務提供緩衝的過期時間。客戶端快取可以減少網路呼叫次數，並且減少下游服務負載的最快方法之一，客戶端快取資料，讓資料失效需要做額外的工作。

• 服務端快取
  服務端來負責處理快取，容易跟蹤和優化快取的命中率。

• 代理伺服器快取
  快取在服務的和客戶端之間，比如方向代理或CDN等。對一切客戶端和服務端不透明

• HTTP快取

• 為寫使用快取
  先寫入本地快取，之後某個時刻將資料寫入下游的，可能更規範化的資料來源中。

• 為彈性使用快取
  下游服務不可用，客戶端可以快取可能失效的資料。

• 隱藏源服務
  保護源服務，不直接暴露源服務。如果快取不命中，立即失敗，非同步重建快取。

• 保持簡單
  避免太多地方使用快取，快取越多，資料越可能失效，就越難保證資料的新鮮程度。

9、自動伸縮

響應型伸縮、預測型伸縮

10、CAP定理

在分散式系統中有三方面需要彼此權衡：一致性、可用性和分割槽容忍性。這個定理告之我們最多隻能能保證三個中的兩個。CA系統在分散式系統中根本不存在。

六、階段總結：

在第一部分我們重點介紹了涉及微服務的一些思想，總結了如何設計一個相對好的服務，並且也介紹了一些微服務和領域驅動的相關概念幫助大家學習掌握。

那麼在第二部分介紹中，我將在如何在微服務中使用事務，自動化測試怎麼做，Devops是什麼，如何利用康威定律管理團隊，以及重點介紹實戰專案，如何基於Spring boot/netflix來構建微服務專案。