致傳統企業朋友：不夠痛就別微服務，有坑

1、微服務落地是一個複雜問題，牽扯到IT架構，應用架構，組織架構多個方面

在多家傳統行業的企業走訪和落地了微服務以後，發現落地微服務是一個很是複雜的問題，甚至都不徹底是技術問題。

當時想微服務既然是改造應用，作微服務治理，相似註冊，發現，熔斷，限流，降級等，固然應該從應用開發組切入，通常一開始聊的會比較開心，從單體架構，到SOA，再到微服務架構，從Dubbo聊到SpringCloud，可是必然會涉及到微服務的發佈和運維問題，涉及到DevOps和容器層，這些都不在開發組的控制範圍內，一旦拉進運維組，對於容器的接受程度就成了一個問題，和傳統物理機，虛擬機的差異，會帶來什麼風險等等等等，尤爲是容器絕對不是輕量級的虛擬化這件事情，就不是一時半會兒能說的明白的。更況且就算說明白了，還有線上應用容器，一旦出了事情，誰背鍋的問題，容器每每會致使應用層和基礎設施層界限模糊，這使得背鍋雙方都會猶豫不決。

有的企業的微服務化是運維部門發起的，運維部門已經意識到了各類各樣不統一的應用給運維帶來的苦，也樂意接受容器的運維模式，這就涉及到容器直接的服務發現是否應該運維在容器層搞定，仍是應用應該本身搞定的問題，還涉及Dockerfile究竟是開發寫仍是運維寫的問題。一旦容器化的過程當中，開發不配合，運維單方面去作這個事情，是徒增煩惱卻收益有限的。

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

在一些相對先進的企業，會在運維組和開發組之間，有個中間件組，或者叫作架構組，來負責推進微服務化改造的事情，架構組就既須要負責勸說業務開發實施微服務化，也要勸說運維組實施容器化，若是架構組的權威性不足，推進每每也會比較困難。

因此微服務，容器，DevOps的推進，不僅僅是一個技術問題，更是一個組織問題，在推進微服務的過程當中，更加可以感受到康威定律的做用，須要更高層次技術總監或者CIO的介入，方可以推進微服務的落地。

然而到了CIO層，在不少企業又體會不到技術層面的痛點了，而更加關注業務的層面了，只要業務能賺錢，架構的痛，中間件的痛，運維的痛，高層不是很是可以感知，也就體會不到微服務，容器化的技術優點了，而微服務和容器化對於業務的優點，不少廠家在說，可以說到表面，說不到內心。

於是微服務和容器化的改造，更加容易發生在一個扁平化的組織裏面，由一個可以體會到基層技術細節的痛的CIO，高瞻遠矚的推進這件事情。這也是爲何微服務的落地通常率先落地在互聯網公司，由於互聯網公司的組織架構實在太平臺，哪怕是高層，也離一線很是的近，瞭解一線的痛。

然而在傳統行業就沒有那麼幸運了，層級每每會比較多，這個時候就須要技術上的痛足夠痛，可以痛到影響業務，可以痛到影響收入，可以痛到被競爭對手甩在後面，才能上達天聽。

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

2、階段一：單體架構羣，多個開發組，統一運維組

2.1. 階段一的組織狀態

組織狀態相對簡單。

統一的運維組，管理物理機，物理網絡，Vmware虛擬化等資源，同時部署上線由運維部負責。
開發組每一個業務都是獨立的，負責寫代碼，不一樣的業務溝通很少，開發除了作本身的系統外，還須要維護外包公司開發的系統，因爲不一樣的外包公司技術選型差別較大，於是處於煙囪式的架構狀態。

傳統煙囪式架構以下圖所示

2.2. 階段一的運維模式

在傳統架構下，基礎設施層每每採起物理機或者虛擬化進行部署，爲了避免同的應用之間方便相互訪問，多采起橋接扁平二層機房網絡，也即全部的機器的IP地址都是能夠相互訪問的，不想互相訪問的，多采用防火牆進行隔離。

不管是使用物理機，仍是虛擬化，配置是相對複雜的，不是作過多年運維的人員，難以獨立的建立一臺機器，並且網絡規劃也須要很是當心，分配給不一樣業務部門的機器，網段不能衝突。全部這一切，都須要運維部門統一進行管理，通常的IT人員或者開發人員既沒有專業性，也不可能給他們權限進行操做，要申請機器怎麼辦，走個工單，審批一下，過一段時間，機器就能建立出來。

