微服務(wù)

微服務(wù)就是一個(gè)獨(dú)立的可部署的占有自己進(jìn)程的一個(gè)實(shí)體垦细， 我們一般把這個(gè)實(shí)體稱之為服務(wù)。 微服務(wù)的核心思維和SRP原則是一樣的： 聚合所有因?yàn)橄嗤蚨淖兊脑兀?分割那些因?yàn)椴挥迷蚨淖兊脑亍?只不過是站在更加宏觀的角度來思考的耻警。 一個(gè)微服務(wù)是完全自治的，它對(duì)外提供API, 并且自身的改變（不包括API的改變）不會(huì)影響依賴者的改變。

微服務(wù)架構(gòu)風(fēng)格是一種使用一套小服務(wù)來開發(fā)單個(gè)應(yīng)用的方式途徑沼沈，每個(gè)服務(wù)運(yùn)行在自己的進(jìn)程中丈冬，并使用輕量級(jí)機(jī)制通信嘱函，通常是HTTP API， 也可以是RPC（Remote Procedure Call—遠(yuǎn)程過程調(diào)用）埂蕊，這些服務(wù)基于業(yè)務(wù)能力構(gòu)建往弓，并能夠通過自動(dòng)化部署機(jī)制來獨(dú)立部署疏唾，這些服務(wù)使用不同的編程語言實(shí)現(xiàn)，以及不同數(shù)據(jù)存儲(chǔ)技術(shù)函似，并保持最低限度的集中式管理槐脏。

一個(gè)微服務(wù)一般完成某個(gè)特定的功能，比如下單管理缴淋、客戶管理等等准给。每一個(gè)微服務(wù)都是微型六角形應(yīng)用，都有自己的業(yè)務(wù)邏輯和適配器重抖。一些微服務(wù)還 會(huì)發(fā)布API給其它微服務(wù)和應(yīng)用客戶端使用露氮。

微服務(wù)的好處:

• 服務(wù)的異構(gòu)性 - 不同的服務(wù)可以使用不同的且適合當(dāng)前服務(wù)的技術(shù)棧，這樣的話公司也有機(jī)會(huì)在某些服務(wù)上嘗試一些新的技術(shù)

• 彈性 - 可以對(duì)錯(cuò)誤進(jìn)行隔離钟沛， 可以通過用多臺(tái)機(jī)器增加可用性畔规。

• 縮放 - 可以通過用多臺(tái)機(jī)器分擔(dān)LOAD

• 易于部署 - 部署的最小單元縮減為單個(gè)服務(wù)

• 組織架構(gòu)的安 - 就算是大公司，人員年分布在不同的地點(diǎn)甚至是國家恨统，通過微服務(wù)叁扫，我們可以把開發(fā)相同微服務(wù)的人員放在一塊。

• 可組合性 - 通過編排微服務(wù)畜埋，可以很方便的搭建客戶化的需求莫绣。

• 可替代性 - 微服務(wù)一般都很小，重寫的難度沒有那么大

微服務(wù)架構(gòu)的不足

• 『微服務(wù)』強(qiáng)調(diào)了服務(wù)大小悠鞍，實(shí)際上对室，有一些開發(fā)者鼓吹建立稍微大一些的，10-100 LOC服務(wù)組咖祭。盡管小服務(wù)更樂于被采用掩宜，但是不要忘了這只是終端的選擇而不是最終的目的。微服務(wù)的目的是有效的拆分應(yīng)用么翰，實(shí)現(xiàn)敏捷開發(fā)和部署牺汤。

• 微服務(wù)應(yīng)用是分布式系統(tǒng)，由此會(huì)帶來固有的復(fù)雜性浩嫌。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進(jìn)程間通訊機(jī)制檐迟。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題码耐。當(dāng)然這并不是什么難事追迟，但相對(duì)于單體式應(yīng)用中通過語言層級(jí)的方法或者進(jìn)程調(diào)用，微服務(wù)下這種技術(shù)顯得更復(fù)雜一些伐坏。

