學(xué)習(xí)目標(biāo)

1. 回顧架構(gòu)的演進(jìn)。
2. 明確springcloud是什么？
3. 明確spring、springboot和springcloud之間的關(guān)系。
4. 了解springcloud的常用組件及其作用。

第1章 架構(gòu)演進(jìn)

1、單體架構(gòu)

我相信，絕大部分同學(xué)都用過(guò)SSM框架進(jìn)行過(guò)開(kāi)發(fā)，當(dāng)時(shí)你們所在項(xiàng)目組肯定是將所有的功能模塊全部放在了同一個(gè)框架里面，只是不同的功能建了一個(gè)不同的包，然后所有的功能模塊數(shù)據(jù)存儲(chǔ)在一個(gè)數(shù)據(jù)庫(kù)里面，然后通過(guò)一臺(tái)Tomcat容器去啟動(dòng)服務(wù)。

這種架構(gòu)在最開(kāi)始公司業(yè)務(wù)量、數(shù)據(jù)量、并發(fā)量小的情況下是沒(méi)問(wèn)題的，甚至對(duì)于開(kāi)發(fā)人員更友好。

但是來(lái)了，但是隨著你公司的發(fā)展，業(yè)務(wù)量增大，功能需求增多，數(shù)據(jù)量并發(fā)量也增大的時(shí)候，單體架構(gòu)就不行了，為什么呢？

1. 隨著業(yè)務(wù)量增大，單臺(tái)Tomcat很容易達(dá)到性能瓶頸，一般的服務(wù)器上Tomcat的最大并發(fā)量也就在200左右。
2. 因?yàn)橹挥幸慌_(tái)服務(wù)器，出現(xiàn)問(wèn)題就直接掛掉了，此時(shí)客戶(hù)端都訪問(wèn)不了服務(wù)，這個(gè)時(shí)候就讓我想起了，讀大學(xué)的時(shí)候選選修課，每次都要等好幾個(gè)小時(shí)才能選上，體驗(yàn)極差。

2、集群架構(gòu)

為了解決上面的這些問(wèn)題，必須要從根源上進(jìn)行優(yōu)化。此時(shí)集群架構(gòu)出現(xiàn)。

集群架構(gòu)的邏輯其實(shí)很簡(jiǎn)單，它就是把整個(gè)系統(tǒng)從一臺(tái)服務(wù)器上部署變成了多臺(tái)服務(wù)器部署，只是對(duì)整個(gè)系統(tǒng)的復(fù)制拷貝。然后增加Nginx服務(wù)器做負(fù)載均衡而已。

但是集群架構(gòu)也存在一些問(wèn)題：

• 如果系統(tǒng)中的某個(gè)很小的功能發(fā)生了版本迭代，那這個(gè)時(shí)候就需要將所有的系統(tǒng)全部停掉，然后進(jìn)行更新。而且可能整個(gè)系統(tǒng)非常龐大了，開(kāi)發(fā)這個(gè)大系統(tǒng)的部門(mén)人員可能也非常多組織架構(gòu)也不好管理。
• 雖然你系統(tǒng)做了集群，但是數(shù)據(jù)庫(kù)往往才是制約你系統(tǒng)性能的最大因素，當(dāng)并發(fā)量大了，數(shù)據(jù)量大了，數(shù)據(jù)庫(kù)是處理不過(guò)來(lái)的。

3、業(yè)務(wù)垂直化拆分

針對(duì)上面的問(wèn)題，架構(gòu)再一次需要改進(jìn)，整個(gè)大系統(tǒng)不適用了，就將不同的功能模塊拆分成小系統(tǒng)。

對(duì)業(yè)務(wù)進(jìn)行垂直化拆分，簡(jiǎn)單來(lái)說(shuō)，就是可以按照系統(tǒng)的業(yè)務(wù)功能拆分出多個(gè)業(yè)務(wù)模塊子系統(tǒng)。每個(gè)子系統(tǒng)由不同的業(yè)務(wù)團(tuán)隊(duì)負(fù)責(zé)。

