前言

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

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

Paste_Image.png

現(xiàn)代互聯(lián)網(wǎng)的方向是當企業(yè)發(fā)展到一定規(guī)模后，一定是大規(guī)模、云計算和大數(shù)據(jù)的三者的結合，從而形成平臺，那么微服務就是基于此而提出的。

一、什么是微服務

1、常見的系統(tǒng)架構
目前我們經(jīng)常接觸的網(wǎng)絡架構主要有三種，如下圖：

Paste_Image.png

2、現(xiàn)實遇到的挑戰(zhàn)

• 擴容困難 我們之前開發(fā)項目用的是虛擬機，每次上線項目需要加機器總會遇到資源不足的情況，還要走非常復雜工單審批流程，還要與運維人員不斷PK，才能申請下來資源，整個流程冗長，機器受限于資源申請困難。

• 部署困難
  每次上線采用專門的人進行布署，上線之前需要與上線人員溝通上線的環(huán)境，防止上線出錯。

• 發(fā)布回滾困難
  每次上線發(fā)現(xiàn)問題后，需要重新從svn主干上面進行代碼編譯，但是有時候會因為各種問題回滾失敗，而且重新編譯很耗時導致回滾緩慢。

• 適配新技術困難
  如果打算在不同的模塊采用不同的語言開發(fā)，或者想在架構中做技術升級都很困難或者不支持。

• 快速開發(fā)困難
  項目中采用單體應用，里面集成了太多功能模塊，無法快速進行功能開發(fā)并且很容易牽一發(fā)動全身。

• 測試困難
  測試人員沒有自動化測試框架，或者Mock系統(tǒng)，導致只能采用簡單的人工測試流程，而且還經(jīng)常發(fā)生功能覆蓋不全面等問題。

• 學習困難

于是我們把項目中遇到上述問題的項目稱為單體應用。

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.
– James Lewis and Martin Fowler
原文：http://martinfowler.com/articles/microservices.html
翻譯文：http://blog.csdn.net/u013970991/article/details/53333921

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

• 一些列的獨立的服務共同組成系統(tǒng)
• 單獨部署，跑在自己的進程里
• 每個服務為獨立的業(yè)務開發(fā)
• 分布式的管理

Paste_Image.png

4、微服務和SOA的區(qū)別

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

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

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

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

• SOA是重ESB，微服務是輕網(wǎng)關。

5、微服務定義小結

Paste_Image.png

二、關于微服務的建模

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

1、松耦合和高內聚
松耦合：修改一個服務不需要同時修改另一個，每個微服務都可以單獨修改和布署。
高內聚：把相關的事務放在一起，把不相關的排除出去，聚集在一起的事務只能干同一件事。
用如下圖可以清晰的表示：

Paste_Image.png

2、限界上下文
限界：就是劃分、規(guī)定，界限、邊界。
上下文：是業(yè)務的整個流程。

Paste_Image.png

當我們檢查已有的系統(tǒng)時，經(jīng)常會發(fā)現(xiàn)系統(tǒng)中存在混雜在一起的模型，他們之間的邊界是非常模糊的。此時你應該為整個系統(tǒng)繪制一個邊界，然后將其歸納在大泥球范圍之內。往往在我們所在的項目中，經(jīng)常是項目版本的迭代的時候出現(xiàn)這樣的情況，導致后期維護代碼越來越困難。

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

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

這里寫圖片描述

!

Paste_Image.png

正如上面二個圖的示例所示，圖一的訂單處理，貨物接收和庫存管理三個模塊在項目研發(fā)初期被歸集到了倉庫服務中，財務服務獲取庫存管理的數(shù)據(jù)，直接訪問倉庫服務的庫存管理接口就可以了。隨著這三個模塊的不斷演進和壯大，單個服務已經(jīng)不能滿足業(yè)務和團隊發(fā)展的需求，這時候將這三個模塊分別拆分演變成圖二的結構圖，這時候訂單管理，貨物接收和庫存管理分別以服務的形式對應不同的團隊，財務服務只需請求庫存管理服務就可以得到相應的數(shù)據(jù)。

三、關于微服務的集成

1、集成原則
微服務的集成做到好，可以保持自治性、可以獨立發(fā)布修改和發(fā)布。

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

2、編排與協(xié)同
編排：同步調用一組服務，等待各個服務的返回結果。優(yōu)點知道業(yè)務流程中每一步跨服務調用結果，缺點容易承擔太多的調用，太耗時，導致調用方的不穩(wěn)定性。
協(xié)同：異步調用一組服務或服務調用加入隊列中，降低服務之間的耦合度，帶來的額外工作業(yè)務流程跨服務的監(jiān)控，不過可通過消費方處理完成后，回調服務方告知處理結果。

