前言

?

首先，最想說(shuō)的是，當(dāng)你要學(xué)習(xí)一套最新的技術(shù)時(shí)，官網(wǎng)的英文文檔是學(xué)習(xí)的最佳渠道。因?yàn)榫W(wǎng)上流傳的多數(shù)資料是官網(wǎng)翻譯而來(lái)，很多描述的重點(diǎn)也都偏向于作者自身碰到的問(wèn)題，這樣就很容易讓你理解和操作出現(xiàn)偏差，最開(kāi)始我就進(jìn)入了這樣誤區(qū)。官網(wǎng)的技術(shù)導(dǎo)讀真的描述的很詳細(xì)，雖然對(duì)于我們看英文很費(fèi)勁，但如果英文不是很差，請(qǐng)選擇沉下心去讀，你一定能收獲好多。

我的學(xué)習(xí)是先從Spring boot開(kāi)始的，然后接觸到微服務(wù)架構(gòu)，當(dāng)然，這一切最大的啟迪還是感謝我的一個(gè)老師，是他給我指明了新的道路，讓我眼前一亮，再次感謝。

Spring 頂級(jí)框架

?

談及微服務(wù)，作為當(dāng)前主流的企業(yè)框架Spring，它提供了一整套相關(guān)的頂級(jí)項(xiàng)目，能讓開(kāi)發(fā)者快速的上手實(shí)現(xiàn)自己的應(yīng)用，今天就介紹下Spring旗下各個(gè)頂級(jí)項(xiàng)目：

Spring IO platform:用于系統(tǒng)部署，是可集成的，構(gòu)建現(xiàn)代化應(yīng)用的版本平臺(tái)，具體來(lái)說(shuō)當(dāng)你使用maven dependency引入spring jar包時(shí)它就在工作了。

Spring Boot:旨在簡(jiǎn)化創(chuàng)建產(chǎn)品級(jí)的 Spring 應(yīng)用和服務(wù)，簡(jiǎn)化了配置文件，使用嵌入式web服務(wù)器，含有諸多開(kāi)箱即用微服務(wù)功能，可以和spring cloud聯(lián)合部署。

Spring Framework:即通常所說(shuō)的spring 框架，是一個(gè)開(kāi)源的Java/Java EE全功能棧應(yīng)用程序框架，其它spring項(xiàng)目如spring boot也依賴(lài)于此框架。

Spring Cloud：微服務(wù)工具包，為開(kāi)發(fā)者提供了在分布式系統(tǒng)的配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線(xiàn)等開(kāi)發(fā)工具包。

Spring XD：是一種運(yùn)行時(shí)環(huán)境（服務(wù)器軟件，非開(kāi)發(fā)框架），組合spring技術(shù)，如spring batch、spring boot、spring >

Spring Data：是一個(gè)數(shù)據(jù)訪(fǎng)問(wèn)及操作的工具包，封裝了很多種數(shù)據(jù)及數(shù)據(jù)庫(kù)的訪(fǎng)問(wèn)相關(guān)技術(shù)，包括：jdbc、Redis、MongoDB、Neo4j等。

Spring Batch：批處理框架，或說(shuō)是批量任務(wù)執(zhí)行管理器，功能包括任務(wù)調(diào)度、日志記錄/跟蹤等。

Spring Security：是一個(gè)能夠?yàn)榛赟pring的企業(yè)應(yīng)用系統(tǒng)提供聲明式的安全訪(fǎng)問(wèn)控制解決方案的安全框架。

Spring Integration：面向企業(yè)應(yīng)用集成（EAI/ESB）的編程框架，支持的通信方式包括HTTP、FTP、TCP/UDP、JMS、RabbitMQ、Email等。

Spring Social：一組工具包，一組連接社交服務(wù)API，如Twitter、Facebook、LinkedIn、GitHub等，有幾十個(gè)。

Spring AMQP：消息隊(duì)列操作的工具包，主要是封裝了RabbitMQ的操作。

Spring HATEOAS：是一個(gè)用于支持實(shí)現(xiàn)超文本驅(qū)動(dòng)的 REST Web 服務(wù)的開(kāi)發(fā)庫(kù)。

Spring Mobile：是Spring MVC的擴(kuò)展，用來(lái)簡(jiǎn)化手機(jī)上的Web應(yīng)用開(kāi)發(fā)。