4、服務(wù)化改造

隨著對(duì)業(yè)務(wù)系統(tǒng)進(jìn)行垂直化改造之后，以業(yè)務(wù)功能緯度拆分出來(lái)多個(gè)子系統(tǒng)，而在各個(gè)子系統(tǒng)中，會(huì)存在比較多的共享業(yè)務(wù)，比如用戶(hù)信息查詢(xún)，在支付業(yè)務(wù)中會(huì)涉及到、在首頁(yè)中也會(huì)涉及到。那么勢(shì)必會(huì)造成重復(fù)開(kāi)發(fā)產(chǎn)生非常多的冗余代碼。那么這個(gè)時(shí)候就引入了服務(wù)化改造的思想，也就是 SOA把一些通用的、會(huì)被多個(gè)上層服務(wù)調(diào)用的模塊獨(dú)立拆分出來(lái)，形成一些共享的基礎(chǔ)服務(wù)。這些被拆分出來(lái)的共享服務(wù)相對(duì)來(lái)說(shuō)是比較獨(dú)立，并且可重用。 比如用戶(hù)管理服務(wù)，包含用戶(hù)注冊(cè)、用戶(hù)查詢(xún)等功能。比如單點(diǎn)登錄服務(wù)。

SOA 的核心目標(biāo)就是通過(guò)服務(wù)的流程化來(lái)實(shí)現(xiàn)業(yè)務(wù)的靈活性，而這個(gè)流程化其實(shí)就是由一系列相關(guān)聯(lián)的任務(wù)組成，這一系列相關(guān)聯(lián)的任務(wù)可以通過(guò)一系列的服務(wù)組合來(lái)實(shí)現(xiàn)具體的業(yè)務(wù)功能SOA 面向服務(wù)架構(gòu)，從語(yǔ)義上說(shuō)，它與面向過(guò)程、面向?qū)ο蟆⒚嫦蚪M件一樣，是一種軟件組建及開(kāi)發(fā)的方式。所以在 SOA 中，服務(wù)是最核心的抽象手段，業(yè)務(wù)被劃分為一些列粗粒度的業(yè)務(wù)服務(wù)和業(yè)務(wù)流程。

SOA 中更強(qiáng)調(diào) ESB 企業(yè)服務(wù)總線(xiàn)，企業(yè)服務(wù)總線(xiàn)可以使得服務(wù)之間的交互是動(dòng)態(tài)的，以及服務(wù)位置是透明的。這樣的好處是服務(wù)的調(diào)用者和服務(wù)的提供者之間是高度解耦的。從而使得服務(wù)有更高的靈活性以及隔離性。

ESB： 是從面相服務(wù)架構(gòu)(SOA)發(fā)展過(guò)來(lái)的，主要是對(duì)多個(gè)系統(tǒng)中的服務(wù)調(diào)用者和服務(wù)提供者的解耦。ESB 本身提供了服務(wù)暴露、接入、協(xié)議轉(zhuǎn)化、數(shù)據(jù)格式轉(zhuǎn)化、路由等功能。

SOA 主要解決的問(wèn)題：

• 信息孤島
• 互聯(lián)互通
• 業(yè)務(wù)重用

5、微服務(wù)架構(gòu)

業(yè)務(wù)系統(tǒng)實(shí)施服務(wù)化改造后，原本共享的業(yè)務(wù)被拆分，形成可復(fù)用的服務(wù)，可以在最大程度上避免共享業(yè)務(wù)的重復(fù)建設(shè)、資源連接瓶頸等問(wèn)題出現(xiàn)。那么那些被拆分出來(lái)的服務(wù)，是否也需要以業(yè)務(wù)功能為維度來(lái)進(jìn)行拆分，使之能夠獨(dú)立進(jìn)行部署，以降低業(yè)務(wù)藕合和提升容錯(cuò)性呢？

