微服務(wù)架構(gòu)的技術(shù)體系、社區(qū)目前已經(jīng)越來(lái)越成熟。在最初系統(tǒng)架構(gòu)的搭建署咽，或者當(dāng)現(xiàn)有架構(gòu)已到達(dá)瓶頸需要進(jìn)行架構(gòu)演進(jìn)時(shí)，很多架構(gòu)師、運(yùn)維工程師會(huì)考慮是否需要搭建微服務(wù)架構(gòu)體系宁否。雖然很多文章都說(shuō)微服務(wù)架構(gòu)是復(fù)雜的窒升、會(huì)帶來(lái)很多分布式的問(wèn)題，但只要我們了解這些問(wèn)題慕匠，并找到解法饱须，就會(huì)有種撥開(kāi)云霧的感覺(jué)。
微服務(wù)架構(gòu)也不是完美的台谊，世上沒(méi)有完美的架構(gòu)蓉媳，微服務(wù)架構(gòu)也是隨著業(yè)務(wù)、團(tuán)隊(duì)成長(zhǎng)而不斷演進(jìn)的锅铅。最開(kāi)始可能就幾個(gè)酪呻、十幾個(gè)微服務(wù)，每個(gè)服務(wù)是分庫(kù)的盐须，通過(guò) API Gateway 并行進(jìn)行服務(wù)數(shù)據(jù)合并玩荠、轉(zhuǎn)發(fā)。隨著業(yè)務(wù)擴(kuò)大贼邓、不斷地加入搜索引擎阶冈、緩存技術(shù)、分布式消息隊(duì)列塑径、數(shù)據(jù)存儲(chǔ)層的數(shù)據(jù)復(fù)制女坑、分區(qū)、分表等统舀。
微服務(wù)是一種服務(wù)間松耦合的匆骗、每個(gè)服務(wù)之間高度自治并且使用輕量級(jí)協(xié)議進(jìn)行通信的可持續(xù)集成部署的分布式架構(gòu)體系。這一句包含了微服務(wù)的特點(diǎn)绑咱，微服務(wù)架構(gòu)和其他架構(gòu)有什么區(qū)別绰筛？以下對(duì)比一些常見(jiàn)的架構(gòu)。
單體架構(gòu)是最簡(jiǎn)單的軟件架構(gòu)描融，常用于傳統(tǒng)的應(yīng)用軟件開(kāi)發(fā)以及傳統(tǒng) Web 應(yīng)用铝噩。傳統(tǒng) Web 應(yīng)用，一般是將所有功能模塊都打包（jar窿克、war）在一個(gè) Web 容器（JBoss骏庸、Tomcate）中部署、運(yùn)行年叮。隨著業(yè)務(wù)復(fù)雜度增加具被、技術(shù)團(tuán)隊(duì)規(guī)模擴(kuò)大，在一個(gè)單體應(yīng)用中維護(hù)代碼只损，會(huì)降低開(kāi)發(fā)效率一姿，即使是處理一個(gè)小需求七咧，也需要將所有機(jī)器上的應(yīng)用全部部署一遍，增加了運(yùn)維的復(fù)雜度叮叹。
當(dāng)某一天使用單體架構(gòu)發(fā)現(xiàn)很難推進(jìn)需求的開(kāi)發(fā)艾栋、以及日積月累的技術(shù)債時(shí)，很多企業(yè)會(huì)開(kāi)始做單體服務(wù)的拆分蛉顽，拆分的方式一般有水平拆分和垂直拆分蝗砾。垂直拆分是把一個(gè)應(yīng)用拆成松耦合的多個(gè)獨(dú)立的應(yīng)用，讓?xiě)?yīng)用可以獨(dú)立部署携冤，有獨(dú)立的團(tuán)隊(duì)進(jìn)行維護(hù)悼粮；水平拆分是把一些通用的，會(huì)被很多上層服務(wù)調(diào)用的模塊獨(dú)立拆分出去曾棕，形成一個(gè)共享的基礎(chǔ)服務(wù)扣猫，這樣拆分可以對(duì)一些性能瓶頸的應(yīng)用進(jìn)行單獨(dú)的優(yōu)化和運(yùn)維管理，也在一定程度上防止了垂直拆分的重復(fù)造輪子睁蕾。
SOA 也叫面向服務(wù)的架構(gòu)苞笨，從單體服務(wù)到 SOA 的演進(jìn)，需要結(jié)合水平拆分及垂直拆分子眶。SOA 強(qiáng)調(diào)用統(tǒng)一的協(xié)議進(jìn)行服務(wù)間的通信，服務(wù)間運(yùn)行在彼此獨(dú)立的硬件平臺(tái)但是需通過(guò)統(tǒng)一的協(xié)議接口相互協(xié)作序芦，也即將應(yīng)用系統(tǒng)服務(wù)化臭杰。舉個(gè)易懂的例子，單體服務(wù)如果相當(dāng)于一個(gè)快餐店谚中，所有的服務(wù)員職責(zé)都是一樣的渴杆，又要負(fù)責(zé)收銀結(jié)算，又要負(fù)責(zé)做漢堡宪塔，又要負(fù)責(zé)端盤子磁奖，又要負(fù)責(zé)打掃，服務(wù)員之間不需要有交流某筐，用戶來(lái)了后比搭，服務(wù)員從前到后負(fù)責(zé)到底。SOA 相當(dāng)于讓服務(wù)員有職責(zé)分工南誊，收銀員負(fù)責(zé)收銀身诺，廚師負(fù)責(zé)做漢堡，保潔阿姨負(fù)責(zé)打掃等抄囚，所有服務(wù)員需要用同一種語(yǔ)言交流霉赡，方便工作協(xié)調(diào)。
微服務(wù)也是一種服務(wù)化幔托，不過(guò)其和 SOA 架構(gòu)的服務(wù)化概念也是有區(qū)別的穴亏，可以從以下幾個(gè)關(guān)鍵字來(lái)理解：
松耦合：每個(gè)微服務(wù)內(nèi)部都可以使用 DDD（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）的思想進(jìn)行設(shè)計(jì)領(lǐng)域模型，服務(wù)間盡量減少同步的調(diào)用，多使用消息的方式讓服務(wù)間的領(lǐng)域事件來(lái)進(jìn)行解耦嗓化。 輕量級(jí)協(xié)議：Dubbo 是 SOA 的開(kāi)源的標(biāo)準(zhǔn)實(shí)現(xiàn)之一锅劝，類似的還有像 gRPC、Thrift 等蟆湖。微服務(wù)更傾向于使用 Restful 風(fēng)格的 API故爵，輕量級(jí)的協(xié)議可以很好得支持跨語(yǔ)言開(kāi)發(fā)的服務(wù)，可能有的微服務(wù)用 Java 語(yǔ)言實(shí)現(xiàn)隅津，有的用 Go 語(yǔ)言诬垂，有的用 C++，但所有的語(yǔ)言都可以支持 Http 協(xié)議通信伦仍，所有的開(kāi)發(fā)人員都能理解 Restful 風(fēng)格 API 的含義结窘。 高度自治和持續(xù)集成：從底層的角度來(lái)說(shuō)，SOA 更加傾向于基于虛擬機(jī)或者服務(wù)器的部署充蓝，每個(gè)應(yīng)用都部署在不同的機(jī)器上隧枫，一般持續(xù)集成工具更多是由運(yùn)維團(tuán)隊(duì)寫(xiě)一些 Shell 腳本以及提供基于共同協(xié)議（比如 Dubbo 管理頁(yè)面）的開(kāi)發(fā)部署頁(yè)面。微服務(wù)可以很好得和容器技術(shù)結(jié)合谓苟，容器技術(shù)比微服務(wù)出現(xiàn)得晚官脓，但是容器技術(shù)的出現(xiàn)讓微服務(wù)的實(shí)施更加簡(jiǎn)便，目前 Docker 已經(jīng)成為很多微服務(wù)實(shí)踐的基礎(chǔ)容器涝焙。因?yàn)槿萜鞯奶厣氨浚砸慌_(tái)機(jī)器上可以部署幾十個(gè)、幾百個(gè)不同的微服務(wù)仑撞。如果某個(gè)微服務(wù)流量壓力比其他微服務(wù)大赤兴，可以在不增加機(jī)器的情況下，在一臺(tái)機(jī)器上多分配一些該微服務(wù)的容器實(shí)例隧哮。同時(shí)桶良，因?yàn)?Docker 的容器編排社區(qū)日漸成熟，類似 Mesos沮翔、Kubernetes 及 Docker 官方提供的 Swarm 都可以作為持續(xù)集成部署的技術(shù)選擇陨帆。
其實(shí)從架構(gòu)的演進(jìn)的角度來(lái)看，整體的演進(jìn)都是朝著越來(lái)越輕量級(jí)鉴竭、越來(lái)越靈活的應(yīng)用方向發(fā)展歧譬，甚至到近兩年日漸成熟起來(lái)的 Serverless（無(wú)服務(wù)）架構(gòu)。從單體服務(wù)到分層的服務(wù)搏存，再到面向服務(wù)瑰步、再到微服務(wù)甚至無(wú)服務(wù)，對(duì)于架構(gòu)的挑戰(zhàn)是越來(lái)越大璧眠。
微服務(wù)架構(gòu)屬于分布式系統(tǒng)嗎缩焦？答案是肯定的读虏。微服務(wù)和 SOA 都是典型的分布式架構(gòu)，只不過(guò)微服務(wù)的部署粒度更細(xì)袁滥，服務(wù)擴(kuò)展更靈活盖桥。
怎樣理解微服務(wù)中的分布式？舉一個(gè)招聘時(shí)一個(gè)同學(xué)來(lái)面試的例子题翻。A 同學(xué)說(shuō)揩徊，目前所在公司在做從單應(yīng)用到微服務(wù)架構(gòu)遷移的工作，已經(jīng)差不多完成了嵌赠。提到微服務(wù)感覺(jué)就有話題聊了塑荒，于是便問(wèn)：“是否可以簡(jiǎn)單描述下服務(wù)拆分后的部署結(jié)構(gòu)、底層存儲(chǔ)的拆分姜挺、遷移方案齿税？”于是 A 同學(xué)說(shuō)，只是做了代碼工程結(jié)構(gòu)的拆分炊豪，還是原來(lái)的部署方式凌箕，數(shù)據(jù)庫(kù)還是那個(gè)庫(kù)，所有的微服務(wù)都用一個(gè)庫(kù)词渤，分布式事務(wù)處理方式是“避免”牵舱，盡量都同步調(diào)用……于是我就跟這位同學(xué)友好地微笑說(shuō)再見(jiàn)了。
微服務(wù)的分布式不僅僅是容器應(yīng)用層面的分布式掖肋，其為了高度自治仆葡，底層的存儲(chǔ)體系也應(yīng)該互相獨(dú)立，并且也不是所有的微服務(wù)都需要持久化的存儲(chǔ)服務(wù)志笼。一個(gè)“手機(jī)驗(yàn)證碼”微服務(wù)可能底層存儲(chǔ)只用一個(gè) Redis；一個(gè)“營(yíng)銷活動(dòng)搭建頁(yè)面”微服務(wù)可能底層存儲(chǔ)只需要一個(gè) MongoDB把篓。
微服務(wù)中的分布式場(chǎng)景除了服務(wù)本身需要有服務(wù)發(fā)現(xiàn)纫溃、負(fù)載均衡，微服務(wù)依賴的底層存儲(chǔ)也會(huì)有分布式的場(chǎng)景：為了高可用性和性能需要處理數(shù)據(jù)庫(kù)的復(fù)制韧掩、分區(qū)紊浩，并且在存儲(chǔ)的分庫(kù)情況下，微服務(wù)需要能保證分布式事務(wù)的一致性疗锐。
微服務(wù)架構(gòu)的技術(shù)體系坊谁、社區(qū)目前已經(jīng)越來(lái)越成熟，所以在初期選擇使用或者企業(yè)技術(shù)體系轉(zhuǎn)型微服務(wù)的時(shí)候滑臊，需要了解微服務(wù)架構(gòu)中的分布式的問(wèn)題：
《分布式微服務(wù)架構(gòu)體系詳解》從微服務(wù)不得不面對(duì)和解決的分布式問(wèn)題出發(fā)口芍，包含分布式技術(shù)的一系列理論以及架構(gòu)模型、算法的介紹雇卷，同時(shí)結(jié)合技術(shù)選型和實(shí)踐應(yīng)用鬓椭，提供一系列解決方案的梳理颠猴。相信閱讀完整個(gè)課程，你會(huì)對(duì)微服務(wù)的分布式問(wèn)題有個(gè)系統(tǒng)地理解小染。本課程會(huì)對(duì)微服務(wù)的分布式場(chǎng)景問(wèn)題一一擊破翘瓮，為你提供解決思路。并且裤翩，本課程通過(guò)對(duì)分布式問(wèn)題的體系化梳理资盅，結(jié)合一些方案的對(duì)比選型，可以讓工程師們一覽微服務(wù)的知識(shí)圖譜踊赠。
