原文地址：http://www.infoq.com/cn/articles/micro-service-architecture-from-zero?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage

導(dǎo)語(yǔ)

雖然已經(jīng)紅了很久，但是“微服務(wù)架構(gòu)”正變得越來(lái)越重要，也將繼續(xù)火下去。

各個(gè)公司與技術(shù)人員都在分享微服務(wù)架構(gòu)的相關(guān)知識(shí)與實(shí)踐經(jīng)驗(yàn)，但我們發(fā)現(xiàn)，目前網(wǎng)上的這些相關(guān)文章中，要么上來(lái)就是很有借鑒意義的干貨，要么就是以高端的專業(yè)術(shù)語(yǔ)來(lái)講述何為微服務(wù)架構(gòu)。就是沒(méi)有一個(gè)做到成熟地將技術(shù)傳播出來(lái)，同時(shí)完美地照顧“初入微服務(wù)領(lǐng)域人員”，從0開(kāi)始，采用通俗易懂的語(yǔ)言去講解微服務(wù)架構(gòu)的系列。

所以，我們邀請(qǐng)青柳云的蘇槐與InfoQ一起共建微服務(wù)架構(gòu)專題“Re：從0開(kāi)始的微服務(wù)架構(gòu)”，為還沒(méi)有入門該領(lǐng)域的技術(shù)人員開(kāi)路，也幫助微服務(wù)架構(gòu)老手溫故知新。

這是專題的第一篇文章，從最基礎(chǔ)的地方入手，讓我們重識(shí)微服務(wù)架構(gòu)。

前言

得益于2013年Docker的誕生，微服務(wù)概念及架構(gòu)的推廣和落地變得更加的可靠和方便。在2016年及之前，微服務(wù)架構(gòu)的討論更多的是活躍于互聯(lián)網(wǎng)企業(yè)及社區(qū)。現(xiàn)如今，隨著Docker和微服務(wù)架構(gòu)組件與Docker等相關(guān)技術(shù)的逐步成熟，微服務(wù)架構(gòu)已然步入傳統(tǒng)企業(yè)及傳統(tǒng)行業(yè)。

但是，程序員作為一個(gè)理性消費(fèi)的群體，需要冷靜地思考，避免挖個(gè)大坑把自己給埋了。所以，我們需要冷靜地搞清楚：微服務(wù)（架構(gòu)）是什么？它有什么優(yōu)勢(shì)劣勢(shì)？我們?yōu)槭裁葱枰捎梦⒎?wù)架構(gòu)？如何讓老板接受這一新技術(shù)？如何落地？如何升級(jí)維護(hù)？等等……

我們?cè)谶^(guò)去7年智慧城市的建設(shè)過(guò)程中，研發(fā)和交付了很多的大型項(xiàng)目，踩過(guò)很多的坑，趟過(guò)很多的雷，深受傳統(tǒng)建設(shè)方法之苦，也深深被微服務(wù)架構(gòu)帶來(lái)的好處所感動(dòng)，我們也將在微服務(wù)架構(gòu)這條路的繼續(xù)前行。在這里，將我們研發(fā)過(guò)程中的一些思考和心得分享給大家，供大家參考。

也許，在不久的將來(lái)，軟件開(kāi)發(fā)只需要組裝，不再需要從頭開(kāi)發(fā)。

(點(diǎn)擊放大圖像)

什么是微服務(wù)架構(gòu)？

形像一點(diǎn)來(lái)說(shuō)，微服務(wù)架構(gòu)就像搭積木，每個(gè)微服務(wù)都是一個(gè)零件，并使用這些零件組裝出不同的形狀。通俗來(lái)說(shuō)，微服務(wù)架構(gòu)就是把一個(gè)大系統(tǒng)按業(yè)務(wù)功能分解成多個(gè)職責(zé)單一的小系統(tǒng)，并利用簡(jiǎn)單的方法使多個(gè)小系統(tǒng)相互協(xié)作，組合成一個(gè)大系統(tǒng)。

如果學(xué)科派一點(diǎn)，微服務(wù)架構(gòu)就是把因相同原因而變化的功能聚合到一起，而把因不同原因而變化的功能分離開(kāi)，并利用輕量化機(jī)制（通常為HTTP RESTful API）實(shí)現(xiàn)通信。

追本溯源，Martin Folwer對(duì)微服務(wù)架構(gòu)的定義是：

(點(diǎn)擊放大圖像)

