在多家傳統(tǒng)行業(yè)的企業(yè)走訪和落地了微服務(wù)之后，我發(fā)現(xiàn)落地微服務(wù)是一個非常復(fù)雜的問題，甚至都不完全是技術(shù)問題，它牽扯到 IT 架構(gòu)，應(yīng)用架構(gòu)，組織架構(gòu)多個方面。

當(dāng)時我想微服務(wù)既然是改造應(yīng)用，做微服務(wù)治理，類似注冊，發(fā)現(xiàn)，熔斷，限流，降級等，當(dāng)然應(yīng)該從應(yīng)用開發(fā)組切入。

 

一般一開始聊的會比較開心，從單體架構(gòu)，到 SOA，再到微服務(wù)架構(gòu)，從 Dubbo 聊到 Spring Cloud，但是必然會涉及到微服務(wù)的發(fā)布和運(yùn)維問題，涉及到 DevOps 和容器層。

這些都不在開發(fā)組的控制范圍內(nèi)，一旦拉進(jìn)運(yùn)維組，對于容器的接受程度就成了一個問題，和傳統(tǒng)物理機(jī)，虛擬機(jī)的差別，會帶來什么風(fēng)險等等。

尤其是容器絕對不是輕量級的虛擬化這件事情，就不是一時半會兒能說的明白的。

更何況就算說明白了，還有線上應(yīng)用容器，一旦出了事情，誰背鍋的問題，容器往往會導(dǎo)致應(yīng)用層和基礎(chǔ)設(shè)施層界限模糊，這使得背鍋雙方都會猶豫不決。

有的企業(yè)的微服務(wù)化是運(yùn)維部門發(fā)起的，運(yùn)維部門已經(jīng)意識到了各種各樣不統(tǒng)一的應(yīng)用給運(yùn)維帶來的苦，也樂意接受容器的運(yùn)維模式。

這就涉及到容器直接的服務(wù)發(fā)現(xiàn)是否應(yīng)該運(yùn)維在容器層搞定，還是應(yīng)用應(yīng)該自己搞定的問題，還涉及 Dockerfile 到底是開發(fā)寫還是運(yùn)維寫的問題。

一旦容器化的過程中，開發(fā)不配合，運(yùn)維單方面去做這個事情，是徒增煩惱卻收益有限的。

下圖是微服務(wù)實施的過程中涉及到的層次，具體的描述參考《云架構(gòu)師進(jìn)階攻略》：

 

在一些相對先進(jìn)的企業(yè)，會在運(yùn)維組和開發(fā)組之間，有個中間件組，或者叫做架構(gòu)組來負(fù)責(zé)推動微服務(wù)化改造的事情。

架構(gòu)組既需要負(fù)責(zé)勸說業(yè)務(wù)開發(fā)實施微服務(wù)化，也要勸說運(yùn)維組實施容器化，如果架構(gòu)組的權(quán)威性不足，推動往往也會比較困難。

所以微服務(wù)，容器，DevOps 的推動，不單單是一個技術(shù)問題，更是一個組織問題。

在推動微服務(wù)的過程中，更加能夠感覺到康威定律的作用，需要更高層次技術(shù)總監(jiān)或者 CIO 的介入，方能夠推動微服務(wù)的落地。

然而到了 CIO 層，在很多企業(yè)又體會不到技術(shù)層面的痛點了，而更加關(guān)注業(yè)務(wù)的層面了。

只要業(yè)務(wù)能賺錢，架構(gòu)的痛，中間件的痛，運(yùn)維的痛，高層不是非常能夠感知，也就體會不到微服務(wù)，容器化的技術(shù)優(yōu)勢了。

而微服務(wù)和容器化對于業(yè)務(wù)的優(yōu)勢，很多廠家在說，能夠說到表面，說不到心里。

因而微服務(wù)和容器化的改造，更加容易發(fā)生在一個扁平化的組織里面，由一個能夠體會到基層技術(shù)細(xì)節(jié)的痛的 CIO，高瞻遠(yuǎn)矚的推動這件事情。

這也是為什么微服務(wù)的落地一般率先落地在互聯(lián)網(wǎng)公司，因為互聯(lián)網(wǎng)公司的組織架構(gòu)實在太平臺，哪怕是高層，也離一線非常的近，了解一線的痛。

然而在傳統(tǒng)行業(yè)就沒有那么幸運(yùn)了，層級往往會比較多，這個時候就需要技術(shù)上的痛足夠痛，能夠痛到影響業(yè)務(wù)，能夠痛到影響收入，能夠痛到被競爭對手甩在后面，才能上達(dá)天聽。

我們接下來就梳理一下，在這個過程中的那些痛。

階段一：單體架構(gòu)群，多個開發(fā)組，統(tǒng)一運(yùn)維組

 

階段一的組織狀態(tài)

階段一的組織狀態(tài)相對簡單，統(tǒng)一的運(yùn)維組，管理物理機(jī)，物理網(wǎng)絡(luò)，Vmware 虛擬化等資源，同時部署上線由運(yùn)維部負(fù)責(zé)。

開發(fā)組每個業(yè)務(wù)都是獨(dú)立的，負(fù)責(zé)寫代碼，不同的業(yè)務(wù)溝通不多，開發(fā)除了做自己的系統(tǒng)外，還需要維護(hù)外包公司開發(fā)的系統(tǒng)，由于不同的外包公司技術(shù)選型差異較大，因而處于煙囪式的架構(gòu)狀態(tài)。

傳統(tǒng)煙囪式架構(gòu)如下圖所示：

 

階段一的運(yùn)維模式

在傳統(tǒng)架構(gòu)下，基礎(chǔ)設(shè)施層往往采取物理機(jī)或者虛擬化進(jìn)行部署，為了不同的應(yīng)用之間方便相互訪問，多采取橋接扁平二層機(jī)房網(wǎng)絡(luò)，即所有的機(jī)器的 IP 地址都是可以相互訪問的，不想互相訪問的，多采用防火墻進(jìn)行隔離。

無論是使用物理機(jī)，還是虛擬化，配置是相對復(fù)雜的，不是做過多年運(yùn)維的人員，難以獨(dú)立的創(chuàng)建一臺機(jī)器，而且網(wǎng)絡(luò)規(guī)劃也需要非常小心，分配給不同業(yè)務(wù)部門的機(jī)器，網(wǎng)段不能沖突。

所有這一切，都需要運(yùn)維部門統(tǒng)一進(jìn)行管理，一般的 IT 人員或者開發(fā)人員既沒有專業(yè)性，也不可能給他們權(quán)限進(jìn)行操作，要申請機(jī)器怎么辦，走個工單，審批一下，過一段時間，機(jī)器就能創(chuàng)建出來。

