微服務(wù)架構(gòu)（MicroserviceArchitecture）是一種架構(gòu)概念，旨在通過將功能分解到各個(gè)離散的服務(wù)中以實(shí)現(xiàn)對解決方案的解耦，你可以將其看作是在架構(gòu)層次而非獲取服務(wù)的。

    類上應(yīng)用很多SOLID原則。微服務(wù)架構(gòu)是個(gè)很有趣的概念，它的主要作用是將功能分解到離散的各個(gè)服務(wù)當(dāng)中，從而降低系統(tǒng)的耦合性，并提供更加靈活的服務(wù)支持。

    概念：把一個(gè)大型的單個(gè)應(yīng)用程序和服務(wù)拆分為數(shù)個(gè)甚至數(shù)十個(gè)的支持微服務(wù)，它可擴(kuò)展單個(gè)組件而不是整個(gè)的應(yīng)用程序堆棧，從而滿足服務(wù)等級協(xié)議。

    定義：圍繞業(yè)務(wù)領(lǐng)域組件來創(chuàng)建應(yīng)用，這些應(yīng)用可獨(dú)立地進(jìn)行開發(fā)、管理和迭代。在分散的組件中使用云架構(gòu)和平臺式部署、管理和服務(wù)功能，使產(chǎn)品交付變得更加簡單。

    本質(zhì)：用一些功能比較明確、業(yè)務(wù)比較精練的服務(wù)去解決更大、更實(shí)際的問題。

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

    官方的定義：

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

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

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

    4、分布式管理

    5、非常強(qiáng)調(diào)隔離性

    大概的標(biāo)準(zhǔn)：

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

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

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

    4、強(qiáng)服務(wù)個(gè)體和弱通信（Smartendpointsanddumbpipes）

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

    6、高度容錯(cuò)性

    7、快速演化和迭代

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

    要實(shí)際的應(yīng)用微服務(wù)，需要解決一下四點(diǎn)問題：

    1、客戶端如何訪問這些服務(wù)

    2、每個(gè)服務(wù)之間如何通信

    3、如此多的服務(wù)，如何實(shí)現(xiàn)？

    4、服務(wù)掛了，如何解決？（備份方案，應(yīng)急處理機(jī)制）

    1、客戶端如何訪問這些服務(wù)

    原來的Monolithic方式開發(fā)，所有的服務(wù)都是本地的，UI可以直接調(diào)用，現(xiàn)在按功能拆分成獨(dú)立的服務(wù)，跑在獨(dú)立的一般都在獨(dú)立的虛擬機(jī)上的Java進(jìn)程了。客戶端UI如何訪問他的？

    后臺有N個(gè)服務(wù)，前臺就需要記住管理N個(gè)服務(wù)，一個(gè)服務(wù)下線/更新/升級，前臺就要重新部署，這明顯不服務(wù)我們拆分的理念，特別當(dāng)前臺是移動(dòng)應(yīng)用的時(shí)候，通常業(yè)務(wù)變化的節(jié)奏更快。

    另外，N個(gè)小服務(wù)的調(diào)用也是一個(gè)不小的網(wǎng)絡(luò)開銷。還有一般微服務(wù)在系統(tǒng)內(nèi)部，通常是無狀態(tài)的，用戶登錄信息和權(quán)限管理最好有一個(gè)統(tǒng)一的地方維護(hù)管理（OAuth）。

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

    ①提供統(tǒng)一服務(wù)入口，讓微服務(wù)對前臺透明

    ②聚合后臺的服務(wù)，節(jié)省流量，提升性能

    ③提供安全，過濾，流控等API管理功能

    資料分享：SpringBoot學(xué)習(xí)筆記，這個(gè)太全了！

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

    用過TaobaoOpenPlatform（淘寶開放平臺）的就能很容易的體會(huì)，TAO就是這個(gè)APIGateway。

    2、每個(gè)服務(wù)之間如何通信

    所有的微服務(wù)都是獨(dú)立的Java進(jìn)程跑在獨(dú)立的虛擬機(jī)上，所以服務(wù)間的通信就是IPC（interprocesscommunication），已經(jīng)有很多成熟的方案?，F(xiàn)在基本最通用的有兩種方式：

    同步調(diào)用：

    ①REST（JAX-RS，SpringBoot）

    SpringBoot最全基礎(chǔ)教程：https://github.com/javastacks/spring-boot-best-practice

    ②RPC（Thrift,Dubbo）

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

    同步和異步的區(qū)別：

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

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

    而異步消息的方式在分布式系統(tǒng)中有特別廣泛的應(yīng)用，他既能減低調(diào)用服務(wù)之間的耦合，又能成為調(diào)用之間的緩沖，確保消息積壓不會(huì)沖垮被調(diào)用方，同時(shí)能保證調(diào)用方的服務(wù)體驗(yàn)，繼續(xù)干自己該干的活，不至于被后臺性能拖慢。不過需要付出的代價(jià)是一致性的減弱，需要接受數(shù)據(jù)最終一致性；還有就是后臺服務(wù)一般要實(shí)現(xiàn)冪等性，因?yàn)橄l(fā)送出于性能的考慮一般會(huì)有重復(fù)（保證消息的被收到且僅收到一次對性能是很大的考驗(yàn)）；最后就是必須引入一個(gè)獨(dú)立的broker，如果公司內(nèi)部沒有技術(shù)積累，對broker分布式管理也是一個(gè)很大的挑戰(zhàn)。

    3、如此多的服務(wù)，如何實(shí)現(xiàn)？

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

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

    另外，SpringCloud微服務(wù)系列面試題和答案全部整理好了，微信搜索Java技術(shù)棧，在后臺發(fā)送：面試，可以在線閱讀。

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

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

    4、服務(wù)掛了，如何解決

    前面提到，Monolithic方式開發(fā)一個(gè)很大的風(fēng)險(xiǎn)是，把所有雞蛋放在一個(gè)籃子里，一榮俱榮，一損俱損。而分布式最大的特性就是網(wǎng)絡(luò)是不可靠的。通過微服務(wù)拆分能降低這個(gè)風(fēng)險(xiǎn)，不過如果沒有特別的保障，結(jié)局肯定是噩夢。所以當(dāng)我們的系統(tǒng)是由一系列的服務(wù)調(diào)用鏈組成的時(shí)候，我們必須確保任一環(huán)節(jié)出問題都不至于影響整體鏈路。

    分享給你：46張PPT弄懂JVM性能調(diào)優(yōu)！

    相應(yīng)的手段有很多：

    ①重試機(jī)制

    ②限流

    ③熔斷機(jī)制

    ④負(fù)載均衡

    ⑤降級（本地緩存）

    這些方法基本都很明確通用，比如Netflix的Hystrix：https://github.com/Netflix/Hystrix、