微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價(jià)值。每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級(jí)的通信機(jī)制互相協(xié)作（通常是基于HTTP協(xié)議的RESTful API）。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，對(duì)具體的服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語(yǔ)言、工具對(duì)其進(jìn)行構(gòu)建 。（摘自王磊先生的《微服務(wù)架構(gòu)與實(shí)踐》）

對(duì)于我個(gè)人，我更喜歡一種延續(xù)性的解釋，微服務(wù)架構(gòu) ≈ 模塊化開(kāi)發(fā) + 分布式計(jì)算。不管微服務(wù)架構(gòu)的定義怎么樣，都是在描述一個(gè)核心思想：把大系統(tǒng)拆分成小型系統(tǒng)，把大事化小，以降低系統(tǒng)的復(fù)雜性，從而大幅降低系統(tǒng)建設(shè)、升級(jí)、運(yùn)維的風(fēng)險(xiǎn)和成本。

順帶提一下，亞馬遜創(chuàng)始人Jeff Bezos在2002年就說(shuō)過(guò)：所有團(tuán)隊(duì)的模塊都要以Service Interface的方式將數(shù)據(jù)和功能開(kāi)放出來(lái)。不這樣做的人會(huì)被炒魷魚。這才是思路超前的大牛。

(點(diǎn)擊放大圖像)

需要注意的是“微服務(wù)”與“微服務(wù)架構(gòu)”是有本質(zhì)區(qū)別的。“微服務(wù)”強(qiáng)調(diào)的是服務(wù)的大小，它關(guān)注的是某一個(gè)點(diǎn)。而“微服務(wù)架構(gòu)”則是一種架構(gòu)思想，需要從整體上對(duì)軟件系統(tǒng)進(jìn)行通盤的考慮。

Chris Richardson說(shuō)：“微服務(wù)”是一個(gè)很糟糕的名字，它導(dǎo)致開(kāi)發(fā)人員創(chuàng)建了許多粒度很小的服務(wù)，每個(gè)服務(wù)擁有一個(gè)單獨(dú)的REST端點(diǎn)。不僅如此，這個(gè)名字還暗示了微服務(wù)在開(kāi)發(fā)者心目中的重要位置。例如，人們會(huì)說(shuō)“我們可以用微服務(wù)來(lái)解決這個(gè)問(wèn)題”；我也看到了越來(lái)越多的“某某微服務(wù)框架”，而實(shí)際上，這些框架跟微服務(wù)架構(gòu)不一定有太多聯(lián)系，它們只是簡(jiǎn)單的Web框架。使用“微服務(wù)架構(gòu)”這個(gè)名字會(huì)更恰當(dāng)些。它是一種架構(gòu)風(fēng)格，它把一系列協(xié)作的服務(wù)組織成一個(gè)系統(tǒng)來(lái)支撐業(yè)務(wù)。

常見(jiàn)的微服務(wù)組件及概念

服務(wù)注冊(cè)，服務(wù)提供方將自己調(diào)用地址注冊(cè)到服務(wù)注冊(cè)中心，讓服務(wù)調(diào)用方能夠方便地找到自己。

服務(wù)發(fā)現(xiàn)，服務(wù)調(diào)用方從服務(wù)注冊(cè)中心找到自己需要調(diào)用的服務(wù)的地址。

負(fù)載均衡，服務(wù)提供方一般以多實(shí)例的形式提供服務(wù)，負(fù)載均衡功能能夠讓服務(wù)調(diào)用方連接到合適的服務(wù)節(jié)點(diǎn)。并且，節(jié)點(diǎn)選擇的工作對(duì)服務(wù)調(diào)用方來(lái)說(shuō)是透明的。

服務(wù)網(wǎng)關(guān)，服務(wù)網(wǎng)關(guān)是服務(wù)調(diào)用的唯一入口，可以在這個(gè)組件是實(shí)現(xiàn)用戶鑒權(quán)、動(dòng)態(tài)路由、灰度發(fā)布、A/B測(cè)試、負(fù)載限流等功能。

配置中心，將本地化的配置信息（properties, xml, yaml等）注冊(cè)到配置中心，實(shí)現(xiàn)程序包在開(kāi)發(fā)、測(cè)試、生產(chǎn)環(huán)境的無(wú)差別性，方便程序包的遷移。

API管理，以方便的形式編寫及更新API文檔，并以方便的形式供調(diào)用者查看和測(cè)試。

