今天就跟大家聊聊有關(guān)PHP中怎么實(shí)現(xiàn)一個(gè)微服務(wù)，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

創(chuàng)新互聯(lián)建站專注于大冶企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,商城網(wǎng)站制作。大冶網(wǎng)站建設(shè)公司,為大冶等地區(qū)提供建站服務(wù)。全流程按需求定制網(wǎng)站，專業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務(wù)

單一應(yīng)用的解決方案

對(duì)于一個(gè)大型的互聯(lián)網(wǎng)系統(tǒng)，一般會(huì)包含多個(gè)應(yīng)用，而且應(yīng)用之間往往還存在共同的業(yè)務(wù)，并且應(yīng)用之間還存在調(diào)用關(guān)系。除此之外 ，對(duì)于大型的互聯(lián)網(wǎng)系統(tǒng)還有一些其它的挑戰(zhàn)，比如如何應(yīng)對(duì)急劇增長(zhǎng)的用戶，如何管理好研發(fā)團(tuán)隊(duì)快速迭代產(chǎn)品研發(fā)，如何保持產(chǎn)品升級(jí)更加穩(wěn)定等等 。

因此，為了使業(yè)務(wù)得到很好的復(fù)用，模塊更加容易拓展和維護(hù)，我們希望業(yè)務(wù)與應(yīng)用分離，某個(gè)業(yè)務(wù)不再屬于一個(gè)應(yīng)用，而是作為一個(gè)獨(dú)立的服務(wù)單獨(dú)進(jìn)行維護(hù)。應(yīng)用本身不再是一個(gè)臃腫的模塊堆積，而是由一個(gè)個(gè)模塊化的服務(wù)組件組合而成。

服務(wù)化

特點(diǎn)

那么采用服務(wù)化給有那些亮點(diǎn)的特色呢 ?

應(yīng)用按業(yè)務(wù)拆分成服務(wù)

各個(gè)服務(wù)均可獨(dú)立部署

服務(wù)可被多個(gè)應(yīng)用共享

服務(wù)之間可以通信

架構(gòu)上系統(tǒng)更加清晰

核心模塊穩(wěn)定，以服務(wù)組件為單位進(jìn)行升級(jí)，避免了頻繁發(fā)布帶來(lái)的風(fēng)險(xiǎn)

開(kāi)發(fā)管理方便

單獨(dú)團(tuán)隊(duì)維護(hù)、工作分明，職責(zé)清晰

業(yè)務(wù)復(fù)用、代碼復(fù)用

非常容易拓展

服務(wù)化面臨的挑戰(zhàn)

系統(tǒng)服務(wù)化之后, 增加了依賴關(guān)系復(fù)雜, 也會(huì)增加服務(wù)與服務(wù)之間交互的次數(shù). 在 fpm 的開(kāi)發(fā)模式下. 因?yàn)闊o(wú)法常駐內(nèi)存給我們帶來(lái)了, 每一次請(qǐng)求都要從零開(kāi)始加載到退出進(jìn)程, 增加了很多無(wú)用的開(kāi)銷, 數(shù)據(jù)庫(kù)連接無(wú)法復(fù)用也得不到保護(hù), 由于fpm是以進(jìn)程為單位的fpm的進(jìn)程數(shù)也決定了并發(fā)數(shù), 這也是是fpm開(kāi)發(fā)簡(jiǎn)單給我們帶來(lái)的問(wèn)題. 所以說(shuō)為什么現(xiàn)在互聯(lián)網(wǎng)平臺(tái)Java比較流行了，.NET和PHP在這方面都不行。PHP非內(nèi)存常駐的就不用說(shuō)了。除此之外，還有很多其他問(wèn)題需要解決。

那么有沒(méi)有好的方案呢？答案是有的，它就是-Swoft。Swoft就是一個(gè)帶有服務(wù)治理功能的RPC框架。Swoft是首個(gè) PHP常駐內(nèi)存協(xié)程全?？蚣? 基于高性能協(xié)程swoole打造的一個(gè) PHP界的Spring Boot

Swoft 提供了類似 Dubbo 更為優(yōu)雅的方式使用 RPC 服務(wù), Swoft 性能是非常棒的有著類似Golang性能, 下面是 對(duì)Swoft 性能的壓測(cè)情況.