• 另一個(gè)關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)怔匣。商業(yè)交易中同時(shí)給多個(gè)業(yè)務(wù)分主體更新消息很普遍握联。這種交易對(duì)于單體式應(yīng)用來說很容易桦沉，因?yàn)橹挥幸粋€(gè)數(shù)據(jù)庫每瞒。在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫纯露。使用分布式交易并不一定是好的選擇剿骨，不僅僅是因?yàn)镃AP理論，還因?yàn)榻裉旄邤U(kuò)展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求埠褪。最終你不得不使用一個(gè)最終一致性的方法浓利，從而對(duì)開發(fā)者提出了更高的要求和挑戰(zhàn)。

• 測(cè)試一個(gè)基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)钞速。比如贷掖，采用流行的Spring Boot架構(gòu)，對(duì)一個(gè)單體式web應(yīng)用渴语，測(cè)試它的REST API苹威，是很容易的事情。反過來驾凶，同樣的服務(wù)測(cè)試需要啟動(dòng)和它有關(guān)的所有服務(wù)（至少需要這些服務(wù)的stubs）牙甫。再重申一次，不能低估了采用微服務(wù)架構(gòu)帶來的復(fù)雜性调违。

• 微服務(wù)架構(gòu)模式應(yīng)用的改變將會(huì)波及多個(gè)服務(wù)窟哺。比如，假設(shè)你在完成一個(gè)案例技肩，需要修改服務(wù)A且轨、B、C亩鬼，而A依賴B殖告，B依賴C。在單體式應(yīng)用中雳锋，你只需要改變相關(guān)模塊黄绩，整合變化，部署就好了玷过。對(duì)比之下爽丹，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對(duì)不同服務(wù)的影響。比如辛蚊，你需要更新服務(wù)C粤蝎，然后是B，最后才是A袋马，幸運(yùn)的是初澎，許多改變一般只影響一個(gè)服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。

hystrix 原理與應(yīng)用

微服務(wù)是解決復(fù)雜服務(wù)的一個(gè)方案碑宴，在功能不變的情況下软啼，對(duì)一個(gè)復(fù)雜的單體服務(wù)分解為多個(gè)可管理的分支。每個(gè)服務(wù)作為輕量的子服務(wù)延柠，通過RPC實(shí)現(xiàn)服務(wù)間的關(guān)聯(lián)祸挪，將服務(wù)簡(jiǎn)單化。每個(gè)服務(wù)根據(jù)自己的需要選擇技術(shù)棧贞间，互不影響贿条，方便開發(fā)、維護(hù)增热。例如S劃分為a,b,c整以。微服務(wù)的好處是有效的拆分應(yīng)用，實(shí)現(xiàn)敏捷開發(fā)和部署峻仇。
微服務(wù)一系列優(yōu)勢(shì)下悄蕾，也給微服務(wù)的管理和穩(wěn)定性帶來挑戰(zhàn)，比如一個(gè)服務(wù)依賴30個(gè)微服務(wù)础浮，每個(gè)微服務(wù)的可用性是99.999%帆调，在不加任何管理的情況下，該聚合服務(wù)的可用性將是99.999%的30次方=99.97%豆同，系統(tǒng)的可用性直接降了兩個(gè)數(shù)量級(jí)達(dá)到三個(gè)九番刊。
且由于依賴的傳遞性，很容易產(chǎn)生雪崩效應(yīng)影锈。