集成框架，微服務(wù)組件都以職責(zé)單一的程序包對(duì)外提供服務(wù)，集成框架以配置的形式將所有微服務(wù)組件（特別是管理端組件）集成到統(tǒng)一的界面框架下，讓用戶能夠在統(tǒng)一的界面中使用系統(tǒng)。

分布式事務(wù)，對(duì)于重要的業(yè)務(wù)，需要通過(guò)分布式事務(wù)技術(shù)（TCC、高可用消息服務(wù)、最大努力通知）保證數(shù)據(jù)的一致性。

調(diào)用鏈，記錄完成一個(gè)業(yè)務(wù)邏輯時(shí)調(diào)用到的微服務(wù)，并將這種串行或并行的調(diào)用關(guān)系展示出來(lái)。在系統(tǒng)出錯(cuò)時(shí)，可以方便地找到出錯(cuò)點(diǎn)。

支撐平臺(tái)，系統(tǒng)微服務(wù)化后，系統(tǒng)變得更加碎片化，系統(tǒng)的部署、運(yùn)維、監(jiān)控等都比單體架構(gòu)更加復(fù)雜，那么，就需要將大部分的工作自動(dòng)化。現(xiàn)在，可以通過(guò)Docker等工具來(lái)中和這些微服務(wù)架構(gòu)帶來(lái)的弊端。 例如持續(xù)集成、藍(lán)綠發(fā)布、健康檢查、性能健康等等。嚴(yán)重點(diǎn)，以我們兩年的實(shí)踐經(jīng)驗(yàn)，可以這么說(shuō)，如果沒(méi)有合適的支撐平臺(tái)或工具，就不要使用微服務(wù)架構(gòu)。

一般情況下，如果希望快速地體會(huì)微服務(wù)架構(gòu)帶來(lái)的好處，使用Spring Cloud提供的服務(wù)注冊(cè)（Eureka）、服務(wù)發(fā)現(xiàn)（Ribbon）、服務(wù)網(wǎng)關(guān)（Zuul）三個(gè)組件即可以快速入門。其它組件則需要根據(jù)自身的業(yè)務(wù)選擇性使用。

微服務(wù)架構(gòu)有哪些優(yōu)勢(shì)劣勢(shì)？

要談優(yōu)勢(shì)，就一定要有對(duì)比，我們可以嘗試著從兩個(gè)維度來(lái)對(duì)比。

一、微服務(wù)架構(gòu)與單體架構(gòu)的對(duì)比