Spring for Android：是Spring框架的一個(gè)擴(kuò)展，其主要目的在乎簡(jiǎn)化Android本地應(yīng)用的開(kāi)發(fā)，提供RestTemplate來(lái)訪(fǎng)問(wèn)Rest服務(wù)。

Spring Web Flow：目標(biāo)是成為管理Web應(yīng)用頁(yè)面流程的最佳方案，將頁(yè)面跳轉(zhuǎn)流程單獨(dú)管理，并可配置。

Spring LDAP：是一個(gè)用于操作LDAP的Java工具包，基于Spring的JdbcTemplate模式，簡(jiǎn)化LDAP訪(fǎng)問(wèn)。

Spring Session：session管理的開(kāi)發(fā)工具包，讓你可以把session保存到redis等，進(jìn)行集群化session管理。

Spring Web Services：是基于Spring的Web服務(wù)框架，提供SOAP服務(wù)開(kāi)發(fā)，允許通過(guò)多種方式創(chuàng)建Web服務(wù)。

Spring Shell：提供交互式的Shell可讓你使用簡(jiǎn)單的基于Spring的編程模型來(lái)開(kāi)發(fā)命令，比如Spring Roo命令。

Spring Roo：是一種Spring開(kāi)發(fā)的輔助工具，使用命令行操作來(lái)生成自動(dòng)化項(xiàng)目，操作非常類(lèi)似于Rails。

Spring Scala：為Scala語(yǔ)言編程提供的spring框架的封裝（新的編程語(yǔ)言，Java平臺(tái)的Scala于2003年底/2004年初發(fā)布）。

Spring BlazeDS Integration：一個(gè)開(kāi)發(fā)RIA工具包，可以集成Adobe Flex、BlazeDS、Spring以及Java技術(shù)創(chuàng)建RIA。

Spring Loaded：用于實(shí)現(xiàn)java程序和web應(yīng)用的熱部署的開(kāi)源工具。

Spring REST Shell：可以調(diào)用Rest服務(wù)的命令行工具，敲命令行操作Rest服務(wù)。

Spring cloud子項(xiàng)目

目前來(lái)說(shuō)spring主要集中于spring boot（用于開(kāi)發(fā)微服務(wù)）和spring cloud相關(guān)框架的開(kāi)發(fā)，我們從幾張圖著手理解，然后再具體介紹：

spring cloud子項(xiàng)目包括：

Spring Cloud Config：配置管理開(kāi)發(fā)工具包，可以讓你把配置放到遠(yuǎn)程服務(wù)器，目前支持本地存儲(chǔ)、Git以及Subversion。

Spring Cloud Bus：事件、消息總線(xiàn)，用于在集群（例如，配置變化事件）中傳播狀態(tài)變化，可與Spring Cloud Config聯(lián)合實(shí)現(xiàn)熱部署。

Spring Cloud Netflix：針對(duì)多種Netflix組件提供的開(kāi)發(fā)工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。

Netflix Eureka：云端負(fù)載均衡，一個(gè)基于 REST 的服務(wù)，用于定位服務(wù)，以實(shí)現(xiàn)云端的負(fù)載均衡和中間層服務(wù)器的故障轉(zhuǎn)移。

Netflix Hystrix：容錯(cuò)管理工具，旨在通過(guò)控制服務(wù)和第三方庫(kù)的節(jié)點(diǎn),從而對(duì)延遲和故障提供更強(qiáng)大的容錯(cuò)能力。

Netflix Zuul：邊緣服務(wù)工具，是提供動(dòng)態(tài)路由，監(jiān)控，彈性，安全等的邊緣服務(wù)。

Netflix Archaius：配置管理API，包含一系列配置管理API，提供動(dòng)態(tài)類(lèi)型化屬性、線(xiàn)程安全配置操作、輪詢(xún)框架、回調(diào)機(jī)制等功能。

Spring Cloud for Cloud Foundry：通過(guò)Oauth2協(xié)議綁定服務(wù)到CloudFoundry，CloudFoundry是VMware推出的開(kāi)源PaaS云平臺(tái)。

Spring Cloud Sleuth：日志收集工具包，封裝了Dapper,Zipkin和HTrace操作。