2.3. 階段一的應用架構

傳統架構數據庫層，因爲外包公司獨立開發，或者不一樣開發部門獨立開發，不一樣業務使用不一樣的數據庫，有用Oracle的，有用SQL Server的，有用Mysql的，有用MongoDB的，各不相同。

傳統架構的中間件層，每一個團隊獨立選型中間件：

• 文件：NFS，FTP，Ceph，S3
• 緩存：Redis Cluster，主備，Sentinel, Memcached
• 分佈式框架：Spring Cloud，Dubbo，Restful or RPC不一樣的部門本身選型
• 分庫分表：Sharding-jdbc，Mycat
• 消息隊列：RabbitMQ, Kafka
• 註冊中心：Zk，Euraka，consul
  傳統架構的服務層，系統或者由外包公司開發，或者由獨立團隊開發。

傳統架構前端，各自開發各自的前端。

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

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

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

機房固然只能運維人員能碰，這裏面有安全的問題，專業性的問題，線上系統嚴肅的問題。若是交給沒有那麼專業的開發去部署環境，一旦系統由漏洞，誰能擔責任，一旦線上系統掛了，又是誰的責任，這個問題問出來，可以讓任何爭論鴉雀無聲。

數據庫不管使用Oracle, DB2，仍是SQL Server都沒有問題，只要公司有足夠的預算，並且性能也的確槓槓的，裏面存儲了大量存儲過程，會使得應用開發簡單不少，並且有專業的乙方幫忙運維，數據庫如此關鍵，若是替換稱爲Mysql，一旦抗不出掛了，或者開源的沒人維護，線上出了事情，誰來負責？

中間件，服務層，前端，所有由外包商或者乙方搞定，端到端維護，要改什麼招手即來，並且每一個系統都是完整的一套，部署方便，運維方便。

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

2.5. 什麼狀況下才會以爲階段一有問題？

固然最初的痛點應該在業務層面，當用戶的需求開始變的多種多樣，業務方時不時的就要上一個新功能，作一個新系統的時候，你會發現外包公司不是能徹底搞定全部的事情，他們是瀑布模型的開發，並且開發出來的系統很難變動，至少很難快速變動。

因而你開始想本身招聘一些開發，開發本身可以把控的系統，至少可以將外包公司開發的系統接管過來，這個時候，應對業務部門的需求，就會靈活的多。

可是本身開發和維護就帶來了新的問題，多種多樣的數據庫，根本不可能招聘到如此多樣的DBA，人都很是的貴，並且隨着系統的增多，這些數據庫的lisense也很是的貴。

多種多樣的中間件，每一個團隊獨立選型中間件，沒有統一的維護，沒有統一的知識積累，沒法統一保障SLA。一旦使用的消息隊列，緩存，框架出了問題，整個團隊沒有人可以搞定這個事情，由於你們都忙於業務開發，沒人有時間深刻的去研究這些中間件的背後原理，常見的問題，如何調優等等。

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

當維護了多套系統以後，你會發現，這些系統各個層次都有不少的共同點，不少能力是能夠複用的，不少數據是能夠打通的。一樣一套邏輯，這裏也有，那裏也有，一樣類型的數據，這裏一份，那裏一份，可是信息是隔離的，數據模型不統一，根本沒法打通。

當出現這些問題的時候，纔是您考慮進入第二個階段。

3、階段二：組織服務化，架構SOA化，基礎設施雲化

3.1. 階段二的組織形態

怎麼解決上面的問題呢？

根據康威定理，組織方面就須要有必定的調整，整個公司仍是分運維組和開發組。

因爲痛點是從業務層面發生的，開始調整的應該是開發組。

應該創建獨立的前端組，統一前端框架，界面一致，全部人掌握統一的前端開發能力，積累前端代碼，在有新的需求的時候，可以快速的進行開發。

創建中間件組，或者架構師組，這部分人不用貼近業務開發，天天的任務就是研究如何使用這些中間件，如何調優，遇到問題如何Debug，造成知識積累。若是有統一的一幫人專一中間件，就能夠根據自身的狀況，選擇有限幾個中間件集中研究，限定業務組只使用這些中間件，可保證選型的一致性，若是中間件被這個組統一維護，也能夠提供可靠的SLA給業務方。

