一、微服務落地是一個復雜問題，牽扯到IT架構(gòu)，應用架構(gòu)，組織架構(gòu)多個方面

---

在多家傳統(tǒng)行業(yè)的企業(yè)走訪和落地了微服務之后，發(fā)現(xiàn)落地微服務是一個非常復雜的問題，甚至都不完全是技術問題。

當時想微服務既然是改造應用，做微服務治理，類似注冊，發(fā)現(xiàn)，熔斷，限流，降級等，當然應該從應用開發(fā)組切入，一般一開始聊的會比較開心，從單體架構(gòu)，到SOA，再到微服務架構(gòu)，從Dubbo聊到SpringCloud，但是必然會涉及到微服務的發(fā)布和運維問題，涉及到DevOps和容器層，這些都不在開發(fā)組的控制范圍內(nèi)，一旦拉進運維組，對于容器的接受程度就成了一個問題，和傳統(tǒng)物理機，虛擬機的差別，會帶來什么風險等等等等，尤其是容器絕對不是輕量級的虛擬化這件事情，就不是一時半會兒能說的明白的。更何況就算說明白了，還有線上應用容器，一旦出了事情，誰背鍋的問題，容器往往會導致應用層和基礎設施層界限模糊，這使得背鍋雙方都會猶豫不決。

有的企業(yè)的微服務化是運維部門發(fā)起的，運維部門已經(jīng)意識到了各種各樣不統(tǒng)一的應用給運維帶來的苦，也樂意接受容器的運維模式，這就涉及到容器直接的服務發(fā)現(xiàn)是否應該運維在容器層搞定，還是應用應該自己搞定的問題，還涉及Dockerfile到底是開發(fā)寫還是運維寫的問題。一旦容器化的過程中，開發(fā)不配合，運維單方面去做這個事情，是徒增煩惱卻收益有限的。

下圖是微服務實施的過程中涉及到的層次，具體的描述參考文章云架構(gòu)師進階攻略

在一些相對先進的企業(yè)，會在運維組和開發(fā)組之間，有個中間件組，或者叫做架構(gòu)組，來負責推動微服務化改造的事情，架構(gòu)組就既需要負責勸說業(yè)務開發(fā)實施微服務化，也要勸說運維組實施容器化，如果架構(gòu)組的權威性不足，推動往往也會比較困難。

所以微服務，容器，DevOps的推動，不單單是一個技術問題，更是一個組織問題，在推動微服務的過程中，更加能夠感覺到康威定律的作用，需要更高層次技術總監(jiān)或者CIO的介入，方能夠推動微服務的落地。

然而到了CIO層，在很多企業(yè)又體會不到技術層面的痛點了，而更加關注業(yè)務的層面了，只要業(yè)務能賺錢，架構(gòu)的痛，中間件的痛，運維的痛，高層不是非常能夠感知，也就體會不到微服務，容器化的技術優(yōu)勢了，而微服務和容器化對于業(yè)務的優(yōu)勢，很多廠家在說，能夠說到表面，說不到心里。

因而微服務和容器化的改造，更加容易發(fā)生在一個扁平化的組織里面，由一個能夠體會到基層技術細節(jié)的痛的CIO，高瞻遠矚的推動這件事情。這也是為什么微服務的落地一般率先落地在互聯(lián)網(wǎng)公司，因為互聯(lián)網(wǎng)公司的組織架構(gòu)實在太平臺，哪怕是高層，也離一線非常的近，了解一線的痛。

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

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

?

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

---

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

組織狀態(tài)相對簡單。

統(tǒng)一的運維組，管理物理機，物理網(wǎng)絡，Vmware虛擬化等資源，同時部署上線由運維部負責。

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

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

2.2. 階段一的運維模式

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

無論是使用物理機，還是虛擬化，配置是相對復雜的，不是做過多年運維的人員，難以獨立的創(chuàng)建一臺機器，而且網(wǎng)絡規(guī)劃也需要非常小心，分配給不同業(yè)務部門的機器，網(wǎng)段不能沖突。所有這一切，都需要運維部門統(tǒng)一進行管理，一般的IT人員或者開發(fā)人員既沒有專業(yè)性，也不可能給他們權限進行操作，要申請機器怎么辦，走個工單，審批一下，過一段時間，機器就能創(chuàng)建出來。

