什么是微服務(wù)？

微服務(wù)沒有一個(gè)標(biāo)準(zhǔn)統(tǒng)一的概念，個(gè)人理解為：微服務(wù)是一種可以讓軟件職責(zé)單一、松耦合、自包含、可以獨(dú)立運(yùn)行和部署的架構(gòu)思想。
關(guān)鍵思想就是：拆分、單一、獨(dú)立、組件化。把原本一個(gè)龐大、復(fù)雜的項(xiàng)目按業(yè)務(wù)邊界拆分一個(gè)一個(gè)獨(dú)立運(yùn)行的小項(xiàng)目，通過接口的方式組裝成一個(gè)大的項(xiàng)目。

微服務(wù)解決了什么問題？

微服務(wù)的出現(xiàn)及流行，一定有它的過人之處，既解決了非微服務(wù)項(xiàng)目的部分問題或缺點(diǎn)。

相對(duì)于微服務(wù)，普通的項(xiàng)目都會(huì)包含很多功能的，是一個(gè)大而全的“超級(jí)”工程。比如：以普通架構(gòu)方式實(shí)現(xiàn)的電商平臺(tái)會(huì)是一個(gè)包含：登錄、權(quán)限、會(huì)員、商品庫存、訂單、收藏、關(guān)注、購物車等功能的單一項(xiàng)目。隨著項(xiàng)目業(yè)務(wù)越來越復(fù)雜、開發(fā)人員越來越多相應(yīng)開發(fā)、編譯、部署、技術(shù)擴(kuò)展、水平擴(kuò)展都會(huì)受到限制。

開發(fā)

太多功能在一個(gè)項(xiàng)目中，可能會(huì)讓代碼復(fù)雜、結(jié)構(gòu)混亂、業(yè)務(wù)關(guān)聯(lián)混亂、技術(shù)單一。過多的功能，讓整個(gè)項(xiàng)目結(jié)構(gòu)復(fù)雜，業(yè)務(wù)相互交織，可能導(dǎo)致開發(fā)人員對(duì)業(yè)務(wù)的理解和代碼實(shí)現(xiàn)相互交織，最后沒人能完全理解整個(gè)項(xiàng)目。而且也很難控制每個(gè)開發(fā)人員能“合法合規(guī)”的編碼，可能會(huì)把兩個(gè)本來松耦合、互不影響的功能因?yàn)閷?shí)現(xiàn)“簡單”就偷懶強(qiáng)關(guān)聯(lián)在一起。

技術(shù)單一

單一的項(xiàng)目為了技術(shù)的統(tǒng)一和管理的簡單方便，一般都會(huì)采用統(tǒng)一的技術(shù)實(shí)現(xiàn)。但是超大型業(yè)務(wù)如電商平臺(tái)，不可能只采用一種技術(shù)（如：java），可能會(huì)結(jié)合業(yè)務(wù)及不同技術(shù)優(yōu)缺點(diǎn)和技術(shù)團(tuán)隊(duì)優(yōu)執(zhí)采用不同的技術(shù)。如果把項(xiàng)目拆分成不同的小項(xiàng)目，每個(gè)小項(xiàng)目可以根據(jù)自己的特點(diǎn)采用不同技術(shù)，只需要提供統(tǒng)一的接口實(shí)現(xiàn)對(duì)接即可，最大化技術(shù)的優(yōu)勢。

編譯

過于龐大的代碼也會(huì)導(dǎo)致整個(gè)項(xiàng)目編譯時(shí)間過長，一次簡單的修改或一個(gè)簡單的單元測試需要漫長的編譯和啟動(dòng)。

版本控制

過多的開發(fā)人員在同一個(gè)項(xiàng)目中共同開發(fā)不同業(yè)務(wù)模塊，也會(huì)大大增加版本沖突。

部署

一個(gè)簡單的修改需要部署整個(gè)項(xiàng)目。當(dāng)多個(gè)功能同時(shí)上線，但僅僅因?yàn)橐粋€(gè)小功能失敗，就會(huì)導(dǎo)致其它所有功能一起回滾。

擴(kuò)展