Spring Cloud Data Flow：大數(shù)據(jù)操作工具，通過(guò)命令行方式操作數(shù)據(jù)流。

Spring Cloud Security：安全工具包，為你的應(yīng)用程序添加安全控制，主要是指OAuth2。

Spring Cloud Consul：封裝了Consul操作，consul是一個(gè)服務(wù)發(fā)現(xiàn)與配置工具，與Docker容器可以無(wú)縫集成。

Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服務(wù)注冊(cè)和發(fā)現(xiàn)。

Spring Cloud Stream：數(shù)據(jù)流操作開(kāi)發(fā)包，封裝了與Redis,Rabbit、Kafka等發(fā)送接收消息。

Spring Cloud CLI：基于 Spring Boot CLI，可以讓你以命令行方式快速建立云組件。

WHAT - 什么是微服務(wù)

?

微服務(wù)簡(jiǎn)介

?

微服務(wù)的流行，Martin功不可沒(méi)，這老頭也是個(gè)奇人，特別擅長(zhǎng)抽象歸納和制造概念，我覺(jué)的這就是最牛逼的markting啊，感覺(jué)這也是目前國(guó)人欠缺的能力。

Martin Fowler是國(guó)際著名的OO專(zhuān)家，敏捷開(kāi)發(fā)方法的創(chuàng)始人之一，現(xiàn)為T(mén)houghtWorks公司的首席科學(xué)家.福勒（Martin Fowler），在面向?qū)ο蠓治鲈O(shè)計(jì)、UML、模式、軟件開(kāi)發(fā)方法學(xué)、XP、重構(gòu)等方面，都是世界頂級(jí)的專(zhuān)家，現(xiàn)為T(mén)hought Works公司的首席科學(xué)家。Thought Works是一家從事企業(yè)應(yīng)用開(kāi)發(fā)和集成的公司。早在20世紀(jì)80年代，Fowler就是使用對(duì)象技術(shù)構(gòu)建多層企業(yè)應(yīng)用的倡導(dǎo)者，他著有幾本經(jīng)典書(shū)籍：《企業(yè)應(yīng)用架構(gòu)模式》、《UML精粹》和《重構(gòu)》等。—— 百度百科

?

先來(lái)看看傳統(tǒng)的web開(kāi)發(fā)方式，通過(guò)對(duì)比比較容易理解什么是Microservice Architecture。和Microservice相對(duì)應(yīng)的，這種方式一般被稱(chēng)為Monolithic（比較難傳神的翻譯）。所有的功能打包在一個(gè) WAR包里，基本沒(méi)有外部依賴(lài)（除了容器），部署在一個(gè)JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有邏輯。

?

Monolithic比較適合小項(xiàng)目，優(yōu)點(diǎn)是：

1、開(kāi)發(fā)簡(jiǎn)單直接，集中式管理

2、基本不會(huì)重復(fù)開(kāi)發(fā)

3、功能都在本地，沒(méi)有分布式的管理開(kāi)銷(xiāo)和調(diào)用開(kāi)銷(xiāo)

它的缺點(diǎn)也非常明顯，特別對(duì)于互聯(lián)網(wǎng)公司來(lái)說(shuō)（不一一列舉了）：

1、開(kāi)發(fā)效率低：所有的開(kāi)發(fā)在一個(gè)項(xiàng)目改代碼，遞交代碼相互等待，代碼沖突不斷

2、代碼維護(hù)難：代碼功能耦合在一起，新人不知道何從下手

3、部署不靈活：構(gòu)建時(shí)間長(zhǎng)，任何小修改必須重新構(gòu)建整個(gè)項(xiàng)目，這個(gè)過(guò)程往往很長(zhǎng)

4、穩(wěn)定性不高：一個(gè)微不足道的小問(wèn)題，可以導(dǎo)致整個(gè)應(yīng)用掛掉

5、擴(kuò)展性不夠：無(wú)法滿(mǎn)足高并發(fā)情況下的業(yè)務(wù)需求

所以，現(xiàn)在主流的設(shè)計(jì)一般會(huì)采用Microservice Architecture，就是基于微服務(wù)的架構(gòu)。簡(jiǎn)單來(lái)說(shuō)，微服務(wù)的目的是有效的拆分應(yīng)用，實(shí)現(xiàn)敏捷開(kāi)發(fā)和部署。

