柚子快報(bào)邀請(qǐng)碼778899分享：java 微服務(wù)學(xué)習(xí)筆記

http://yzkb.51969.com/

Eureka

Ribbon負(fù)載均衡

用服務(wù)提供者的服務(wù)名稱遠(yuǎn)程調(diào)用,而返回實(shí)際ip端口

Ribbon 負(fù)載均衡規(guī)則

規(guī)則接口是 IRule 默認(rèn)實(shí)現(xiàn)是 ZoneAvoidanceRule ，根據(jù) zone 選擇服務(wù)列表，然后輪詢（Zone 可以理解為 一個(gè)機(jī)房、一個(gè)機(jī)架等)

饑餓加載

Ribbon 默認(rèn)是采用懶加載，即第一次訪問(wèn)時(shí)才會(huì)去創(chuàng)建 LoadBalanceClient ，請(qǐng)求時(shí)間會(huì)很長(zhǎng)。 而饑餓加載則會(huì)在項(xiàng)目啟動(dòng)時(shí)創(chuàng)建，降低第一次訪問(wèn)的耗時(shí)

Nacos

注冊(cè)中心

隔離與服務(wù)分級(jí)存儲(chǔ)

Nacos 環(huán)境隔離

每個(gè) namespace 都有唯一 id 服務(wù)設(shè)置 namespace 時(shí)要寫(xiě) id 而不是名稱 不同 namespace 下的服務(wù)互相不可見(jiàn) Nacos 中服務(wù)存儲(chǔ)和數(shù)據(jù)存儲(chǔ)的最外層都是一個(gè)名為 namespace 的東西，用來(lái)做最外層隔離

Nacos 服務(wù)分級(jí)存儲(chǔ)模型

一級(jí)是服務(wù)，例如 userservice 二級(jí)是集群，例如杭州或上海 三級(jí)是實(shí)例，例如杭州機(jī)房的某臺(tái)部署了 userservice 的服務(wù)器

Nacos 與 Eureka 的區(qū)別

Nacos 支持服務(wù)端主動(dòng)檢測(cè)提供者狀態(tài)：臨時(shí)實(shí)例采用心跳模式，非臨時(shí)實(shí)例（親兒子）采用主動(dòng)檢測(cè)模式 臨時(shí)實(shí)例心跳不正常會(huì)被剔除，非臨時(shí)實(shí)例則不會(huì)被剔除 Nacos 支持服務(wù)列表變更的消息推送模式，服務(wù)列表更新更及時(shí)，Eureka心跳檢測(cè)時(shí)間間隔更長(zhǎng)，更容易出問(wèn)題 Nacos 集群默認(rèn)采用 AP（可用性） 方式，當(dāng)集群中存在非臨時(shí)實(shí)例時(shí)，采用 CP（可靠性） 模式； Eureka 采用 AP 方式

配置管理

bootstrap.yml優(yōu)先級(jí)大于application.yml

配置自動(dòng)刷新（熱更新）

在 @Value 注入的變量所在類(lèi)上添加注解 @RefreshScope 使用 @ConfigurationProperties 注解

多服務(wù)共享配置

[ 服務(wù)名 ]-[spring.profile.active].yaml：環(huán)境配置 [ 服務(wù)名 ].yaml：默認(rèn)配置，多環(huán)境共享