2.3. 階段一的應用架構(gòu)

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

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

• 文件：NFS，FTP，Ceph，S3

• 緩存：Redis Cluster，主備，Sentinel, Memcached

• 分布式框架：Spring Cloud，Dubbo，Restful or RPC不同的部門自己選型

• 分庫分表：Sharding-jdbc，Mycat

• 消息隊列：RabbitMQ, Kafka

• 注冊中心：Zk，Euraka，consul

傳統(tǒng)架構(gòu)的服務層，系統(tǒng)或者由外包公司開發(fā)，或者由獨立團隊開發(fā)。

傳統(tǒng)架構(gòu)前端，各自開發(fā)各自的前端。

2.4. 階段一有什么問題嗎？

其實階段一沒有任何問題，我們甚至能找出一萬個理由說明這種模式的好處。

運維部和開放部是天然分開的，誰也不想管對方，兩邊的老大也是評級的，本相安無事。

機房當然只能運維人員能碰，這里面有安全的問題，專業(yè)性的問題，線上系統(tǒng)嚴肅的問題。如果交給沒有那么專業(yè)的開發(fā)去部署環(huán)境，一旦系統(tǒng)由漏洞，誰能擔責任，一旦線上系統(tǒng)掛了，又是誰的責任，這個問題問出來，能夠讓任何爭論鴉雀無聲。

數(shù)據(jù)庫無論使用Oracle, DB2，還是SQL Server都沒有問題，只要公司有足夠的預算，而且性能也的確杠杠的，里面存儲了大量存儲過程，會使得應用開發(fā)簡單很多，而且有專業(yè)的乙方幫忙運維，數(shù)據(jù)庫如此關鍵，如果替換稱為Mysql，一旦抗不出掛了，或者開源的沒人維護，線上出了事情，誰來負責？

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

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

2.5. 什么情況下才會覺得階段一有問題？

當然最初的痛點應該在業(yè)務層面，當用戶的需求開始變的多種多樣，業(yè)務方時不時的就要上一個新功能，做一個新系統(tǒng)的時候，你會發(fā)現(xiàn)外包公司不是能完全搞定所有的事情，他們是瀑布模型的開發(fā)，而且開發(fā)出來的系統(tǒng)很難變更，至少很難快速變更。

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

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

多種多樣的中間件，每個團隊獨立選型中間件，沒有統(tǒng)一的維護，沒有統(tǒng)一的知識積累，無法統(tǒng)一保障SLA。一旦使用的消息隊列，緩存，框架出了問題，整個團隊沒有人能夠搞定這個事情，因為大家都忙于業(yè)務開發(fā)，沒人有時間深入的去研究這些中間件的背后原理，常見的問題，如何調(diào)優(yōu)等等。

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

當維護了多套系統(tǒng)之后，你會發(fā)現(xiàn)，這些系統(tǒng)各個層次都有很多的共同點，很多能力是可以復用的，很多數(shù)據(jù)是可以打通的。同樣一套邏輯，這里也有，那里也有，同樣類型的數(shù)據(jù)，這里一份，那里一份，但是信息是隔離的，數(shù)據(jù)模型不統(tǒng)一，根本無法打通。

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

?

三、階段二：組織服務化，架構(gòu)SOA化，基礎設施云化

---

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

怎么解決上面的問題呢？

根據(jù)康威定理，組織方面就需要有一定的調(diào)整，整個公司還是分運維組和開發(fā)組。

由于痛點是從業(yè)務層面發(fā)生的，開始調(diào)整的應該是開發(fā)組。

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

建立中間件組，或者架構(gòu)師組，這部分人不用貼近業(yè)務開發(fā)，每天的任務就是研究如何使用這些中間件，如何調(diào)優(yōu)，遇到問題如何Debug，形成知識積累。如果有統(tǒng)一的一幫人專注中間件，就可以根據(jù)自身的情況，選擇有限幾個中間件集中研究，限定業(yè)務組只使用這些中間件，可保證選型的一致性，如果中間件被這個組統(tǒng)一維護，也可以提供可靠的SLA給業(yè)務方。