階段一的應(yīng)用架構(gòu)

傳統(tǒng)架構(gòu)數(shù)據(jù)庫層，由于外包公司獨(dú)立開發(fā)，或者不同開發(fā)部門獨(dú)立開發(fā)，不同業(yè)務(wù)使用不同的數(shù)據(jù)庫，有用 Oracle 的，有用 SQL Server 的，有用 MySQL 的，有用 MongoDB 的，各不相同。

傳統(tǒng)架構(gòu)的中間件層，每個團(tuán)隊獨(dú)立選型中間件：

• 文件：NFS，F(xiàn)TP，Ceph，S3。
• 緩存：Redis Cluster，主備，Sentinel，Memcached。
• 分布式框架：Spring Cloud，Dubbo，Restful or RPC 不同的部門自己選型。
• 分庫分表：Sharding-jdbc，Mycat。
• 消息隊列：RabbitMQ，Kafka。
• 注冊中心：ZK，Euraka，Consul。

傳統(tǒng)架構(gòu)的服務(wù)層，系統(tǒng)或者由外包公司開發(fā)，或者由獨(dú)立團(tuán)隊開發(fā)。傳統(tǒng)架構(gòu)前端，各自開發(fā)各自的前端。

階段一有什么問題?

階段一沒有任何問題，我們甚至能找出一萬個理由說明這種模式的好處。運(yùn)維部和開發(fā)部是天然分開的，誰也不想管對方，兩邊的老大也是平級的，本相安無事。

機(jī)房當(dāng)然只能運(yùn)維人員能碰，這里面有安全的問題，專業(yè)性的問題，線上系統(tǒng)嚴(yán)肅的問題。

如果交給沒有那么專業(yè)的開發(fā)去部署環(huán)境，一旦系統(tǒng)有漏洞，誰能擔(dān)責(zé)任，一旦線上系統(tǒng)掛了，又是誰的責(zé)任，這個問題問出來，能夠讓任何爭論鴉雀無聲。

數(shù)據(jù)庫無論使用 Oracle，DB2，還是 SQL Server 都沒有問題，只要公司有足夠的預(yù)算，而且性能也的確杠杠的，里面存儲了大量存儲過程，會使得應(yīng)用開發(fā)簡單很多。

而且有專業(yè)的乙方幫忙運(yùn)維，數(shù)據(jù)庫如此關(guān)鍵，如果替換為 MySQL，一旦抗不出掛了，或者開源的沒人維護(hù)，線上出了事情，誰來負(fù)責(zé)?

中間件，服務(wù)層，前端，全部由外包商或者乙方搞定，端到端維護(hù)，要改什么招手即來，而且每個系統(tǒng)都是完整的一套，部署方便，運(yùn)維方便。

其實沒有任何問題，這個時候上容器或者上微服務(wù)，的確自找麻煩。

什么情況下才會覺得階段一有問題?

當(dāng)然最初的痛點應(yīng)該在業(yè)務(wù)層面，當(dāng)用戶的需求開始變的多種多樣，業(yè)務(wù)方時不時的就要上一個新功能。

做一個新系統(tǒng)的時候，你會發(fā)現(xiàn)外包公司不是能完全搞定所有的事情，他們是瀑布模型的開發(fā)，而且開發(fā)出來的系統(tǒng)很難變更，至少很難快速變更。

于是你開始想自己招聘一些開發(fā)，開發(fā)自己能夠把控的系統(tǒng)，至少能夠?qū)⑼獍鹃_發(fā)的系統(tǒng)接管過來，這個時候，應(yīng)對業(yè)務(wù)部門的需求，就會靈活的多。

但是自己開發(fā)和維護(hù)就帶來了新的問題，多種多樣的數(shù)據(jù)庫，根本不可能招聘到如此多樣的 DBA，人都非常的貴，而且隨著系統(tǒng)的增多，這些數(shù)據(jù)庫的 Lisense 也非常的貴。

多種多樣的中間件，每個團(tuán)隊獨(dú)立選型中間件，沒有統(tǒng)一的維護(hù)，沒有統(tǒng)一的知識積累，無法統(tǒng)一保障 SLA。

一旦使用的消息隊列，緩存，框架出了問題，整個團(tuán)隊沒有人能夠搞定這個事情，因為大家都忙于業(yè)務(wù)開發(fā)，沒人有時間深入的去研究這些中間件的背后原理，常見的問題，如何調(diào)優(yōu)等等。

前端框架也有相同的問題，技術(shù)棧不一致，界面風(fēng)格不一致，根本無法自動做 UI 測試。

當(dāng)維護(hù)了多套系統(tǒng)之后，你會發(fā)現(xiàn)，這些系統(tǒng)各個層次都有很多的共同點，很多能力是可以復(fù)用的，很多數(shù)據(jù)是可以打通的。

同樣一套邏輯，這里也有，那里也有，同樣類型的數(shù)據(jù)，這里一份，那里一份，但是信息是隔離的，數(shù)據(jù)模型不統(tǒng)一，根本無法打通。

當(dāng)出現(xiàn)這些問題的時候，才是您考慮進(jìn)入第二個階段的時候。

階段二：組織服務(wù)化，架構(gòu) SOA 化，基礎(chǔ)設(shè)施云化

 

階段二的組織形態(tài)

怎么解決上面的問題呢?根據(jù)康威定理，組織方面就需要有一定的調(diào)整，整個公司還是分運(yùn)維組和開發(fā)組。由于痛點是從業(yè)務(wù)層面發(fā)生的，開始調(diào)整的應(yīng)該是開發(fā)組。

應(yīng)該建立獨(dú)立的前端組，統(tǒng)一前端框架，界面一致，所有人掌握統(tǒng)一的前端開發(fā)能力，積累前端代碼，在有新的需求的時候，能夠快速的進(jìn)行開發(fā)。

建立中間件組，或者架構(gòu)師組，這部分人不用貼近業(yè)務(wù)開發(fā)，每天的任務(wù)就是研究如何使用這些中間件，如何調(diào)優(yōu)，遇到問題如何 Debug，形成知識積累。

如果有統(tǒng)一的一幫人專注中間件，就可以根據(jù)自身的情況，選擇有限幾個中間件集中研究，限定業(yè)務(wù)組只使用這些中間件，可保證選型的一致性，如果中間件被這個組統(tǒng)一維護(hù)，也可以提供可靠的 SLA 給業(yè)務(wù)方。

將業(yè)務(wù)開發(fā)組分出一部分來，建立中臺組，將可以復(fù)用的能力和代碼，交由這幾個組開發(fā)出服務(wù)來，給業(yè)務(wù)組使用。