用《The art of scalability》一書(shū)里提到的scale cube比較容易理解如何拆分。你看，我們叫分庫(kù)分表，別人總結(jié)成了scale cube，這就是抽象的能力啊，把復(fù)雜的東西用最簡(jiǎn)單的概念解釋和總結(jié)。X軸代表運(yùn)行多個(gè)負(fù)載均衡器之后運(yùn)行的實(shí)例，Y軸代表將應(yīng)用進(jìn)一步分解為微服務(wù) （分庫(kù)），數(shù)據(jù)量大時(shí)，還可以用Z軸將服務(wù)按數(shù)據(jù)分區(qū)（分表）

?

微服務(wù)的具體特征

先看看最官方的定義吧

The microservice architectural style is an approach to developing a single application as?a?suite of small services, each?running in its own process?and communicating with lightweight mechanisms, often an HTTP resource API. These services are?**built around business capabilities**?and independently deployable?by fully automated deployment machinery. There is?a?bare minimum of centralized management?of these services?, which may be written in different programming languages and use different >

-- James Lewis and Martin Fowler

?

把Martin老頭的定義大概的翻譯一下就是下面幾條，這個(gè)定義還是太抽象是不是，那就對(duì)了，就是要?jiǎng)?wù)虛，都說(shuō)明白了誰(shuí)還找他付費(fèi)咨詢(xún)啊，這么貴。

1. 一些列的獨(dú)立的服務(wù)共同組成系統(tǒng)

2. 單獨(dú)部署，跑在自己的進(jìn)程里

3. 每個(gè)服務(wù)為獨(dú)立的業(yè)務(wù)開(kāi)發(fā)

4. 分布式的管理

Martin自己也說(shuō)了，每個(gè)人對(duì)微服務(wù)都可以有自己的理解，不過(guò)大概的標(biāo)準(zhǔn)還是有一些的。

1、分布式服務(wù)組成的系統(tǒng)

2、按照業(yè)務(wù)而不是技術(shù)來(lái)劃分組織

3、做有生命的產(chǎn)品而不是項(xiàng)目

4、Smart endpoints and dumb pipes（我的理解是強(qiáng)服務(wù)個(gè)體和弱通信）

5、自動(dòng)化運(yùn)維（DevOps）

6、容錯(cuò)

7、快速演化

SOA vs Microservice

除了Smart endpoints and dumb pipes都很容易理解對(duì)嗎？相信很多人都會(huì)問(wèn)一個(gè)問(wèn)題，這是不是就是SOA換了個(gè)概念，掛羊頭賣(mài)狗肉啊，有說(shuō)法把Microservice叫成 Lightway SOA。也有很多傳統(tǒng)磚家跳出來(lái)說(shuō)Microservice就是SOA。其實(shí)Martin也沒(méi)否認(rèn)SOA和Microservice的關(guān)系。

我個(gè)人理解，Microservice是SOA的傳承，但一個(gè)最本質(zhì)的區(qū)別就在于Smart endpoints and dumb pipes，或者說(shuō)是真正的分布式的、去中心化的。Smart endpoints and dumb pipes本質(zhì)就是去ESB，把所有的“思考”邏輯包括路由、消息解析等放在服務(wù)內(nèi)部（Smart endpoints），去掉一個(gè)大一統(tǒng)的ESB，服務(wù)間輕（dumb pipes）通信，是比SOA更徹底的拆分。

HOW - 怎么具體實(shí)踐微服務(wù)

聽(tīng)上去好像都不錯(cuò)，具體怎么落地啊？這需要回答下面幾個(gè)問(wèn)題：

1、客戶(hù)端如何訪(fǎng)問(wèn)這些服務(wù)？

2、服務(wù)之間如何通信？

3、這么多服務(wù)，怎么找?

4、服務(wù)掛了怎么辦？

5、客戶(hù)端如何訪(fǎng)問(wèn)這些服務(wù)？