互聯(lián)網(wǎng)的飛速發(fā)展，用戶和請求量急劇增加，傳統(tǒng)的項(xiàng)目很難擴(kuò)展（水平、垂直），即集群和分布式擴(kuò)展的問題。

微服務(wù)如何解決上面問題？

以上就是單個(gè)（單體）大項(xiàng)目的問題，微服務(wù)就是要解決上面的問題。

核心思路很簡單，就是拆分，即然是單體項(xiàng)目的問題，那么直接把項(xiàng)目拆分成一個(gè)個(gè)小項(xiàng)目是不是就可以完美解決。

微服務(wù)有哪些缺點(diǎn)？

然而，這并不是銀彈，也不是最完美的解決方案。微服務(wù)有自己的優(yōu)點(diǎn)，也帶來了相應(yīng)的劣勢。具體如下：

如何拆分：微服務(wù)的核心就是拆分項(xiàng)目，把整個(gè)項(xiàng)目模塊化、組件化；職責(zé)更單一，精中力量做好一件事。但是如何拆分才是合理的？通常的作法是，按業(yè)務(wù)拆分，功能從業(yè)務(wù)上分類，非常耦合的分在同一個(gè)微服務(wù)中；反之，耦合性非常低的則放到不同的微服務(wù)。

事務(wù)：原本在同一個(gè)項(xiàng)目中的兩個(gè)操作，如果拆分到不同的項(xiàng)目中，那么就可能會(huì)遇到分布式事務(wù)的問題。這是一個(gè)棘手但沒有完美解決方案的問題?；驹瓌t是，需要在同一事務(wù)中實(shí)現(xiàn)的兩個(gè)操作屬于強(qiáng)耦合業(yè)務(wù)，最好拆分到同一個(gè)微服務(wù)。如果確實(shí)是兩個(gè)微服務(wù)（如：減庫存、扣款）則通過其它方式（如：消息隊(duì)列、分布式事務(wù)鎖、重試機(jī)制、對(duì)賬）來解決

spring cloud

微服務(wù)是一個(gè)架構(gòu)思想，并不是一種實(shí)現(xiàn)，它指明了解決單體應(yīng)該缺點(diǎn)的方向，但并沒有給定相應(yīng)的實(shí)現(xiàn)和解決方案以及細(xì)節(jié)。

spring cloud是spring提供的，基于spring boot以及結(jié)合Netflix 相關(guān)思想和代碼對(duì)微服務(wù)理念的java實(shí)現(xiàn)。spring cloud本質(zhì)上是分布式解決方案，但微服務(wù)最終也落實(shí)到分布式，因此也是對(duì)微服務(wù)的實(shí)現(xiàn)方案。

Spring Cloud 為開發(fā)人員提供了一些可以用于快速構(gòu)建分布式系統(tǒng)通用模式的工具（例如：配置管理、服務(wù)注冊與發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線）。分布式系統(tǒng)的協(xié)調(diào)趨于一些模版模式， 并且，使用Spring Cloud使開發(fā)人員可以快速創(chuàng)建實(shí)現(xiàn)了這些模式的服務(wù)和應(yīng)用。 他們可以在任何的分布式環(huán)境中良好運(yùn)行，這些環(huán)境包括開發(fā)人員自己的筆記本、裸機(jī)上的數(shù)據(jù)中心、像Cloud Foundry這樣的托管平臺(tái)（云平臺(tái)）。

spring cloud主要提供了分布系統(tǒng)中以下幾個(gè)開箱即用的功能：

分布式/版本化/集中化配置 - spring cloud config 服務(wù)注冊發(fā)現(xiàn) - Netflix Eureka 路由 - Netflix Zuul 服務(wù)之間的點(diǎn)對(duì)點(diǎn)調(diào)用（Service-to-service calls）負(fù)載均衡-Netflix Ribbon 斷路器 - Netflix Hystrix 分布式消息

五大核心組件：

服務(wù)注冊發(fā)現(xiàn) - Netflix Eureka

配置中心 - spring cloud config

負(fù)載均衡-Netflix Ribbon

斷路器 - Netflix Hystrix

路由(網(wǎng)關(guān)) - Netflix Zuul
電子商務(wù)社交平臺(tái)源碼請加企鵝求求：三五三六二四七二五九