javascript
基于 Spring Boot + Cloud 构建微云架构
點(diǎn)擊上方“Java基基”，選擇“設(shè)為星標(biāo)”
做積極的人，而不是積極廢人！
源碼精品專欄
?原創(chuàng) | Java 2019 超神之路，很肝~
中文詳細(xì)注釋的開(kāi)源項(xiàng)目
RPC 框架 Dubbo 源碼解析
網(wǎng)絡(luò)應(yīng)用框架 Netty 源碼解析
消息中間件 RocketMQ 源碼解析
數(shù)據(jù)庫(kù)中間件 Sharding-JDBC 和 MyCAT 源碼解析
作業(yè)調(diào)度中間件 Elastic-Job 源碼解析
分布式事務(wù)中間件 TCC-Transaction 源碼解析
Eureka 和 Hystrix 源碼解析
Java 并發(fā)源碼
來(lái)源：?my.oschina.net/u/3636867/blog/1802517
前言
Spring 頂級(jí)框架
WHAT - 什么是微服務(wù)
HOW - 怎么具體實(shí)踐微服務(wù)
So What - 思考
前言
首先，最想說(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也依賴于此框架。
Spring Cloud ：微服務(wù)工具包，為開(kāi)發(fā)者提供了在分布式系統(tǒng)的配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線等開(kāi)發(fā)工具包。
Spring XD ：是一種運(yùn)行時(shí)環(huán)境（服務(wù)器軟件，非開(kāi)發(fā)框架），組合spring技術(shù)，如spring batch、spring boot、spring data，采集大數(shù)據(jù)并處理。
Spring Data ：是一個(gè)數(shù)據(jù)訪問(wèn)及操作的工具包，封裝了很多種數(shù)據(jù)及數(shù)據(jù)庫(kù)的訪問(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)提供聲明式的安全訪問(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)訪問(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訪問(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)目，操作非常類似于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 ：事件、消息總線，用于在集群（例如，配置變化事件）中傳播狀態(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)類型化屬性、線程安全配置操作、輪詢框架、回調(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專家，敏捷開(kāi)發(fā)方法的創(chuàng)始人之一，現(xiàn)為ThoughtWorks公司的首席科學(xué)家.福勒（Martin Fowler），在面向?qū)ο蠓治鲈O(shè)計(jì)、UML、模式、軟件開(kāi)發(fā)方法學(xué)、XP、重構(gòu)等方面，都是世界頂級(jí)的專家，現(xiàn)為Thought 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)典書籍：《企業(yè)應(yīng)用架構(gòu)模式》、《UML精粹》和《重構(gòu)》等?！?百度百科
先來(lái)看看傳統(tǒng)的web開(kāi)發(fā)方式，通過(guò)對(duì)比比較容易理解什么是Microservice Architecture。和Microservice相對(duì)應(yīng)的，這種方式一般被稱為Monolithic（比較難傳神的翻譯）。所有的功能打包在一個(gè) WAR包里，基本沒(mé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)銷和調(diào)用開(kāi)銷
它的缺點(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ú)法滿足高并發(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》一書里提到的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 data storage technologies.
-- James Lewis and Martin Fowler
把Martin老頭的定義大概的翻譯一下就是下面幾條，這個(gè)定義還是太抽象是不是，那就對(duì)了，就是要?jiǎng)?wù)虛，都說(shuō)明白了誰(shuí)還找他付費(fèi)咨詢啊，這么貴。
一些列的獨(dú)立的服務(wù)共同組成系統(tǒng)
單獨(dú)部署，跑在自己的進(jìn)程里
每個(gè)服務(wù)為獨(dú)立的業(yè)務(wù)開(kāi)發(fā)
分布式的管理
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è)概念，掛羊頭賣狗肉啊，有說(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、客戶端如何訪問(wèn)這些服務(wù)？
2、服務(wù)之間如何通信？
3、這么多服務(wù)，怎么找?
4、服務(wù)掛了怎么辦？
5、客戶端如何訪問(wèn)這些服務(wù)？
原來(lái)的Monolithic方式開(kāi)發(fā)，所有的服務(wù)都是本地的，UI可以直接調(diào)用，現(xiàn)在按功能拆分成獨(dú)立的服務(wù)，跑在獨(dú)立的一般都在獨(dú)立的虛擬機(jī)上的 Java進(jìn)程了?？蛻舳薝I如何訪問(wèn)他的？后臺(tái)有N個(gè)服務(wù)，前臺(tái)就需要記住管理N個(gè)服務(wù)，一個(gè)服務(wù)下線/更新/升級(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)銷。還有一般微服務(wù)在系統(tǒng)內(nèi)部，通常是無(wú) 狀態(tài)的，用戶登錄信息和權(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)講都可以寫本書，而且大家一般都比較熟悉細(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è)很有意 思的話題。
一般REST基于HTTP，更容易實(shí)現(xiàn)，更容易被接受，服務(wù)端實(shí)現(xiàn)技術(shù)也更靈活些，各個(gè)語(yǔ)言都能支持，同時(shí)能跨客戶端，對(duì)客戶端沒(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í)可能下線，也可能應(yīng)對(duì)臨時(shí)訪問(wèn)壓力增加新的服務(wù)節(jié)點(diǎn)。服務(wù)之間如何相互 感知？服務(wù)如何管理？這就是服務(wù)發(fā)現(xiàn)的問(wèn)題了。
一般有兩類做法，也各有優(yōu)缺點(diǎn)。基本都是通過(guò)zookeeper等類似技術(shù)做服務(wù)注冊(cè)信息的分布式管理。當(dāng) 服務(wù)上線時(shí)，服務(wù)提供者將自己的服務(wù)信息注冊(cè)到ZK（或類似框架），并通過(guò)心跳維持長(zhǎng)鏈接，實(shí)時(shí)更新鏈接信息。服務(wù)調(diào)用者通過(guò)ZK尋址，根據(jù)可定制算法， 找到一個(gè)服務(wù)，還可以將服務(wù)信息緩存在本地以提高性能。當(dāng)服務(wù)下線時(shí)，ZK會(huì)發(fā)通知給服務(wù)客戶端。
1、客戶端做：優(yōu)點(diǎn)是架構(gòu)簡(jiǎn)單，擴(kuò)展靈活，只對(duì)服務(wù)注冊(cè)器依賴。缺點(diǎn)是客戶端要維護(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è)線上故障就是一個(gè)很不起眼的SQL計(jì)數(shù)功能，在訪問(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ú)依賴
5、獨(dú)立按需擴(kuò)展
6、可用性高
7、缺點(diǎn)（挑戰(zhàn)）
8、多服務(wù)運(yùn)維難度
9、系統(tǒng)部署依賴
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ù)雜度，且有 很大用戶增量預(yù)期的應(yīng)用，說(shuō)人話就是新興的互聯(lián)網(wǎng)公司。創(chuàng)業(yè)初期，不可能買大量的機(jī)器或者很貴的機(jī)器，但是又必須考慮應(yīng)對(duì)成功后的巨量的用戶，微服務(wù)架構(gòu) 成了最好的選擇。
So What - 思考**
看到上面的圖，不是不覺(jué)得特別的熟悉？其實(shí)我們N年前就用的滾瓜爛熟了好不好？褲子都拖了。
其實(shí)本來(lái)所謂的微服務(wù)就是對(duì)互聯(lián)網(wǎng)在應(yīng)用技術(shù)的一個(gè)總結(jié)歸納，IT廠商鼓吹所有概念無(wú)非是為了生意（business），SOA是，Cloud是，Microservice也是。下面玩笑很有意思的概括了這個(gè)情況（我加了第一條線，原圖點(diǎn)擊閱讀原文查看）
所以微服對(duì)我們的思考我覺(jué)得更多的是思維上的，對(duì)已微服務(wù)架構(gòu)，技術(shù)上不是問(wèn)題，意識(shí)比工具重要。
1、按照業(yè)務(wù) 或者客戶需求組織資源（這是最難的）
2、做有生命的產(chǎn)品，而不是項(xiàng)目
3、頭狼戰(zhàn)隊(duì)，全?；?/p>
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í)間再學(xué)習(xí)整理下。
歡迎加入我的知識(shí)星球，一起探討架構(gòu)，交流源碼。加入方式，長(zhǎng)按下方二維碼噢：
已在知識(shí)星球更新源碼解析如下：
最近更新《芋道 SpringBoot 2.X 入門》系列，已經(jīng) 20 余篇，覆蓋了?MyBatis、Redis、MongoDB、ES、分庫(kù)分表、讀寫分離、SpringMVC、Webflux、權(quán)限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能測(cè)試等等內(nèi)容。
提供近 3W 行代碼的 SpringBoot 示例，以及超 4W 行代碼的電商微服務(wù)項(xiàng)目。
獲取方式：點(diǎn)“在看”，關(guān)注公眾號(hào)并回復(fù)?666?領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
如果你喜歡這篇文章，喜歡，轉(zhuǎn)發(fā)。
生活很美好，明天見(jiàn)(｡･ω･｡)ﾉ?
總結(jié)
以上是生活随笔為你收集整理的基于 Spring Boot + Cloud 构建微云架构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 【开启SSH】小米AIoT路由器 AC2
- 下一篇： 【SpringBoot搭建个人博客】-