將業務開發組分出一部分來，創建中臺組，將能夠複用的能力和代碼，交由這幾個組開發出服務來，給業務組使用，這樣數據模型會統一，業務開發的時候，首先先看看有哪些現成的服務可使用，不用所有從零開發，也會提升開發效率。

3.2. 階段二的應用架構

要創建中臺，變成服務爲其餘業務使用，就須要使用SOA架構，將能夠複用的組件服務化，註冊到服務的註冊中心。

對於有錢的企業，可能會採購商用的ESB總線，也有使用Dubbo本身封裝稱爲服務註冊中心。

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

這兩個題目的答案，不一樣的企業不一樣，其實分爲兩個階段，第一個階段是嘗試階段，也即整個公司對於服務化拆分沒有任何經驗，固然不敢拿核心業務上手，每每選取一個邊角的業務，先拆拆看，這個時候拆自己是重要的，實際上是爲了拆而拆，拆的比較理想化，符合領域驅動設計的最好，如何拆呢？固然是弄一個兩個月，核心員工你們閉門開發，進行拆分和組合，來積累經驗。不少企業目前處於這個階段。

可是其實這個階段的拆法也只能用來積累經驗，由於我們最初要拆分，是爲了快速響應業務請求，而這個邊角的模塊，每每不是最痛的核心業務。原本業務就邊角，拆不拆收益不大，並且也沒辦法很好的作能力複用。複用固然都想複用核心能力。

因此其實最重要的是第二個階段，業務真正的服務化的階段。固然要拿業務需求最多的核心業務邏輯下手，才能起到快速響應業務請求，複用能力的做用。

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

那核心業務邏輯中，哪些應該拆出來呢？不少企業會問咱們，其實企業本身的開發最清楚。

這個時候常常犯的錯誤是，先將核心業務邏輯從單體應用中拆分出來。例如將下單邏輯造成下單服務，從online服務中拆分出來。

固然不該該這樣，例如兩軍打仗，當炊事班的煙燻着戰士了，是將中軍大營搬出去，仍是講炊事班搬出去呢？固然是炊事班了。

另一點是，可以造成複用的組件，每每不是核心業務邏輯。這個很好理解，兩個不一樣的業務，固然是核心業務邏輯不一樣(要不就成一種業務了)，核心業務邏輯每每是組合邏輯，雖然複雜，可是每每不具有複用性，就算是下單，不一樣的電商也是不同的，這家推出了什麼什麼豆，那家推出了什麼什麼券，另外一家有個什麼什麼活動，都是核心業務邏輯的不一樣，會常常變。可以複用的，每每是用戶中心，支付中心，倉儲中心，庫存中心等等核心業務的周邊邏輯。

因此拆分，應該將這些核心業務的周邊邏輯，從核心業務裏面拆出來，最終Online就剩下下單的核心路徑了，就能夠改爲下單服務了。當業務方忽然有了需求推出一個搶購活動，就能夠複用剛纔的周邊邏輯了。搶購就成了另外一個應用的核心邏輯，其實核心邏輯是傳真引線的，周邊邏輯是保存數據，提供原子化接口的。

那哪些周邊邏輯應該先拆出來呢？問本身的開發吧，那些戰戰兢兢，本身修改後生怕把核心邏輯搞掛了的組，是本身有動力從核心邏輯中拆分出來的，這個不須要技術總監和架構師去督促，他們有本身的原有動力，是一個很天然的過程。

這裏的原有動力，一個是開發獨立，一個是上線獨立，就像考拉的online系統裏面，倉庫組就想本身獨立出去，由於他們要對接各類各樣的倉儲系統，全球這麼多的倉庫，系統都很傳統，接口不同，沒新對接一個，開發的時候，都擔憂把下單核心邏輯搞掛了，形成線上事故，其實倉儲系統能夠定義本身的重試和容災機制，沒有下單那麼嚴重。物流組也想獨立出去，由於對接的物流公司太多了，也要常常上線，也不想把下單搞掛。

您也能夠梳理一下貴公司的業務邏輯，也會有自行願意拆分的業務，造成中臺服務。

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

而後咱們再看，如何拆分的問題？

關於拆分的前提，時機，方法，規範等，參考文章微服務化之服務拆分與服務發現

首先要作的，就是原有工程代碼的標準化，咱們常稱爲「任何人接手任何一個模塊都能看到熟悉的面孔」

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

