這些年互聯(lián)網(wǎng)的快速發(fā)展，分布式，微服務(wù)的概念風(fēng)靡整個行業(yè)。在企業(yè)中IT的架構(gòu)，從過去的單體應(yīng)用架構(gòu)發(fā)展到現(xiàn)在廣為人知的微服務(wù)架構(gòu)。不說別的，現(xiàn)在出去面試都不好意思說自己不知道微服務(wù)。微服務(wù)是一種架構(gòu)風(fēng)格，將我們的業(yè)務(wù)拆分若干個服務(wù)，為我們的開發(fā)帶來了極大的便利。過去，架構(gòu)是從單體應(yīng)用架構(gòu)-->分布式架構(gòu)-->微服務(wù)發(fā)展。

單體應(yīng)用架構(gòu)

這種架構(gòu)在老的Java web項目中還存在，就是一套代碼擼到底。就是項目中從controller到service再到dao層，不進(jìn)行任何的拆分，所有的代碼都堆積在一個項目中。這樣打出來的war巨大無比，啟動都要費好多時間。比如下面的例子：

這樣就把供應(yīng)鏈所有的的功能業(yè)務(wù)代碼放在項目中，可想而知，代碼量有多大。不過這種架構(gòu)方式既有缺點又有優(yōu)點優(yōu)點：

• 簡單方便，易于開發(fā)。所有人員都在一個項目上做開發(fā)，沒有接口的遠(yuǎn)程調(diào)用，很方便。
• 相對容易測試以及部署運維。打包成測試包之后，部署到測試環(huán)境即可從頭到尾進(jìn)行測試。而且不受網(wǎng)絡(luò)影響
• 缺點：
• 代碼不易管理。沒有進(jìn)行拆分，也就是所有的開發(fā)人員都在一個項目上提交代碼，就會出現(xiàn)我們非常惡心的代碼沖突~
• 代碼耦合度高?？赡軆H僅修改一小個代碼，就會導(dǎo)致整個系統(tǒng)出現(xiàn)問題，不敢下手隨意修改代碼啊，淚奔~
• 系統(tǒng)擴展性差。要增加或者上線某個小功能的時候，整個應(yīng)用都得停下來部署，用戶體驗太差了~
• 系統(tǒng)啟動慢。毫無疑問，模塊太多了也是一種累贅。
• 因此這種架構(gòu)慢慢被淘汰，衍生出分布式架構(gòu)

分布式應(yīng)用架構(gòu)

分布式架構(gòu)從業(yè)務(wù)的不同進(jìn)行拆分，將我們的單體應(yīng)用拆分多個業(yè)務(wù)服務(wù)系統(tǒng)，每個服務(wù)系統(tǒng)就是一個單體應(yīng)用，他們之間通過商定好的api進(jìn)行調(diào)用。例如將上面的例子拆分，將龐大的供應(yīng)鏈系統(tǒng)拆分成采供管理系統(tǒng)，資產(chǎn)管理系統(tǒng)，倉儲管理系統(tǒng)：

這種拆分，大大降低了代碼的耦合度，提高了服務(wù)的可用性。從原來一個大項目重新分配任務(wù)小組，每個小組負(fù)責(zé)自己的業(yè)務(wù)項目，業(yè)務(wù)服務(wù)之間通過api調(diào)用，每個服務(wù)模塊運行在不同的主機上。當(dāng)然這種分布式架構(gòu)一下子表現(xiàn)出的優(yōu)點也表現(xiàn)出缺點。優(yōu)點：

