微服務(wù)架構(gòu)（MicroserviceArchitecture）是一種架構(gòu)概念，旨在通過將功能分解到各個離散的服務(wù)中以實現(xiàn)對解決方案的解耦，你可以將其看作是在架構(gòu)層次而非獲取服務(wù)的。
類上應(yīng)用很多SOLID原則。微服務(wù)架構(gòu)是個很有趣的概念，它的主要作用是將功能分解到離散的各個服務(wù)當(dāng)中，從而降低系統(tǒng)的耦合性，并提供更加靈活的服務(wù)支持。
概念：把一個大型的單個應(yīng)用程序和服務(wù)拆分為數(shù)個甚至數(shù)十個的支持微服務(wù)，它可擴(kuò)展單個組件而不是整個的應(yīng)用程序堆棧，從而滿足服務(wù)等級協(xié)議。
定義：圍繞業(yè)務(wù)領(lǐng)域組件來創(chuàng)建應(yīng)用，這些應(yīng)用可獨立地進(jìn)行開發(fā)、管理和迭代。在分散的組件中使用云架構(gòu)和平臺式部署、管理和服務(wù)功能，使產(chǎn)品交付變得更加簡單。
本質(zhì)：用一些功能比較明確、業(yè)務(wù)比較精練的服務(wù)去解決更大、更實際的問題。
官方的定義：
1、一些列的獨立的服務(wù)共同組成系統(tǒng)
2、單獨部署，跑在自己的進(jìn)程中
3、每個服務(wù)為獨立的業(yè)務(wù)開發(fā)
4、分布式管理
5、非常強(qiáng)調(diào)隔離性
大概的標(biāo)準(zhǔn)：
1、分布式服務(wù)組成的系統(tǒng)
2、按照業(yè)務(wù)，而不是技術(shù)來劃分組織
3、做有生命的產(chǎn)品而不是項目
4、強(qiáng)服務(wù)個體和弱通信（Smartendpointsanddumbpipes）
5、自動化運(yùn)維（DevOps）
6、高度容錯性
7、快速演化和迭代
要實際的應(yīng)用微服務(wù)，需要解決一下四點問題：
1、客戶端如何訪問這些服務(wù)
2、每個服務(wù)之間如何通信
3、如此多的服務(wù)，如何實現(xiàn)？
4、服務(wù)掛了，如何解決？（備份方案，應(yīng)急處理機(jī)制）
1、客戶端如何訪問這些服務(wù)
原來的Monolithic方式開發(fā)，所有的服務(wù)都是本地的，UI可以直接調(diào)用，現(xiàn)在按功能拆分成獨立的服務(wù)，跑在獨立的一般都在獨立的虛擬機(jī)上的Java進(jìn)程了?？蛻舳薝I如何訪問他的？
后臺有N個服務(wù)，前臺就需要記住管理N個服務(wù)，一個服務(wù)下線/更新/升級，前臺就要重新部署，這明顯不服務(wù)我們拆分的理念，特別當(dāng)前臺是移動應(yīng)用的時候，通常業(yè)務(wù)變化的節(jié)奏更快。
另外，N個小服務(wù)的調(diào)用也是一個不小的網(wǎng)絡(luò)開銷。還有一般微服務(wù)在系統(tǒng)內(nèi)部，通常是無狀態(tài)的，用戶登錄信息和權(quán)限管理最好有一個統(tǒng)一的地方維護(hù)管理（OAuth）。
所以，一般在后臺N個服務(wù)和UI之間一般會一個代理或者叫APIGateway，他的作用包括：
①提供統(tǒng)一服務(wù)入口，讓微服務(wù)對前臺透明
②聚合后臺的服務(wù)，節(jié)省流量，提升性能
③提供安全，過濾，流控等API管理功能
資料分享：SpringBoot學(xué)習(xí)筆記，這個太全了！
其實這個APIGateway可以有很多廣義的實現(xiàn)辦法，可以是一個軟硬一體的盒子，也可以是一個簡單的MVC框架，甚至是一個Node.js的服務(wù)端。他們最重要的作用是為前臺（通常是移動應(yīng)用）提供后臺服務(wù)的聚合，提供一個統(tǒng)一的服務(wù)出口，解除他們之間的耦合，不過APIGateway也有可能成為單點故障點或者性能的瓶頸。
用過TaobaoOpenPlatform（淘寶開放平臺）的就能很容易的體會，TAO就是這個APIGateway。
2、每個服務(wù)之間如何通信
所有的微服務(wù)都是獨立的Java進(jìn)程跑在獨立的虛擬機(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)用問題，性能體驗上也會差些，特別是調(diào)用層次多的時候。RESTful和RPC的比較也是一個很有意思的話題。
一般REST基于HTTP，更容易實現(xiàn)，更容易被接受，服務(wù)端實現(xiàn)技術(shù)也更靈活些，各個語言都能支持，同時能跨客戶端，對客戶端沒有特殊的要求，只要封裝了HTTP的SDK就能調(diào)用，所以相對使用的廣一些。RPC也有自己的優(yōu)點，傳輸協(xié)議更高效，安全更可控，特別在一個公司內(nèi)部，如果有統(tǒng)一個的開發(fā)規(guī)范和統(tǒng)一的服務(wù)框架時，他的開發(fā)效率優(yōu)勢更明顯些。就看各自的技術(shù)積累實際條件，自己的選擇了。
而異步消息的方式在分布式系統(tǒng)中有特別廣泛的應(yīng)用，他既能減低調(diào)用服務(wù)之間的耦合，又能成為調(diào)用之間的緩沖，確保消息積壓不會沖垮被調(diào)用方，同時能保證調(diào)用方的服務(wù)體驗，繼續(xù)干自己該干的活，不至于被后臺性能拖慢。不過需要付出的代價是一致性的減弱，需要接受數(shù)據(jù)最終一致性；還有就是后臺服務(wù)一般要實現(xiàn)冪等性，因為消息發(fā)送出于性能的考慮一般會有重復(fù)（保證消息的被收到且僅收到一次對性能是很大的考驗）；最后就是必須引入一個獨立的broker，如果公司內(nèi)部沒有技術(shù)積累，對broker分布式管理也是一個很大的挑戰(zhàn)。
3、如此多的服務(wù)，如何實現(xiàn)？
在微服務(wù)架構(gòu)中，一般每一個服務(wù)都是有多個拷貝，來做負(fù)載均衡。一個服務(wù)隨時可能下線，也可能應(yīng)對臨時訪問壓力增加新的服務(wù)節(jié)點。服務(wù)之間如何相互感知？服務(wù)如何管理？
這就是服務(wù)發(fā)現(xiàn)的問題了。一般有兩類做法，也各有優(yōu)缺點。基本都是通過zookeeper等類似技術(shù)做服務(wù)注冊信息的分布式管理。當(dāng)服務(wù)上線時，服務(wù)提供者將自己的服務(wù)信息注冊到ZK（或類似框架），并通過心跳維持長鏈接，實時更新鏈接信息。服務(wù)調(diào)用者通過ZK尋址，根據(jù)可定制算法，找到一個服務(wù)，還可以將服務(wù)信息緩存在本地以提高性能。當(dāng)服務(wù)下線時，ZK會發(fā)通知給服務(wù)客戶端。
另外，SpringCloud微服務(wù)系列面試題和答案全部整理好了，微信搜索Java技術(shù)棧，在后臺發(fā)送：面試，可以在線閱讀。
客戶端做：優(yōu)點是架構(gòu)簡單，擴(kuò)展靈活，只對服務(wù)注冊器依賴。缺點是客戶端要維護(hù)所有調(diào)用服務(wù)的地址，有技術(shù)難度，一般大公司都有成熟的內(nèi)部框架支持，比如Dubbo。
服務(wù)端做：優(yōu)點是簡單，所有服務(wù)對于前臺調(diào)用方透明，一般在小公司在云服務(wù)上部署的應(yīng)用采用的比較多。
4、服務(wù)掛了，如何解決
前面提到，Monolithic方式開發(fā)一個很大的風(fēng)險是，把所有雞蛋放在一個籃子里，一榮俱榮，一損俱損。而分布式最大的特性就是網(wǎng)絡(luò)是不可靠的。通過微服務(wù)拆分能降低這個風(fēng)險，不過如果沒有特別的保障，結(jié)局肯定是噩夢。所以當(dāng)我們的系統(tǒng)是由一系列的服務(wù)調(diào)用鏈組成的時候，我們必須確保任一環(huán)節(jié)出問題都不至于影響整體鏈路。
分享給你：46張PPT弄懂JVM性能調(diào)優(yōu)！
相應(yīng)的手段有很多：
①重試機(jī)制
②限流
③熔斷機(jī)制
④負(fù)載均衡
⑤降級（本地緩存）
這些方法基本都很明確通用，比如Netflix的Hystrix：https://github.com/Netflix/Hystrix、