一個(gè)應(yīng)用中芹务，任意一個(gè)點(diǎn)的不可用或者響應(yīng)延時(shí)都有可能造成服務(wù)不可用
更可怕的是，被hang住的請(qǐng)求會(huì)很快耗盡系統(tǒng)的資源鸭廷，當(dāng)該類請(qǐng)求越來越多枣抱，占用的計(jì)算機(jī)資源越來越多的時(shí)候，會(huì)導(dǎo)致系統(tǒng)瓶頸出現(xiàn)辆床，造成其他的請(qǐng)求同樣不可用佳晶，最終導(dǎo)致業(yè)務(wù)系統(tǒng)崩潰，又稱：雪崩效應(yīng)
造成雪崩原因可以歸結(jié)為以下三個(gè)：
? 服務(wù)提供者不可用（硬件故障讼载，程序Bug轿秧，緩存擊穿，用戶大量請(qǐng)求）
? 重試加大流量（用戶重試咨堤，代碼邏輯重試）
? 服務(wù)調(diào)用者不可用（同步等待造成的資源耗盡）
? 最終的結(jié)果就是一個(gè)服務(wù)不可用導(dǎo)致一系列服務(wù)的不可用菇篡，而往往這種后果往往無法預(yù)料的。

hystrix實(shí)現(xiàn)原理

hystrix語義為“豪豬”一喘，具有自我保護(hù)的能力驱还。hystrix的出現(xiàn)即為解決雪崩效應(yīng)，它通過四個(gè)方面的機(jī)制來解決這個(gè)問題
? 隔離（線程池隔離和信號(hào)量隔離）：限制調(diào)用分布式服務(wù)的資源使用，某一個(gè)調(diào)用的服務(wù)出現(xiàn)問題不會(huì)影響其他服務(wù)調(diào)用议蟆。
? 優(yōu)雅的降級(jí)機(jī)制：超時(shí)降級(jí)灼伤、資源不足時(shí)(線程或信號(hào)量)降級(jí)，降級(jí)后可以配合降級(jí)接口返回托底數(shù)據(jù)咪鲜。
? 融斷：當(dāng)失敗率達(dá)到閥值自動(dòng)觸發(fā)降級(jí)(如因網(wǎng)絡(luò)故障/超時(shí)造成的失敗率高)，熔斷器觸發(fā)的快速失敗會(huì)進(jìn)行快速恢復(fù)撞鹉。
? 緩存：提供了請(qǐng)求緩存疟丙、請(qǐng)求合并實(shí)現(xiàn)。
? 支持實(shí)時(shí)監(jiān)控鸟雏、報(bào)警享郊、控制（修改配置）

隔離

隔離.png

（1）線程池隔離模式：使用一個(gè)線程池來存儲(chǔ)當(dāng)前的請(qǐng)求，線程池對(duì)請(qǐng)求作處理孝鹊，設(shè)置任務(wù)返回處理超時(shí)時(shí)間炊琉，堆積的請(qǐng)求堆積入線程池隊(duì)列。這種方式需要為每個(gè)依賴的服務(wù)申請(qǐng)線程池又活，有一定的資源消耗苔咪，好處是可以應(yīng)對(duì)突發(fā)流量（流量洪峰來臨時(shí)，處理不完可將數(shù)據(jù)存儲(chǔ)到線程池隊(duì)里慢慢處理）
（2）信號(hào)量隔離模式：使用一個(gè)原子計(jì)數(shù)器（或信號(hào)量）來記錄當(dāng)前有多少個(gè)線程在運(yùn)行柳骄，請(qǐng)求來先判斷計(jì)數(shù)器的數(shù)值团赏，若超過設(shè)置的最大線程個(gè)數(shù)則丟棄改類型的新請(qǐng)求，若不超過則執(zhí)行計(jì)數(shù)操作請(qǐng)求來計(jì)數(shù)器+1耐薯，請(qǐng)求返回計(jì)數(shù)器-1舔清。這種方式是嚴(yán)格的控制線程且立即返回模式，無法應(yīng)對(duì)突發(fā)流量（流量洪峰來臨時(shí)曲初，處理的線程超過數(shù)量体谒，其他的請(qǐng)求會(huì)直接返回，不繼續(xù)去請(qǐng)求依賴的服務(wù)）

區(qū)別（兩種隔離方式只能選其一）：

融斷