微服務(wù)并不是一種新思想的方法。它更像是一種思想的精煉，是一種服務(wù)化思想的最佳實(shí)踐方向而已，所以我認(rèn)為微服務(wù)其實(shí)是在 SOA 思路下，隨著各個(gè)企業(yè)對(duì)于服務(wù)化治理上不斷地完善，以及對(duì)軟件的交付鏈路以及基礎(chǔ)設(shè)施逐步成熟之下的一種自然的產(chǎn)物。 微服務(wù)也是一種面向服務(wù)的架構(gòu)模型，只是它更強(qiáng)調(diào)服務(wù)的粒度。也就是服務(wù)的職責(zé)更加單一更加精煉我們也可以把 SOA 看成是微服務(wù)的超集。 也就是多個(gè)微服務(wù)可以組成一個(gè) soa 服務(wù)。

6、微服務(wù)和 SOA 架構(gòu)的區(qū)別

經(jīng)常會(huì)有同學(xué)問(wèn)，微服務(wù)和 SOA 架構(gòu)有什么區(qū)別。這個(gè)區(qū)別一定要從架構(gòu)的發(fā)展過(guò)程來(lái)了解。這兩種架構(gòu)模式，其實(shí)本質(zhì)上應(yīng)該是在分布式架構(gòu)這條時(shí)間線(xiàn)上，基于服務(wù)化思想的不斷完善，以及基礎(chǔ)設(shè)施的逐步成熟之下的一種升級(jí)。既然存在于時(shí)間線(xiàn)的先后，那也就意味著，這兩種架構(gòu)模式所關(guān)注的點(diǎn)不一樣。

第2章 Spring Cloud

上一章講到了架構(gòu)的演進(jìn)過(guò)程，事實(shí)上不管什么架構(gòu)，都是需要通過(guò)合適的框架技術(shù)進(jìn)行落地，從最開(kāi)始的spring框架，到后來(lái)的springboot，再到現(xiàn)在的springcloud，那為什么需要springcloud呢？spring為什么不行呢？

要想整體弄明白這些問(wèn)題，那我們接下來(lái)先弄清楚幾個(gè)概念，自己在腦海里面形成一套體系：

1. spring在開(kāi)發(fā)過(guò)程中有什么問(wèn)題？
2. springboot的出現(xiàn)解決了什么？
3. springboot跟springcloud是什么關(guān)系
4. springcloud是什么？它包含了什么？

1、spring的問(wèn)題

事實(shí)上spring的出現(xiàn)就是為了簡(jiǎn)化開(kāi)發(fā)的，spring的核心概念絕大部分同學(xué)都能說(shuō)出來(lái)，無(wú)非就是3個(gè)，IoC、DI、AOP，下面稍微解釋一下這仨兄弟是干嘛的。