將業(yè)務開發(fā)組分出一部分來，建立中臺組，將可以復用的能力和代碼，交由這幾個組開發(fā)出服務來，給業(yè)務組使用，這樣數(shù)據(jù)模型會統(tǒng)一，業(yè)務開發(fā)的時候，首先先看看有哪些現(xiàn)成的服務可以使用，不用全部從零開發(fā)，也會提高開發(fā)效率。

3.2. 階段二的應用架構(gòu)

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

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

接下來就是要考慮，哪些應該拆出來？ 最后考慮的是如何拆出來？

這兩個題目的答案，不同的企業(yè)不同，其實分為兩個階段，第一個階段是嘗試階段，也即整個公司對于服務化拆分沒有任何經(jīng)驗，當然不敢拿核心業(yè)務上手，往往選取一個邊角的業(yè)務，先拆拆看，這個時候拆本身是重要的，其實是為了拆而拆，拆的比較理想化，符合領域驅(qū)動設計的最好，如何拆呢？當然是弄一個兩個月，核心員工大家閉門開發(fā)，進行拆分和組合，來積累經(jīng)驗。很多企業(yè)目前處于這個階段。

但是其實這個階段的拆法也只能用來積累經(jīng)驗，因為咱們最初要拆分，是為了快速響應業(yè)務請求，而這個邊角的模塊，往往不是最痛的核心業(yè)務。本來業(yè)務就邊角，拆不拆收益不大，而且也沒辦法很好的做能力復用。復用當然都想復用核心能力。

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

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

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

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

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

另外一點是，能夠形成復用的組件，往往不是核心業(yè)務邏輯。這個很好理解，兩個不同的業(yè)務，當然是核心業(yè)務邏輯不同(要不就成一種業(yè)務了)，核心業(yè)務邏輯往往是組合邏輯，雖然復雜，但是往往不具備復用性，就算是下單，不同的電商也是不一樣的，這家推出了什么什么豆，那家推出了什么什么券，另一家有個什么什么活動，都是核心業(yè)務邏輯的不同，會經(jīng)常變。能夠復用的，往往是用戶中心，支付中心，倉儲中心，庫存中心等等核心業(yè)務的周邊邏輯。

所以拆分，應該將這些核心業(yè)務的周邊邏輯，從核心業(yè)務里面拆出來，最終Online就剩下下單的核心路徑了，就可以改成下單服務了。當業(yè)務方突然有了需求推出一個搶購活動，就可以復用剛才的周邊邏輯了。搶購就成了另一個應用的核心邏輯，其實核心邏輯是傳真引線的，周邊邏輯是保存數(shù)據(jù)，提供原子化接口的。

那哪些周邊邏輯應該先拆出來呢？問自己的開發(fā)吧，那些戰(zhàn)戰(zhàn)兢兢，自己修改后生怕把核心邏輯搞掛了的組，是自己有動力從核心邏輯中拆分出來的，這個不需要技術總監(jiān)和架構(gòu)師去督促，他們有自己的原有動力，是一個很自然的過程。

這里的原有動力，一個是開發(fā)獨立，一個是上線獨立，就像考拉的online系統(tǒng)里面，倉庫組就想自己獨立出去，因為他們要對接各種各樣的倉儲系統(tǒng)，全球這么多的倉庫，系統(tǒng)都很傳統(tǒng)，接口不一樣，沒新對接一個，開發(fā)的時候，都擔心把下單核心邏輯搞掛了，造成線上事故，其實倉儲系統(tǒng)可以定義自己的重試和容災機制，沒有下單那么嚴重。物流組也想獨立出去，因為對接的物流公司太多了，也要經(jīng)常上線，也不想把下單搞掛。

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

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

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

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

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

例如打開一個java工程，應該有以下的package：

• API接口包：所有的接口定義都在這里，對于內(nèi)部的調(diào)用，也要實現(xiàn)接口，這樣一旦要拆分出去，對于本地的接口調(diào)用，就可以變?yōu)檫h程的接口調(diào)用

• 訪問外部服務包：如果這個進程要訪問其他進程，對于外部訪問的封裝都在這里，對于單元測試來講，對于這部分的Mock，可以使得不用依賴第三方，就能進行功能測試。對于服務拆分，調(diào)用其他的服務，也是在這里。