• 降低了業(yè)務(wù)模塊之間耦合度。將模塊拆分之后，通過接口進(jìn)行調(diào)用，其他業(yè)務(wù)代碼不受影響。
• 項目細(xì)分化，不同的項目組負(fù)責(zé)不同的任務(wù)。
• 系統(tǒng)擴展性高，靈活。增加或者改造某個功能時，不需要牽一發(fā)而動全身影響到別的模塊。不會存在因為其他服務(wù)不存在而造成我自己的服務(wù)不能啟動或者不可用的問題。
• 缺點：
• 受網(wǎng)絡(luò)影響。系統(tǒng)之間經(jīng)過api遠(yuǎn)程調(diào)用，不僅增加了接口開發(fā)工作量，而且受網(wǎng)絡(luò)限制。
• 數(shù)據(jù)的一致性問題。
• 增加了運維工作量。
• 這種分布式架構(gòu)按照角色來劃分，分為：生產(chǎn)者（服務(wù)提供方），消費者（服務(wù)調(diào)用方）。
• 應(yīng)用場景：項目中使用kafka就是一個分布式系統(tǒng)。

微服務(wù)應(yīng)用架構(gòu)

其實90%的微服務(wù)架構(gòu)就是分布式架構(gòu)一種延申。微服務(wù)的概念最早源于Martin Fowler發(fā)表的一篇《Microsevices》。這種微服務(wù)按照業(yè)務(wù)的功能繼續(xù)拆分成相互獨立的微服務(wù)，各個微服務(wù)之間是松耦合的，也是通過遠(yuǎn)程協(xié)議進(jìn)行調(diào)用。例如我們將采供管理再一次拆分，將采供管理系統(tǒng)拆分成需求管理，采購管理，入庫管理：

這種拆分方式將分布式應(yīng)用架構(gòu)更加細(xì)分化。各個微服務(wù)之間通過各種遠(yuǎn)程協(xié)議進(jìn)行同步/異步調(diào)用，各個微服務(wù)之間也是獨立部署。當(dāng)然這種服務(wù)架構(gòu)也同樣。除了具備分布式架構(gòu)的缺點外，還有：

• 通信，http請求速度慢，通常一個操作可能會涉及到多個微服務(wù)的相互調(diào)用，如果為了完成一個操作而多次從服務(wù)端調(diào)用不同的微服務(wù)，http請求的耗時可能會成為瓶頸。
• 增加復(fù)雜性以及加大 了技術(shù)支持。在微服務(wù)中不僅僅服務(wù)之間的調(diào)用這么簡單，還需要許多技術(shù)支撐，比如服務(wù)注冊中心，熔斷器，鏈路跟中，分布式配置中心，分布式事務(wù)等等技術(shù)上的支持，加大了開發(fā)人員的額外任務(wù)量。
• 服務(wù)眾多，其測試，部署，監(jiān)控變得更加復(fù)雜。
• 下面這張是從網(wǎng)上拷貝下來的微服務(wù)架構(gòu)圖，可以看出來需要好多技術(shù)來支持構(gòu)成完整的微服務(wù)架構(gòu)：

• 當(dāng)然這種帶來的弊端遠(yuǎn)遠(yuǎn)小于帶來的好處。

微服務(wù)技術(shù)方案的選型

市面上支持微服務(wù)的技術(shù)棧是多種多樣的，但是按照現(xiàn)在比較流行的，無非就是springcloud以及dubbo方案。springcloud是spring社區(qū)下的項目，提供了完整的落地方案，包括服務(wù)發(fā)現(xiàn)，網(wǎng)關(guān)，配置中心，鏈路跟蹤等。而dubbo是阿里巴巴基于java分布式服務(wù)治理框架，但是它沒有提供完整的解決方案，而是專注于RPC領(lǐng)域。兩者技術(shù)選型對比：

當(dāng)然了，我們在實際中不能光是微服務(wù)而微服務(wù)，要根據(jù)具體場景來選型。選擇適合自己業(yè)務(wù)的架構(gòu)，才是最好的架構(gòu)。

以上是我本人對應(yīng)用架構(gòu)的理解，如果有不對之處，證明本人學(xué)業(yè)不精，還望各位理解諒解。

本人水平有限，難免有錯誤或遺漏之處，望大家指正和諒解，提出寶貴意見，愿與之交流。