這樣數(shù)據(jù)模型會統(tǒng)一，業(yè)務(wù)開發(fā)的時候，首先先看看有哪些現(xiàn)成的服務(wù)可以使用，不用全部從零開發(fā)，也會提高開發(fā)效率。

階段二的應(yīng)用架構(gòu)

要建立中臺，變成服務(wù)為其他業(yè)務(wù)使用，就需要使用 SOA 架構(gòu)，將可以復(fù)用的組件服務(wù)化，注冊到服務(wù)的注冊中心。

對于有錢的企業(yè)，可能會采購商用的 ESB 總線，也有使用 Dubbo 自己封裝稱為服務(wù)注冊中心。

接下來就是要考慮，哪些應(yīng)該拆出來? ***考慮的是如何拆出來?

這兩個題目的答案，不同的企業(yè)不同，其實分為兩個階段，***個階段是嘗試階段，也即整個公司對于服務(wù)化拆分沒有任何經(jīng)驗，當(dāng)然不敢拿核心業(yè)務(wù)上手，往往選取一個邊角的業(yè)務(wù)，先拆拆看。

這個時候拆本身是重要的，其實是為了拆而拆，拆的比較理想化，符合領(lǐng)域驅(qū)動設(shè)計的***，如何拆呢?

當(dāng)然是弄一個兩個月，核心員工大家閉門開發(fā)，進(jìn)行拆分和組合，來積累經(jīng)驗。很多企業(yè)目前處于這個階段。

但是其實這個階段的拆法也只能用來積累經(jīng)驗，因為咱們最初要拆分，是為了快速響應(yīng)業(yè)務(wù)請求，而這個邊角的模塊，往往不是最痛的核心業(yè)務(wù)。

本來業(yè)務(wù)就邊角，拆不拆收益不大，而且也沒辦法很好的做能力復(fù)用。復(fù)用當(dāng)然都想復(fù)用核心能力。

所以其實最重要的是第二個階段，業(yè)務(wù)真正的服務(wù)化的階段。當(dāng)然要拿業(yè)務(wù)需求最多的核心業(yè)務(wù)邏輯下手，才能起到快速響應(yīng)業(yè)務(wù)請求，復(fù)用能力的作用。

例如考拉最初也是一個使用 Oracle，對外只有一個 Online 業(yè)務(wù)的單體應(yīng)用，而真正的拆分，就是圍繞核心的下單業(yè)務(wù)邏輯進(jìn)行的。

 

那核心業(yè)務(wù)邏輯中，哪些應(yīng)該拆出來呢?很多企業(yè)會問我們，其實企業(yè)自己的開發(fā)最清楚。

這個時候經(jīng)常犯的錯誤是，先將核心業(yè)務(wù)邏輯從單體應(yīng)用中拆分出來。例如將下單邏輯形成下單服務(wù)，從 Online 服務(wù)中拆分出來。

當(dāng)然不應(yīng)該這樣，例如兩軍打仗，當(dāng)炊事班的煙熏著戰(zhàn)士了，是將中軍大營搬出去，還是講炊事班搬出去呢?當(dāng)然是炊事班了。

另外一點是，能夠形成復(fù)用的組件，往往不是核心業(yè)務(wù)邏輯。這個很好理解，兩個不同的業(yè)務(wù)，當(dāng)然是核心業(yè)務(wù)邏輯不同(要不就成一種業(yè)務(wù)了)。

核心業(yè)務(wù)邏輯往往是組合邏輯，雖然復(fù)雜，但是往往不具備復(fù)用性，就算是下單，不同的電商也是不一樣的。

這家推出了什么什么豆，那家推出了什么什么券，另一家有個什么什么活動，都是核心業(yè)務(wù)邏輯的不同，會經(jīng)常變。

能夠復(fù)用的，往往是用戶中心，支付中心，倉儲中心，庫存中心等等核心業(yè)務(wù)的周邊邏輯。

所以拆分，應(yīng)該將這些核心業(yè)務(wù)的周邊邏輯，從核心業(yè)務(wù)里面拆出來，最終 Online 就剩下下單的核心路徑了，就可以改成下單服務(wù)了。

當(dāng)業(yè)務(wù)方突然有了需求推出一個搶購活動，就可以復(fù)用剛才的周邊邏輯了。搶購就成了另一個應(yīng)用的核心邏輯，其實核心邏輯是穿針引線的，周邊邏輯是保存數(shù)據(jù)，提供原子化接口的。

那哪些周邊邏輯應(yīng)該先拆出來呢?問自己的開發(fā)吧，那些戰(zhàn)戰(zhàn)兢兢，自己修改后生怕把核心邏輯搞掛了的組，是自己有動力從核心邏輯中拆分出來的。

這個不需要技術(shù)總監(jiān)和架構(gòu)師去督促，他們有自己的原有動力，是一個很自然的過程。

 

這里的原有動力，一個是開發(fā)獨(dú)立，一個是上線獨(dú)立，就像考拉的 Online 系統(tǒng)里面，倉庫組就想自己獨(dú)立出去。

因為他們要對接各種各樣的倉儲系統(tǒng)，全球這么多的倉庫，系統(tǒng)都很傳統(tǒng)，接口不一樣，每新對接一個，開發(fā)的時候，都擔(dān)心把下單核心邏輯搞掛了，造成線上事故。

其實倉儲系統(tǒng)可以定義自己的重試和容災(zāi)機(jī)制，沒有下單那么嚴(yán)重。物流組也想獨(dú)立出去，因為對接的物流公司太多了，也要經(jīng)常上線，也不想把下單搞掛。

您也可以梳理一下貴公司的業(yè)務(wù)邏輯，也會有自行愿意拆分的業(yè)務(wù)，形成中臺服務(wù)。

當(dāng)周邊的邏輯拆分之后，一些核心的邏輯，互相怕影響，也可以拆分出去，例如下單和支付，支付對接多個支付方的時候，也不想影響下單，也可以獨(dú)立出去。

然后我們再看，如何拆分的問題?

關(guān)于拆分的前提，時機(jī)，方法，規(guī)范等，參考文章《微服務(wù)化之服務(wù)拆分與服務(wù)發(fā)現(xiàn)》：

 

首先要做的，就是原有工程代碼的標(biāo)準(zhǔn)化，我們常稱為“任何人接手任何一個模塊都能看到熟悉的面孔”。

例如打開一個 Java 工程，應(yīng)該有以下的 Package：