正常狀態(tài)下评汰，電路處于關(guān)閉狀態(tài)(Closed)，如果調(diào)用持續(xù)出錯(cuò)或者超時(shí)痢虹，電路被打開進(jìn)入熔斷狀態(tài)(Open)被去，后續(xù)一段時(shí)間內(nèi)的所有調(diào)用都會(huì)被拒絕(Fail Fast)，一段時(shí)間以后奖唯，保護(hù)器會(huì)嘗試進(jìn)入半熔斷狀態(tài)(Half-Open)惨缆，允許少量請(qǐng)求進(jìn)來嘗試，如果調(diào)用仍然失敗，則回到熔斷狀態(tài)坯墨，如果調(diào)用成功寂汇，則回到電路閉合狀態(tài);

熔斷.png

降級(jí)

在股票市場(chǎng)，熔斷這個(gè)詞大家都不陌生捣染，是指當(dāng)股指波幅達(dá)到某個(gè)點(diǎn)后骄瓣，交易所為控制風(fēng)險(xiǎn)采取的暫停交易措施。相應(yīng)的耍攘，服務(wù)熔斷一般是指軟件系統(tǒng)中榕栏，由于某些原因使得服務(wù)出現(xiàn)了過載現(xiàn)象，為防止造成整個(gè)系統(tǒng)故障蕾各，從而采用的一種保護(hù)措施扒磁，所以很多地方把熔斷亦稱為過載保護(hù)。
大家都見過女生旅行吧式曲，大號(hào)的旅行箱是必備物妨托，平常走走近處綽綽有余，但一旦出個(gè)遠(yuǎn)門吝羞，再大的箱子都白搭了兰伤，怎么辦呢？常見的情景就是把物品拿出來分分堆钧排，比了又比医清，最后一些非必需品的就忍痛放下了，等到下次箱子夠用了卖氨，再帶上用一用会烙。而服務(wù)降級(jí)，就是這么回事筒捺，整體資源快不夠了柏腻，忍痛將某些服務(wù)先關(guān)掉，待渡過難關(guān)系吭，再開啟回來五嫂。
二者的目標(biāo)是一致的，目的都是保證上游服務(wù)的穩(wěn)定性肯尺。但其關(guān)注的重點(diǎn)并不一樣沃缘，融斷對(duì)下層依賴的服務(wù)并不級(jí)（或者說孰輕孰重），一旦產(chǎn)生故障就斷掉则吟；而降級(jí)需要對(duì)下層依賴的業(yè)務(wù)分級(jí)槐臀，把產(chǎn)生故障的丟了，換一個(gè)輕量級(jí)的方案氓仲，是一種退而求其次的方法水慨。

根據(jù)業(yè)務(wù)場(chǎng)景的不同得糜，一般采用以下兩種模式：
第一種（最常用）如果服務(wù)失敗，則我們通過fallback進(jìn)行降級(jí)晰洒，返回靜態(tài)值朝抖。
第二種采用服務(wù)級(jí)聯(lián)的模式，如果第一個(gè)服務(wù)失敗谍珊，則調(diào)用備用服務(wù)治宣，例如失敗重試或者訪問緩存失敗再去取數(shù)據(jù)庫。服務(wù)級(jí)聯(lián)的目的則是盡最大努力保證返回?cái)?shù)據(jù)的成功性砌滞，但如果考慮不充分侮邀，則有可能導(dǎo)致級(jí)聯(lián)的服務(wù)崩潰（比如，緩存失敗了布持，把全部流量打到數(shù)據(jù)庫，瞬間導(dǎo)致數(shù)據(jù)庫掛掉）陕悬。因此級(jí)聯(lián)模式题暖，也要慎用，增加了管理的難度捉超。

緩存

不建議使用胧卤，對(duì)問題排查會(huì)造成很大的困擾

hystrix應(yīng)用

流程.png

• 兩個(gè)核心代理HystrixCommand,HystrixObservableCommand，任何依賴的服務(wù)只需要繼承這兩個(gè)類就可以了拼岳。其中HystrixObservableCommand使用觀察者模式（不在此介紹范圍之內(nèi)枝誊，了解請(qǐng)移步RxJava）
• HystrixCommand 可以采用同步調(diào)用和異步調(diào)用，異步返回Future對(duì)象（還未直接支持CompletebleFuture）
  如果開啟了緩存惜纸，則會(huì)根據(jù)GroupKey,Commandkey以及cachedKey確定是否存在緩存（不建議使用）