提問(wèn) 整體式架構(gòu)有什么壞處？ 答：1.耦合度高，難以管理；2.修改的成本高，費(fèi)時(shí)費(fèi)力；3.開(kāi)發(fā)和測(cè)試不靈活；4.使實(shí)施新概念變得困難 gpt補(bǔ)充：技術(shù)選型的限制：由于整個(gè)應(yīng)用程序都是使用相同的技術(shù)棧構(gòu)建的，因此難以引入新的技術(shù)或更新現(xiàn)有技術(shù) 微服務(wù)架構(gòu)是怎么解決這些“壞處”的？ 答：將應(yīng)用程序拆分為小型服務(wù)，每個(gè)服務(wù)都有自己的代碼庫(kù)和數(shù)據(jù)庫(kù)。1.這樣可以降低耦合度，使得修改和維護(hù)變得更加容易。2.并且由于微服務(wù)是相互獨(dú)立的，因此一個(gè)服務(wù)的故障不會(huì)影響整個(gè)系統(tǒng)的可用性，系統(tǒng)具有更高的容錯(cuò)性。3.可以更靈活地選擇技術(shù)和工具 微服務(wù)具有自主性和專用性，關(guān)于專用性，如果開(kāi)發(fā)人員逐漸將更多代碼增加到一項(xiàng)服務(wù)中并且這項(xiàng)服務(wù)變得復(fù)雜，那么可以將其拆分成多項(xiàng)更小的服務(wù)。 那同時(shí)，微服務(wù)架構(gòu)帶來(lái)了什么問(wèn)題，對(duì)于微服務(wù)架構(gòu)的（）特性，我們得解決哪些以前整體式架構(gòu)不用考慮的問(wèn)題？ 答：微服務(wù)架構(gòu)中涉及多個(gè)服務(wù)、多個(gè)組件，并且每個(gè)微服務(wù)都有自己的數(shù)據(jù)存儲(chǔ)，它們分布在不同的服務(wù)器甚至不同的數(shù)據(jù)中心中。因此，必須處理分布式系統(tǒng)的各種復(fù)雜性，也需要有效的監(jiān)控和調(diào)試工具來(lái)跟蹤整個(gè)系統(tǒng)的運(yùn)行狀態(tài)。 gpt: 微服務(wù)架構(gòu)中的服務(wù)之間需要通過(guò)網(wǎng)絡(luò)進(jìn)行通信，可能會(huì)增加延遲和網(wǎng)絡(luò)開(kāi)銷(xiāo) 對(duì)于自主性： 各個(gè)組件之間的任何通信都是通過(guò)明確定義的 API 進(jìn)行的，需要解決服務(wù)發(fā)現(xiàn)、服務(wù)注冊(cè)、負(fù)載均衡、服務(wù)監(jiān)控等問(wèn)題，以確保每個(gè)服務(wù)能夠自主地運(yùn)行并與其他服務(wù)協(xié)作。 為了解決上面提到的問(wèn)題，微服務(wù)帶來(lái)的新的技術(shù)（中間件、組件）有哪些？ 答：服務(wù)注冊(cè)與發(fā)現(xiàn)： ? Consul： 提供服務(wù)發(fā)現(xiàn)和服務(wù)健康檢查功能，用于發(fā)現(xiàn)和管理微服務(wù)。 ? etcd： 分布式鍵值存儲(chǔ)系統(tǒng)，也用于服務(wù)發(fā)現(xiàn)和配置管理。 2. 負(fù)載均衡： ? Nginx： 開(kāi)源的反向代理服務(wù)器，用于負(fù)載均衡和請(qǐng)求轉(zhuǎn)發(fā)。 ? HAProxy： 高性能的負(fù)載均衡器，支持TCP和HTTP應(yīng)用層負(fù)載均衡。 3. 消息隊(duì)列/事件總線： ? Kafka： 高吞吐量的分布式消息隊(duì)列，用于實(shí)時(shí)數(shù)據(jù)流處理。 ? RabbitMQ： 開(kāi)源的消息代理，用于支持異步消息傳遞和事件驅(qū)動(dòng)架構(gòu)。 4. API網(wǎng)關(guān)： ? Kong： 開(kāi)源的API網(wǎng)關(guān)和微服務(wù)管理層，提供路由、認(rèn)證、訪問(wèn)控制等功能。 ? Netflix Zuul： Netflix開(kāi)源的API網(wǎng)關(guān)，可用于動(dòng)態(tài)路由、負(fù)載均衡等。 5. 分布式追蹤： ? Jaeger： 分布式追蹤系統(tǒng)，用于跟蹤和監(jiān)控微服務(wù)架構(gòu)中的請(qǐng)求路徑和性能。 ? Zipkin： 分布式的實(shí)時(shí)追蹤系統(tǒng)，用于跟蹤請(qǐng)求的路徑和性能指標(biāo)。 6. 容器化和編排： ? Docker： 容器化平臺(tái)，用于打包、發(fā)布和運(yùn)行應(yīng)用程序。 ? Kubernetes： 自動(dòng)化容器編排工具，用于管理容器化應(yīng)用程序的部署、擴(kuò)展和運(yùn)維。 7. 分布式數(shù)據(jù)庫(kù)： ? Cassandra： 分布式NoSQL數(shù)據(jù)庫(kù)，具有高可擴(kuò)展性和高可用性。 ? MongoDB： 面向文檔的NoSQL數(shù)據(jù)庫(kù)，適用于處理大量數(shù)據(jù)和快速迭代。 嘗試用venn圖畫(huà)出微服務(wù)架構(gòu)和分布式架構(gòu)的關(guān)系

柚子快報(bào)邀請(qǐng)碼778899分享：java 微服務(wù)學(xué)習(xí)筆記

http://yzkb.51969.com/

推薦文章