致傳統(tǒng)企業(yè)朋友：不夠痛就別微服務(wù)，有坑

應(yīng)用層需要處理這十二個(gè)問(wèn)題，最后一個(gè)都不能少，實(shí)施微服務(wù)，你做好準(zhǔn)備了嗎？你真覺(jué)得攢一攢springcloud，就能夠做好這些嗎？

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

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

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

其實(shí)開(kāi)發(fā)和運(yùn)維變成了一個(gè)融合的過(guò)程，開(kāi)發(fā)會(huì)幫運(yùn)維做一些事情，例如環(huán)境交付的提前，Dockerfile的書(shū)寫(xiě)。

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

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

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

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

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

業(yè)務(wù)部門(mén)分前端組，業(yè)務(wù)開(kāi)發(fā)組，中臺(tái)開(kāi)發(fā)組。

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

實(shí)施微服務(wù)，容器化，DevOps有很多的技術(shù)選型。

其中容器化的部分，Kubernetes當(dāng)之無(wú)愧的選擇。但是Kubernetes可不僅僅志在容器，他是為微服務(wù)而設(shè)計(jì)的。對(duì)于實(shí)施微服務(wù)各方面都有涉及。

詳細(xì)分析參加為什么 kubernetes 天然適合微服務(wù)  但是Kubernetes對(duì)于容器的運(yùn)行時(shí)生命周期管理比較完善，但是對(duì)于服務(wù)治理方面還不夠強(qiáng)大。

因而對(duì)于微服務(wù)的治理方面，多選擇使用Dubbo或者SpringCloud。使用Dubbo的存量應(yīng)用比較多，相對(duì)于Dubbo來(lái)講，SpringCloud比較新，組件也比較豐富。但是SpringCloud的組件都不到開(kāi)箱即用的程度，需要比較高的學(xué)習(xí)曲線(xiàn)。

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

       主要為了解決從階段一到階段二，或者階段二到階段三的改進(jìn)中的痛點(diǎn)。

下面我們列舉幾個(gè)場(chǎng)景。

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

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

回歸測(cè)試最好是基于接口的，因?yàn)榛赨I的很危險(xiǎn)，有的接口是有的，但是UI上不能點(diǎn)，這個(gè)接口如果有Bug，就被暫時(shí)隱藏掉了，當(dāng)后面有了新的需求，當(dāng)開(kāi)發(fā)發(fā)現(xiàn)有個(gè)接口能夠調(diào)用的時(shí)候，一調(diào)用就掛了。

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

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

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

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

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

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

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

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

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

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

場(chǎng)景四：架構(gòu)SOA化后，對(duì)外提供API服務(wù)，構(gòu)建開(kāi)放平臺(tái)

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

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

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

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

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

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

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

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

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

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

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

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

在服務(wù)之間，也可以通過(guò)微服務(wù)框架，進(jìn)行熔斷，限流，降級(jí)。Dubbo對(duì)于服務(wù)的控制在接口層面，SpringCloud對(duì)于服務(wù)的管理在實(shí)例層面，這兩個(gè)粒度不同的客戶(hù)選擇不一樣，都用Dubbo粒度太細(xì)，都用SpringCloud粒度太粗，所以需要可以靈活配置。

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

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

本文轉(zhuǎn)自 ：劉超的通俗云計(jì)算。