摘要:數(shù)據(jù)的去中心化,進(jìn)一步降低了微服務(wù)之間的耦合度,不同服務(wù)可以采用不同的數(shù)據(jù)庫(kù)技術(shù)等。微服務(wù)架構(gòu)是持續(xù)交付的巨大推動(dòng)力,允許在頻繁發(fā)布不同服務(wù)的同時(shí)保持系統(tǒng)其他部分的可用性和穩(wěn)定性。
什么是微服務(wù)?
微服務(wù)(Microservices Architecture)是一種架構(gòu)風(fēng)格,一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署,各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下,每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)能力。
微服務(wù)的概念源于2014年3月Martin Fowler所寫的文章“Microservices”http://martinfowler.com/articles/microservices.html
單體架構(gòu)(Monolithic Architecture )企業(yè)級(jí)的應(yīng)用一般都會(huì)面臨各種各樣的業(yè)務(wù)需求,而常見(jiàn)的方式是把大量功能堆積到同一個(gè)單體架構(gòu)中去。比如:常見(jiàn)的ERP、CRM等系統(tǒng)都以單體架構(gòu)的方式運(yùn)行,同時(shí)由于提供了大量的業(yè)務(wù)功能,隨著功能的升級(jí),整個(gè)研發(fā)、發(fā)布、定位問(wèn)題,擴(kuò)展,升級(jí)這樣一個(gè)“怪物”系統(tǒng)會(huì)變得越來(lái)越困難。
這種架構(gòu)模式就是把應(yīng)用整體打包部署,具體的樣式依賴本身應(yīng)用采用的語(yǔ)言,如果采用java語(yǔ)言,自然你會(huì)打包成war包,部署在Tomcat或者Jetty這樣的應(yīng)用服務(wù)器上,如果你使用spring boot還可以打包成jar包部署。其他還有Rails和Node.js應(yīng)用以目錄層次的形式打包
上圖:?jiǎn)误w架構(gòu)
大部分企業(yè)通過(guò)SOA來(lái)解決上述問(wèn)題,SOA的思路是把應(yīng)用中相近的功能聚合到一起,以服務(wù)的形式提供出去。因此基于SOA架構(gòu)的應(yīng)用可以理解為一批服務(wù)的組合。SOA帶來(lái)的問(wèn)題是,引入了大量的服務(wù)、消息格式定義和規(guī)范。
多數(shù)情況下,SOA的服務(wù)直接相互獨(dú)立,但是部署在同一個(gè)運(yùn)行環(huán)境中(類似于一個(gè)Tomcat實(shí)例下,運(yùn)行了很多web應(yīng)用)。和單體架構(gòu)類似,隨著業(yè)務(wù)功能的增多SOA的服務(wù)會(huì)變得越來(lái)越復(fù)雜,本質(zhì)上看沒(méi)有因?yàn)槭褂肧OA而變的更好。圖1,是一個(gè)包含多種服務(wù)的在線零售網(wǎng)站,所有的服務(wù)部署在一個(gè)運(yùn)行環(huán)境中,是一個(gè)典型的單體架構(gòu)。
單體架構(gòu)的應(yīng)用一般有以下特點(diǎn):
設(shè)計(jì)、開(kāi)發(fā)、部署為一個(gè)多帶帶的單元。
會(huì)變得越來(lái)越復(fù)雜,最后導(dǎo)致維護(hù)、升級(jí)、新增功能變得異常困難
很難以敏捷研發(fā)模式進(jìn)行開(kāi)發(fā)和發(fā)布
部分更新,都需要重新部署整個(gè)應(yīng)用
水平擴(kuò)展:必須以應(yīng)用為單位進(jìn)行擴(kuò)展,在資源需求有沖突時(shí)擴(kuò)展變得比較困難(部分服務(wù)需要更多的計(jì)算資源,部分需要更多內(nèi)存資源)
可用性:一個(gè)服務(wù)的不穩(wěn)定會(huì)導(dǎo)致整個(gè)應(yīng)用出問(wèn)題
創(chuàng)新困難:很難引入新的技術(shù)和框架,所有的功能都構(gòu)建在同質(zhì)的框架之上
運(yùn)維困難:變更或升級(jí)的影響分析困難,任何一個(gè)小修改都可能導(dǎo)致單體應(yīng)用整體運(yùn)行出現(xiàn)故障。
微服務(wù)架構(gòu)(Microservices Architecture)微服務(wù)架構(gòu)的核心思想是,一個(gè)應(yīng)用是由多個(gè)小的、相互獨(dú)立的、微服務(wù)組成,這些服務(wù)運(yùn)行在自己的進(jìn)程中,開(kāi)發(fā)和發(fā)布都沒(méi)有依賴。不同服務(wù)通過(guò)一些輕量級(jí)交互機(jī)制來(lái)通信,例如 RPC、HTTP 等,服務(wù)可獨(dú)立擴(kuò)展伸縮,每個(gè)服務(wù)定義了明確的邊界,不同的服務(wù)甚至可以采用不同的編程語(yǔ)言來(lái)實(shí)現(xiàn),由獨(dú)立的團(tuán)隊(duì)來(lái)維護(hù)。簡(jiǎn)單的來(lái)說(shuō),一個(gè)系統(tǒng)的不同模塊轉(zhuǎn)變成不同的服務(wù)!而且服務(wù)可以使用不同的技術(shù)加以實(shí)現(xiàn)!
上圖:微服務(wù)架構(gòu)
微服務(wù)設(shè)計(jì)那我們?cè)谖⒎?wù)中應(yīng)該怎樣設(shè)計(jì)呢。以下是微服務(wù)的設(shè)計(jì)指南:
職責(zé)單一原則(Single Responsibility Principle):把某一個(gè)微服務(wù)的功能聚焦在特定業(yè)務(wù)或者有限的范圍內(nèi)會(huì)有助于敏捷開(kāi)發(fā)和服務(wù)的發(fā)布。
設(shè)計(jì)階段就需要把業(yè)務(wù)范圍進(jìn)行界定。
需要關(guān)心微服務(wù)的業(yè)務(wù)范圍,而不是服務(wù)的數(shù)量和規(guī)模盡量小。數(shù)量和規(guī)模需要依照業(yè)務(wù)功能而定。
于SOA不同,某個(gè)微服務(wù)的功能、操作和消息協(xié)議盡量簡(jiǎn)單。
項(xiàng)目初期把服務(wù)的范圍制定相對(duì)寬泛,隨著深入,進(jìn)一步重構(gòu)服務(wù),細(xì)分微服務(wù)是個(gè)很好的做法。
微服務(wù)消息在單體架構(gòu)中,不同功能之間通信通過(guò)方法調(diào)用,或者跨語(yǔ)言通信。SOA降低了這種語(yǔ)言直接的耦合度,采用基于SOAP協(xié)議的web服務(wù)。這種web服務(wù)的功能和消息體定義都十分復(fù)雜,微服務(wù)需要更輕量的機(jī)制。
同步消息 REST同步消息就是客戶端需要保持等待,直到服務(wù)器返回應(yīng)答。REST是微服務(wù)中默認(rèn)的同步消息方式,它提供了基于HTTP協(xié)議和資源API風(fēng)格的簡(jiǎn)單消息格式,多數(shù)微服務(wù)都采用這種方式(每個(gè)功能代表了一個(gè)資源和對(duì)應(yīng)的操作)
異步消息 – AMQP, STOMP, MQTT異步消息就是客戶端不需要一直等待服務(wù)應(yīng)答,有應(yīng)到后會(huì)得到通知。某些微服務(wù)需要用到異步消息,一般采用AMQP, STOMP, MQTT 這三種通訊協(xié)議
消息格式 – JSON, XML, Thrift, ProtoBuf, Avro消息格式是微服務(wù)中另外一個(gè)很重要的因素。SOA的web服務(wù)一般采用文本消息,基于復(fù)雜的消息格式(SOAP)和消息定義(xsd)。微服務(wù)采用簡(jiǎn)單的文本協(xié)議JSON和XML,基于HTTP的資源API風(fēng)格。如果需要二進(jìn)制,通過(guò)用到Thrift, ProtoBuf, Avro。
服務(wù)約定 – 定義接口 – Swagger, RAML, Thrift IDL如果把功能實(shí)現(xiàn)為服務(wù),并發(fā)布,需要定義一套約定。單體架構(gòu)中,SOA采用WSDL,WSDL過(guò)于復(fù)雜并且和SOAP緊耦合,不適合微服務(wù)。
REST設(shè)計(jì)的微服務(wù),通常采用Swagger和RAML定義約定。
對(duì)于不是基于REST設(shè)計(jì)的微服務(wù),比如Thrift,通常采用IDL(Interface Definition Languages),比如Thrift IDL。
微服務(wù)集成 (服務(wù)間通信)大部分微服務(wù)基于RPC、HTTP、JSON這樣的標(biāo)準(zhǔn)協(xié)議,集成不同標(biāo)準(zhǔn)和格式變的不再重要。另外一個(gè)選擇是采用輕量級(jí)的消息總線或者網(wǎng)關(guān),有路由功能,沒(méi)有復(fù)雜的業(yè)務(wù)邏輯。下面就介紹幾種常見(jiàn)的架構(gòu)方式。
點(diǎn)對(duì)點(diǎn)方式點(diǎn)對(duì)點(diǎn)方式中,服務(wù)之間直接用。每個(gè)微服務(wù)都開(kāi)放REST API,并且調(diào)用其它微服務(wù)的接口。
上圖:通過(guò)點(diǎn)對(duì)點(diǎn)方式通信
很明顯,在比較簡(jiǎn)單的微服務(wù)應(yīng)用場(chǎng)景下,這種方式還可行,隨著應(yīng)用復(fù)雜度的提升,會(huì)變得越來(lái)越不可維護(hù)。這點(diǎn)有些類似SOA的ESB,盡量不采用點(diǎn)對(duì)點(diǎn)的集成方式。
API-網(wǎng)關(guān)方式API網(wǎng)關(guān)方式的核心要點(diǎn)是,所有的客戶端和消費(fèi)端都通過(guò)統(tǒng)一的網(wǎng)關(guān)接入微服務(wù),在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能個(gè)。通常,網(wǎng)關(guān)也是提供REST/HTTP的訪問(wèn)API。服務(wù)端通過(guò)API-GW注冊(cè)和管理服務(wù)。
上圖:通過(guò)API-網(wǎng)關(guān)暴露微服務(wù)
所有的業(yè)務(wù)接口通過(guò)API網(wǎng)關(guān)暴露,是所有客戶端接口的唯一入口。微服務(wù)之間的通信也通過(guò)API網(wǎng)關(guān)。
采用網(wǎng)關(guān)方式有如下優(yōu)勢(shì):
有能力為微服務(wù)接口提供網(wǎng)關(guān)層次的抽象。比如:微服務(wù)的接口可以各種各樣,在網(wǎng)關(guān)層,可以對(duì)外暴露統(tǒng)一的規(guī)范接口。
輕量的消息路由、格式轉(zhuǎn)換。
統(tǒng)一控制安全、監(jiān)控、限流等非業(yè)務(wù)功能。
每個(gè)微服務(wù)會(huì)變得更加輕量,非業(yè)務(wù)功能個(gè)都在網(wǎng)關(guān)層統(tǒng)一處理,微服務(wù)只需要關(guān)注業(yè)務(wù)邏輯
目前,API網(wǎng)關(guān)方式應(yīng)該是微服務(wù)架構(gòu)中應(yīng)用最廣泛的設(shè)計(jì)模式。
消息代理方式微服務(wù)也可以集成在異步的場(chǎng)景下,通過(guò)隊(duì)列和訂閱主題,實(shí)現(xiàn)消息的發(fā)布和訂閱。一個(gè)微服務(wù)可以是消息的發(fā)布者,把消息通過(guò)異步的方式發(fā)送到隊(duì)列或者訂閱主題下。作為消費(fèi)者的微服務(wù)可以從隊(duì)列或者主題共獲取消息。通過(guò)消息中間件把服務(wù)之間的直接調(diào)用解耦。
上圖:異步通信方式
通常異步的生產(chǎn)者/消費(fèi)者模式,通過(guò)AMQP, STOMP, MQTT 等異步消息通訊協(xié)議規(guī)范。
數(shù)據(jù)的去中心化單體架構(gòu)中,不同功能的服務(wù)模塊都把數(shù)據(jù)存儲(chǔ)在某個(gè)中心數(shù)據(jù)庫(kù)中。
每個(gè)微服務(wù)有自己私有的數(shù)據(jù)庫(kù),其它微服務(wù)不能直接訪問(wèn)。單體架構(gòu),用一個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)所有數(shù)據(jù)
微服務(wù)方式,多個(gè)服務(wù)之間的設(shè)計(jì)相互獨(dú)立,數(shù)據(jù)也應(yīng)該相互獨(dú)立(比如,某個(gè)微服務(wù)的數(shù)據(jù)庫(kù)結(jié)構(gòu)定義方式改變,可能會(huì)中斷其它服務(wù))。因此,每個(gè)微服務(wù)都應(yīng)該有自己的數(shù)據(jù)庫(kù)。
每個(gè)微服務(wù)有自己私有的數(shù)據(jù)庫(kù),其它微服務(wù)不能直接訪問(wèn)。每個(gè)微服務(wù)有自己私有的數(shù)據(jù)庫(kù),其它微服務(wù)不能直接訪問(wèn)。
數(shù)據(jù)去中心話的核心要點(diǎn):
每個(gè)微服務(wù)有自己私有的數(shù)據(jù)庫(kù)持久化業(yè)務(wù)數(shù)據(jù)
每個(gè)微服務(wù)只能訪問(wèn)自己的數(shù)據(jù)庫(kù),而不能訪問(wèn)其它服務(wù)的數(shù)據(jù)庫(kù)
某些業(yè)務(wù)場(chǎng)景下,需要在一個(gè)事務(wù)中更新多個(gè)數(shù)據(jù)庫(kù)。這種情況也不能直接訪問(wèn)其它微服務(wù)的數(shù)據(jù)庫(kù),而是通過(guò)對(duì)于微服務(wù)進(jìn)行操作。
數(shù)據(jù)的去中心化,進(jìn)一步降低了微服務(wù)之間的耦合度,不同服務(wù)可以采用不同的數(shù)據(jù)庫(kù)技術(shù)(SQL、NoSQL等)。在復(fù)雜的業(yè)務(wù)場(chǎng)景下,如果包含多個(gè)微服務(wù),通常在客戶端或者中間層(網(wǎng)關(guān))處理。
微服務(wù)架構(gòu)的優(yōu)點(diǎn):每個(gè)服務(wù)都比較簡(jiǎn)單,只關(guān)注于一個(gè)業(yè)務(wù)功能。
微服務(wù)架構(gòu)方式是松耦合的,可以提供更高的靈活性。
微服務(wù)可通過(guò)最佳及最合適的不同的編程語(yǔ)言與工具進(jìn)行開(kāi)發(fā),能夠做到有的放矢地解決針對(duì)性問(wèn)題。
每個(gè)微服務(wù)可由不同團(tuán)隊(duì)獨(dú)立開(kāi)發(fā),互不影響,加快推出市場(chǎng)的速度。
微服務(wù)架構(gòu)是持續(xù)交付(CD)的巨大推動(dòng)力,允許在頻繁發(fā)布不同服務(wù)的同時(shí)保持系統(tǒng)其他部分的可用性和穩(wěn)定性。
微服務(wù)架構(gòu)的缺點(diǎn):微服務(wù)的一些想法在實(shí)踐上是好的,但當(dāng)整體實(shí)現(xiàn)時(shí)也會(huì)呈現(xiàn)出其復(fù)雜性。
運(yùn)維開(kāi)銷及成本增加:整體應(yīng)用可能只需部署至一小片應(yīng)用服務(wù)區(qū)集群,而微服務(wù)架構(gòu)可能變成需要構(gòu)建/測(cè)試/部署/運(yùn)行數(shù)十個(gè)獨(dú)立的服務(wù),并可能需要支持多種語(yǔ)言和環(huán)境。這導(dǎo)致一個(gè)整體式系統(tǒng)如果由20個(gè)微服務(wù)組成,可能需要40~60個(gè)進(jìn)程。
必須有堅(jiān)實(shí)的DevOps開(kāi)發(fā)運(yùn)維一體化技能:開(kāi)發(fā)人員需要熟知運(yùn)維與投產(chǎn)環(huán)境,開(kāi)發(fā)人員也需要掌握必要的數(shù)據(jù)存儲(chǔ)技術(shù)如NoSQL,具有較強(qiáng)DevOps技能的人員比較稀缺,會(huì)帶來(lái)招聘人才方面的挑戰(zhàn)。
隱式接口及接口匹配問(wèn)題:把系統(tǒng)分為多個(gè)協(xié)作組件后會(huì)產(chǎn)生新的接口,這意味著簡(jiǎn)單的交叉變化可能需要改變?cè)S多組件,并需協(xié)調(diào)一起發(fā)布。在實(shí)際環(huán)境中,一個(gè)新品發(fā)布可能被迫同時(shí)發(fā)布大量服務(wù),由于集成點(diǎn)的大量增加,微服務(wù)架構(gòu)會(huì)有更高的發(fā)布風(fēng)險(xiǎn)。
代碼重復(fù):某些底層功能需要被多個(gè)服務(wù)所用,為了避免將“同步耦合引入到系統(tǒng)中”,有時(shí)需要向不同服務(wù)添加一些代碼,這就會(huì)導(dǎo)致代碼重復(fù)。
分布式系統(tǒng)的復(fù)雜性:作為一種分布式系統(tǒng),微服務(wù)引入了復(fù)雜性和其他若干問(wèn)題,例如網(wǎng)絡(luò)延遲、容錯(cuò)性、消息序列化、不可靠的網(wǎng)絡(luò)、異步機(jī)制、版本化、差異化的工作負(fù)載等,開(kāi)發(fā)人員需要考慮以上的分布式系統(tǒng)問(wèn)題。
異步機(jī)制:微服務(wù)往往使用異步編程、消息與并行機(jī)制,如果應(yīng)用存在跨微服務(wù)的事務(wù)性處理,事務(wù)的實(shí)現(xiàn)更具挑戰(zhàn)性,其實(shí)現(xiàn)機(jī)制會(huì)變得復(fù)雜化。
可測(cè)性的挑戰(zhàn):在動(dòng)態(tài)環(huán)境下服務(wù)間的交互會(huì)產(chǎn)生非常微妙的行為,難以可視化及全面測(cè)試。經(jīng)典微服務(wù)往往不太重視測(cè)試,更多的是通過(guò)監(jiān)控發(fā)現(xiàn)生產(chǎn)環(huán)境的異常,進(jìn)而快速回滾或采取其他必要的行動(dòng)。但對(duì)于特別在意風(fēng)險(xiǎn)規(guī)避監(jiān)管或投產(chǎn)環(huán)境錯(cuò)誤會(huì)產(chǎn)生顯著影響的場(chǎng)景下需要特別注意。
關(guān)于微服務(wù)架構(gòu)的取舍在合適的項(xiàng)目,合適的團(tuán)隊(duì),采用微服務(wù)架構(gòu)收益會(huì)大于成本。
微服務(wù)架構(gòu)有很多吸引人的地方,但在擁抱微服務(wù)之前,也需要認(rèn)清它所帶來(lái)的挑戰(zhàn)。
需要避免為了“微服務(wù)”而“微服務(wù)”。
微服務(wù)架構(gòu)引入策略 – 對(duì)傳統(tǒng)企業(yè)而言,開(kāi)始時(shí)可以考慮引入部分合適的微服務(wù)架構(gòu)原則對(duì)已有系統(tǒng)進(jìn)行改造或新建微服務(wù)應(yīng)用,逐步探索及積累微服務(wù)架構(gòu)經(jīng)驗(yàn),而非全盤實(shí)施微服務(wù)架構(gòu)。
Contact作者:鵬磊
出處:http://www.ymq.io
Email:admin@souyunku.com
版權(quán)歸作者所有,轉(zhuǎn)載請(qǐng)注明出處
Wechat:關(guān)注公眾號(hào),搜云庫(kù),專注于開(kāi)發(fā)技術(shù)的研究與知識(shí)分享
原文鏈接:翻譯系_力譜宿云LeapCloud團(tuán)隊(duì)_云服務(wù)研發(fā)成員:Frank Qin
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/70452.html
摘要:要玩好微服務(wù),微服務(wù)平臺(tái)需要的不僅僅是無(wú)侵入的服務(wù)治理能力,容器測(cè)試等服務(wù)也是必要的,這也是網(wǎng)易云輕舟微服務(wù)的產(chǎn)品設(shè)計(jì)思路。 歡迎訪問(wèn)網(wǎng)易云社區(qū),了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營(yíng)經(jīng)驗(yàn)。 簡(jiǎn)單地說(shuō),微服務(wù)架構(gòu)就是以業(yè)務(wù)域或業(yè)務(wù)功能為邊界,將一個(gè)大而全的應(yīng)用拆分為可以獨(dú)立開(kāi)發(fā),獨(dú)立部署,獨(dú)立測(cè)試,獨(dú)立運(yùn)行的一組小的應(yīng)用,并且使用輕量級(jí),通用的機(jī)制在這組應(yīng)用間進(jìn)行通信。 showImg(https:...
摘要:作為一項(xiàng)在云中部署應(yīng)用和服務(wù)的新技術(shù)已成為當(dāng)下最新的熱門話題。曾熱衷于促進(jìn)的綜合軟件棧,說(shuō)該公司對(duì)于微服務(wù)架構(gòu)有著很好的定位。 Microservices作為一項(xiàng)在云中部署應(yīng)用和服務(wù)的新技術(shù)已成為當(dāng)下最新的熱門話題。但大部分圍繞microservices的爭(zhēng)論都集中在容器或其他技術(shù)是否能很好的實(shí)施微服務(wù),而紅帽說(shuō)API應(yīng)該是重點(diǎn)。 企業(yè)和服務(wù)提供商正在尋找更好的方法將應(yīng)用程序部署在云環(huán)...
摘要:每個(gè)微服務(wù)提供一組,供其他微服務(wù)或者應(yīng)用客戶端所用。由于微服務(wù)架構(gòu)的分布式特點(diǎn),測(cè)試一個(gè)基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。微服務(wù)架構(gòu)模式下,應(yīng)用的改變將會(huì)波及多個(gè)服務(wù)。 微服務(wù)Microservices已經(jīng)成為軟件架構(gòu)最流行的熱詞之一。網(wǎng)絡(luò)上看到很多關(guān)于微服務(wù)的文章,但是感覺(jué)很多離我們還很遙遠(yuǎn),并且沒(méi)有找到多少真正在企業(yè)場(chǎng)景中應(yīng)用的實(shí)例。此處省略一萬(wàn)字~~~~于是想要將自己最近一段...
摘要:如何快速搭建一個(gè)微服務(wù)架構(gòu)上圖異步通信方式通常異步的生產(chǎn)者消費(fèi)者模式,通過(guò)等異步消息通訊協(xié)議規(guī)范。數(shù)據(jù)的去中心化,進(jìn)一步降低了微服務(wù)之間的耦合度,不同服務(wù)可以采用不同的數(shù)據(jù)庫(kù)技術(shù)等。 什么是微服務(wù)? 微服務(wù)(Microservices Architecture)是一種架構(gòu)風(fēng)格,一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署,各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服...
摘要:第二種則由多個(gè)小單元構(gòu)成,每個(gè)小單元都是獨(dú)立的服務(wù)。微服務(wù)架構(gòu)所依賴的彈性通信輕量等需求容器恰好可以完美提供,因此微服務(wù)與容器可以說(shuō)是完美的一對(duì)。談到架構(gòu),微服務(wù)架構(gòu)已然是時(shí)至今日必聊的一個(gè)話題,系統(tǒng)架構(gòu)的選型與是否轉(zhuǎn)型,不應(yīng)該是為了微服務(wù)架構(gòu)而架構(gòu),而是源于微服務(wù)架構(gòu)自身是否更適合業(yè)務(wù)自身的需求,微服務(wù)架構(gòu)的優(yōu)勢(shì)與所要付出的代價(jià)是否值得你,去做一次轉(zhuǎn)變。 ? ?GIStack for M...
閱讀 1750·2021-09-28 09:43
閱讀 1111·2021-09-23 11:22
閱讀 2707·2021-09-14 18:05
閱讀 1823·2019-08-30 15:52
閱讀 2812·2019-08-30 10:55
閱讀 2007·2019-08-29 16:58
閱讀 1323·2019-08-29 16:37
閱讀 3031·2019-08-29 16:25