這里寫圖片描述

（編排）

Paste_Image.png

（協(xié)同）

3、版本管理

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

• 盡早發(fā)現(xiàn)破壞性的修改 按照契約，通過測試及早發(fā)現(xiàn)是服務方還是消費方破壞性的修改

• 不同的接口版本共存 最好共存兩個版本

4、案例分析

案例一：如何拆分單塊系統(tǒng)結構

Paste_Image.png

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

案例二：如何跨系統(tǒng)訪問數(shù)據(jù)表

Paste_Image.png

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

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

Paste_Image.png

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

四、如何大規(guī)模的使用微服務

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

1、故障無所不在
網(wǎng)絡是不可靠，只能盡力限制引起故障的因數(shù)，達到一定規(guī)模后，故障不可避免。
2、跨功能需求
服務吞吐量、可用性和數(shù)據(jù)持久性等這些需求需要持續(xù)測量，并保證服務滿足可接受的目標。
3、功能降級
構建彈性系統(tǒng)，因微服務功能分散，在有可能down機的微服務上，能夠安全的降級以保證彈性
4、反服務脆弱
為了不會引起嚴重級聯(lián)影響，需要正確的設置超時、實現(xiàn)艙壁隔離或斷路層等以避免在第一時間調用一個不健康的服務。

• 超時
  設置超時時間對于調用下游服務十分重要，超時時間設置太長有可能把下游系統(tǒng)拖慢，設置太短可能下游服務未處理完成。最好設置一個默認的超時時間，當超時發(fā)生時后，記錄到日志里看看發(fā)生了什么，并且做響應的調整。

• 斷路器
  使用斷路器，當請求下游服務發(fā)生一定數(shù)量的失敗后，短路器打開，接下來的請求快速失敗。一斷時間后，查看下游服務是否已服務，重置斷路器。

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

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

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

6、擴展
增加負載、減少延遲。

• 更強大的主機：垂直擴展，更好的機器。
• 拆分負載：按業(yè)務拆分成不同的微服務
• 分散風險：數(shù)據(jù)跨機房，異地備份等
• 負載均衡：避免服務單點故障
• 作業(yè)分離：Job獨立服務執(zhí)行
• 重新設計：一般設計系統(tǒng)需要考慮10倍容量增長。重新設計系統(tǒng)應對規(guī)模化，是成功的標志。

7、擴展數(shù)據(jù)庫

• 服務的可用性
• 服務的持久性：多副本
• 讀取數(shù)據(jù)擴展：讀寫分離
• 寫操作擴展：分表分庫
• 共享數(shù)據(jù)庫設施：容易形成單點故障
• CQRS：命令查詢職責分離

8、緩存的使用
通過存儲之前的操作結果，以便后續(xù)請求使用這個結果，而無需花重新計算或查詢。

• 客戶端緩存
  客戶端緩存獲取的結果，客戶端決定何時獲取新副本。一般是有下游服務提供緩沖的過期時間。客戶端緩存可以減少網(wǎng)絡調用次數(shù)，并且減少下游服務負載的最快方法之一，客戶端緩存數(shù)據(jù)，讓數(shù)據(jù)失效需要做額外的工作。

• 服務端緩存
  服務端來負責處理緩存，容易跟蹤和優(yōu)化緩存的命中率。

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

• HTTP緩存

• 為寫使用緩存
  先寫入本地緩存，之后某個時刻將數(shù)據(jù)寫入下游的，可能更規(guī)范化的數(shù)據(jù)源中。

• 為彈性使用緩存
  下游服務不可用，客戶端可以緩存可能失效的數(shù)據(jù)。

• 隱藏源服務
  保護源服務，不直接暴露源服務。如果緩存不命中，立即失敗，異步重建緩存。

• 保持簡單
  避免太多地方使用緩存，緩存越多，數(shù)據(jù)越可能失效，就越難保證數(shù)據(jù)的新鮮程度。

9、自動伸縮
響應型伸縮、預測型伸縮

10、CAP定理
在分布式系統(tǒng)中有三方面需要彼此權衡：一致性、可用性和分區(qū)容忍性。這個定理告之我們最多只能能保證三個中的兩個。CA系統(tǒng)在分布式系統(tǒng)中根本不存在。

六、階段總結：

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

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