• 數(shù)據(jù)庫DTO：如果要訪問數(shù)據(jù)庫，在這里定義原子的數(shù)據(jù)結(jié)構(gòu)

• 訪問數(shù)據(jù)庫包：訪問數(shù)據(jù)庫的邏輯全部在這個包里面

• 服務與商務邏輯：這里實現(xiàn)主要的商業(yè)邏輯，拆分也是從這里拆分出來。

• 外部服務：對外提供服務的邏輯在這里，對于接口的提供方，要實現(xiàn)在這里。

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

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

• 內(nèi)部配置項(啟動后不變，改變需要重啟)

• 集中配置項(配置中心，可動態(tài)下發(fā))

• 外部配置項(外部依賴，和環(huán)境相關)

當一個工程的結(jié)構(gòu)非常標準化之后，接下來在原有服務中，先獨立功能模塊 ，規(guī)范輸入輸出，形成服務內(nèi)部的分離。在分離出新的進程之前，先分離出新的jar，只要能夠分離出新的jar，基本也就實現(xiàn)了松耦合。

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

為什么要越早獨立越好呢？哪怕還沒實現(xiàn)邏輯先獨立呢？因為服務拆分的過程是漸進的，伴隨著新功能的開發(fā)，新需求的引入，這個時候，對于原來的接口，也會有新的需求進行修改，如果你想把業(yè)務邏輯獨立出來，獨立了一半，新需求來了，改舊的，改新的都不合適，新的還沒獨立提供服務，舊的如果改了，會造成從舊工程遷移到新工程，邊遷移邊改變，合并更加困難。如果盡早獨立，所有的新需求都進入新的工程，所有調(diào)用方更新的時候，都改為調(diào)用新的進程，對于老進程的調(diào)用會越來越少，最終新進程將老進程全部代理。

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

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

3.3. 階段二的運維模式

經(jīng)過業(yè)務層的的服務化，也對運維組造成了壓力。

應用逐漸拆分，服務數(shù)量增多。

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

而持續(xù)集成的流程，往往需要頻繁的部署測試環(huán)境。

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

而頻繁的部署，就需要頻繁創(chuàng)建和刪除虛擬機。

如果還是采用上面審批的模式，運維部就會成為瓶頸，要不就是影響開發(fā)進度，要不就是被各種部署累死。

這就需要進行運維模式的改變，也即基礎設施層云化。

虛擬化到云化有什么不一樣呢？

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

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

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

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

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

原來的網(wǎng)絡使用的都是物理網(wǎng)絡，問題在于物理網(wǎng)絡是所有部門共享的，沒辦法交給一個業(yè)務部門自由的配置和使用。因而要有VPC虛擬網(wǎng)絡的概念，每個租戶可以隨意配置自己的子網(wǎng)，路由表，和外網(wǎng)的連接等，不同的租戶的網(wǎng)段可以沖突，互不影響，租戶可以根據(jù)自己的需要，隨意的在界面上，用軟件的方式做網(wǎng)絡規(guī)劃。

除了基礎設施云化之外，運維部門還應該將應用的部署自動化。

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

云計算如何管理應用呢？我們將應用分成兩種，一種稱為通用的應用，一般指一些復雜性比較高，但大家都在用的，例如數(shù)據(jù)庫。幾乎所有的應用都會用數(shù)據(jù)庫，但數(shù)據(jù)庫軟件是標準的，雖然安裝和維護比較復雜，但無論誰安裝都是一樣。這樣的應用可以變成標準的PaaS層的應用放在云平臺的界面上。當用戶需要一個數(shù)據(jù)庫時，一點就出來了，用戶就可以直接用了。

所以對于運維模式的第二個改變是，通用軟件PaaS化。

前面說過了，在開發(fā)部門有中間件組負責這些通用的應用，運維也自動部署這些應用，兩個組的界限是什么樣的呢？

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

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

除了通用的應用，還有個性化的應用，應該通過腳本進行部署，例如工具Puppet, Chef, Ansible, SaltStack等。