• API 接口包：所有的接口定義都在這里，對于內(nèi)部的調(diào)用，也要實現(xiàn)接口，這樣一旦要拆分出去，對于本地的接口調(diào)用，就可以變?yōu)檫h(yuǎn)程的接口調(diào)用。
• 訪問外部服務(wù)包：如果這個進(jìn)程要訪問其他進(jìn)程，對于外部訪問的封裝都在這里。
• 對于單元測試來講，對于這部分的 Mock，可以使得不用依賴第三方，就能進(jìn)行功能測試。對于服務(wù)拆分，調(diào)用其他的服務(wù)，也是在這里。
• 數(shù)據(jù)庫 DTO：如果要訪問數(shù)據(jù)庫，在這里定義原子的數(shù)據(jù)結(jié)構(gòu)。
• 訪問數(shù)據(jù)庫包：訪問數(shù)據(jù)庫的邏輯全部在這個包里面。
• 服務(wù)與商務(wù)邏輯：這里實現(xiàn)主要的商業(yè)邏輯，拆分也是從這里拆分出來。
• 外部服務(wù)：對外提供服務(wù)的邏輯在這里，對于接口的提供方，要實現(xiàn)在這里。

另外是測試文件夾，每個類都應(yīng)該有單元測試，要審核單元測試覆蓋率，模塊內(nèi)部應(yīng)該通過 Mock 的方法實現(xiàn)集成測試。

接下來是配置文件夾，配置 profile，配置分為幾類：

• 內(nèi)部配置項(啟動后不變，改變需要重啟)。
• 集中配置項(配置中心，可動態(tài)下發(fā))。
• 外部配置項(外部依賴，和環(huán)境相關(guān))。

當(dāng)一個工程的結(jié)構(gòu)非常標(biāo)準(zhǔn)化之后，接下來在原有服務(wù)中，先獨(dú)立功能模塊 ，規(guī)范輸入輸出，形成服務(wù)內(nèi)部的分離。

在分離出新的進(jìn)程之前，先分離出新的 Jar，只要能夠分離出新的 Jar，基本也就實現(xiàn)了松耦合。

接下來，應(yīng)該新建工程，新啟動一個進(jìn)程，盡早的注冊到注冊中心，開始提供服務(wù)，這個時候，新的工程中的代碼邏輯可以先沒有，只是轉(zhuǎn)調(diào)用原來的進(jìn)程接口。

為什么要越早獨(dú)立越好呢?哪怕還沒實現(xiàn)邏輯先獨(dú)立呢?因為服務(wù)拆分的過程是漸進(jìn)的，伴隨著新功能的開發(fā)，新需求的引入，這個時候，對于原來的接口，也會有新的需求進(jìn)行修改。

如果你想把業(yè)務(wù)邏輯獨(dú)立出來，獨(dú)立了一半，新需求來了，改舊的，改新的都不合適，新的還沒獨(dú)立提供服務(wù)，舊的如果改了，會造成從舊工程遷移到新工程，邊遷移邊改變，合并更加困難。

如果盡早獨(dú)立，所有的新需求都進(jìn)入新的工程，所有調(diào)用方更新的時候，都改為調(diào)用新的進(jìn)程，對于老進(jìn)程的調(diào)用會越來越少，最終新進(jìn)程將老進(jìn)程全部代理。

接下來就可以將老工程中的邏輯逐漸遷移到新工程，由于代碼遷移不能保證邏輯的完全正確，因而需要持續(xù)集成，灰度發(fā)布，微服務(wù)框架能夠在新老接口之間切換。

最終當(dāng)新工程穩(wěn)定運(yùn)行，并且在調(diào)用監(jiān)控中，已經(jīng)沒有對于老工程的調(diào)用的時候，就可以將老工程下線了。

階段二的運(yùn)維模式

經(jīng)過業(yè)務(wù)層的的服務(wù)化，也對運(yùn)維組造成了壓力。應(yīng)用逐漸拆分，服務(wù)數(shù)量增多。

在服務(wù)拆分的***實踐中，有一條就是，拆分過程需要進(jìn)行持續(xù)集成，保證功能一致。

 

而持續(xù)集成的流程，往往需要頻繁的部署測試環(huán)境。隨著服務(wù)的拆分，不同的業(yè)務(wù)開發(fā)組會接到不同的需求，并行開發(fā)功能增多，發(fā)布頻繁，會造成測試環(huán)境，生產(chǎn)環(huán)境更加頻繁的部署。

而頻繁的部署，就需要頻繁創(chuàng)建和刪除虛擬機(jī)。如果還是采用上面審批的模式，運(yùn)維部就會成為瓶頸，要不就是影響開發(fā)進(jìn)度，要不就是被各種部署累死。

這就需要進(jìn)行運(yùn)維模式的改變，也即基礎(chǔ)設(shè)施層云化。虛擬化到云化有什么不一樣呢?

首先要有良好的租戶管理，從運(yùn)維集中管理到租戶自助使用模式的轉(zhuǎn)換。

 

即人工創(chuàng)建，人工調(diào)度，人工配置的集中管理模式已經(jīng)成為瓶頸，應(yīng)該變?yōu)樽鈶糇灾墓芾?，機(jī)器自動的調(diào)度，自動的配置。

其次，要實現(xiàn)基于 Quota 和 QoS 的資源控制。

也即對于租戶創(chuàng)建的資源的控制，不用精細(xì)化到運(yùn)維手動管理一切，只要給這個客戶分配了租戶，分配了 Quota，設(shè)置了 Qos，租戶就可以在運(yùn)維限定的范圍內(nèi)，自由隨意的創(chuàng)建，使用，刪除虛擬機(jī)，無需通知運(yùn)維，這樣迭代速度就會加快。

再次，要實現(xiàn)基于虛擬網(wǎng)絡(luò)，VPC，SDN 的網(wǎng)絡(luò)規(guī)劃。

 

原來的網(wǎng)絡(luò)使用的都是物理網(wǎng)絡(luò)，問題在于物理網(wǎng)絡(luò)是所有部門共享的，沒辦法交給一個業(yè)務(wù)部門自由的配置和使用。

因而要有 VPC 虛擬網(wǎng)絡(luò)的概念，每個租戶可以隨意配置自己的子網(wǎng)，路由表，和外網(wǎng)的連接等，不同的租戶的網(wǎng)段可以沖突，互不影響，租戶可以根據(jù)自己的需要，隨意的在界面上，用軟件的方式做網(wǎng)絡(luò)規(guī)劃。

除了基礎(chǔ)設(shè)施云化之外，運(yùn)維部門還應(yīng)該將應(yīng)用的部署自動化。

 

因為如果云計算不管應(yīng)用，一旦出現(xiàn)擴(kuò)容，或者自動部署的需求，云平臺創(chuàng)建出來的虛擬機(jī)還是空的，需要運(yùn)維手動上去部署，根本忙不過來。因而云平臺，也一定要管理應(yīng)用。