• API接口包：全部的接口定義都在這裏，對於內部的調用，也要實現接口，這樣一旦要拆分出去，對於本地的接口調用，就能夠變爲遠程的接口調用
• 訪問外部服務包：若是這個進程要訪問其餘進程，對於外部訪問的封裝都在這裏，對於單元測試來說，對於這部分的Mock，可使得不用依賴第三方，就能進行功能測試。對於服務拆分，調用其餘的服務，也是在這裏。
• 數據庫DTO：若是要訪問數據庫，在這裏定義原子的數據結構
• 訪問數據庫包：訪問數據庫的邏輯所有在這個包裏面
• 服務與商務邏輯：這裏實現主要的商業邏輯，拆分也是從這裏拆分出來。
• 外部服務：對外提供服務的邏輯在這裏，對於接口的提供方，要實如今這裏。

另外是測試文件夾，每一個類都應該有單元測試，要審覈單元測試覆蓋率，模塊內部應該經過Mock的方法實現集成測試。

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

• 內部配置項(啓動後不變，改變須要重啓)
• 集中配置項(配置中心，可動態下發)
• 外部配置項(外部依賴，和環境相關)

當一個工程的結構很是標準化以後，接下來在原有服務中，先獨立功能模塊 ，規範輸入輸出，造成服務內部的分離。在分離出新的進程以前，先分離出新的jar，只要可以分離出新的jar，基本也就實現了鬆耦合。

接下來，應該新建工程，新啓動一個進程，儘早的註冊到註冊中心，開始提供服務，這個時候，新的工程中的代碼邏輯能夠先沒有，只是轉調用原來的進程接口。

爲何要越早獨立越好呢？哪怕還沒實現邏輯先獨立呢？由於服務拆分的過程是漸進的，伴隨着新功能的開發，新需求的引入，這個時候，對於原來的接口，也會有新的需求進行修改，若是你想把業務邏輯獨立出來，獨立了一半，新需求來了，改舊的，改新的都不合適，新的還沒獨立提供服務，舊的若是改了，會形成從舊工程遷移到新工程，邊遷移邊改變，合併更加困難。若是儘早獨立，全部的新需求都進入新的工程，全部調用方更新的時候，都改成調用新的進程，對於老進程的調用會愈來愈少，最終新進程將老進程所有代理。

接下來就能夠將老工程中的邏輯逐漸遷移到新工程，因爲代碼遷移不能保證邏輯的徹底正確，於是須要持續集成，灰度發佈，微服務框架可以在新老接口之間切換。

最終當新工程穩定運行，而且在調用監控中，已經沒有對於老工程的調用的時候，就能夠將老工程下線了。

3.3. 階段二的運維模式

通過業務層的的服務化，也對運維組形成了壓力。

應用逐漸拆分，服務數量增多。

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

而持續集成的流程，每每須要頻繁的部署測試環境。

隨着服務的拆分，不一樣的業務開發組會接到不一樣的需求，並行開發功能增多，發佈頻繁，會形成測試環境，生產環境更加頻繁的部署。

而頻繁的部署，就須要頻繁建立和刪除虛擬機。

若是仍是採用上面審批的模式，運維部就會成爲瓶頸，要不就是影響開發進度，要不就是被各類部署累死。

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

虛擬化到雲化有什麼不同呢？

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

也即人工建立，人工調度，人工配置的集中管理模式已經成爲瓶頸，應該變爲租戶自助的管理，機器自動的調度，自動的配置。

其次，要實現基於Quota和QoS的資源控制。

也即對於租戶建立的資源的控制，不用精細化到運維手動管理一切，只要給這個客戶分配了租戶，分配了Quota，設置了Qos，租戶就能夠在運維限定的範圍內，自由隨意的建立，使用，刪除虛擬機，無需通知運維，這樣迭代速度就會加快。

再次，要實現基於虛擬網絡，VPC，SDN的網絡規劃。

原來的網絡使用的都是物理網絡，問題在於物理網絡是全部部門共享的，沒辦法交給一個業務部門自由的配置和使用。於是要有VPC虛擬網絡的概念，每一個租戶能夠隨意配置本身的子網，路由表，和外網的鏈接等，不一樣的租戶的網段能夠衝突，互不影響，租戶能夠根據本身的須要，隨意的在界面上，用軟件的方式作網絡規劃。

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

