技術(shù)架構(gòu)為什么要服務(wù)化？關(guān)乎體量和需求的增長變化首先明確，服務(wù)化的本質(zhì)是依托實際需求的。假如你的系統(tǒng)只有幾十幾百個人使用，在當下的技術(shù)架構(gòu)中單體應用完全足夠，這時候追逐服務(wù)化反而是一種舍本逐末，撿芝麻

技術(shù)架構(gòu)為什么要服務(wù)化？

關(guān)乎體量和需求的增長變化

首先明確，服務(wù)化的本質(zhì)是依托實際需求的。假如你的系統(tǒng)只有幾十幾百個人使用，在當下的技術(shù)架構(gòu)中單體應用完全足夠，這時候追逐服務(wù)化反而是一種舍本逐末，撿芝麻丟西瓜的舉動了。為什么要服務(wù)化？因為單體應用面臨越來越多的系統(tǒng)需求功能迭代、面對越來越多的用戶使用，無法保證穩(wěn)定性、可靠性、可擴展性。還存在模塊間流量不平衡，資源權(quán)重無法得到有效分配的一大批問題。伴隨系統(tǒng)越來越龐大，彼此間耦合的調(diào)用關(guān)系到處都是，很有可能牽一發(fā)動全身。對產(chǎn)品的可維護性來說也變差了。

服務(wù)化優(yōu)勢

當企業(yè)面臨單體應用的瓶頸問題是，可以果斷采取服務(wù)化改造優(yōu)勢如下。

1、減少耦合，梳理關(guān)系。

2、明確服務(wù)重點，有側(cè)重進行資源分配。

3、減少單點故障發(fā)生。

4、服務(wù)升級易于擴展。

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

簡單點，HTTP是協(xié)議，RPC是概念！實現(xiàn)RPC可以基于HTTP協(xié)議（Feign），TCP協(xié)議(Netty)，RMI協(xié)議（Soap），WebService（XML—RPC）框架。傳輸過程中，也因為序列化方式的不同，又有一些框架和協(xié)議，比如Dubbo中的Dubbo協(xié)議，gRpc—Protobuf序列化協(xié)議等等。其實，都是基于遠程調(diào)用的概念，何為遠程調(diào)用？

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

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

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

如何才能成為java架構(gòu)師？我為大家來分析一下？

首先架構(gòu)師不是那么好當，技術(shù)實力一定要過關(guān)，要具有架構(gòu)師的思想，其次架構(gòu)師是企業(yè)級開發(fā)所需的Dubbo框架、zookeper基本原理、redis分布式緩存、JVM性能優(yōu)化，Nginx apache Tomcat集群部署、大數(shù)據(jù)hadoop，Hbase實時計算spark、storm、數(shù)據(jù)分析分詞和權(quán)重等核心技術(shù)。

如何成為一個優(yōu)秀的架構(gòu)師呢？我用七張圖片來告訴大家。

另外的四張圖片想成為架構(gòu)師的可以私信我，每天更新java架構(gòu)師技術(shù)視頻資料。

大家可以先學習下分布式鎖的實現(xiàn)：

鏈接: https://pan.baidu.com/s/1y8rkldBEpkHXHS3GvJXGTg 密碼: umu3