這里有一個實踐是，不建議使用裸機部署，因為這樣部署非常的慢，推薦基于虛擬機鏡像的自動部署。在云平臺上，任何虛擬機的創(chuàng)建都是基于鏡像的，我們可以在鏡像里面，將要部署的環(huán)境大部分部署好，只需要做少量的定制化，這些由部署工具完成。

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

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

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

進行完第二階段之后，整個狀態(tài)如上圖所示。

這里運維部門的職能有了一定的改變，除了最基本的資源創(chuàng)建，還要提供自助的操作平臺，PaaS化的中間件，基于鏡像和腳本的自動部署。

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

3.4. 階段二有什么問題嗎？

其實大部分的企業(yè)，到了這個階段，已經(jīng)可以解決大部分的問題了。

能夠做到架構(gòu)SOA化，基礎設施云化的公司已經(jīng)是傳統(tǒng)行業(yè)在信息化領域的佼佼者了。

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

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

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

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

3.5. 什么情況下才會覺得階段二有問題？

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

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

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

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

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

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

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

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

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

當出現(xiàn)這些問題的時候，才應該考慮進入第三個階段，微服務化

?

四、階段三：組織DevOps化，架構(gòu)微服務化，基礎設施容器化

---

4.1. 階段三的應用架構(gòu)

從SOA到微服務化這一步非常關鍵，復雜度也比較高，上手需要謹慎。

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

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

為什么要拆分到這個粒度呢？主要是高并發(fā)的需求。

但是高并發(fā)不是沒有成本的，拆分成這個粒度會有什么問題呢？你會發(fā)現(xiàn)等拆完了，下面的這些措施一個都不能少。

• 拆分如何保證功能不變，不引入Bug——持續(xù)集成，參考微服務化的基石——持續(xù)集成

• 靜態(tài)資源要拆分出來，緩存到接入層或者CDN，將大部分流量攔截在離用戶近的邊緣節(jié)點或者接入層緩存，參考微服務的接入層設計與動靜資源隔離

• 應用的狀態(tài)要從業(yè)務邏輯中拆分出來，使得業(yè)務無狀態(tài)，可以基于容器進行橫向擴展，參考微服務化之無狀態(tài)化與容器化

• 核心業(yè)務和非核心業(yè)務要拆分，方便核心業(yè)務的擴展以及非核心業(yè)務的降級，參考微服務化之服務拆分與服務發(fā)現(xiàn)

• 數(shù)據(jù)庫要讀寫分離，要分庫分表，才能在超大數(shù)據(jù)量的情況下，數(shù)據(jù)庫具有橫向擴展的能力，不成為瓶頸，參考微服務化的數(shù)據(jù)庫設計與讀寫分離

• 要層層緩存，只有少數(shù)的流量到達中軍大營數(shù)據(jù)庫，參考微服務化之緩存的設計

• 要使用消息隊列，將原來連續(xù)調(diào)用的多個服務異步化為監(jiān)聽消息隊列，從而縮短核心邏輯

• 服務之間要設定熔斷，限流，降級策略，一旦調(diào)用阻塞應該快速失敗，而不應該卡在那里，處于亞健康狀態(tài)的服務要被及時熔斷，不產(chǎn)生連鎖反應。非核心業(yè)務要進行降級，不再調(diào)用，將資源留給核心業(yè)務。要在壓測到的容量范圍內(nèi)對調(diào)用限流，寧可慢慢處理，也不用一下子都放進來，把整個系統(tǒng)沖垮。

• 拆分成的服務太多了，沒辦法一個個配置，需要統(tǒng)一的一個配置中心，將配置下發(fā)

• 拆分成的服務太多了，沒辦法一個個看日志，需要統(tǒng)一的日志中心，將日志匯總

• 拆分成的服務太多了，很難定位性能瓶頸，需要通過APM全鏈路應用監(jiān)控，發(fā)現(xiàn)性能瓶頸，及時修改

• 拆分成的服務太多了，不壓測一下，誰也不知道到底能夠抗住多大的量，因而需要全鏈路的壓測系統(tǒng)。

應用層需要處理這十二個問題，最后一個都不能少，實施微服務，你做好準備了嗎？你真覺得攢一攢springcloud，就能夠做好這些嗎？