S/N	對(duì)比點(diǎn)	微服務(wù)架構(gòu)	單體架構(gòu)	結(jié)論
1	上手難度	API接口調(diào)用	數(shù)據(jù)庫(kù)共享或本地程序調(diào)用	單體架構(gòu)勝
2.1	開(kāi)發(fā)效率（簡(jiǎn)單項(xiàng)目）	早期設(shè)計(jì)和溝通的工作量加大，隨著項(xiàng)目規(guī)模和時(shí)間的推移，效率變化不大	早期工作量小，隨著項(xiàng)目規(guī)模和時(shí)間的推移，效率大幅度下降	單體架構(gòu)勝
2.2	開(kāi)發(fā)效率（復(fù)雜項(xiàng)目）	早期設(shè)計(jì)和溝通的工作量加大，隨著項(xiàng)目規(guī)模和時(shí)間的推移，效率變化不大	早期工作量小，隨著項(xiàng)目規(guī)模和時(shí)間的推移，效率大幅度下降	微服務(wù)架構(gòu)勝
3	系統(tǒng)設(shè)計(jì)（高內(nèi)聚低耦合）	每個(gè)業(yè)務(wù)單獨(dú)包裝成一個(gè)微服務(wù)，數(shù)據(jù)和代碼都從物理上隔離開(kāi)來(lái)，實(shí)現(xiàn)高內(nèi)聚低耦合相對(duì)容易	以包的形式對(duì)代碼進(jìn)行模塊劃分，控制得當(dāng)即可實(shí)現(xiàn)高內(nèi)聚。但最終都是在數(shù)據(jù)層面將整個(gè)系統(tǒng)耦合在一起	微服務(wù)架構(gòu)勝
4	系統(tǒng)設(shè)計(jì)（擴(kuò)展性）	獨(dú)立開(kāi)發(fā)新模塊，通過(guò)API與現(xiàn)有模塊交互	在現(xiàn)有系統(tǒng)上修改，與現(xiàn)存業(yè)務(wù)邏輯高度耦合	微服務(wù)架構(gòu)勝
5	需求變更響應(yīng)速度	各個(gè)微服務(wù)組件獨(dú)立變更，容易實(shí)施敏捷開(kāi)發(fā)方法	需要了解整個(gè)系統(tǒng)才可以正確修改，容易導(dǎo)致不相關(guān)模塊的意外失敗	微服務(wù)架構(gòu)勝
6	系統(tǒng)升級(jí)效率	各個(gè)微服務(wù)組件獨(dú)立升級(jí)，上手和開(kāi)發(fā)效率高，影響面小	需要了解整個(gè)系統(tǒng)才可以正確修改，容易導(dǎo)致不相關(guān)模塊的意外失敗	微服務(wù)架構(gòu)勝
7	運(yùn)維效率	大系統(tǒng)被拆分為多個(gè)小系統(tǒng)，部署和運(yùn)維難度加大，但可以利用DevOps等方式將運(yùn)維工作自動(dòng)化	簡(jiǎn)單直接	單體架構(gòu)勝
8	知識(shí)積累	微服務(wù)組件可以在新項(xiàng)目中直接復(fù)用，包括前端頁(yè)面	一般以共享庫(kù)的形式復(fù)用后臺(tái)代碼	微服務(wù)架構(gòu)勝
9.1	硬件需求（簡(jiǎn)單項(xiàng)目）	一個(gè)系統(tǒng)需部署多個(gè)微服務(wù)，需要啟動(dòng)多個(gè)運(yùn)行容器	整個(gè)系統(tǒng)只需要一個(gè)運(yùn)行容器	單體架構(gòu)勝
9.2	硬件需求（高要求項(xiàng)目）	按需為不同業(yè)務(wù)模塊伸縮資源節(jié)點(diǎn)	為整個(gè)系統(tǒng)分配資源，導(dǎo)致冗余	微服務(wù)架構(gòu)勝
10.1	項(xiàng)目成本（簡(jiǎn)單系統(tǒng)）	項(xiàng)目早期和后期，成本變化曲線平緩	項(xiàng)目早期成本低，后期成本大	單體架構(gòu)勝
10.2	項(xiàng)目成本（復(fù)雜系統(tǒng)）	項(xiàng)目早期和后期，成本變化曲線平緩	項(xiàng)目早期成本低，后期成本大	微服務(wù)架構(gòu)勝
11	非功能需求	為單獨(dú)的微服務(wù)按需調(diào)優(yōu)，甚至更換實(shí)現(xiàn)方式和程序語(yǔ)言	為整個(gè)系統(tǒng)調(diào)優(yōu)，牽一發(fā)而動(dòng)全身	微服務(wù)架構(gòu)勝
12	職責(zé)、成就感	擁有明確的職責(zé)劃分，主人翁意識(shí)和成就感加強(qiáng)，容易形成自組織型團(tuán)隊(duì)	職責(zé)不明確，容易產(chǎn)生扯皮行為	微服務(wù)架構(gòu)勝
13	風(fēng)險(xiǎn)	大系統(tǒng)被拆分為小系統(tǒng)，風(fēng)險(xiǎn)可被控制在小系統(tǒng)內(nèi)，但也引入了各小系統(tǒng)之間的交互風(fēng)險(xiǎn)	系統(tǒng)是一個(gè)整體，一榮俱榮，一損俱損	微服務(wù)架構(gòu)勝

結(jié)論:

對(duì)于簡(jiǎn)單項(xiàng)目來(lái)說(shuō)，單體架構(gòu)5勝8敗。（優(yōu)勢(shì)項(xiàng)：開(kāi)發(fā)效率、上手難度、運(yùn)維效率、硬件需求、項(xiàng)目成本；劣勢(shì)項(xiàng)：系統(tǒng)設(shè)計(jì)（高內(nèi)聚低耦合）、系統(tǒng)設(shè)計(jì)（擴(kuò)展性）、需求變更響應(yīng)速度、系統(tǒng)升級(jí)效率、知識(shí)積累、非功能需求、職責(zé)、成就感、風(fēng)險(xiǎn)）

對(duì)于復(fù)雜項(xiàng)目來(lái)說(shuō)，單體架構(gòu)2勝11敗。（優(yōu)勢(shì)項(xiàng)：上手難度、運(yùn)維效率；劣勢(shì)項(xiàng)：硬件需求、項(xiàng)目成本、開(kāi)發(fā)效率、系統(tǒng)設(shè)計(jì)（高內(nèi)聚低耦合）、系統(tǒng)設(shè)計(jì)（擴(kuò)展性）、需求變更響應(yīng)速度、系統(tǒng)升級(jí)效率、知識(shí)積累、非功能需求、職責(zé)、成就感、風(fēng)險(xiǎn)；）