云計算如何管理應(yīng)用呢?我們將應(yīng)用分成兩種，一種稱為通用的應(yīng)用，一般指一些復(fù)雜性比較高，但大家都在用的，例如數(shù)據(jù)庫。

幾乎所有的應(yīng)用都會用數(shù)據(jù)庫，但數(shù)據(jù)庫軟件是標(biāo)準(zhǔn)的，雖然安裝和維護(hù)比較復(fù)雜，但無論誰安裝都是一樣。

這樣的應(yīng)用可以變成標(biāo)準(zhǔn)的 PaaS 層的應(yīng)用放在云平臺的界面上。當(dāng)用戶需要一個數(shù)據(jù)庫時，一點就出來了，用戶就可以直接用了。

 

所以對于運(yùn)維模式的第二個改變是，通用軟件 PaaS 化。前面說過了，在開發(fā)部門有中間件組負(fù)責(zé)這些通用的應(yīng)用，運(yùn)維也自動部署這些應(yīng)用，兩個組的界限是什么樣的呢?

一般的實踐方式是，云平臺的 PaaS 負(fù)責(zé)創(chuàng)建的中間件的穩(wěn)定，保證 SLA，當(dāng)出現(xiàn)問題的時候，會自動修復(fù)。

而開發(fā)部門的中間件組，主要研究如何正確的使用這些 PaaS，配置什么樣的參數(shù)，使用的正確姿勢等等，這個和業(yè)務(wù)相關(guān)。

 

除了通用的應(yīng)用，還有個性化的應(yīng)用，應(yīng)該通過腳本進(jìn)行部署，例如工具 Puppet，Chef，Ansible，SaltStack 等。

這里有一個實踐是，不建議使用裸機(jī)部署，因為這樣部署非常的慢，推薦基于虛擬機(jī)鏡像的自動部署。

在云平臺上，任何虛擬機(jī)的創(chuàng)建都是基于鏡像的，我們可以在鏡像里面，將要部署的環(huán)境大部分部署好，只需要做少量的定制化，這些由部署工具完成。

 

下圖是 OpenStack 基于 Heat 的虛擬機(jī)編排，除了調(diào)用 OpenStack API 基于鏡像創(chuàng)建虛擬機(jī)之外，還要調(diào)用 SaltStack 的 Master，將定制化的指令下發(fā)給虛擬機(jī)里面的 Agent。

 

基于虛擬機(jī)鏡像和腳本下發(fā)，可以構(gòu)建自動化部署平臺 NDP：

 

這樣可以基于虛擬機(jī)鏡像，做完整的應(yīng)用的部署和上線，稱為編排?；诰幣?，就可以進(jìn)行很好的持續(xù)集成，例如每天晚上，自動部署一套環(huán)境，進(jìn)行回歸測試，從而保證修改的正確性。

 

進(jìn)行完第二階段之后，整個狀態(tài)如上圖所示。這里運(yùn)維部門的職能有了一定的改變，除了最基本的資源創(chuàng)建，還要提供自助的操作平臺，PaaS 化的中間件，基于鏡像和腳本的自動部署。

開發(fā)部門的職能也有了一定的改變，拆分稱為前端組，業(yè)務(wù)開發(fā)組，中臺組，中間件組，其中中間件組和運(yùn)維部門的聯(lián)系最緊密。

階段二有什么問題?

大部分的企業(yè)，到了這個階段，已經(jīng)可以解決大部分的問題了。能夠做到架構(gòu) SOA 化，基礎(chǔ)設(shè)施云化的公司已經(jīng)是傳統(tǒng)行業(yè)在信息化領(lǐng)域的佼佼者了。

中臺開發(fā)組基本能夠解決中臺的能力復(fù)用問題，持續(xù)集成也基本跑起來了，使得業(yè)務(wù)開發(fā)組的迭代速度明顯加快。

集中的中間件組或者架構(gòu)組，可以集中選型，維護(hù)，研究消息隊列，緩存等中間件。

在這個階段，由于業(yè)務(wù)的穩(wěn)定性要求，很多公司還是會采用 Oracle 商用數(shù)據(jù)庫，也沒有什么問題。

實現(xiàn)到了階段二，在同行業(yè)內(nèi)，已經(jīng)有一定的競爭優(yōu)勢了。

什么情況下才會覺得階段二有問題?

我們發(fā)現(xiàn)，當(dāng)傳統(tǒng)行業(yè)不再滿足于在本行業(yè)的領(lǐng)先地位，希望能夠?qū)拥交ヂ?lián)網(wǎng)業(yè)務(wù)的時候，上面的模式才出現(xiàn)新的痛點。

對接互聯(lián)網(wǎng)所面臨的***的問題，就是巨大的用戶量所帶來的請求量和數(shù)據(jù)量，會是原來的 N 倍，能不能撐得住，大家都心里沒底。

例如有的客戶推出互聯(lián)網(wǎng)理財秒殺搶購，原來的架構(gòu)無法承載近百倍的瞬間流量。

有的客戶對接了互聯(lián)網(wǎng)支付，甚至對接了國內(nèi)***的外賣平臺，而原來的 ESB 總線，就算擴(kuò)容到***規(guī)模(13 個節(jié)點)，也可能撐不住。

有的客戶雖然已經(jīng)用了 Dubbo 實現(xiàn)了服務(wù)化，但是沒有熔斷，限流，降級的服務(wù)治理策略，有可能一個請求慢，高峰期波及一大片，或者請求全部接進(jìn)來，***都撐不住而掛一片。

有的客戶希望實現(xiàn)工業(yè)互連網(wǎng)平臺，可是接入的數(shù)據(jù)量動輒 PB 級別，如果扛不住是一個很大的問題。

有的客戶起初使用開源的緩存和消息隊列，分布式數(shù)據(jù)庫，但是讀寫頻率到了一定的程度，就會出現(xiàn)各種奇奇怪怪的問題，不知道應(yīng)該如何調(diào)優(yōu)。

有的客戶發(fā)現(xiàn)，一旦到了互聯(lián)網(wǎng)大促級別，Oracle 數(shù)據(jù)庫是肯定扛不住的，需要從 Oracle 遷移到 DDB 分布式數(shù)據(jù)庫，可是怎么個遷移法，如何平滑過渡，心里沒底。

有的客戶服務(wù)拆分之后，原來原子化的操作分成了兩個服務(wù)調(diào)用，如何仍然保持原子化，要不全部成功，要不全部失敗，需要分布式事務(wù)，雖然業(yè)內(nèi)有大量的分布式方案，但是能夠承載高并發(fā)支付的框架還沒有。