ab壓力測(cè)試處理速度十分驚人, 在 i78代CPU, 16GB 內(nèi)存下100000萬(wàn)個(gè)請(qǐng)求只用了5s時(shí)間在fpm開(kāi)發(fā)模式下基本不可能達(dá)到. 這也足以證明Swoft` 的高性能和穩(wěn)定性,

優(yōu)雅的服務(wù)治理

服務(wù)注冊(cè)與發(fā)現(xiàn)

微服務(wù)治理過(guò)程中，經(jīng)常會(huì)涉及注冊(cè)啟動(dòng)的服務(wù)到第三方集群，比如 consul / etcd 等等，以 Swoft 框架中使用 swoft-consul 組件，實(shí)現(xiàn)服務(wù)注冊(cè)與發(fā)現(xiàn)為例。

實(shí)現(xiàn)邏輯

agent->services();

        $services = [
        
        ];

        return $services;
    }
}

服務(wù)熔斷

在分布式環(huán)境下，特別是微服務(wù)結(jié)構(gòu)的分布式系統(tǒng)中， 一個(gè)軟件系統(tǒng)調(diào)用另外一個(gè)遠(yuǎn)程系統(tǒng)是非常普遍的。這種遠(yuǎn)程調(diào)用的被調(diào)用方可能是另外一個(gè)進(jìn)程，或者是跨網(wǎng)路的另外一臺(tái)主機(jī), 這種遠(yuǎn)程的調(diào)用和進(jìn)程的內(nèi)部調(diào)用最大的區(qū)別是，遠(yuǎn)程調(diào)用可能會(huì)失敗，或者掛起而沒(méi)有任何回應(yīng)，直到超時(shí)。更壞的情況是， 如果有多個(gè)調(diào)用者對(duì)同一個(gè)掛起的服務(wù)進(jìn)行調(diào)用，那么就很有可能的是一個(gè)服務(wù)的超時(shí)等待迅速蔓延到整個(gè)分布式系統(tǒng)，引起連鎖反應(yīng)， 從而消耗掉整個(gè)分布式系統(tǒng)大量資源。最終可能導(dǎo)致系統(tǒng)癱瘓。

斷路器（Circuit Breaker）模式就是為了防止在分布式系統(tǒng)中出現(xiàn)這種瀑布似的連鎖反應(yīng)導(dǎo)致的災(zāi)難。

基本的斷路器模式下，保證了斷路器在open狀態(tài)時(shí)，保護(hù)supplier不會(huì)被調(diào)用， 但我們還需要額外的措施可以在supplier恢復(fù)服務(wù)后，可以重置斷路器。一種可行的辦法是斷路器定期探測(cè)supplier的服務(wù)是否恢復(fù)， 一但恢復(fù)， 就將狀態(tài)設(shè)置成close。斷路器進(jìn)行重試時(shí)的狀態(tài)為半開(kāi)（half-open）狀態(tài)。

熔斷器的使用想到簡(jiǎn)單且功能強(qiáng)大，使用一個(gè) @Breaker 注解即可，Swoft 的熔斷器可以用于任何場(chǎng)景, 例如 服務(wù)調(diào)用的時(shí)候使用, 請(qǐng)求第三方的時(shí)候都可以對(duì)它進(jìn)行熔斷降級(jí)

服務(wù)限流
限流、熔斷、降級(jí)這個(gè)強(qiáng)調(diào)多少遍都不過(guò)分，因?yàn)榇_實(shí)很重要。服務(wù)不行的時(shí)候一定要熔斷。限流是一個(gè)保護(hù)自己最大的利器，如果沒(méi)有自我保護(hù)機(jī)制，不管有多少連接都會(huì)接收，如果后端處理不過(guò)來(lái)，前端流量又很大的時(shí)候肯定就掛了。
限流是對(duì)稀缺資源訪問(wèn)時(shí)，比如秒殺，搶購(gòu)的商品時(shí)，來(lái)限制并發(fā)和請(qǐng)求的數(shù)量，從而有效的進(jìn)行削峰并使得流量曲線平滑。限流的目的是對(duì)并發(fā)訪問(wèn)和并發(fā)請(qǐng)求進(jìn)行限速，或者一個(gè)時(shí)間窗口內(nèi)請(qǐng)求進(jìn)行限速?gòu)亩鴣?lái)保護(hù)系統(tǒng)，一旦達(dá)到或超過(guò)限制速率就可以拒絕服務(wù)，或者進(jìn)行排隊(duì)等待等。
Swoft 限流器底層采用的是令牌桶算法，底層依賴于 redis 實(shí)現(xiàn)分布式限流。
Swoft 限速器不僅可以限流控制器，也可以限制任何 bean 里面的方法，可以控制方法的訪問(wèn)速率。這里以下面使用示例詳解
getUriPath();
        return ['requestLimiter2', $uri];
    }
    
    /**
     * @param Request $request
     *
     * @return array
     */
    public function limiterFallback(Request $request): array
    {
        $uri = $request->getUriPath();
        return ['limiterFallback', $uri];
    }
}
key 這里支持 symfony/expression-language 表達(dá)式， 如果被限速會(huì)調(diào)用 fallback中定義的limiterFallback 方法
配置中心
說(shuō)起配置中心前我們先說(shuō)說(shuō)配置文件，我們并不陌生，它提供我們可以動(dòng)態(tài)修改程序運(yùn)行能力。引用別人的一句話就是：
系統(tǒng)運(yùn)行時(shí)(runtime)飛行姿態(tài)的動(dòng)態(tài)調(diào)整！
我可以把我們的工作稱之為在快速飛行的飛機(jī)上修理零件。我們?nèi)祟惪偸菬o(wú)法掌控和預(yù)知一切。對(duì)于我們系統(tǒng)來(lái)說(shuō)，我們總是需要預(yù)留一些控制線條，以便在我們需要的時(shí)候做出調(diào)整，控制系統(tǒng)方向（如灰度控制、限流調(diào)整），這對(duì)于擁抱變化的互聯(lián)網(wǎng)行業(yè)尤為重要。
對(duì)于單機(jī)版，我們稱之為配置（文件）；對(duì)于分布式集群系統(tǒng)，我們稱之為配置中心（系統(tǒng)）;
到底什么是分布式配置中心
隨著業(yè)務(wù)的發(fā)展、微服務(wù)架構(gòu)的升級(jí)，服務(wù)的數(shù)量、程序的配置日益增多（各種微服務(wù)、各種服務(wù)器地址、各種參數(shù)），傳統(tǒng)的配置文件方式和數(shù)據(jù)庫(kù)的方式已無(wú)法滿足開(kāi)發(fā)人員對(duì)配置管理的要求：
安全性：配置跟隨源代碼保存在代碼庫(kù)中，容易造成配置泄漏；
時(shí)效性：修改配置，需要重啟服務(wù)才能生效；
局限性：無(wú)法支持動(dòng)態(tài)調(diào)整：例如日志開(kāi)關(guān)、功能開(kāi)關(guān)；
因此，我們需要配置中心來(lái)統(tǒng)一管理配置！把業(yè)務(wù)開(kāi)發(fā)者從復(fù)雜以及繁瑣的配置中解脫出來(lái)，只需專注于業(yè)務(wù)代碼本身，從而能夠顯著提升開(kāi)發(fā)以及運(yùn)維效率。同時(shí)將配置和發(fā)布包解藕也進(jìn)一步提升發(fā)布的成功率，并為運(yùn)維的細(xì)力度管控、應(yīng)急處理等提供強(qiáng)有力的支持。
關(guān)于分布式配置中心，網(wǎng)上已經(jīng)有很多開(kāi)源的解決方案，例如：
Apollo是攜程框架部門研發(fā)的分布式配置中心，能夠集中化管理應(yīng)用不同環(huán)境、不同集群的配置，配置修改后能夠?qū)崟r(shí)推送到應(yīng)用端，并且具備規(guī)范的權(quán)限、流程治理等特性，適用于微服務(wù)配置管理場(chǎng)景。
以Apollo 為例，從遠(yuǎn)端配置中心拉取配置以及安全重啟服務(wù)。如果對(duì) Apollo 不熟悉，可以先看Swoft 擴(kuò)展 Apollo 組件以及閱讀 Apollo 官方文檔。
以 Swoft 中使用 Apollo 為例，當(dāng) Apollo 配置變更后，重啟服務(wù)(http-server / rpc-server/ ws-server)。如下是一個(gè) agent 例子：
config->pull('application');
        
        // Print data
        var_dump($data);
    }
}
看完上述內(nèi)容，你們對(duì)PHP中怎么實(shí)現(xiàn)一個(gè)微服務(wù)有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。
            
            
                        

            分享名稱：PHP中怎么實(shí)現(xiàn)一個(gè)微服務(wù)            

            本文網(wǎng)址：http://weahome.cn/article/gocgsg.html