• IoC實(shí)際上就是一個(gè)容器，它就是用來(lái)裝Bean對(duì)象的；回到最最基礎(chǔ)的層面，我們java開(kāi)發(fā)就是在不斷的通過(guò)new創(chuàng)建對(duì)象，然后拿到對(duì)象之后調(diào)用對(duì)象里面的方法。OK，那在實(shí)際開(kāi)發(fā)過(guò)程中，如果所有的對(duì)象都需要手動(dòng)去創(chuàng)建將是一個(gè)非常繁瑣的過(guò)程，也許你有1萬(wàn)個(gè)類(lèi)，然后這1萬(wàn)個(gè)類(lèi)在各種地方都要?jiǎng)?chuàng)建對(duì)象，這個(gè)時(shí)候假設(shè)用到了A類(lèi)的對(duì)象，然后你在B類(lèi)中new了對(duì)象，如果要在C、D、E等等類(lèi)中要用到這個(gè)對(duì)象的話(huà)，將會(huì)很麻煩，這只是一種情況，在開(kāi)發(fā)中這種類(lèi)似的現(xiàn)象隨處可見(jiàn)，所以spring為了解決這個(gè)過(guò)程，設(shè)計(jì)了一個(gè)IoC的功能，你就理解成一個(gè)中心容器，用來(lái)裝項(xiàng)目中幾乎所有需要用到的Bean對(duì)象。
• IoC的概念理解了，那么這個(gè)時(shí)候你要想，對(duì)象創(chuàng)建了，但是對(duì)象里面可能會(huì)存在別的一些成員屬性，而這些成員屬性又是另外的一些對(duì)象，舉個(gè)例子就是A對(duì)象里面有個(gè)成員屬性是B對(duì)象，那這個(gè)時(shí)候你要去進(jìn)行引用的關(guān)聯(lián)，這一步也非常麻煩和繁瑣，怎么辦呢？spring的DI幫你完成了，在A對(duì)象new的過(guò)程中，spring就會(huì)去中心容器找有沒(méi)有B對(duì)象，有的話(huà)就把這個(gè)B對(duì)象賦值給A對(duì)象的屬性。
• AOP的概念其實(shí)更好理解，它是基于動(dòng)態(tài)代理完成的，你們要清晰的指導(dǎo)，代理就是做增強(qiáng)的，什么意思呢？假設(shè)有一個(gè)對(duì)象的業(yè)務(wù)功能就是創(chuàng)建訂單，OK，那我不想直接調(diào)用這個(gè)對(duì)象的創(chuàng)建訂單功能，我想在創(chuàng)建訂單之前和之后干點(diǎn)別的事情，比如說(shuō)打印日志這個(gè)事，這個(gè)時(shí)候就用到了代理。

OK，spring基于這仨兄弟確實(shí)簡(jiǎn)化了很多開(kāi)發(fā)的流程，但是，在最開(kāi)始的過(guò)程中spring在進(jìn)行IoC注入對(duì)象的過(guò)程中，它是基于XML方式的，這個(gè)邏輯很容易理解，就是你要把什么對(duì)象放到容器中去，只需要在XML文件中配置一下就好了。

但是，正因?yàn)檫@個(gè)，使得spring變的無(wú)比的繁瑣，你想想，一個(gè)項(xiàng)目中得用到多少個(gè)對(duì)象，每個(gè)對(duì)象都去配置一下，完?duì)僮恿恕Ｒ獙?xiě)無(wú)數(shù)個(gè)XML文件了。

spring開(kāi)始發(fā)力，要優(yōu)化了，引入注解，但是沒(méi)用啊，如果你項(xiàng)目要集成別的組件呢？比如redis，比如mybatis。甚至在微服務(wù)項(xiàng)目中要引入集成各種組件的話(huà)，那更加崩潰。

其實(shí)歸根結(jié)底，spring還是沒(méi)有解決IoC注入的復(fù)雜流程，以及外部化配置的統(tǒng)一管理。

2、springboot

看過(guò)springboot源碼的同學(xué)都知道，springboot底層其實(shí)會(huì)走一遍spring的流程。也就是springboot依賴(lài)于spring，同時(shí)它也在spring的基礎(chǔ)之上作了一些工作。

具體作了啥，實(shí)際上就是解決IoC自動(dòng)注入和配置統(tǒng)一管理，使得這個(gè)工作不再需要程序員去做了，框架自己干了。具體怎么解決的參照之前的內(nèi)容。

3、springcloud生態(tài)

先明確springcloud是什么？網(wǎng)上都說(shuō)，啊呀springcloud就是做微服務(wù)的，它是一個(gè)生態(tài)啊等等。進(jìn)說(shuō)一些我們聽(tīng)不懂的。

那我這里用最簡(jiǎn)單的語(yǔ)言去解釋一下：