由於若是雲計算無論應用，一旦出現擴容，或者自動部署的需求，雲平臺建立出來的虛擬機仍是空的，須要運維手動上去部署，根本忙不過來。於是雲平臺，也必定要管理應用。

雲計算如何管理應用呢？咱們將應用分紅兩種，一種稱爲通用的應用，通常指一些複雜性比較高，但你們都在用的，例如數據庫。幾乎全部的應用都會用數據庫，但數據庫軟件是標準的，雖然安裝和維護比較複雜，但不管誰安裝都是同樣。這樣的應用能夠變成標準的PaaS層的應用放在雲平臺的界面上。當用戶須要一個數據庫時，一點就出來了，用戶就能夠直接用了。

因此對於運維模式的第二個改變是，通用軟件PaaS化。
前面說過了，在開發部門有中間件組負責這些通用的應用，運維也自動部署這些應用，兩個組的界限是什麼樣的呢？

通常的實踐方式是，雲平臺的PaaS負責建立的中間件的穩定，保證SLA，當出現問題的時候，會自動修復。

而開發部門的中間件組，主要研究如何正確的使用這些PaaS，配置什麼樣的參數，使用的正確姿式等等，這個和業務相關。

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

這裏有一個實踐是，不建議使用裸機部署，由於這樣部署很是的慢，推薦基於虛擬機鏡像的自動部署。在雲平臺上，任何虛擬機的建立都是基於鏡像的，咱們能夠在鏡像裏面，將要部署的環境大部分部署好，只須要作少許的定製化，這些由部署工具完成。

下圖是OpenStack基於Heat的虛擬機編排，除了調用OpenStack API基於鏡像建立虛擬機以外，還要調用SaltStack的master，將定製化的指令下發給虛擬機裏面的agent。

基於虛擬機鏡像和腳本下發，能夠構建自動化部署平臺NDP

這樣能夠基於虛擬機鏡像，作完整的應用的部署和上線，稱爲編排。基於編排，就能夠進行很好的持續集成，例如天天晚上，自動部署一套環境，進行迴歸測試，從而保證修改的正確性。

進行完第二階段以後，整個狀態如上圖所示。

這裏運維部門的職能有了必定的改變，除了最基本的資源建立，還要提供自助的操做平臺，PaaS化的中間件，基於鏡像和腳本的自動部署。

開發部門的職能也有了必定的改變，拆分稱爲前端組，業務開發組，中臺組，中間件組，其中中間件組合運維部門的聯繫最緊密。

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

其實大部分的企業，到了這個階段，已經能夠解決大部分的問題了。

可以作到架構SOA化，基礎設施雲化的公司已是傳統行業在信息化領域的佼佼者了。

中臺開發組基本可以解決中臺的能力複用問題，持續集成也基本跑起來了，使得業務開發組的迭代速度明顯加快。

集中的中間件組或者架構組，能夠集中選型，維護，研究消息隊列，緩存等中間件。

在這個階段，因爲業務的穩定性要求，不少公司仍是會採用Oracle商用數據庫，也沒有什麼問題。

實現到了階段二，在同行業內，已經有必定的競爭優點了。

3.5. 什麼狀況下才會以爲階段二有問題？

咱們發現，當傳統行業再也不知足於在本行業的領先地位，但願可以對接到互聯網業務的時候，上面的模式纔出現新的痛點。

對接互聯網所面臨的最大的問題，就是巨大的用戶量所帶來的請求量和數據量，會是原來的N倍，能不能撐得住，你們都內心沒底。

例若有的客戶推出互聯網理財秒殺搶購，原來的架構沒法承載近百倍的瞬間流量。

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

有的客戶雖然已經用了Dubbo實現了服務化，可是沒有熔斷，限流，降級的服務治理策略，有可能一個請求慢，高峯期波及一大片，或者請求所有接進來，最後都撐不住而掛一片。

有的客戶但願實現工業互連網平臺，但是接入的數據量動輒PB級別，若是扛的住是一個很大的問題。

有的客戶起初使用開源的緩存和消息隊列，分佈式數據庫，可是讀寫頻率到了必定的程度，就會出現各類奇奇怪怪的問題，不知道應該如何調優。

有的客戶發現，一旦到了互聯網大促級別，Oracle數據庫是確定扛不住的，須要從Oracle遷移到DDB分佈式數據庫，但是怎麼個遷移法，如何平滑過渡，內心沒底。