原來(lái)的Monolithic方式開(kāi)發(fā)，所有的服務(wù)都是本地的，UI可以直接調(diào)用，現(xiàn)在按功能拆分成獨(dú)立的服務(wù)，跑在獨(dú)立的一般都在獨(dú)立的虛擬機(jī)上的 Java進(jìn)程了。客戶(hù)端UI如何訪(fǎng)問(wèn)他的？后臺(tái)有N個(gè)服務(wù)，前臺(tái)就需要記住管理N個(gè)服務(wù)，一個(gè)服務(wù)下線(xiàn)/更新/升級(jí)，前臺(tái)就要重新部署，這明顯不服務(wù)我們 拆分的理念，特別當(dāng)前臺(tái)是移動(dòng)應(yīng)用的時(shí)候，通常業(yè)務(wù)變化的節(jié)奏更快。另外，N個(gè)小服務(wù)的調(diào)用也是一個(gè)不小的網(wǎng)絡(luò)開(kāi)銷(xiāo)。還有一般微服務(wù)在系統(tǒng)內(nèi)部，通常是無(wú) 狀態(tài)的，用戶(hù)登錄信息和權(quán)限管理最好有一個(gè)統(tǒng)一的地方維護(hù)管理（OAuth）。

所以，一般在后臺(tái)N個(gè)服務(wù)和UI之間一般會(huì)一個(gè)代理或者叫API Gateway，他的作用包括

1、提供統(tǒng)一服務(wù)入口，讓微服務(wù)對(duì)前臺(tái)透明

2、聚合后臺(tái)的服務(wù)，節(jié)省流量，提升性能

3、提供安全，過(guò)濾，流控等API管理功能

我的理解其實(shí)這個(gè)API Gateway可以有很多廣義的實(shí)現(xiàn)辦法，可以是一個(gè)軟硬一體的盒子，也可以是一個(gè)簡(jiǎn)單的MVC框架，甚至是一個(gè)Node.js的服務(wù)端。他們最重要的作 用是為前臺(tái)（通常是移動(dòng)應(yīng)用）提供后臺(tái)服務(wù)的聚合，提供一個(gè)統(tǒng)一的服務(wù)出口，解除他們之間的耦合，不過(guò)API Gateway也有可能成為單點(diǎn)故障點(diǎn)或者性能的瓶頸。

一般用過(guò)Taobao Open Platform的就能很容易的體會(huì)，TAO就是這個(gè)API Gateway。

?

服務(wù)之間如何通信？

因?yàn)樗械奈⒎?wù)都是獨(dú)立的Java進(jìn)程跑在獨(dú)立的虛擬機(jī)上，所以服務(wù)間的通行就是IPC（inter process communication），已經(jīng)有很多成熟的方案。現(xiàn)在基本最通用的有兩種方式。這幾種方式，展開(kāi)來(lái)講都可以寫(xiě)本書(shū)，而且大家一般都比較熟悉細(xì)節(jié)了， 就不展開(kāi)講了。

1、同步調(diào)用

2、REST（JAX-RS，Spring Boot）

3、RPC（Thrift, Dubbo）

4、異步消息調(diào)用(Kafka, Notify, MetaQ)

?

一般同步調(diào)用比較簡(jiǎn)單，一致性強(qiáng)，但是容易出調(diào)用問(wèn)題，性能體驗(yàn)上也會(huì)差些，特別是調(diào)用層次多的時(shí)候。RESTful和RPC的比較也是一個(gè)很有意 思的話(huà)題。

一般REST基于HTTP，更容易實(shí)現(xiàn)，更容易被接受，服務(wù)端實(shí)現(xiàn)技術(shù)也更靈活些，各個(gè)語(yǔ)言都能支持，同時(shí)能跨客戶(hù)端，對(duì)客戶(hù)端沒(méi)有特殊的要 求，只要封裝了HTTP的SDK就能調(diào)用，所以相對(duì)使用的廣一些。RPC也有自己的優(yōu)點(diǎn)，傳輸協(xié)議更高效，安全更可控，特別在一個(gè)公司內(nèi)部，如果有統(tǒng)一個(gè) 的開(kāi)發(fā)規(guī)范和統(tǒng)一的服務(wù)框架時(shí)，他的開(kāi)發(fā)效率優(yōu)勢(shì)更明顯些。就看各自的技術(shù)積累實(shí)際條件，自己的選擇了。

而異步消息的方式在分布式系統(tǒng)中有特別廣泛的應(yīng)用，他既能減低調(diào)用服務(wù)之間的耦合，又能成為調(diào)用之間的緩沖，確保消息積壓不會(huì)沖垮被調(diào)用方，同時(shí)能 保證調(diào)用方的服務(wù)體驗(yàn)，繼續(xù)干自己該干的活，不至于被后臺(tái)性能拖慢。