當(dāng)出現(xiàn)這些問題的時候，才應(yīng)該考慮進(jìn)入第三個階段，微服務(wù)化。

階段三：組織 DevOps 化，架構(gòu)微服務(wù)化，基礎(chǔ)設(shè)施容器化

 

階段三的應(yīng)用架構(gòu)

從 SOA 到微服務(wù)化這一步非常關(guān)鍵，復(fù)雜度也比較高，上手需要謹(jǐn)慎。

為了能夠承載互聯(lián)網(wǎng)高并發(fā)，業(yè)務(wù)往往需要拆分的粒度非常的細(xì)，細(xì)到什么程度呢?我們來看下面的圖：

 

在這些知名的使用微服務(wù)的互聯(lián)網(wǎng)公司中，微服務(wù)之間的相互調(diào)用已經(jīng)密密麻麻相互關(guān)聯(lián)成為一個網(wǎng)狀，幾乎都看不出條理來。

為什么要拆分到這個粒度呢?主要是高并發(fā)的需求。但是高并發(fā)不是沒有成本的，拆分成這個粒度會有什么問題呢?

你會發(fā)現(xiàn)等拆完了，下面的這些措施一個都不能少：

• 拆分如何保證功能不變，不引入 Bug——持續(xù)集成。
• 靜態(tài)資源要拆分出來，緩存到接入層或者 CDN，將大部分流量攔截在離用戶近的邊緣節(jié)點或者接入層緩存。
• 應(yīng)用的狀態(tài)要從業(yè)務(wù)邏輯中拆分出來，使得業(yè)務(wù)無狀態(tài)，可以基于容器進(jìn)行橫向擴(kuò)展。
• 核心業(yè)務(wù)和非核心業(yè)務(wù)要拆分，方便核心業(yè)務(wù)的擴(kuò)展以及非核心業(yè)務(wù)的降級。
• 數(shù)據(jù)庫要讀寫分離，要分庫分表，才能在超大數(shù)據(jù)量的情況下，數(shù)據(jù)庫具有橫向擴(kuò)展的能力，不成為瓶頸。
• 要層層緩存，只有少數(shù)的流量到達(dá)中軍大營數(shù)據(jù)庫。
• 要使用消息隊列，將原來連續(xù)調(diào)用的多個服務(wù)異步化為監(jiān)聽消息隊列，從而縮短核心邏輯。
• 服務(wù)之間要設(shè)定熔斷，限流，降級策略，一旦調(diào)用阻塞應(yīng)該快速失敗，而不應(yīng)該卡在那里，處于亞健康狀態(tài)的服務(wù)要被及時熔斷，不產(chǎn)生連鎖反應(yīng)。
• 非核心業(yè)務(wù)要進(jìn)行降級，不再調(diào)用，將資源留給核心業(yè)務(wù)。要在壓測到的容量范圍內(nèi)對調(diào)用限流，寧可慢慢處理，也不用一下子都放進(jìn)來，把整個系統(tǒng)沖垮。
• 拆分成的服務(wù)太多了，沒辦法一個個配置，需要統(tǒng)一的一個配置中心，將配置下發(fā)。
• 拆分成的服務(wù)太多了，沒辦法一個個看日志，需要統(tǒng)一的日志中心，將日志匯總。
• 拆分成的服務(wù)太多了，很難定位性能瓶頸，需要通過APM全鏈路應(yīng)用監(jiān)控，發(fā)現(xiàn)性能瓶頸，及時修改。
• 拆分成的服務(wù)太多了，不壓測一下，誰也不知道到底能夠抗住多大的量，因而需要全鏈路的壓測系統(tǒng)。

 

應(yīng)用層需要處理這十二個問題，***一個都不能少，實施微服務(wù)，你做好準(zhǔn)備了嗎?你真覺得攢一攢 Spring Cloud，就能夠做好這些嗎?

階段三的運(yùn)維模式

業(yè)務(wù)的微服務(wù)化改造之后，對于運(yùn)維的模式是有沖擊的。

 

如果業(yè)務(wù)拆成了如此網(wǎng)狀的細(xì)粒度，服務(wù)的數(shù)目就會非常的多，每個服務(wù)都會獨(dú)立發(fā)布，獨(dú)立上線，因而版本也非常多。

這樣環(huán)境就會非常的多，手工部署已經(jīng)不可能，必須實施自動部署。好在在上一個階段，我們已經(jīng)實施了自動部署，或者基于腳本的，或者基于鏡像的，但是到了微服務(wù)階段都有問題。

如果基于腳本的部署，腳本原來多由運(yùn)維寫，由于服務(wù)太多，變化也多，腳本肯定要不斷的更新。

而每家公司的開發(fā)人員都遠(yuǎn)遠(yuǎn)多于運(yùn)維人員，運(yùn)維根本來不及維護(hù)自動部署的腳本。那腳本能不能由開發(fā)寫呢?

一般是不可行的，開發(fā)對于運(yùn)行環(huán)境了解有限，而且腳本沒有一個標(biāo)準(zhǔn)，運(yùn)維無法把控開發(fā)寫的腳本的質(zhì)量。

基于虛擬機(jī)鏡像的就會好很多，因為需要腳本做的事情比較少，大部分對于應(yīng)用的配置都打在鏡像里面了。

如果基于虛擬機(jī)鏡像進(jìn)行交付，也能起到標(biāo)準(zhǔn)交付的效果。而且一旦上線有問題，也可以基于虛擬機(jī)鏡像的版本進(jìn)行回滾。

但是虛擬機(jī)鏡像實在是太大了，動不動幾百個 G，如果一共一百個服務(wù)，每個服務(wù)每天一個版本，一天就是 10000G，這個存儲容量，誰也受不了。

這個時候，容器就有作用了。鏡像是容器的根本性發(fā)明，是封裝和運(yùn)行的標(biāo)準(zhǔn)，其他什么 namespace，cgroup，早就有了。

原來開發(fā)交付給運(yùn)維的，是一個 war 包，一系列配置文件，一個部署文檔，但是由于部署文檔更新不及時，常常出現(xiàn)運(yùn)維部署出來出錯的情況。

有了容器鏡像，開發(fā)交付給運(yùn)維的，是一個容器鏡像，容器內(nèi)部的運(yùn)行環(huán)境，應(yīng)該體現(xiàn)在 Dockerfile 文件中，這個文件是應(yīng)該開發(fā)寫的。

這個時候，從流程角度，將環(huán)境配置這件事情，往前推了，推到了開發(fā)這里，要求開發(fā)完畢之后，就需要考慮環(huán)境部署的問題，而不能當(dāng)甩手掌柜。