有的客戶服務拆分以後，原來原子化的操做分紅了兩個服務調用，如何仍然保持原子化，要不所有成功，要不所有失敗，須要分佈式事務，雖然業內有大量的分佈式方案，可是可以承載高併發支付的框架尚未。

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

4、階段三：組織DevOps化，架構微服務化，基礎設施容器化

4.1. 階段三的應用架構

從SOA到微服務化這一步很是關鍵，複雜度也比較高，上手須要謹慎。

爲了可以承載互聯網高併發，業務每每須要拆分的粒度很是的細，細到什麼程度呢？咱們來看下面的圖。

在這些知名的使用微服務的互聯網公司中，微服務之間的相互調用已經密密麻麻相互關聯成爲一個網狀，幾乎都看不出條理來。

爲何要拆分到這個粒度呢？主要是高併發的需求。

可是高併發不是沒有成本的，拆分紅這個粒度會有什麼問題呢？你會發現等拆完了，下面的這些措施一個都不能少。

• 拆分如何保證功能不變，不引入Bug——持續集成，參考微服務化的基石——持續集成
• 靜態資源要拆分出來，緩存到接入層或者CDN，將大部分流量攔截在離用戶近的邊緣節點或者接入層緩存，參考微服務的接入層設計與動靜資源隔離
• 應用的狀態要從業務邏輯中拆分出來，使得業務無狀態，能夠基於容器進行橫向擴展，參考微服務化之無狀態化與容器化
• 核心業務和非核心業務要拆分，方便核心業務的擴展以及非核心業務的降級，參考微服務化之服務拆分與服務發現
• 數據庫要讀寫分離，要分庫分表，才能在超大數據量的狀況下，數據庫具備橫向擴展的能力，不成爲瓶頸，參考微服務化的數據庫設計與讀寫分離
• 要層層緩存，只有少數的流量到達中軍大營數據庫，參考微服務化之緩存的設計
• 要使用消息隊列，將原來連續調用的多個服務異步化爲監聽消息隊列，從而縮短核心邏輯
• 服務之間要設定熔斷，限流，降級策略，一旦調用阻塞應該快速失敗，而不該該卡在那裏，處於亞健康狀態的服務要被及時熔斷，不產生連鎖反應。非核心業務要進行降級，再也不調用，將資源留給核心業務。要在壓測到的容量範圍內對調用限流，寧肯慢慢處理，也不用一會兒都放進來，把整個系統沖垮。
• 拆分紅的服務太多了，沒辦法一個個配置，須要統一的一個配置中心，將配置下發
• 拆分紅的服務太多了，沒辦法一個個看日誌，須要統一的日誌中心，將日誌彙總
• 拆分紅的服務太多了，很難定位性能瓶頸，須要經過APM全鏈路應用監控，發現性能瓶頸，及時修改
• 拆分紅的服務太多了，不壓測一下，誰也不知道到底可以抗住多大的量，於是須要全鏈路的壓測系統。
  

應用層須要處理這十二個問題，最後一個都不能少，實施微服務，你作好準備了嗎？你真以爲攢一攢springcloud，就可以作好這些嗎？

4.2. 階段三的運維模式

業務的微服務化改造以後，對於運維的模式是有衝擊的。

若是業務拆成了如此網狀的細粒度，服務的數目就會很是的多，每一個服務都會獨立發佈，獨立上線，於是版本也很是多。

這樣環境就會很是的多，手工部署已經不可能，必須實施自動部署。好在在上一個階段，咱們已經實施了自動部署，或者基於腳本的，或者基於鏡像的，可是到了微服務階段都有問題。

若是基於腳本的部署，腳本原來多由運維寫，因爲服務太多，變化也多，腳本確定要不斷的更新，而每家公司的開發人員都遠遠多於運維人員，運維根原本不及維護自動部署的腳本。那腳本能不能由開發寫呢？通常是不可行的，開發對於運行環境瞭解有限，並且腳本沒有一個標準，運維沒法把控開發寫的腳本的質量。

基於虛擬機鏡像的就會好不少，由於須要腳本作的事情比較少，大部分對於應用的配置都打在鏡像裏面了。若是基於虛擬機鏡像進行交付，也能起到標準交付的效果。並且一旦上線有問題，也能夠基於虛擬機鏡像的版本進行回滾。

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

這個時候，容器就有做用了。鏡像是容器的根本性發明，是封裝和運行的標準，其餘什麼namespace，cgroup，早就有了。

