不要再說微服務(wù)可以解決一切問題了！
??點擊“博文視點Broadview”，獲取更多書訊
微服務(wù)架構(gòu)提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，形成分布式調(diào)用，為用戶提供最終價值。
因此無論是創(chuàng)業(yè)型公司還是互聯(lián)網(wǎng)獨角獸企業(yè)，都將微服務(wù)架構(gòu)當成一把利刃，用它解決項目在開發(fā)中所遇到的一切問題。
目前，能夠支持微服務(wù)架構(gòu)的開源技術(shù)有很多，那么微服務(wù)架構(gòu)真的很容易嗎？
通過互聯(lián)網(wǎng)大會以及企業(yè)內(nèi)部培訓等方式和多家創(chuàng)業(yè)型公司的CTO和架構(gòu)師交流后發(fā)現(xiàn)，很多項目以微服務(wù)架構(gòu)規(guī)劃開始，經(jīng)過幾次迭代后卻以單體架構(gòu)收尾，導致項目失敗。
項目復盤后分析后得出，失敗主要是由于缺乏實戰(zhàn)經(jīng)驗，在架構(gòu)設(shè)計階段不能快速識別和有效解決微服架構(gòu)的副作用所導致的。
實際上，微服務(wù)架構(gòu)是一把雙刃劍，其目標是將單體應(yīng)用拆分為無狀態(tài)的服務(wù)，通過橫向擴展的方式解決項目的瓶頸，還能解決項目中出現(xiàn)的諸如代碼沖突、模塊耦合、項目交付質(zhì)量下降、團隊工作效率下降的問題、接口性能瓶頸等問題。
微服務(wù)架構(gòu)的弊端也很明顯，例如不能簡單的通過一行注解來保證事務(wù)的完整性，容易出現(xiàn)數(shù)據(jù)不一致性情況。
那么，如何最簡單可靠地使用分布式事務(wù)解決數(shù)據(jù)不一致的問題呢？
原本內(nèi)部接口調(diào)用變成服務(wù)間的RPC調(diào)用，和單體應(yīng)用相比，微服務(wù)架構(gòu)下的接口性能反而更低了，這種問題該如何規(guī)避？
RPC調(diào)用過程因為網(wǎng)絡(luò)問題不可避免出現(xiàn)重復調(diào)用情況，引發(fā)臟數(shù)據(jù)，因此在微服務(wù)架構(gòu)下就要求每個接口都需要具備冪等性，那么，冪等性的常用解決方案有哪些？
微服務(wù)拆分沒有技術(shù)標準，這就涉及到服務(wù)到底如何拆分比較合理，服務(wù)拆分顆粒度如何把握，一個服務(wù)的維護團隊有多少人比較合適呢？
系統(tǒng)架構(gòu)設(shè)計時先按功能拆分獨立的服務(wù)，再引入Dubbo或者SpringCloud框架，系統(tǒng)就變成了微服務(wù)架構(gòu)了嗎？
為什么從單體變成微服務(wù)架構(gòu)后原始接口反而變慢了？
微服務(wù)框架下的代碼到底如何優(yōu)化？
微服務(wù)架構(gòu)轉(zhuǎn)型后，測試團隊還是按照之前的思維執(zhí)行接口測試、功能測試，是否覆蓋所有場景？
框架是否需要測試，服務(wù)與服務(wù)之間調(diào)用的異常該如何測試？
當這些技術(shù)問題擺在研發(fā)團隊面前時，有些CTO開始猶豫了：
創(chuàng)業(yè)型公司技術(shù)架構(gòu)選型在項目啟動時就按微服務(wù)架構(gòu)來設(shè)計項目是否必要？
若沒有使用微服務(wù)架構(gòu)那么項目運行過程中出現(xiàn)性能問題如何解決呢？
假設(shè)目前是單體架構(gòu)，后續(xù)如何能平滑遷移到微服務(wù)架構(gòu)？
隨著項目團隊逐步壯大以及在生產(chǎn)環(huán)境下不斷的試錯，團隊經(jīng)過多次線上實戰(zhàn)，獲得了很多寶貴生產(chǎn)的經(jīng)驗，終究會找到處理這些副用作的方法或技巧。
然而，當公司業(yè)務(wù)轉(zhuǎn)型從單一業(yè)務(wù)線變成多元化的業(yè)務(wù)線后，似乎微服務(wù)架構(gòu)下的系統(tǒng)又出現(xiàn)了新的問題：
各業(yè)務(wù)線之間的數(shù)據(jù)形成孤島，同樣的功能重復開發(fā)，有時為加快項目開發(fā)進度甚至從別的業(yè)務(wù)線直接把原功能的代碼復制過來經(jīng)過簡單修改就完成新需求的開發(fā)，導致同類型的bug在每個業(yè)務(wù)線都會出現(xiàn)。
研發(fā)團隊人數(shù)一直在不斷的增加，但是總是感覺研發(fā)人員不夠用。
此時，中臺的出現(xiàn)恰好解決了這些問題，中臺倡導企業(yè)級能力復用的思想，提倡將共性需求下沉到中臺形成通用能力對外輸出，以減少重復開發(fā)。因此，微服務(wù)架構(gòu)轉(zhuǎn)向中臺架構(gòu)，是僅喊口號還是需要怎么怎樣系統(tǒng)的過程？
《架構(gòu)演變實戰(zhàn)：從單體到微服務(wù)再到中臺》這本書通過真實案例實戰(zhàn)的方式完整地講述了如何從一個單體架構(gòu)逐步轉(zhuǎn)型到中臺的歷程！
全書共9個章節(jié)：
第1章通過案例的方式講解當單體架構(gòu)遇到問題后如何去優(yōu)化，其次通過一個失敗的案例來描述在真正打算使用微服務(wù)架構(gòu)前需要有哪些準備。
第2章則介紹服務(wù)如何拆分，以及標準化微服務(wù)架構(gòu)的項目結(jié)構(gòu)有哪些優(yōu)勢。
第3章則以概念和實戰(zhàn)來介紹常用的微服務(wù)開始模式有哪些。
第4章則以實際案例為基礎(chǔ)，描述如何從單體架構(gòu)轉(zhuǎn)型到微服務(wù)架構(gòu)，在這過程中需要做哪些工作。
微服務(wù)重點在于每個服務(wù)的打磨，因此第5章則通過具體方案講述如何去打磨每個服務(wù)，如何使用多級緩存、并行調(diào)用等手段來提高系統(tǒng)的吞吐量，如果使用混合限流來保障服務(wù)的穩(wěn)定性，如何使用消息隊列來做削峰等。網(wǎng)關(guān)是系統(tǒng)的統(tǒng)一入口，是微服務(wù)架構(gòu)下非常重要的組件，當開源網(wǎng)關(guān)不滿足業(yè)務(wù)需要，如何自研一套微服務(wù)網(wǎng)關(guān)呢?
第6章則以具體案例來介紹如何從0開始自研滿足個性化需求的網(wǎng)關(guān)。微服務(wù)架構(gòu)不僅開發(fā)模式需要轉(zhuǎn)變，測試方式也需要轉(zhuǎn)變，那么微服務(wù)架構(gòu)下如何做系統(tǒng)測試，為什么又要引入混沌實驗？
第7章站在測試角度去看微服務(wù)架構(gòu)下的測試。
第8章去評估在既能保障服務(wù)穩(wěn)定運行，又能避免浪費，通過科學有效的方式來以全鏈路壓測平臺為基礎(chǔ)，系統(tǒng)科學的評估線上容量。
第9章則講述如何從微服務(wù)架構(gòu)走向中臺，在這過程中需要如何去組建中臺團隊，需要公司的哪些支持配合等，如何把控中臺的需求以及中臺如何分階段去考核等。
本書以真實案例為基礎(chǔ)，再融合技術(shù)要點，逐步介紹如何設(shè)計出滿足業(yè)務(wù)需求和性能需求的架構(gòu)，是架構(gòu)師參考的工具書，也是技術(shù)優(yōu)化的參考書。
微服務(wù)由于具有擴展性強、松耦合、便于敏捷開發(fā)等特性，在云計算時代被越來越多的組織所采用，采用微服務(wù)架構(gòu)成為現(xiàn)代企業(yè)數(shù)字化轉(zhuǎn)型的必經(jīng)之路。
本書從單體應(yīng)用開篇，詳盡闡述了架構(gòu)選型、拆分、實施、優(yōu)化等微服務(wù)落地過程中所遇到的問題和解決的辦法。全書深入淺出，既有整體的理論性指導，又有對Dubbo、Spring Cloud等微服務(wù)工具的詳盡解釋，對于微服務(wù)實踐者有非常高的參考和學習價值。
——厲啟鵬，Apache RocketMQ PMC M ember、RocketMQ中國社區(qū)發(fā)起人
初識本書作者是在Dubbo社區(qū)的線下沙龍中，后續(xù)在Dubbo社區(qū)的維護過程中我們也有過一些深入的交流與探討。作者對Dubbo、微服務(wù)架構(gòu)的深刻認知與豐富的實踐經(jīng)驗讓人印象深刻。
本書從當前流行的微服務(wù)架構(gòu)出發(fā)，詳細介紹了如何從單體架構(gòu)升級為微服務(wù)架構(gòu)，并以實戰(zhàn)的形式從基礎(chǔ)理論開始，逐步優(yōu)化微服務(wù)架構(gòu)的每個細節(jié)，最終升級為中臺架構(gòu)，整個升級思路講解清晰。本書將理論和實踐相結(jié)合，可作為微服務(wù)架構(gòu)技術(shù)選型或?qū)嵤┑膮⒖紙D書。
——劉軍，Apache Dubbo PMC Chair、Dubbo3開源負責人
本書的最大特點是貼合業(yè)務(wù)來談架構(gòu)，針對不同的業(yè)務(wù)場景給出了有針對性、接地氣的架構(gòu)范式、演進思路及落地策略，同時融合了潘老師基于自身實戰(zhàn)經(jīng)驗的深度總結(jié)。相信這本誠意之作定能讓讀者受益匪淺！
——李鑫，《微服務(wù)治理：體系、架構(gòu)及實踐》作者、天弘基金線上渠道技術(shù)負責人
從微服務(wù)的基礎(chǔ)知識，到微服務(wù)的進階知識，以及到最后的中臺系統(tǒng)實戰(zhàn)，作者條理清晰、由淺入深地介紹了服務(wù)架構(gòu)所涉及的方方面面的關(guān)鍵技術(shù)和原理。建議相關(guān)從業(yè)人員閱讀本書。
——王新棟，京東零售技術(shù)總監(jiān)、《架構(gòu)修煉之道》作者
本書從一個創(chuàng)業(yè)公司由單體架構(gòu)向微服務(wù)架構(gòu)轉(zhuǎn)型的實際案例出發(fā)，向讀者展示了構(gòu)建分布式系統(tǒng)的全生命周期。通過翔實的案例剖析、深度的原理講解及實操分享，讀者不僅知其然，更能知其所以然。本書不失為一本可以常備案頭的實用百寶書。相信不管是對分布式原理感興趣的初學者，還是正著手分布式轉(zhuǎn)型的資深工程師，通過閱讀本書，都會有所收獲。
——宋順（齊天），螞蟻集團高級技術(shù)專家、Apollo Config PM C
本書基于潘老師自己的經(jīng)驗，對中臺架構(gòu)及其實現(xiàn)做了很客觀的闡述，利弊解釋都頗富“實感”。沒有完美的架構(gòu)，也沒有完美的方法，顧“此”極有可能失“彼”，這也再度驗證了很多人對架構(gòu)的看法。架構(gòu)即平衡之道，架構(gòu)即取舍之道。架構(gòu)理論有共性，架構(gòu)實施則充滿個性，需要在實施中時刻提醒自己，在別人的經(jīng)驗和自己的環(huán)境中做好取舍，在別人的能力和自己的限制之間做好平衡。不然，本書第1章的“翻車”事故，就有可能在你實踐本書第9章的設(shè)計時重現(xiàn)。大的成功不是很容易復現(xiàn)，大的失敗卻很容易再臨。
——付曉巖，《企業(yè)級業(yè)務(wù)架構(gòu)設(shè)計：方法論與實踐》《聚合架構(gòu)：面向數(shù)字生態(tài)的構(gòu)件化企業(yè)架構(gòu)》作者
下單立減50，快快掃碼搶購吧！
如果喜歡本文 歡迎 在看丨留言丨分享至朋友圈 三連 熱文推薦
▼點擊閱讀原文，了解本書詳情~