二、微服務(wù)與共享庫(kù)的對(duì)比

注：這里以使用方自行安裝微服務(wù)為場(chǎng)景來(lái)比較。這里的共享庫(kù)指的是像Java中的公共jar依賴。

S/N	對(duì)比點(diǎn)	微服務(wù)	共享庫(kù)	結(jié)論
1	易用性	整體安裝 + API調(diào)用	共享庫(kù)引用 + 本地調(diào)用	平手
2	程序耦合度	微服務(wù)為完整的業(yè)務(wù)邏輯單元，通過(guò)API的形式為其它模塊提供服務(wù)	在使用方的源代碼中引用共享庫(kù)的類和方法	平手
3	版本升級(jí)	單獨(dú)升級(jí)，其它模塊無(wú)感知	修改源代碼，升級(jí)使用方的代碼版本，例如pom.xml, build.gradle	微服務(wù)架構(gòu)勝
4	Bug修復(fù)	單獨(dú)升級(jí)，自動(dòng)生效	修改源代碼，升級(jí)使用方的代碼版本，例如pom.xml, build.gradle	微服務(wù)架構(gòu)勝
5	非功能需求	為單獨(dú)的微服務(wù)優(yōu)化或擴(kuò)縮容；在需求更高的情況下，可以重新設(shè)計(jì)或使用不同的程序語(yǔ)言	為整個(gè)業(yè)務(wù)系統(tǒng)優(yōu)化或擴(kuò)縮容，共享庫(kù)的程序語(yǔ)言必須和業(yè)務(wù)系統(tǒng)的程序語(yǔ)言相同	微服務(wù)架構(gòu)勝
6	復(fù)用程度	可以復(fù)用從前端頁(yè)面到后臺(tái)數(shù)據(jù)庫(kù)的整個(gè)業(yè)務(wù)邏輯和代碼	可以復(fù)用后臺(tái)代碼和數(shù)據(jù)庫(kù)，但程序語(yǔ)言需要和業(yè)務(wù)系統(tǒng)保持一致	微服務(wù)架構(gòu)勝

什么場(chǎng)景需要用微服務(wù)架構(gòu)？

看了上面的比較，微服務(wù)架構(gòu)可以說(shuō)是以壓倒性的優(yōu)勢(shì)勝過(guò)單體架構(gòu)和共享庫(kù)，會(huì)讓人產(chǎn)生一種錯(cuò)覺(jué)，微服務(wù)架構(gòu)就是軟件開(kāi)發(fā)中的銀彈。

但是，正如大家所了解的，軟件研發(fā)是一個(gè)系統(tǒng)工程，它沒(méi)有銀彈，不能夠一招鮮吃遍天。正如當(dāng)年的CMMI和敏捷方法一樣，敏捷雖好，但它不一定能適用于所有的場(chǎng)景，它對(duì)組織環(huán)境、團(tuán)隊(duì)氛圍、溝通方式、技術(shù)能力這些都是有一些要求的，如果用不好，反而會(huì)帶來(lái)一些負(fù)面影響。

那么，我們什么時(shí)候需要采用微服務(wù)呢？從我個(gè)人的經(jīng)驗(yàn)來(lái)看，我認(rèn)為有三種場(chǎng)景可以考慮使用微服務(wù)。

規(guī)模大（團(tuán)隊(duì)超過(guò)10人）

業(yè)務(wù)復(fù)雜度高（系統(tǒng)超過(guò)5個(gè)子模塊）

需要長(zhǎng)期演進(jìn)（項(xiàng)目開(kāi)發(fā)和維護(hù)周期超過(guò)半年）

這里借一張圖來(lái)說(shuō)明:

(點(diǎn)擊放大圖像)

橫軸是復(fù)雜度，縱軸是生產(chǎn)效率。從生產(chǎn)效率的角度來(lái)講，在兩條曲線的交叉點(diǎn)之前，單體架構(gòu)是占優(yōu)勢(shì)的，過(guò)了交叉點(diǎn)之后，單體架構(gòu)的生產(chǎn)效率將大幅度下降。