原來開發交付給運維的，是一個war包，一系列配置文件，一個部署文檔，可是因爲部署文檔更新不及時，經常出現運維部署出來出錯的狀況。有了容器鏡像，開發交付給運維的，是一個容器鏡像，容器內部的運行環境，應該體如今Dockerfile文件中，這個文件是應該開發寫的。

這個時候，從流程角度，將環境配置這件事情，往前推了，推到了開發這裏，要求開發完畢以後，就須要考慮環境部署的問題，而不能當甩手掌櫃。因爲容器鏡像是標準的，就不存在腳本沒法標準化的問題，一旦單個容器運行不起來，確定是Dockerfile的問題。

而運維組只要維護容器平臺就能夠，單個容器內的環境，交給開發來維護。這樣作的好處就是，雖然進程多，配置變化多，更新頻繁，可是對於某個模塊的開發團隊來說，這個量是很小的，由於5-10我的專門維護這個模塊的配置和更新，不容易出錯。本身改的東西本身知道。

若是這些工做量全交給少數的運維團隊，不但信息傳遞會使得環境配置不一致，部署量會大很是多。

容器做用之一就是環境交付提早，讓每一個開發僅僅多作5%的工做，就可以節約運維200%的工做，而且不容易出錯。

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

容器鏡像有個特色，就是ssh到裏面作的任何修改，重啓都不見了，恢復到鏡像原來的樣子，也就杜絕了原來咱們部署環境，這改改，那修修最後部署成功的壞毛病。

由於若是機器數目比較少，還能夠登陸到每臺機器上改改東西，一旦出了錯誤，比較好排查，可是微服務狀態下，環境如此複雜，規模如此大，一旦有個節點，由於人爲修改配置致使錯誤，很是難排查，因此應該貫徹不可改變基礎設施，一旦部署了，就不要手動調整了，想調整從頭走發佈流程。

這裏面還有一個概念叫作一切即代碼，單個容器的運行環境Dockerfile是代碼，容器之間的關係編排文件是代碼，配置文件是代碼，全部的都是代碼，代碼的好處就是誰改了什麼，Git裏面一清二楚，均可以track，有的配置錯了，能夠統一發現誰改的。

4.3. 階段三的組織形態

到了微服務階段，實施容器化以後，你會發現，然而原本原來運維該作的事情開發作了，開發的老大願意麼？開發的老大會投訴運維的老大麼？

這就不是技術問題了，其實這就是DevOps，DevOps不是不區分開發和運維，而是公司從組織到流程，可以打通，看如何合做，邊界如何劃分，對系統的穩定性更有好處。

其實開發和運維變成了一個融合的過程，開發會幫運維作一些事情，例如環境交付的提早，Dockerfile的書寫。

運維也能夠幫助研發作一些事情，例如微服務之間的註冊發現，治理，配置等，不可能公司的每個業務都單獨的一套框架，能夠下沉到運維組來變成統一的基礎設施，提供統一的管理。

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

在網易就是這個模式，杭州研究院做爲公共技術服務部門，有運維部門管理機房，上面是雲平臺組，基於OpenStack開發了租戶可自助操做的雲平臺。PaaS組件也是雲平臺的一部分，點擊可得，提供SLA保障。容器平臺也是雲平臺的一部分，而且基於容器提供持續集成，持續部署的工具鏈。

微服務的管理和治理也是雲平臺的一部分，業務部門可使用這個平臺進行微服務的開發。

業務部門的中間件組或者架構組合雲平臺組溝通密切，主要是如何以正確的姿式使用雲平臺組件。

業務部門分前端組，業務開發組，中臺開發組。

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

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

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

詳細分析參加爲何 kubernetes 自然適合微服務

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

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

於是基於Kubernetes和SpringCloud，就有了下面這個微服務，容器，DevOps的綜合管理平臺。包含基於Kubernetes的容器平臺，持續集成平臺，測試平臺，API網關，微服務框架，APM應用性能管理。

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

下面咱們列舉幾個場景。

場景一：架構SOA拆分時，如何保證迴歸測試功能集不變

前面說過，服務拆分後，最怕的是拆完了引入一大堆的bug，經過理智確定不能保證拆分後功能集是不變的，於是須要有迴歸測試集合保證，只要測試集合經過了，功能就沒有太大的問題。