• 判斷斷路器是否開啟叶撒，開啟則直接調(diào)用getFallback,
• 判斷是否滿足信號(hào)量隔離或線程池隔離的條件，如果隔離則拋異常
• 執(zhí)行run方法
• metrics包含了一個(gè)計(jì)數(shù)器耐版，用來計(jì)算當(dāng)前服務(wù)的狀態(tài)祠够，無論是成* 功調(diào)用，還是拋異常都會(huì)記錄數(shù)據(jù)（接下來再詳細(xì)講）
  執(zhí)行降級(jí)策略

代碼實(shí)現(xiàn)

public class GetInfoFromSinaiCommand extends HystrixCommand<List<PoiInfo>> {
    private PoiClient poiClient;
    private List<Integer> poiIds;
    private static final List<String> FIELDS = ImmutableList.of("id", "cate", "subcate");

    public GetInfoFromSinaiCommand(PoiClient poiClient, List<Integer> poiIds) {
        super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("sinai"))
                //command配置
                .andCommandKey(HystrixCommandKey.Factory.asKey("GetInfoFromSinaiCommand"))
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
                        .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.THREAD))
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter().withRequestCacheEnabled(true))

                //融斷器配置
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter().withCircuitBreakerEnabled(true))
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter().withCircuitBreakerRequestVolumeThreshold(20))
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter().withCircuitBreakerSleepWindowInMilliseconds(5000))
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter().withCircuitBreakerErrorThresholdPercentage(50))

                //ThreadPool配置
                .andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("GetInfoFromSinaiCommand"))
                .andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter().withCoreSize(10))
                .andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter().withCoreSize(-1))

        );
        this.poiClient = poiClient;
        this.poiIds = poiIds;

    }

    @Override
    public List<PoiInfo> run() throws Exception {
        if (poiIds.isEmpty()) {
            return Lists.newArrayList();
        }
        List<PoiModel> pioModels = poiClient.listPois(poiIds, FIELDS);
        return parseResult(pioModels);
    }

    @Override
    protected String getCacheKey() {
        return String.valueOf(poiIds);
    }

    @Override
    protected List<PoiInfo> getFallback() {
        return Lists.newArrayList();
    }

    private List<PoiInfo> parseResult(List<PoiModel> poiModels) {
        if (poiModels == null || poiModels.isEmpty()) {
            return Lists.newArrayList();
        }
        List<PoiInfo> res = Lists.newArrayList();
        for (PoiModel poiModel : poiModels) {
            PoiInfo poiInfo = new PoiInfo();
            poiInfo.setPoiId(poiModel.getId());

            if (poiModel.getCate() != null) {
                poiInfo.setCate(poiModel.getCate());
            }
            if (poiModel.getSubcate() != null) {
                poiInfo.setSubcate(poiModel.getSubcate());
            }
            res.add(poiInfo);
        }
        return res;
    }
}

參數(shù)說明

1.command配置 executionIsolationStrategy ExecutionIsolationStrategy.THREAD 信號(hào)隔離或線程隔離粪牲，默認(rèn):采用線程隔離,