springcloud就是springboot集成各種各樣starter組件的一個(gè)集體，springcloud底層核心框架就是springboot，然后springboot集成不同組件的時(shí)候不需要程序員去寫(xiě)XML文件以及配置文件了，而是一些好事之徒，他們基于springboot自動(dòng)裝配原理寫(xiě)了starter組件，然后將這些starter組件和springboot的整體我們給了一個(gè)名字叫做springcloud。

明白了吧，那知道springcloud是什么之后，在來(lái)看這個(gè)生態(tài)里面包含了啥，springboot我知道了，starter組件有哪些呢？

這個(gè)不用去背，我們自己根據(jù)數(shù)據(jù)流向從整體上去串一串就好了，當(dāng)你串明白了，那你離架構(gòu)師就不是太遠(yuǎn)了。

（1）網(wǎng)關(guān)

Gateway組件

我們知道 spring cloud 可以用來(lái)開(kāi)發(fā)微服務(wù)，但是應(yīng)該很少有同學(xué)真正知道 spring cloud 是什么。

官方的解釋是：spring cloud 提供了一些可以讓開(kāi)發(fā)者快速構(gòu)建分布式應(yīng)用的工具，這些服務(wù)可以很好的工作在任何分布式環(huán)境下。

既然提供的是一些快速構(gòu)建微服務(wù)應(yīng)用的工具，那么我們需要了解微服務(wù)開(kāi)發(fā)過(guò)程中需要解決哪些問(wèn)題？

在微服務(wù)實(shí)施之后，各個(gè)服務(wù)的拆分粒度很小，對(duì)于客戶(hù)端來(lái)說(shuō)，做一個(gè)操作可能會(huì)涉及到后端的多個(gè)服務(wù)組件的調(diào)用，那意味著它需要頻繁的發(fā)起多次訪問(wèn)才能進(jìn)行數(shù)據(jù)聚合實(shí)現(xiàn)用戶(hù)的功能。

如果我們?cè)谒械奈⒎?wù)之前增加一個(gè)網(wǎng)關(guān)，對(duì)于客戶(hù)端來(lái)說(shuō)它需要做什么功能操作直接調(diào)用網(wǎng)關(guān)并且告訴網(wǎng)關(guān)所要做的事情即可，網(wǎng)關(guān)根據(jù)請(qǐng)求的功能對(duì)后端的多個(gè)服務(wù)的數(shù)據(jù)進(jìn)行聚合聚合哦從而減少客戶(hù)端的調(diào)用頻次。

并且，由于有了網(wǎng)關(guān)的聚合，我們還可以在網(wǎng)關(guān)層對(duì)請(qǐng)求進(jìn)行統(tǒng)一鑒權(quán)和認(rèn)證； 包括還可以實(shí)現(xiàn)限流、請(qǐng)求日志統(tǒng)一記錄、 灰度發(fā)布等等。

（2）遠(yuǎn)程通信

Openfeign、Dubbo

服務(wù)拆分以后就會(huì)涉及到服務(wù)的遠(yuǎn)程通信，比如 http 協(xié)議或者 rpc 協(xié)議。

（3）服務(wù)發(fā)現(xiàn)

Eureka、Nacos

在滿(mǎn)足基礎(chǔ)通信的基礎(chǔ)上，如何做到服務(wù)的統(tǒng)一管理以及服務(wù)的動(dòng)態(tài)感知，就需要涉及到服務(wù)的注冊(cè)中心來(lái)實(shí)現(xiàn)服務(wù)注冊(cè)和發(fā)現(xiàn)的功能。

（4）負(fù)載均衡

Ribbon、Dubbo

假設(shè)服務(wù)提供者為了擴(kuò)大吞吐量，采用 10 臺(tái)機(jī)器的集群部署，這個(gè)時(shí)候客戶(hù)端從注冊(cè)中心獲得服務(wù)以后，應(yīng)該調(diào)用哪臺(tái)機(jī)器呢？

所以必然有一種負(fù)載均衡的機(jī)制，來(lái)實(shí)現(xiàn)客戶(hù)端請(qǐng)求的分發(fā)。