4.2. 階段三的運維模式

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

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

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

如果基于腳本的部署，腳本原來多由運維寫，由于服務太多，變化也多，腳本肯定要不斷的更新，而每家公司的開發(fā)人員都遠遠多于運維人員，運維根本來不及維護自動部署的腳本。那腳本能不能由開發(fā)寫呢？一般是不可行的，開發(fā)對于運行環(huán)境了解有限，而且腳本沒有一個標準，運維無法把控開發(fā)寫的腳本的質(zhì)量。

基于虛擬機鏡像的就會好很多，因為需要腳本做的事情比較少，大部分對于應用的配置都打在鏡像里面了。如果基于虛擬機鏡像進行交付，也能起到標準交付的效果。而且一旦上線有問題，也可以基于虛擬機鏡像的版本進行回滾。

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

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

原來開發(fā)交付給運維的，是一個war包，一系列配置文件，一個部署文檔，但是由于部署文檔更新不及時，常常出現(xiàn)運維部署出來出錯的情況。有了容器鏡像，開發(fā)交付給運維的，是一個容器鏡像，容器內(nèi)部的運行環(huán)境，應該體現(xiàn)在Dockerfile文件中，這個文件是應該開發(fā)寫的。

這個時候，從流程角度，將環(huán)境配置這件事情，往前推了，推到了開發(fā)這里，要求開發(fā)完畢之后，就需要考慮環(huán)境部署的問題，而不能當甩手掌柜。由于容器鏡像是標準的，就不存在腳本無法標準化的問題，一旦單個容器運行不起來，肯定是Dockerfile的問題。

而運維組只要維護容器平臺就可以，單個容器內(nèi)的環(huán)境，交給開發(fā)來維護。這樣做的好處就是，雖然進程多，配置變化多，更新頻繁，但是對于某個模塊的開發(fā)團隊來講，這個量是很小的，因為5-10個人專門維護這個模塊的配置和更新，不容易出錯。自己改的東西自己知道。

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

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

容器的另外一個作用，就是不可改變基礎設施。

容器鏡像有個特點，就是ssh到里面做的任何修改，重啟都不見了，恢復到鏡像原來的樣子，也就杜絕了原來我們部署環(huán)境，這改改，那修修最后部署成功的壞毛病。

因為如果機器數(shù)目比較少，還可以登錄到每臺機器上改改東西，一旦出了錯誤，比較好排查，但是微服務狀態(tài)下，環(huán)境如此復雜，規(guī)模如此大，一旦有個節(jié)點，因為人為修改配置導致錯誤，非常難排查，所以應該貫徹不可改變基礎設施，一旦部署了，就不要手動調(diào)整了，想調(diào)整從頭走發(fā)布流程。

這里面還有一個概念叫做一切即代碼，單個容器的運行環(huán)境Dockerfile是代碼，容器之間的關系編排文件是代碼，配置文件是代碼，所有的都是代碼，代碼的好處就是誰改了什么，Git里面一清二楚，都可以track，有的配置錯了，可以統(tǒng)一發(fā)現(xiàn)誰改的。

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

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

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

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

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

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

在網(wǎng)易就是這個模式，杭州研究院作為公共技術服務部門，有運維部門管理機房，上面是云平臺組，基于OpenStack開發(fā)了租戶可自助操作的云平臺。PaaS組件也是云平臺的一部分，點擊可得，提供SLA保障。容器平臺也是云平臺的一部分，并且基于容器提供持續(xù)集成，持續(xù)部署的工具鏈。

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

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

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

?

五、如何實施微服務，容器化，DevOps

---

實施微服務，容器化，DevOps有很多的技術選型。

其中容器化的部分，Kubernetes當之無愧的選擇。但是Kubernetes可不僅僅志在容器，他是為微服務而設計的。對于實施微服務各方面都有涉及。

詳細分析參加為什么 kubernetes 天然適合微服務

但是Kubernetes對于容器的運行時生命周期管理比較完善，但是對于服務治理方面還不夠強大。

因而對于微服務的治理方面，多選擇使用Dubbo或者SpringCloud。使用Dubbo的存量應用比較多，相對于Dubbo來講，SpringCloud比較新，組件也比較豐富。但是SpringCloud的組件都不到開箱即用的程度，需要比較高的學習曲線。