由于容器鏡像是標(biāo)準(zhǔn)的，就不存在腳本無法標(biāo)準(zhǔn)化的問題，一旦單個容器運(yùn)行不起來，肯定是 Dockerfile 的問題。

而運(yùn)維組只要維護(hù)容器平臺就可以，單個容器內(nèi)的環(huán)境，交給開發(fā)來維護(hù)。這樣做的好處就是，雖然進(jìn)程多，配置變化多，更新頻繁。

但是對于某個模塊的開發(fā)團(tuán)隊來講，這個量是很小的，因為 5-10 個人專門維護(hù)這個模塊的配置和更新，不容易出錯。自己改的東西自己知道。

如果這些工作量全交給少數(shù)的運(yùn)維團(tuán)隊，不但信息傳遞會使得環(huán)境配置不一致，部署量會大非常多。

容器作用之一就是環(huán)境交付提前，讓每個開發(fā)僅僅多做 5% 的工作，就能夠節(jié)約運(yùn)維 200% 的工作，并且不容易出錯。

 

 

容器的另外一個作用，就是不可改變基礎(chǔ)設(shè)施。容器鏡像有個特點，就是 SSH 到里面做的任何修改，重啟都不見了，恢復(fù)到鏡像原來的樣子，也就杜絕了原來我們部署環(huán)境，這改改，那修修***部署成功的壞毛病。

因為如果機(jī)器數(shù)目比較少，還可以登錄到每臺機(jī)器上改改東西，一旦出了錯誤，比較好排查。

但是微服務(wù)狀態(tài)下，環(huán)境如此復(fù)雜，規(guī)模如此大，一旦有個節(jié)點，因為人為修改配置導(dǎo)致錯誤，非常難排查，所以應(yīng)該貫徹不可改變基礎(chǔ)設(shè)施，一旦部署了，就不要手動調(diào)整了，想調(diào)整從頭走發(fā)布流程。

這里面還有一個概念叫做一切即代碼，單個容器的運(yùn)行環(huán)境 Dockerfile 是代碼，容器之間的關(guān)系編排文件是代碼，配置文件是代碼，所有的都是代碼。

代碼的好處就是誰改了什么，Git 里面一清二楚，都可以 Track，有的配置錯了，可以統(tǒng)一發(fā)現(xiàn)誰改的。

階段三的組織形態(tài)

到了微服務(wù)階段，實施容器化之后，你會發(fā)現(xiàn)，本來原來運(yùn)維該做的事情開發(fā)做了，開發(fā)的老大愿意么?開發(fā)的老大會投訴運(yùn)維的老大么?

這就不是技術(shù)問題了，其實這就是 DevOps，DevOps 不是不區(qū)分開發(fā)和運(yùn)維，而是公司從組織到流程，能夠打通，看如何合作，邊界如何劃分，對系統(tǒng)的穩(wěn)定性更有好處。

 

開發(fā)和運(yùn)維變成了一個融合的過程，開發(fā)會幫運(yùn)維做一些事情，例如環(huán)境交付的提前，Dockerfile 的書寫。

運(yùn)維也可以幫助研發(fā)做一些事情，例如微服務(wù)之間的注冊發(fā)現(xiàn)，治理，配置等，不可能公司的每一個業(yè)務(wù)都單獨(dú)的一套框架，可以下沉到運(yùn)維組來變成統(tǒng)一的基礎(chǔ)設(shè)施，提供統(tǒng)一的管理。

實施容器，微服務(wù)，DevOps 后，整個分工界面就變成了下面的樣子：

 

在網(wǎng)易就是這個模式，杭州研究院作為公共技術(shù)服務(wù)部門，有運(yùn)維部門管理機(jī)房，上面是云平臺組，基于 OpenStack 開發(fā)了租戶可自助操作的云平臺。

PaaS 組件也是云平臺的一部分，點擊可得，提供 SLA 保障。容器平臺也是云平臺的一部分，并且基于容器提供持續(xù)集成，持續(xù)部署的工具鏈。

微服務(wù)的管理和治理也是云平臺的一部分，業(yè)務(wù)部門可以使用這個平臺進(jìn)行微服務(wù)的開發(fā)。

業(yè)務(wù)部門的中間件組或者架構(gòu)組和云平臺組溝通密切，主要是如何以正確的姿勢使用云平臺組件。

業(yè)務(wù)部門分前端組，業(yè)務(wù)開發(fā)組，中臺開發(fā)組。

如何實施微服務(wù)，容器化，DevOps

實施微服務(wù)，容器化，DevOps 有很多的技術(shù)選型。其中容器化的部分，Kubernetes 是當(dāng)之無愧的選擇。

但是 Kubernetes 可不僅僅志在容器，它是為微服務(wù)而設(shè)計的。對于實施微服務(wù)各方面都有涉及。

 

Kubernetes 對于容器的運(yùn)行時生命周期管理比較完善，但是對于服務(wù)治理方面還不夠強(qiáng)大。

因而對于微服務(wù)的治理方面，多選擇使用 Dubbo 或者 Spring Cloud。使用 Dubbo 的存量應(yīng)用比較多，相對于 Dubbo 來講，Spring Cloud 比較新，組件也比較豐富。

但是 Spring Cloud 的組件都不到開箱即用的程度，需要比較高的學(xué)習(xí)曲線。

 

因而基于 Kubernetes 和 Spring Cloud，就有了下面這個微服務(wù)，容器，DevOps 的綜合管理平臺。

包含基于 Kubernetes 的容器平臺，持續(xù)集成平臺，測試平臺，API 網(wǎng)關(guān)，微服務(wù)框架，APM 應(yīng)用性能管理。

 

主要為了解決從階段一到階段二，或者階段二到階段三的改進(jìn)中的痛點。下面我們列舉幾個場景：

場景一：架構(gòu) SOA 拆分時，如何保證回歸測試功能集不變

前面說過，服務(wù)拆分后，最怕的是拆完了引入一大堆的 Bug，通過理智肯定不能保證拆分后功能集是不變的，因而需要有回歸測試集合保證，只要測試集合通過了，功能就沒有太大的問題。

回歸測試***是基于接口的，因為基于 UI 的很危險，有的接口是有的，但是 UI 上不能點，這個接口如果有 Bug，就被暫時隱藏掉了，當(dāng)后面有了新的需求，當(dāng)開發(fā)發(fā)現(xiàn)有個接口能夠調(diào)用的時候，一調(diào)用就掛了。

 

 

有了基于 Restful API 的接口測試之后，可以組成場景測試，將多個 API 調(diào)用組合成為一個場景，例如下單，扣優(yōu)惠券，減庫存，就是一個組合場景。

另外可以形成測試集合，例如冒煙測試集合，當(dāng)開發(fā)將功能交付給測試的時候，執(zhí)行一下。

