建站
咨詢
售后
建站咨詢
新聞中心
很多系統(tǒng)遷移到微服務(wù)架構(gòu)之后，并沒有明顯感覺到微服務(wù)架構(gòu)帶來的優(yōu)勢，反而覺得帶來了更高的復雜度，王啟軍在《持續(xù)演進的Cloud Native》書中總結(jié)了七種微服務(wù)架構(gòu)沒能發(fā)揮出固有優(yōu)勢的原因，看看自己“中槍”了沒!
做網(wǎng)站、成都做網(wǎng)站服務(wù)團隊是一支充滿著熱情的團隊，執(zhí)著、敏銳、追求更好，是創(chuàng)新互聯(lián)的標準與要求，同時竭誠為客戶提供服務(wù)是我們的理念。成都創(chuàng)新互聯(lián)公司把每個網(wǎng)站當做一個產(chǎn)品來開發(fā)，精雕細琢，追求一名工匠心中的細致，我們更用心！
1、用傳統(tǒng)方式構(gòu)建微服務(wù)
微服務(wù)架構(gòu)和傳統(tǒng)的架構(gòu)方式思路完全不一樣。例如傳統(tǒng)方式實現(xiàn)高可用，更相信流程，更相信KPI對人的影響，因此流程需要讓更多的人去測試，制定更嚴格的發(fā)布流程。
而微服務(wù)架構(gòu)強調(diào)的是自動化發(fā)布、灰度發(fā)布、Design For Failure、自動化測試、故障隔離、自愈。很多失敗的案例以傳統(tǒng)的方式去構(gòu)建微服務(wù)架構(gòu)，一切都沒有轉(zhuǎn)變，只是把服務(wù)拆開，根本無法享受微服務(wù)架構(gòu)帶來的便利，反而因此遇到了更多麻煩。最明顯的是對開發(fā)人員的影響，他們質(zhì)疑微服務(wù)架構(gòu)是否適合自己的業(yè)務(wù)場景，而一個充滿質(zhì)疑的團隊是不可能具備強大戰(zhàn)斗力的。
2、組織結(jié)構(gòu)不變
如果要充分發(fā)揮微服務(wù)架構(gòu)的優(yōu)勢，組織結(jié)構(gòu)必須發(fā)生轉(zhuǎn)變，構(gòu)建和微服務(wù)配套的小團隊，并且讓他們擁有絕對的自主權(quán)。實際上，相當一部分實施微服務(wù)架構(gòu)的團隊都沒有做到這一點，因為組織結(jié)構(gòu)總是涉及利益。比較典型的問題是，小團隊不需要團隊以外的任何人來批準是否上線，架構(gòu)如何演進，使用什么數(shù)據(jù)庫。如果小團隊沒有權(quán)利，任何變動都要等待高層進行決策，就會形成決策瓶頸點，導致效率低下，這違背了微服務(wù)架構(gòu)的初衷，團隊成員也會因此失去主動性。
3、習慣于領(lǐng)導安排工作
傳統(tǒng)的研發(fā)模式嚴重依賴流程，原因是沒有人愿意承擔責任，所有人都把責任推到流程上。微服務(wù)架構(gòu)和敏捷開發(fā)流程是天作之合，傳統(tǒng)研發(fā)模式需要領(lǐng)導批準，然后由團隊負責人直接分解任務(wù)、定工時、安排任務(wù)負責人，而按照敏捷開發(fā)流程，開發(fā)計劃應該是團隊決定的，任務(wù)自主認領(lǐng)。精英化團隊絕不僅僅是團隊人數(shù)更少，人員能力更強這么簡單，這只是表面上的，更重要的是責任感和主觀能動性以及信任!
某公司CEO 曾經(jīng)說過這樣一件事情，員工把請假流程提給“我”，讓“我”審批，但是“我”根本沒有審批的必要，因為你隨便說一個理由“我”都不可能拒絕，就算拒絕了，下回會來一個更難以拒絕的理由。后來公司所有的請假都不需要審批了，只要在群里發(fā)一條消息，讓相關(guān)同事知道就可以了。
4、糾結(jié)如何拆分服務(wù)
不理解微服務(wù)架構(gòu)的人，通常從字面理解，他們認為微服務(wù)架構(gòu)的重中之重就是服務(wù)拆分。
到底拆分多細?與其浪費更多的時間思考這個問題，不如先拆出幾個服務(wù)運行一下，感受一下。架構(gòu)是一個持續(xù)的過程，有時候很難從技術(shù)角度完全解釋清楚。
另一個錯誤是一次性拆分，不能改變。由于技術(shù)人員對業(yè)務(wù)領(lǐng)域知識的理解不斷加深，業(yè)務(wù)邏輯有可能運行一段時間也會轉(zhuǎn)變，這時候改變是不可避免的。重新合并、劃分，是一個正常的演變過程。架構(gòu)是動態(tài)的，不是靜態(tài)的。
5、以大規(guī)模拆分服務(wù)開始
微服務(wù)架構(gòu)需要一個適應過程，持續(xù)拆分效果更佳。如果從大規(guī)模拆分服務(wù)開始，需要具備三個條件，否則可能會遇到相當多的麻煩。
- 團隊有微服務(wù)架構(gòu)經(jīng)驗。
- 已具備微服務(wù)架構(gòu)的先決條件，包括自動化的研發(fā)環(huán)境、全面的健康檢查、必要的公共服務(wù)及框架，以及敏捷基礎(chǔ)設(shè)施。
- 業(yè)務(wù)目標非常明確，已經(jīng)可以預期未來的規(guī)模，業(yè)務(wù)幾乎無變化。
6、高估架構(gòu)的移植性
架構(gòu)是一門藝術(shù)，不是隨隨便便復制一下就可以的，Google、Amazon、Facebook 的架構(gòu)問世已經(jīng)很長時間了，研發(fā)人員跳槽這么頻繁，但是沒有哪個公司能模仿好。MySQL 開源了這么多年，放到不同人的手里，結(jié)果完全不一樣。實際上實施微服務(wù)架構(gòu)在一個業(yè)務(wù)場景中的優(yōu)勢在另一個場景中很可能會變成一種劣勢。如果你仔細研究就會發(fā)現(xiàn)，大多數(shù)公司實施的微服務(wù)架構(gòu)就跟各個公司的管理制度一樣各不相同。很多公司為了顯示自己的架構(gòu)有多厲害而實施微服務(wù)架構(gòu)，最終只會害了團隊，因為只把精力放在微服務(wù)架構(gòu)上，可能就減少了對業(yè)務(wù)實現(xiàn)、用戶體驗的關(guān)注。
7、從來沒有做過微服務(wù)架構(gòu)的人領(lǐng)導你完成遷移
如果轉(zhuǎn)型的團隊由沒有經(jīng)驗的人來領(lǐng)導，那么結(jié)果就是只關(guān)注表面，拆了多少服務(wù)、服務(wù)粒度、服務(wù)注冊發(fā)現(xiàn)、負載均衡、調(diào)用鏈分析，而隱藏的各種性能問題、擴展性問題、可用性問題都沒有得到足夠的關(guān)注。如果只是從幾個服務(wù)拆分開始積累經(jīng)驗還好，一旦大規(guī)模拆分，就會讓整個團隊都質(zhì)疑微服務(wù)架構(gòu)的意義。架構(gòu)是需要實踐的，不要以為看幾篇文章就得到了架構(gòu)的真諦，細節(jié)會“殺死”團隊。
本文選自《持續(xù)演進的Cloud Native：云原生架構(gòu)下微服務(wù)最佳實踐》，作者王啟軍 ，電子工業(yè)出版社10月出版。
作者從全局視角出發(fā)，全面闡釋Cloud Native 的關(guān)鍵技術(shù)，以及其衍生出來的工具、團隊文化等核心要素，對于正在部署微服務(wù)架構(gòu)或開展云原生業(yè)務(wù)的企業(yè)和組織而言，終于有了面向落地的務(wù)實參考和全面指導。
當前名稱：遷移到微服務(wù)架構(gòu)，為什么你仍沒有發(fā)現(xiàn)它的固有優(yōu)勢
網(wǎng)頁地址：http://m.5511xx.com/article/dhdephs.html
