net平臺(tái)有什么好的微服務(wù)框架？謝謝邀請(qǐng)。目前.net平臺(tái)某款微服務(wù)要說(shuō)很紅很好好像真的都談不上，不像Java的Spring Cloud這樣有比較高的人氣，但據(jù)說(shuō)可使用Spring Cloud來(lái)開(kāi)發(fā).

net平臺(tái)有什么好的微服務(wù)框架？

謝謝邀請(qǐng)。目前.net平臺(tái)某款微服務(wù)要說(shuō)很紅很好好像真的都談不上，不像Java的Spring Cloud這樣有比較高的人氣，但據(jù)說(shuō)可使用Spring Cloud來(lái)開(kāi)發(fā).Net Core應(yīng)用（.NET Core就是專(zhuān)門(mén)針對(duì)模塊化的微服務(wù)架構(gòu)而設(shè)計(jì)）。但針對(duì).Net平臺(tái)的微服務(wù)項(xiàng)目也還不少，只是均不太具有多高的人氣，相對(duì)來(lái)說(shuō)可能Azure Service Fabric算得上比較好的吧。下面是相關(guān).net微服務(wù)的部分列表：

1、SteelToe OSS

2、Azure Service Fabric：這款主要是微軟構(gòu)建，而且Service Fabric將開(kāi)源。

3、.Net China Foundation：這里有多個(gè)一微服務(wù)為導(dǎo)向的開(kāi)源項(xiàng)目。

4、Microdot Framework

5、其它還有Xigadee、Apworks frameword、Cronus、NancyFx、GRPC等。

微服務(wù)架構(gòu)主要是在云中部署應(yīng)用和服務(wù)，這一概念提出也并不久，處于快速發(fā)展階段，應(yīng)用也越來(lái)越多越來(lái)越廣泛。

微服務(wù)調(diào)用為啥用RPC框架，http不更簡(jiǎn)單嗎？

簡(jiǎn)單點(diǎn)，HTTP是協(xié)議，RPC是概念！實(shí)現(xiàn)RPC可以基于HTTP協(xié)議（Feign），TCP協(xié)議(Netty)，RMI協(xié)議（Soap），WebService（XML—RPC）框架。傳輸過(guò)程中，也因?yàn)樾蛄谢绞降牟煌钟幸恍┛蚣芎蛥f(xié)議，比如Dubbo中的Dubbo協(xié)議，gRpc—Protobuf序列化協(xié)議等等。其實(shí)，都是基于遠(yuǎn)程調(diào)用的概念，何為遠(yuǎn)程調(diào)用？

重點(diǎn)是，RPC就是遠(yuǎn)程調(diào)用，遠(yuǎn)程調(diào)用就是客戶(hù)端把調(diào)用的接口，參數(shù)，參數(shù)類(lèi)型，方法，返回值，返回值類(lèi)型等（這些稱(chēng)為方法簽名），通過(guò)如上的協(xié)議，發(fā)送給服務(wù)端，告知服務(wù)端需要調(diào)用的接口方法，這個(gè)過(guò)程就是RPC的實(shí)現(xiàn)過(guò)程！HTTP和RPC是不同層面的兩個(gè)東西！

性能方面，HTTP本身是基于TCP協(xié)議的，屬于應(yīng)用層協(xié)議，所以HTTP協(xié)議本身在實(shí)現(xiàn)過(guò)程中就會(huì)占用大量的資源（內(nèi)存，帶寬等），性能上肯定沒(méi)有通過(guò)TCP直接實(shí)現(xiàn)RPC協(xié)議快，不管HTTP如何優(yōu)化肯定的是不如TCP的！而TCP則是依靠字節(jié)碼，現(xiàn)在普遍采用的是將客戶(hù)端調(diào)用的接口信息，序列化的方式發(fā)送給服務(wù)端，序列化框架又包含很多（Hession，Protobuf，Kryo等等，序列化性能最高的是Kryo，序列化后字節(jié)碼最小的是Protobuf），序列化后的字節(jié)碼越小，占用帶寬越少，序列化時(shí)間越短，線(xiàn)程IO等待時(shí)間就會(huì)越小。所以，在具體應(yīng)用層面有很多可探討的技術(shù)，可以根據(jù)自己的硬件能力來(lái)選擇相應(yīng)的技術(shù)就可以了！

歡迎熱愛(ài)技術(shù)的人來(lái)探討！

談?wù)勎⒎?wù)架構(gòu)是一個(gè)怎樣的存在？

微服務(wù)是近些年被廣泛提及的一個(gè)概念，微服務(wù)架構(gòu)可以理解為一個(gè)輕量級(jí)的服務(wù)治理方案，也就是將系統(tǒng)的功能，通過(guò)服務(wù)的形式發(fā)布到服務(wù)器上，對(duì)服務(wù)進(jìn)行組合調(diào)用，實(shí)現(xiàn)具體的功能，解決實(shí)際業(yè)務(wù)問(wèn)題的架構(gòu)風(fēng)格。

微服務(wù)產(chǎn)生于單體應(yīng)用的擴(kuò)大化，隨著信息化不斷發(fā)展，企業(yè)對(duì)軟件功能的要求越來(lái)越具體，也愈發(fā)的細(xì)致，如果通過(guò)應(yīng)用程序來(lái)實(shí)現(xiàn)，必然是一個(gè)極其復(fù)雜而又痛苦的過(guò)程，由此誕生了微服務(wù)的概念。就是將功能發(fā)布成服務(wù)，應(yīng)用程序通過(guò)調(diào)用不同的服務(wù)來(lái)實(shí)現(xiàn)業(yè)務(wù)，這種設(shè)計(jì)架構(gòu)稱(chēng)之為微服務(wù)。

微服務(wù)架構(gòu)的優(yōu)點(diǎn)在于每個(gè)服務(wù)可以有獨(dú)立的團(tuán)隊(duì)開(kāi)發(fā)，服務(wù)之間互不干涉，保障了系統(tǒng)的穩(wěn)定性。由于功能被拆分到更細(xì)的粒度，有效的降低了程序的復(fù)雜程度，對(duì)硬件的需求也隨之降低，但是微服務(wù)也有一些不足，比如服務(wù)調(diào)用帶來(lái)的系統(tǒng)復(fù)雜性，服務(wù)間的依賴(lài)關(guān)系也是難以管理的，如何構(gòu)建合理的服務(wù)依賴(lài)是考驗(yàn)架構(gòu)師能力的重要依據(jù)；最后，微服務(wù)架構(gòu)的部署以及跟蹤也是很難的?？傊?，微服務(wù)架構(gòu)有著自身的應(yīng)用場(chǎng)景以及特點(diǎn)，了解哪些場(chǎng)景適合微服務(wù)比掌握微服務(wù)的具體技術(shù)更為重要，適當(dāng)?shù)募夹g(shù)用在適當(dāng)?shù)膱?chǎng)景，才能發(fā)揮合適的價(jià)值。

數(shù)通暢聯(lián) 專(zhuān)注于企業(yè)IT架構(gòu)、SOA綜合集成、數(shù)據(jù)治理分析領(lǐng)域，感謝您的閱讀與關(guān)注！