再如日常測試集合，每天晚上跑一遍，看看當(dāng)天提交的代碼有沒有引入新的 Bug。再如回歸測試集合，上線之前跑一遍，保證大部分的功能是正確的。

場景二：架構(gòu) SOA 化的時候，如何統(tǒng)一管理并提供中臺服務(wù)

當(dāng)業(yè)務(wù)要提供中臺服務(wù)的時候，中臺服務(wù)首先希望能夠注冊到一個地方，當(dāng)業(yè)務(wù)組開發(fā)業(yè)務(wù)邏輯的時候，能夠在這個地方找到中臺的接口如何調(diào)用的文檔，當(dāng)業(yè)務(wù)組的業(yè)務(wù)注冊上來的時候，可以進(jìn)行調(diào)用。

 

在微服務(wù)框架除普通的注冊發(fā)現(xiàn)功能之外，還提供知識庫的功能，使得接口和文檔統(tǒng)一維護(hù)，文檔和運(yùn)行時一致，從而調(diào)用方看著文檔就可以進(jìn)行調(diào)用。

另外提供注冊，發(fā)現(xiàn)，調(diào)用期間的鑒權(quán)功能，不是誰看到中臺服務(wù)都能調(diào)用，需要中臺管理員授權(quán)才可以。

為了防止中臺服務(wù)被惡意調(diào)用，提供賬戶審計功能，記錄操作。

場景三：服務(wù) SOA 化的時候，如何保證關(guān)鍵服務(wù)的調(diào)用安全

 

有的服務(wù)非常關(guān)鍵，例如支付服務(wù)，和資金相關(guān)，不是誰想調(diào)用就能調(diào)用的，一旦被非法調(diào)用了，后果嚴(yán)重。

在服務(wù)治理里面有路由功能，除了能夠配置靈活的路由功能之外，還可以配置黑白名單，可以基于 IP 地址，也可以基于服務(wù)名稱，配置只有哪些應(yīng)用可以調(diào)用，可以配合云平臺的 VPC 功能，限制調(diào)用方。

場景四：架構(gòu) SOA 化后，對外提供 API 服務(wù)，構(gòu)建開放平臺

 

架構(gòu) SOA 化之后，除了對內(nèi)提供中臺服務(wù)，很多能力也可以開放給外部的合作伙伴，形成開放平臺。

例如你是一家物流企業(yè)，除了在你的頁面上下單寄快遞之外，其他的電商也可以調(diào)用你的 API 來寄快遞。

這就需要有一個 API 網(wǎng)關(guān)來管理 API，對接你的電商只要登錄到這個 API 網(wǎng)關(guān)，就能看到 API 以及如何調(diào)用，API 網(wǎng)關(guān)上面的文檔管理就是這個作用。

另外 API 網(wǎng)關(guān)提供接口的統(tǒng)一認(rèn)證鑒權(quán)，也提供 API 接口的定時開關(guān)功能，靈活控制 API 的生命周期。

場景五：互聯(lián)網(wǎng)場景下的灰度發(fā)布和 A/B 測試

接下來我們切換到互聯(lián)網(wǎng)業(yè)務(wù)場景，經(jīng)常會做 A/B 測試，這就需要 API 網(wǎng)關(guān)的流量分發(fā)功能。

例如我們做互聯(lián)網(wǎng)業(yè)務(wù)，當(dāng)上一個新功能的 時候，不清楚客戶是否喜歡，于是可以先開放給山東的客戶。

當(dāng) HTTP 頭里面有來自山東的字段，則訪問 B 系統(tǒng)，其他客戶還是訪問 A 系統(tǒng)，這個時候可以看山東的客戶是否都喜歡，如果都喜歡，就推向全國，如果不喜歡，就撤下來。

場景六：互聯(lián)網(wǎng)場景下的預(yù)發(fā)測試

這個也是互聯(lián)網(wǎng)場景下經(jīng)常遇到的預(yù)發(fā)測試，雖然我們在測試環(huán)境里面測試了很多輪。

但是由于線上場景更加復(fù)雜，有時候需要使用線上真實數(shù)據(jù)進(jìn)行測試，這個時候可以在線上的正式環(huán)境旁邊部署一套預(yù)發(fā)環(huán)境。

使用 API 網(wǎng)關(guān)將真實的請求流量，鏡像一部分到預(yù)發(fā)環(huán)境，如果預(yù)發(fā)環(huán)境能夠正確處理真實流量，再上線就放心多了。

場景七：互聯(lián)網(wǎng)場景下的性能壓測

互聯(lián)網(wǎng)場景下要做線上真實的性能壓測，才能知道整個系統(tǒng)真正的瓶頸點。

但是性能壓測的數(shù)據(jù)不能進(jìn)真實的數(shù)據(jù)庫，因而需要進(jìn)入影子庫，性能壓測的流量，也需要有特殊的標(biāo)記放在 HTTP 頭里面，讓經(jīng)過的業(yè)務(wù)系統(tǒng)知道這是壓測數(shù)據(jù)，不進(jìn)入真實的數(shù)據(jù)庫。

這個特殊的標(biāo)記要在 API 網(wǎng)關(guān)上添加，但是由于不同的壓測系統(tǒng)要求不一樣，因而需要 API 網(wǎng)關(guān)有定制路由插件功能，可以隨意添加自己的字段到 HTTP 頭里面，和壓測系統(tǒng)配合。

場景八：微服務(wù)場景下的熔斷，限流，降級

微服務(wù)場景下，大促的時候，需要進(jìn)行熔斷，限流，降級。這個在 API 網(wǎng)關(guān)上可以做，將超過壓測值的流量，通過限流，攔在系統(tǒng)外面，從而保證盡量的流量，能夠下單成功。

在服務(wù)之間，也可以通過微服務(wù)框架，進(jìn)行熔斷，限流，降級。Dubbo 對于服務(wù)的控制在接口層面，Spring Cloud 對于服務(wù)的管理在實例層面。

這兩個粒度不同的客戶選擇不一樣，都用 Dubbo 粒度太細(xì)，都用 Spring Cloud 粒度太粗，所以需要可以靈活配置。

 

場景九：微服務(wù)場景下的精細(xì)化流量管理。

 

 

在互聯(lián)網(wǎng)場景下，經(jīng)常需要對于流量進(jìn)行精細(xì)化的管理，可以根據(jù) HTTP Header 里面的參數(shù)進(jìn)行分流。

例如 VIP 用戶訪問一個服務(wù)，非 VIP 用戶訪問另一個服務(wù)，這樣可以對高收入的用戶推薦更加精品的產(chǎn)品，增加連帶率。