不過(guò)需要付出的代價(jià)是一致性的減弱，需要接受數(shù)據(jù)最終一致性；還有就是后臺(tái)服務(wù)一般要 實(shí)現(xiàn)冪等性，因?yàn)橄l(fā)送出于性能的考慮一般會(huì)有重復(fù)（保證消息的被收到且僅收到一次對(duì)性能是很大的考驗(yàn)）；最后就是必須引入一個(gè)獨(dú)立的broker，如 果公司內(nèi)部沒(méi)有技術(shù)積累，對(duì)broker分布式管理也是一個(gè)很大的挑戰(zhàn)。

這么多服務(wù)，怎么找?

在微服務(wù)架構(gòu)中，一般每一個(gè)服務(wù)都是有多個(gè)拷貝，來(lái)做負(fù)載均衡。一個(gè)服務(wù)隨時(shí)可能下線(xiàn)，也可能應(yīng)對(duì)臨時(shí)訪(fǎng)問(wèn)壓力增加新的服務(wù)節(jié)點(diǎn)。服務(wù)之間如何相互 感知？服務(wù)如何管理？這就是服務(wù)發(fā)現(xiàn)的問(wèn)題了。

一般有兩類(lèi)做法，也各有優(yōu)缺點(diǎn)。基本都是通過(guò)zookeeper等類(lèi)似技術(shù)做服務(wù)注冊(cè)信息的分布式管理。當(dāng) 服務(wù)上線(xiàn)時(shí)，服務(wù)提供者將自己的服務(wù)信息注冊(cè)到ZK（或類(lèi)似框架），并通過(guò)心跳維持長(zhǎng)鏈接，實(shí)時(shí)更新鏈接信息。服務(wù)調(diào)用者通過(guò)ZK尋址，根據(jù)可定制算法， 找到一個(gè)服務(wù)，還可以將服務(wù)信息緩存在本地以提高性能。當(dāng)服務(wù)下線(xiàn)時(shí)，ZK會(huì)發(fā)通知給服務(wù)客戶(hù)端。

1、客戶(hù)端做：優(yōu)點(diǎn)是架構(gòu)簡(jiǎn)單，擴(kuò)展靈活，只對(duì)服務(wù)注冊(cè)器依賴(lài)。缺點(diǎn)是客戶(hù)端要維護(hù)所有調(diào)用服務(wù)的地址，有技術(shù)難度，一般大公司都有成熟的內(nèi)部框架支持，比如Dubbo。

2、服務(wù)端做：優(yōu)點(diǎn)是簡(jiǎn)單，所有服務(wù)對(duì)于前臺(tái)調(diào)用方透明，一般在小公司在云服務(wù)上部署的應(yīng)用采用的比較多。

?

這么多服務(wù)，服務(wù)掛了怎么辦？

前面提到，Monolithic方式開(kāi)發(fā)一個(gè)很大的風(fēng)險(xiǎn)是，把所有雞蛋放在一個(gè)籃子里，一榮俱榮，一損俱損。而分布式最大的特性就是網(wǎng)絡(luò)是不可靠 的。通過(guò)微服務(wù)拆分能降低這個(gè)風(fēng)險(xiǎn)，不過(guò)如果沒(méi)有特別的保障，結(jié)局肯定是噩夢(mèng)。

我們剛遇到一個(gè)線(xiàn)上故障就是一個(gè)很不起眼的SQL計(jì)數(shù)功能，在訪(fǎng)問(wèn)量上升 時(shí)，導(dǎo)致數(shù)據(jù)庫(kù)load彪高，影響了所在應(yīng)用的性能，從而影響所有調(diào)用這個(gè)應(yīng)用服務(wù)的前臺(tái)應(yīng)用。所以當(dāng)我們的系統(tǒng)是由一系列的服務(wù)調(diào)用鏈組成的時(shí)候，我們 必須確保任一環(huán)節(jié)出問(wèn)題都不至于影響整體鏈路。相應(yīng)的手段有很多：

1、重試機(jī)制

2、限流

3、熔斷機(jī)制

4、負(fù)載均衡

5、降級(jí)（本地緩存）

這些方法基本上都很明確通用，就不詳細(xì)說(shuō)明了。