2.熔斷器配置
executionIsolationThreadTimeoutInMillisecond 1s 隔離時(shí)間大古瓤，即多長(zhǎng)時(shí)間后進(jìn)行重試
executionIsolationSemaphoreMaxConcurrentRequests 10 使用信號(hào)量隔離時(shí)，命令調(diào)用最大的并發(fā)數(shù),默認(rèn):10
fallbackIsolationSemaphoreMaxConcurrentRequests 10 使用信號(hào)量隔離時(shí)腺阳，命令fallback(降級(jí))調(diào)用最大的并發(fā)數(shù),默認(rèn):10
fallbackEnabled true 是否開啟fallback降級(jí)策略
executionIsolationThreadInterruptOnTimeout true 使用線程隔離時(shí)落君，是否對(duì)命令執(zhí)行超時(shí)的線程調(diào)用中斷（Thread.interrupt()）操作
metricsRollingStatisticalWindowInMilliseconds 10000ms 統(tǒng)計(jì)滾動(dòng)的時(shí)間窗口,默認(rèn):10s
metricsRollingStatisticalWindowBuckets 10 統(tǒng)計(jì)窗口的Buckets的數(shù)量,默認(rèn):10個(gè)
metricsRollingPercentileEnabled true 是否開啟監(jiān)控統(tǒng)計(jì)功能,默認(rèn):true
requestLogEnabled true 是否開啟請(qǐng)求日志
requestCacheEnabled true 是否開啟請(qǐng)求緩存
circuitBreakerRequestVolumeThreshold 20 主要用在小流量
circuitBreakerSleepWindowInMilliseconds 5000ms 熔斷器默認(rèn)工作時(shí)間,默認(rèn):5秒.熔斷器中斷請(qǐng)求5秒后會(huì)進(jìn)入半打開狀態(tài),放部分流量過去重試
circuitBreakerEnabled true 是否啟用熔斷器,默認(rèn)true. 啟動(dòng)
circuitBreakerErrorThresholdPercentage 50 默認(rèn):50%。當(dāng)出錯(cuò)率超過50%后熔斷器啟動(dòng)
circuitBreakerForceOpen false 是否強(qiáng)制開啟熔斷器阻斷所有請(qǐng)求,默認(rèn):false,不開啟
circuitBreakerForceClosed false 是否允許熔斷器忽略錯(cuò)誤,默認(rèn)false, 不開啟

3.線程池配置 HystrixThreadPoolProperties.Setter().withCoreSize(int value) 10 配置線程池大小,默認(rèn)值10個(gè)
HystrixThreadPoolProperties.Setter().withMaxQueueSize(int value) -1 配置線程值等待隊(duì)列長(zhǎng)度

監(jiān)控上報(bào)

Hystrix高級(jí)特性

RequestCache和RequestCollapsing是Hystrix高級(jí)的特性亭引，一般來說绎速，我們會(huì)在Request 范圍內(nèi)使用這些高級(jí)特性，需要先初始化HystrixRequestContext進(jìn)行生命周期的管理焙蚓，在標(biāo)準(zhǔn)Web應(yīng)用中我們可以借助過濾器來解決這個(gè)問題 朝氓。

RequestCache

RequestCache實(shí)現(xiàn)及使用方式：
假設(shè)兩個(gè)線程發(fā)起相同的HTTP請(qǐng)求魔市，Hystrix會(huì)把請(qǐng)求參數(shù)初始化到ThreadLocal中，兩個(gè)Command異步執(zhí)行赵哲，每個(gè)Command會(huì)把請(qǐng)求參數(shù)從ThreadLocal中拷貝到Command所在自身的線程中待德，Command在執(zhí)行的時(shí)候會(huì)通過CacheKey優(yōu)先從緩存中嘗試獲取是否已有緩存結(jié)果，如果命中枫夺，直接從HystrixRequestCache返回将宪，如果沒有命中，那么需要進(jìn)行一次真實(shí)調(diào)用橡庞，然后把結(jié)果回寫到緩存中较坛，在請(qǐng)求范圍內(nèi)共享響應(yīng)結(jié)果。

主要有三個(gè)優(yōu)點(diǎn)：

• 在當(dāng)次請(qǐng)求內(nèi)對(duì)同一個(gè)依賴進(jìn)行重復(fù)調(diào)用扒最，只會(huì)真實(shí)調(diào)用一次丑勤。
• 在當(dāng)次請(qǐng)求內(nèi)數(shù)據(jù)可以保證一致性。
• 可以減少不必要的線程開銷吧趣。

Hystrix通過實(shí)現(xiàn)getCacheKey方法來激活緩存機(jī)制法竞；