迴歸測試最好是基於接口的，由於基於UI的很危險，有的接口是有的，可是UI上不能點，這個接口若是有Bug，就被暫時隱藏掉了，當後面有了新的需求，當開發發現有個接口可以調用的時候，一調用就掛了。

有了基於Restful API的接口測試以後，能夠組成場景測試，將多個API調用組合成爲一個場景，例以下單，扣優惠券，減庫存，就是一個組合場景。

另外能夠造成測試集合，例如冒煙測試集合，當開發將功能交付給測試的時候，執行一下。再如平常測試集合，天天晚上跑一遍，看看當天提交的代碼有沒有引入新的bug。再如迴歸測試集合，上線以前跑一遍，保證大部分的功能是正確的。

場景二：架構SOA化的時候，如何統一管理並提供中臺服務

當業務要提供中臺服務的時候，中臺服務首先但願可以註冊到一個地方，當業務組開發業務邏輯的時候，可以在這個地方找到中臺的接口如何調用的文檔，當業務組的業務註冊上來的時候，能夠進行調用。

在微服務框架普通的註冊發現功能以外，還提供知識庫的功能，使得接口和文檔統一維護，文檔和運行時一致，從而調用方看着文檔就能夠進行調用。

另外提供註冊，發現，調用期間的鑑權功能，不是誰看到中臺服務都能調用，須要中臺管理員受權才能夠。

爲了防止中臺服務被惡意調用，提供帳戶審計功能，記錄操做。

場景三：服務SOA化的時候，如何保證關鍵服務的調用安全

有的服務很是關鍵，例如支付服務，和資金相關，不是誰想調用就能調用的，一旦被非法調用了，後果嚴重。

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

場景四：架構SOA化後，對外提供API服務，構建開放平臺

架構SOA化以後，除了對內提供中臺服務，不少能力也能夠開放給外部的合做夥伴，造成開放平臺。例如你是一家物流企業，除了在你的頁面上下單寄快遞以外，其餘的電商也能夠調用你的API來寄快遞，這就須要有一個API網關來管理API，對接你的電商只要登陸到這個API網關，就能看到API以及如何調用，API網關上面的文檔管理就是這個做用。

另外API網關提供接口的統一認證鑑權，也提供API接口的定時開關功能，靈活控制API的生命週期。

場景五：互聯網場景下的灰度發佈和A/B測試

接下來咱們切換到互聯網業務場景，常常會作A/B測試，這就須要API網關的流量分發功能。

例如咱們作互聯網業務，當上一個新功能的 時候，不清楚客戶是否喜歡，因而能夠先開放給山東的客戶，當HTTP頭裏面有來自山東的字段，則訪問B系統，其餘客戶仍是訪問A系統，這個時候能夠看山東的客戶是否都喜歡，若是都喜歡，就推向全國，若是不喜歡，就撤下來。

場景六：互聯網場景下的預發測試

這個也是互聯網場景下常常遇到的預發測試，雖然咱們在測試環境裏面測試了不少輪，可是因爲線上場景更加複雜，有時候須要使用線上真實數據進行測試，這個時候能夠在線上的正式環境旁邊部署一套預發環境，使用API網關將真實的請求流量，鏡像一部分到預發環境，若是預發環境可以正確處理真實流量，再上線就放心多了。

場景七：互聯網場景下的性能壓測

互聯網場景下要作線上真實的性能壓測，才能知道整個系統真正的瓶頸點。可是性能壓測的數據不能進真實的數據庫，於是須要進入影子庫，性能壓測的流量，也須要有特殊的標記放在HTTP頭裏面，讓通過的業務系統知道這是壓測數據，不進入真實的數據庫。

這個特殊的標記要在API網關上添加，可是因爲不一樣的壓測系統要求不同，於是須要API網關有定製路由插件功能，能夠隨意添加本身的字段到HTTP頭裏面，和壓測系統配合。

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

微服務場景下，大促的時候，須要進行熔斷，限流，降級。這個在API網關上能夠作，將超過壓測值的流量，經過限流，攔在系統外面，從而保證儘可能的流量，可以下單成功。

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

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

在互聯網場景下，常常須要對於流量進行精細化的管理，能夠根據HTTP Header裏面的參數進行分流，例如VIP用戶訪問一個服務，非VIP用戶訪問另外一個服務，這樣能夠對高收入的用戶推薦更加精品的產品，增長連帶率。