此文已由作者劉超授權網易雲社區發布。

歡迎訪問網易雲社區，了解更多網易技術產品運營經驗。

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

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

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

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

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

在這個階段，由於業務的穩定性要求，很多公司還是會采用Oracle商用數據庫，也沒有什麽問題。

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

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

我們發現，當傳統行業不再滿足於在本行業的領先地位，希望能夠對接到互聯網業務的時候，上面的模式才出現新的痛點。

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

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

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

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

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

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

有的客戶發現，一旦到了互聯網大促級別，Oracle數據庫是肯定扛不住的，需要從Oracle遷移到DDB分布式數據庫，可是怎麽個遷移法，如何平滑過渡，心裏沒底。

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

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

四、階段三：組織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保障。容器平臺也是雲平臺的一部分，並且基於容器提供持續集成，持續部署的工具鏈。

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

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

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

五、如何實施微服務，容器化，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用戶訪問另一個服務，這樣可以對高收入的用戶推薦更加精品的產品，增加連帶率。

網易雲計算基礎服務深度整合了 IaaS、PaaS 及容器技術，提供彈性計算、DevOps 工具鏈及微服務基礎設施等服務，幫助企業解決 IT、架構及運維等問題，使企業更聚焦於業務，是新一代的雲計算平臺，點擊可免費試用。

免費體驗雲安全(易盾)內容安全、驗證碼等服務

更多網易技術、產品、運營經驗分享請點擊。

相關文章：
【推薦】 GitLab 自動觸發 Jenkins 構建
【推薦】 純幹貨！live2d動畫制作簡述以及踩坑

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