?

WHY - 微服務(wù)的應(yīng)用

這里有一個(gè)圖非常好的總結(jié)微服務(wù)架構(gòu)需要考慮的問(wèn)題，包括

1、API Gateway

2、服務(wù)間調(diào)用

3、服務(wù)發(fā)現(xiàn)

4、服務(wù)容錯(cuò)

5、服務(wù)部署

6、數(shù)據(jù)調(diào)用

?

微服務(wù)的優(yōu)點(diǎn)和缺點(diǎn)（或者說(shuō)挑戰(zhàn)）一樣明顯。

1、優(yōu)點(diǎn)

2、開(kāi)發(fā)簡(jiǎn)單

3、技術(shù)棧靈活

4、服務(wù)獨(dú)立無(wú)依賴(lài)

5、獨(dú)立按需擴(kuò)展

6、可用性高

7、缺點(diǎn)（挑戰(zhàn)）

8、多服務(wù)運(yùn)維難度

9、系統(tǒng)部署依賴(lài)

10、服務(wù)間通信成本

11、數(shù)據(jù)一致性

12、系統(tǒng)集成測(cè)試

13、重復(fù)工作

14、性能監(jiān)控

沒(méi)有最好的，只有適合自己的。

?

1、對(duì)于大的互聯(lián)網(wǎng)公司，微服務(wù)架構(gòu)是血液，是習(xí)慣，每家公司都有自己的套路和架構(gòu)，細(xì)節(jié)有不同，但是核心理念是通的。

2、對(duì)于一般的公司而言，實(shí)踐微服務(wù)有非常大的技術(shù)挑戰(zhàn)，于是乎才有了這么多IT供應(yīng)商考慮這里的商機(jī)。微服務(wù)比較適合未來(lái)有一定的擴(kuò)展復(fù)雜度，且有 很大用戶(hù)增量預(yù)期的應(yīng)用，說(shuō)人話(huà)就是新興的互聯(lián)網(wǎng)公司。創(chuàng)業(yè)初期，不可能買(mǎi)大量的機(jī)器或者很貴的機(jī)器，但是又必須考慮應(yīng)對(duì)成功后的巨量的用戶(hù)，微服務(wù)架構(gòu) 成了最好的選擇。

So What - 思考

看到上面的圖，不是不覺(jué)得特別的熟悉？其實(shí)我們N年前就用的滾瓜爛熟了好不好？褲子都拖了。

其實(shí)本來(lái)所謂的微服務(wù)就是對(duì)互聯(lián)網(wǎng)在應(yīng)用技術(shù)的一個(gè)總結(jié)歸納，IT廠(chǎng)商鼓吹所有概念無(wú)非是為了生意（business），SOA是，Cloud是，Microservice也是。下面玩笑很有意思的概括了這個(gè)情況（我加了第一條線(xiàn)，原圖點(diǎn)擊閱讀原文查看）

?

所以微服對(duì)我們的思考我覺(jué)得更多的是思維上的，對(duì)已微服務(wù)架構(gòu)，技術(shù)上不是問(wèn)題，意識(shí)比工具重要。

1、按照業(yè)務(wù) 或者客戶(hù)需求組織資源（這是最難的）

2、做有生命的產(chǎn)品，而不是項(xiàng)目

3、頭狼戰(zhàn)隊(duì)，全棧化

4、后臺(tái)服務(wù)貫徹Single Responsibility Principle

5、VM->Docker （to PE）

6、DevOps (to PE)

同時(shí)，對(duì)于開(kāi)發(fā)同學(xué)，有這么多的中間件和強(qiáng)大的PE支持固然是好事，我們也需要深入去了解這些中間件背后的原理，知其然知其所以然，設(shè)想下，如果我們是一個(gè)小公司的CTO，離開(kāi)的阿里的大環(huán)境，在有限的技術(shù)資源如何通過(guò)開(kāi)源技術(shù)實(shí)施微服務(wù)？

最后，一般提到微服務(wù)都離不開(kāi)DevOps和Docker，理解微服務(wù)架構(gòu)是核心，devops和docker是工具，是手段。

品略圖書(shū)館 http://www.pinlue.com/

?

總結(jié)

以上是生活随笔為你收集整理的基于Spring Boot+Cloud构建微云架构。的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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