所以很多專家和同行朋友都說(shuō)，我們可以在開(kāi)始的時(shí)候先使用單體架構(gòu)，當(dāng)業(yè)務(wù)發(fā)展到一定程度的時(shí)候，再重構(gòu)成微服務(wù)架構(gòu)。對(duì)于這一點(diǎn)，我是持保留意見(jiàn)的，因?yàn)樵趯?shí)踐中，架構(gòu)改造的難度還是很大的，會(huì)有一些問(wèn)題，例如:

• 客戶或業(yè)務(wù)部門是否給我們這樣的時(shí)間窗口？
• 這段時(shí)間的研發(fā)經(jīng)費(fèi)是否有出處？
• 項(xiàng)目負(fù)責(zé)人或技術(shù)團(tuán)隊(duì)是否有主動(dòng)的意愿進(jìn)行架構(gòu)升級(jí)？
• 項(xiàng)目負(fù)責(zé)人或技術(shù)團(tuán)隊(duì)是否愿意為架構(gòu)升級(jí)帶來(lái)的不穩(wěn)定風(fēng)險(xiǎn)負(fù)責(zé)？

我們常常聽(tīng)到的一句話是：暫時(shí)先這樣，等我們沒(méi)這么忙的時(shí)候，再來(lái)優(yōu)化一下。但是，絕大多數(shù)情況下，這一天從來(lái)沒(méi)有出現(xiàn)過(guò)。

再想想年初，我們的私有云平臺(tái)經(jīng)過(guò)2年多的發(fā)展，已經(jīng)包含了容器服務(wù)平臺(tái)（PaaS）、API網(wǎng)關(guān)、監(jiān)控平臺(tái)、定時(shí)任務(wù)平臺(tái)、數(shù)據(jù)庫(kù)管理、用戶權(quán)限管理等等十多個(gè)基礎(chǔ)模塊，也包含了一些為上層應(yīng)用服務(wù)提供的日志服務(wù)、緩存服務(wù)、消息服務(wù)等等。并且，部署到了二十多個(gè)客戶的生產(chǎn)環(huán)境里。可悲的是，我們支撐了很多的業(yè)務(wù)系統(tǒng)的微服務(wù)化，但平臺(tái)本身任然是一個(gè)單體系統(tǒng)。

我們也深深地感受到了平臺(tái)往前發(fā)展的阻力：

• 很多時(shí)候，客戶需要的不是一個(gè)大而全的平臺(tái)，他們希望按他們的意愿采購(gòu)需要的模塊。
• 新人進(jìn)入團(tuán)隊(duì)后，從熟悉到動(dòng)手產(chǎn)出的時(shí)間偏長(zhǎng)。
• 其它研發(fā)團(tuán)隊(duì)有一些比較好的組件能滿足平臺(tái)產(chǎn)品的需求，卻不能直接拿來(lái)用。
• 兩個(gè)不同的模塊之間產(chǎn)生了不該出現(xiàn)的耦合關(guān)系，導(dǎo)致意想不到的Bug。

所以，春節(jié)過(guò)后，大家開(kāi)了一個(gè)會(huì)，決定將平臺(tái)微服務(wù)化。而帶來(lái)的代價(jià)就是要說(shuō)服老板給我們兩個(gè)月時(shí)間來(lái)重構(gòu)。

幸運(yùn)的是，我們很快得到了老板的支持，并且重構(gòu)工作比較順利；不幸的是，那二十多個(gè)客戶的生產(chǎn)環(huán)境的升級(jí)非常麻煩，每升級(jí)一個(gè)客戶都得花上一周左右的時(shí)間，至今也才升級(jí)了一小部分。

所以，理想的情況下，我建議在項(xiàng)目初期的時(shí)候就從上面提到的三點(diǎn)做好評(píng)估，到底采用哪種架構(gòu)形式是符合項(xiàng)目具體情況的。

當(dāng)然，如果真的有朋友想將歷史悠久的單體架構(gòu)升級(jí)到微服務(wù)架構(gòu)，我建議先從邊緣邏輯開(kāi)始，逐步逐步地將業(yè)務(wù)邏輯從單體系統(tǒng)里剝離出來(lái)。我沒(méi)有這方面的經(jīng)驗(yàn)，但可以想象，這將是一個(gè)非常長(zhǎng)期和痛苦的過(guò)程。

下篇文章

下篇文章分享一下微服務(wù)架構(gòu)的簡(jiǎn)單模式。

(點(diǎn)擊放大圖像)

?

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/p/7426626.html

總結(jié)

以上是生活随笔為你收集整理的Re：从0开始的微服务架构：（一）重识微服务架构--转的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。