（5）熔斷、限流、降級(jí)

Hystrix、Sentinel

在分布式架構(gòu)中，各個(gè)服務(wù)節(jié)點(diǎn)一定需要滿(mǎn)足高可用，所以對(duì)于服務(wù)本身來(lái)說(shuō)，一方面是在有準(zhǔn)備的前提下做好充足的擴(kuò)容。另一方面，服務(wù)需要有熔斷、限流、降級(jí)的能力。

當(dāng)一個(gè)服務(wù)調(diào)用另外一個(gè)服務(wù)，可能因?yàn)榫W(wǎng)絡(luò)原因、或者連接池滿(mǎn)等問(wèn)題導(dǎo)致頻繁出現(xiàn)錯(cuò)誤，需要有一種熔斷機(jī)制，來(lái)防止因?yàn)檎?qǐng)求堆積導(dǎo)致整個(gè)應(yīng)用雪崩。

當(dāng)發(fā)現(xiàn)整個(gè)系統(tǒng)的確負(fù)載過(guò)高的時(shí)候，可以選擇降級(jí)某些功能或某些調(diào)用，保證最重要的交易流程的通過(guò)，以及最重要的資源全部用于保證最核心的流程。

在設(shè)置了熔斷以及降級(jí)策略后，還有一種手段來(lái)保護(hù)系統(tǒng)，就是限流算法。

我們能夠通過(guò)全鏈路壓測(cè)了解到整個(gè)系統(tǒng)的吞吐量，但實(shí)際上的流量可能會(huì)超過(guò)我們預(yù)期的值，比如存在惡意攻擊、或者突然的高峰流量。在這種情況下可以通過(guò)限流來(lái)保護(hù)系統(tǒng)不崩潰，但是對(duì)于部分用戶(hù)來(lái)說(shuō)，會(huì)出現(xiàn)被限流導(dǎo)致體驗(yàn)不好的情況。

（6）配置中心

Config、Nacos

服務(wù)拆分以后，服務(wù)的數(shù)量非常多，如果所有的配置都以配置文件的方式放在應(yīng)用本地的話(huà)，非常難以管理，可以想象當(dāng)有幾百上千個(gè)進(jìn)程中有一個(gè)配置出現(xiàn)了問(wèn)題，是很難將它找出來(lái)的，因而需要有統(tǒng)一的配置中心，來(lái)管理所有的配置，進(jìn)行統(tǒng)一的配置下發(fā)。

在微服務(wù)中，配置往往分為幾類(lèi)，一類(lèi)是幾乎不變的配置，這種配置可以直接打在容器鏡像里面，第二類(lèi)是啟動(dòng)時(shí)就會(huì)確定的配置，這種配置往往通過(guò)環(huán)境變量，在容器啟動(dòng)的時(shí)候傳進(jìn)去，第三類(lèi)就是統(tǒng)一的配置，需要通過(guò)配置中心進(jìn)行下發(fā)，例如在大促的情況下，有些功能需要降級(jí)，哪些功能可以降級(jí)，哪些功能不能降級(jí)，都可以在配置文件中統(tǒng)一配置。

（7）分布式事務(wù)

Seata

對(duì)于數(shù)據(jù)庫(kù)的垂直拆分，已經(jīng)服務(wù)的拆分，單體的數(shù)據(jù)庫(kù)事務(wù)完全不能滿(mǎn)足需求了，這個(gè)時(shí)候就需要一個(gè)第三方的協(xié)調(diào)工具來(lái)做到統(tǒng)一管理事務(wù)提交回滾等操作，這個(gè)時(shí)候Seata出現(xiàn)了。

4、服務(wù)帶來(lái)的問(wèn)題

（1）業(yè)務(wù)團(tuán)隊(duì)的痛點(diǎn)