因而基于Kubernetes和SpringCloud，就有了下面這個微服務，容器，DevOps的綜合管理平臺。包含基于Kubernetes的容器平臺，持續(xù)集成平臺，測試平臺，API網(wǎng)關，微服務框架，APM應用性能管理。?

主要為了解決從階段一到階段二，或者階段二到階段三的改進中的痛點。

下面我們列舉幾個場景。

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

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

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

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

另外可以形成測試集合，例如冒煙測試集合，當開發(fā)將功能交付給測試的時候，執(zhí)行一下。再如日常測試集合，每天晚上跑一遍，看看當天提交的代碼有沒有引入新的bug。再如回歸測試集合，上線之前跑一遍，保證大部分的功能是正確的。

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

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

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

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

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

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

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

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

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

架構(gòu)SOA化之后，除了對內(nèi)提供中臺服務，很多能力也可以開放給外部的合作伙伴，形成開放平臺。例如你是一家物流企業(yè)，除了在你的頁面上下單寄快遞之外，其他的電商也可以調(diào)用你的API來寄快遞，這就需要有一個API網(wǎng)關來管理API，對接你的電商只要登錄到這個API網(wǎng)關，就能看到API以及如何調(diào)用，API網(wǎng)關上面的文檔管理就是這個作用。

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

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

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

例如我們做互聯(lián)網(wǎng)業(yè)務，當上一個新功能的 時候，不清楚客戶是否喜歡，于是可以先開放給山東的客戶，當HTTP頭里面有來自山東的字段，則訪問B系統(tǒng)，其他客戶還是訪問A系統(tǒng)，這個時候可以看山東的客戶是否都喜歡，如果都喜歡，就推向全國，如果不喜歡，就撤下來。

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

這個也是互聯(lián)網(wǎng)場景下經(jīng)常遇到的預發(fā)測試，雖然我們在測試環(huán)境里面測試了很多輪，但是由于線上場景更加復雜，有時候需要使用線上真實數(shù)據(jù)進行測試，這個時候可以在線上的正式環(huán)境旁邊部署一套預發(fā)環(huán)境，使用API網(wǎng)關將真實的請求流量，鏡像一部分到預發(fā)環(huán)境，如果預發(fā)環(huán)境能夠正確處理真實流量，再上線就放心多了。

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

互聯(lián)網(wǎng)場景下要做線上真實的性能壓測，才能知道整個系統(tǒng)真正的瓶頸點。但是性能壓測的數(shù)據(jù)不能進真實的數(shù)據(jù)庫，因而需要進入影子庫，性能壓測的流量，也需要有特殊的標記放在HTTP頭里面，讓經(jīng)過的業(yè)務系統(tǒng)知道這是壓測數(shù)據(jù)，不進入真實的數(shù)據(jù)庫。

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

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

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

在服務之間，也可以通過微服務框架，進行熔斷，限流，降級。Dubbo對于服務的控制在接口層面，SpringCloud對于服務的管理在實例層面，這兩個粒度不同的客戶選擇不一樣，都用Dubbo粒度太細，都用SpringCloud粒度太粗，所以需要可以靈活配置。

場景九：微服務場景下的精細化流量管理。

在互聯(lián)網(wǎng)場景下，經(jīng)常需要對于流量進行精細化的管理，可以根據(jù)HTTP Header里面的參數(shù)進行分流，例如VIP用戶訪問一個服務，非VIP用戶訪問另一個服務，這樣可以對高收入的用戶推薦更加精品的產(chǎn)品，增加連帶率。

?

原文：https://mp.weixin.qq.com/s?__biz=MzI1NzYzODk4OQ==&mid=2247484966&idx=1&sn=23fcb9a0b27a804643e183d86686bc63&chksm=ea151104dd629812e0f111ee85b65dbf9a342ed798f7f005b6a326c278f4bb5b560b9c8e5934&mpshare=1&scene=23&srcid=1119PERBSzAJtJ4u70UDozkm#rd

總結(jié)

以上是生活随笔為你收集整理的致传统企业朋友：不够痛就别微服务，有坑的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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