1. 對(duì)于業(yè)務(wù)開(kāi)發(fā)團(tuán)隊(duì)而言，最強(qiáng)的是技術(shù)嗎？一定不是，業(yè)務(wù)團(tuán)隊(duì)最強(qiáng)的一定是對(duì)于業(yè)務(wù)的理解和熟悉程度。
2. 而業(yè)務(wù)應(yīng)用的核心價(jià)值，就是為了實(shí)現(xiàn)業(yè)務(wù)場(chǎng)景，而不是寫(xiě)微服務(wù)，微服務(wù)只是一種實(shí)現(xiàn)業(yè)務(wù)的手段。
3. 業(yè)務(wù)團(tuán)隊(duì)除了關(guān)心業(yè)務(wù)之外，他們所面臨的最大的挑戰(zhàn)在于，如何保證系統(tǒng)的穩(wěn)定性何可擴(kuò)展性、如何設(shè)計(jì)一個(gè)安全的 open api。如果對(duì)服務(wù)進(jìn)行拆分、如何保證跨庫(kù)的數(shù)據(jù)一致性。以及對(duì)于舊系統(tǒng)的改造。
4. 于公司層面而言，業(yè)務(wù)團(tuán)隊(duì)的壓力還來(lái)自于時(shí)間人力的投入，我們用于被各種 deadline 趕著走。所以作為一個(gè)業(yè)務(wù)程序員，如果在這個(gè) deadline 之前還需要花更多的時(shí)間投入在spring cloud 這些工具的學(xué)習(xí)上，那無(wú)疑是雪上加霜。公司對(duì)于業(yè)務(wù)團(tuán)隊(duì)的考核，永遠(yuǎn)只看結(jié)果！

（2）跨語(yǔ)言帶來(lái)的問(wèn)題

微服務(wù)有一個(gè)很重要的特性，就是不同的微服務(wù)可以采用自己最擅長(zhǎng)的語(yǔ)言來(lái)編寫(xiě)程序。這種特性在企業(yè)中落地的時(shí)候又會(huì)帶來(lái)一些問(wèn)題。

比如公司內(nèi)部會(huì)開(kāi)發(fā)一些公共的類(lèi)庫(kù)或者框架，也或者會(huì)使用第三方的類(lèi)庫(kù)或者框架來(lái)實(shí)現(xiàn)某些功能。

但是由于公司的微服務(wù)用了各種各樣的語(yǔ)言，那意味著這些類(lèi)庫(kù)需要針對(duì)不同的語(yǔ)言開(kāi)發(fā)兼容版本。如果是主流語(yǔ)言還好，如果是一些小眾語(yǔ)言，那對(duì)于這些基礎(chǔ)組件的開(kāi)發(fā)者而言無(wú)疑是晴天霹靂.

（3）總結(jié)

從這些痛點(diǎn)中可以發(fā)現(xiàn)，我們所做的所有非業(yè)務(wù)類(lèi)的事情，都是為了保證把請(qǐng)求發(fā)送到正確的地方，并且能夠及時(shí)或得正確的結(jié)果。那對(duì)于對(duì)于業(yè)務(wù)開(kāi)發(fā)人員而言，是否有必要去關(guān)心這些呢？

回到最開(kāi)始我們說(shuō)的一個(gè)例子，在進(jìn)行計(jì)算機(jī)網(wǎng)絡(luò)通信的時(shí)候，開(kāi)發(fā)人員有必要去關(guān)心網(wǎng)絡(luò)通信的細(xì)節(jié)嗎？ 我們?cè)谑褂?http 協(xié)議進(jìn)行數(shù)據(jù)傳輸時(shí)，關(guān)心過(guò)底層是使用 TCP 還是 udp？數(shù)據(jù)是怎么傳輸?shù)模?/p>

既然我們不需要關(guān)心這些，那對(duì)于微服務(wù)架構(gòu)中的這些問(wèn)題，業(yè)務(wù)開(kāi)發(fā)人員為什么一定要關(guān)心服務(wù)的通訊呢？