中間件為什么學(xué)？如何學(xué)？如何成為一個(gè)優(yōu)秀的程序員？
我覺(jué)得優(yōu)秀程序員要滿足兩點(diǎn)：1.扎實(shí)的編程語(yǔ)言基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)基礎(chǔ)，要能實(shí)現(xiàn)各種基本的crud需求,這是基礎(chǔ)；2、就是了解工程上需要了解的知識(shí)，編程是一個(gè)系統(tǒng)性的工程。各個(gè)公司有自己的代碼框架差異很大暫不討論，但是常用的中間件能夠幫助更好地編程實(shí)現(xiàn)，非常有用。所以要學(xué)。第三就是性能優(yōu)化架構(gòu)優(yōu)化，當(dāng)有了對(duì)整體系統(tǒng)的認(rèn)知，準(zhǔn)確找到性能瓶頸根據(jù)業(yè)務(wù)需求進(jìn)行改進(jìn)。
而在中間件這方面：
首先我現(xiàn)階段注重的是廣度和共性，系統(tǒng)觀打牢，每個(gè)組件只是簡(jiǎn)單實(shí)踐了一下（docker運(yùn)行服務(wù)，nginx部署負(fù)載均衡，rpc簡(jiǎn)單使用），了解一下大體怎么運(yùn)作的，沒(méi)有更多復(fù)雜功能的嘗試。要廣泛了解各種中間件比如緩存，代理，容器，消息隊(duì)列，rpc的架構(gòu)思想，優(yōu)秀的設(shè)計(jì)理念（比如抽象層次k8s,vfs，設(shè)計(jì)模式等）和數(shù)據(jù)結(jié)構(gòu)（紅黑樹+鏈表，跳表等）。因?yàn)闀簳r(shí)沒(méi)有業(yè)務(wù)環(huán)境，專注于某個(gè)組件鉆牛角尖，可能以后都不會(huì)用到。所以注重整體學(xué)習(xí)，了解共性。
性能方面，對(duì)組件相應(yīng)修改和自己創(chuàng)造，正在學(xué)習(xí)，比如在學(xué)習(xí)linux內(nèi)核，性能之巔這本書。需要不斷提高自己，才能不被輕易替代。
（中間件和性能方面，我覺(jué)得已知的未知更重要，也就是知道該從哪些方面做，只是還沒(méi)有去做。）
**

docker:

** 出現(xiàn)是因?yàn)橄啾扔谔摂M機(jī)，資源復(fù)用更加靈活，虛擬機(jī)是一個(gè)完整的操作系統(tǒng)，占用空間大，啟動(dòng)慢；docker容器技術(shù)可以根據(jù)也無(wú)需求，配置不同的環(huán)境，不會(huì)互相影響。鏡像操作方便遷移，實(shí)現(xiàn)build once run everywhere

docker主要就是隔離和標(biāo)準(zhǔn)化。核心技術(shù)是namespace技術(shù)和cgroup技術(shù)。
namespace是讓不同容器看起來(lái)沒(méi)有關(guān)聯(lián)，防止不同空間命名沖突，比如pid,用戶Id，ip地址等。
每一個(gè)容器有自己的ns, 就和多進(jìn)程一樣，一個(gè)進(jìn)程的1234地址和另一個(gè)進(jìn)程的1234地址不是一個(gè)物理地址（虛擬地址）。不同ns中相同的命名也不是真正相同的資源。
可以通過(guò)proc/pid/ns文件夾查看進(jìn)程所屬的ns，然后想要修改的話可以用nsenter進(jìn)入指定的別的ns空間。

cgroup是用起來(lái)隔離的技術(shù)。樹狀結(jié)構(gòu)組織，若干個(gè)進(jìn)程組成cgroup，若干個(gè)cgroup樹狀排列，同時(shí)有很多樹，代表不同的系統(tǒng)資源，CPU,內(nèi)存，網(wǎng)絡(luò)，設(shè)備等
可以進(jìn)行一些資源的監(jiān)控限制等操作，比如限制mysql一組進(jìn)程核綁定，占用多大CPU時(shí)間，內(nèi)存和帶寬，可以訪問(wèn)哪些設(shè)備等等。

常用操作，
先拉取鏡像 docker pull ubuntu
然后啟動(dòng)一個(gè)容器 docker run -i -t -name 名字 cmd
如果是交互式的話就是/bin/bash

docker image查看鏡像
docker ps 查看容器 docker inspect c_id查看具體容器信息
docker top 容器id 查看其中的進(jìn)程

編譯dockfile還可以post發(fā)布鏡像到docker_hub庫(kù)里面，沒(méi)試過(guò)。

我用它主要在兩個(gè)方面，一個(gè)是計(jì)算機(jī)系統(tǒng)實(shí)驗(yàn)中，每次實(shí)驗(yàn)要裝不同的環(huán)境，而且是不兼容的，所以為了方便，就用了docker加載鏡像。不然的話就要卸載。

還有一個(gè)就是在docker部署網(wǎng)站。（靜態(tài)）
步驟是，1.端口映射一下，docker run -p 80指定80端口。
2、下載nginx和vim. 寫一個(gè)簡(jiǎn)單的html文件，修改nginx配置為那個(gè)文件，啟動(dòng)nginx。然后ctrl+Q退出，保證容器還是在運(yùn)行的。然后docker port web查看一下映射情況，通過(guò)宿主機(jī)地址127.0.0.1加映射端口訪問(wèn)

**

k8s

**
要知道k8s出現(xiàn)的原因，其實(shí)就是數(shù)據(jù)中心的操作系統(tǒng)，為了管理很多機(jī)器的軟硬件資源的。
主要組成和操作系統(tǒng)類似。
調(diào)度器controller 進(jìn)程線程進(jìn)程組（docker pod service） 網(wǎng)絡(luò)（每個(gè)pod有ip地址）存儲(chǔ)（文件存儲(chǔ)，對(duì)象存儲(chǔ)，塊存儲(chǔ)，有自己的接口管理）和包管理工具h(yuǎn)elm
關(guān)注一下Kubernetes 會(huì)將 Service DNS的名字作為域名解析成為一個(gè)虛擬的 Cluster IP，然后通過(guò)負(fù)載均衡，轉(zhuǎn)發(fā)到后端的 Pod。雖然 Pod 可能漂移，IP 會(huì)變，但是 Service 會(huì)一直不變。（Service就相當(dāng)于一組pod,也就是實(shí)現(xiàn)某種功能的一個(gè)進(jìn)程集合，比如mysql的一組進(jìn)程,也就是說(shuō)，在進(jìn)行service作為虛擬ip的時(shí)候，真正到的pod會(huì)變飄逸的，但是service不會(huì)變的，有點(diǎn)類似于NAT，可以實(shí)現(xiàn)負(fù)載均衡了。）

k8s解決的核心問(wèn)題是？

服務(wù)發(fā)現(xiàn)和負(fù)載均衡
也就是說(shuō)給你一個(gè)程序，你需要決定在哪個(gè)機(jī)器的pod上運(yùn)行。k8s的容器本身就可以指定資源大小CPU,內(nèi)存等。它有自己的DNS和ip地址公開(kāi)開(kāi)容器，流量大的時(shí)候還可以負(fù)載均衡。

還有存儲(chǔ)編排（可選擇對(duì)象，文件，塊存儲(chǔ)）

自我修復(fù)，高可用。

架構(gòu)：傳統(tǒng)的客戶端服務(wù)端架構(gòu)
服務(wù)端由一組master節(jié)點(diǎn)（存儲(chǔ)狀態(tài)，調(diào)度分配資源）和一系列worker節(jié)點(diǎn)組成。

主節(jié)點(diǎn)結(jié)構(gòu)：
它主要負(fù)責(zé)接收客戶端的請(qǐng)求，安排容器的執(zhí)行并且運(yùn)行控制循環(huán)，將集群的狀態(tài)向目標(biāo)狀態(tài)進(jìn)行遷移。（主要有API和客戶端交互接口，etcd鍵值數(shù)據(jù)庫(kù)存儲(chǔ)狀態(tài)，調(diào)度器主要負(fù)責(zé)的是讓pod在特定空閑節(jié)點(diǎn)運(yùn)行，調(diào)度的策略包括資源的需求，親和性（一組進(jìn)程最好在一臺(tái)主機(jī)進(jìn)行，通信方便）還有一個(gè)controler控制器，負(fù)責(zé)故障的通知轉(zhuǎn)移，以及副本，令牌控制等）

其他的 Worker 節(jié)點(diǎn)實(shí)現(xiàn)就相對(duì)比較簡(jiǎn)單了，它主要由 kubelet 和 kube-proxy 兩部分以及運(yùn)行時(shí)（docker）組成。
kubelet: 是工作節(jié)點(diǎn)執(zhí)行操作的 agent，負(fù)責(zé)具體的容器生命周期管理，根據(jù)從數(shù)據(jù)庫(kù)中獲取的信息來(lái)管理容器，并上報(bào) pod 運(yùn)行狀態(tài)等。
kube-proxy: 是一個(gè)簡(jiǎn)單的網(wǎng)絡(luò)訪問(wèn)代理，同時(shí)也是一個(gè) Load Balancer。它負(fù)責(zé)將訪問(wèn)到某個(gè)服務(wù)的請(qǐng)求具體分配給工作節(jié)點(diǎn)上同一類標(biāo)簽的 Pod。
kube-proxy 實(shí)質(zhì)就是通過(guò)操作防火墻規(guī)則(iptables，service ip到pod ip的映射)來(lái)實(shí)現(xiàn) Pod 的映射。（客戶端通過(guò)services的cluster ip來(lái)訪問(wèn)，這個(gè)代理會(huì)根據(jù)iptable規(guī)則重定向到其中的pod，流量大的時(shí)候還可以負(fù)載均衡）service就是一組pod,保證健壯性。

Pod、Service、Volume 和 Namespace 是 Kubernetes 集群中四大基本對(duì)象，它們能夠表示系統(tǒng)中部署的應(yīng)用、工作負(fù)載、網(wǎng)絡(luò)和磁盤資源，共同定義了集群的狀態(tài)。Kubernetes 中很多其他的資源其實(shí)只對(duì)這些基本的對(duì)象進(jìn)行了組合。
配置文件用yaml寫，kubectl 是 Kubernetes 自帶的客戶端，可以用它來(lái)直接操作 Kubernetes 集群。
介紹一下k8s。先說(shuō)是數(shù)據(jù)中心的操作系統(tǒng)，整體架構(gòu)什么樣（主節(jié)點(diǎn)和worker節(jié)點(diǎn)） 抽象層次值得學(xué)習(xí)（docker,pod,service,volume,ns）
關(guān)于存儲(chǔ)有幾種存儲(chǔ)方式接口統(tǒng)一；
關(guān)于網(wǎng)絡(luò)有pod唯一ip地址和service cluster ip地址，自己的網(wǎng)絡(luò)模型；
關(guān)于客戶端有自己的kubectl 和helm包管理工具。

如何在k8s上發(fā)布服務(wù)？
NodePort、LoadBalancer、Ingress控制器三種方式將服務(wù)公開(kāi)
NodePort：30000-32767）范圍內(nèi)分配一個(gè)端口，每個(gè)節(jié)點(diǎn)都將該端口代理到您的服務(wù)
LoadBalance服務(wù)類型會(huì)自動(dòng)部署一個(gè)外部負(fù)載均衡器，該外部負(fù)載均衡器與特定的IP地址關(guān)聯(lián)，并將外部流量路由到集群中的Kubernetes服務(wù)
Ingress控制器通常不會(huì)消除對(duì)外部負(fù)載均衡器的需要，只是在負(fù)載均衡器后面增加了一個(gè)額外的路由和控制層。

**

k8s基本命令了解

get describe log
**
最常用的就是查看某個(gè)ns下資源pod的使用情況 ： kubectl get pod -n ns. 在正式使用中，我們永遠(yuǎn)不會(huì)把資源發(fā)布在默認(rèn)命名空間。所以，永遠(yuǎn)不要忘記在get命令后面加上-n。

kubectl describe pod <pod名> -n <命名空間>來(lái)獲取一個(gè) pod 的基本信息。比如node信息知道pod在哪個(gè)機(jī)器上，label知道pod主要用途是什么，controll by知道創(chuàng)建pod上層資源是什么，繼續(xù)查看上層資源定位信息。container包含了每個(gè)docker的信息
如果出現(xiàn)問(wèn)題的話，可以在獲取到的信息的末尾看到Event段落，其中記錄著導(dǎo)致 pod 故障的原因。

kubectl logs <pod名>來(lái)查看pod的日志 通過(guò)添加-f參數(shù)可以持續(xù)查看日志.

kubectl create 創(chuàng)建資源 從yaml配置文件創(chuàng)建 和 簡(jiǎn)易創(chuàng)建.
kubectl explain 解釋配置,配置信息太多，抽象層次多。
kubectl delete 刪除一切！
kubectl edit <資源類型> <資源名>在實(shí)際使用中更偏向于人工修改某個(gè)配置項(xiàng)來(lái)解決問(wèn)題，例如修改鏡像地址解決拉取不到鏡像的問(wèn)題。kubectl apply -f <新配置文件名.yaml>例如你通過(guò)kubectl apply -f https://some-network-site/resourse.yaml命令從一個(gè)網(wǎng)站上部署了你的資源，這樣當(dāng)它的管理者更新了這個(gè)配置文件后，你只需要再次執(zhí)行這個(gè)命令就可以應(yīng)用更新后的內(nèi)容了，而且完全不用關(guān)心修改了哪些配置項(xiàng)。

nginx介紹和實(shí)戰(zhàn)

**
nignx是正向代理（為客戶端代理，服務(wù)端不知道），反向代理，負(fù)載均衡和動(dòng)靜分離。特點(diǎn)是內(nèi)存小，高性能高并發(fā)。

nignx還可以實(shí)現(xiàn)高可用，keeplived選項(xiàng)可以增加nginx服務(wù)器的數(shù)量；

Nginx配置文件（內(nèi)部也是epoll，接收客戶端新連接，然后子進(jìn)程線程處理它和服務(wù)器連接（負(fù)載均衡））
全局塊 ：影響 nginx 服務(wù)器整體運(yùn)行的配置指令。比如worker_process越大代表支持并發(fā)數(shù)越多。

events塊：主要影響Nginx服務(wù)器與用戶的網(wǎng)絡(luò)連接。比如： worker_connections 1024; ，支持的最大連接數(shù)。

第三部分 http塊
http 塊又包括 http 全局塊和 server 塊，是服務(wù)器配置中最頻繁的部分，包括配置代理、緩存、日志定義等絕大多數(shù)功能。
server塊：配置虛擬主機(jī)的相關(guān)參數(shù)。
location塊：配置請(qǐng)求路由，以及各種頁(yè)面的處理情況。
比如下面這個(gè)例子：在瀏覽器地址欄輸入 http://192.168.4.32/example/a.html ，平均到 5000 和 8080 端口中，實(shí)現(xiàn)負(fù)載均衡效果。
upstream myserver {
server 192.167.4.32:5000;
server 192.168.4.32:8080;
}

server {
listen 80; #監(jiān)聽(tīng)端口
server_name 192.168.4.32; #監(jiān)聽(tīng)地址

location  / {             
    root html;  #html目錄        
    index index.html index.htm;  #設(shè)置默認(rèn)頁(yè)    
    proxy_pass  http://myserver;  #請(qǐng)求轉(zhuǎn)向 myserver 定義的服務(wù)器列表      
}

}
在server里面監(jiān)聽(tīng)你要訪問(wèn)的那個(gè)網(wǎng)站和端口（http是80） 然后定義自己的服務(wù)器的ip+port。在location里面 proxy_pass設(shè)置為自己的地址， index設(shè)置默認(rèn)的網(wǎng)頁(yè)。
其中，負(fù)載均衡的形式可以是默認(rèn)輪詢，或者weight權(quán)重，或者 ip_hash，fair響應(yīng)時(shí)間短的得到；
location ~代表正則表達(dá)式匹配

Nginx 緩存 expires 3d; 通過(guò) expires 參數(shù)設(shè)置，可以使瀏覽器緩存過(guò)期時(shí)間之前的內(nèi)容，減少與服務(wù)器之間的請(qǐng)求和流量。

動(dòng)靜分離：設(shè)置動(dòng)靜兩個(gè)地址，然后location匹配，如果是jsp,php需要和后端交互的，就到動(dòng)態(tài)網(wǎng)址，靜態(tài)的比如jpg,css等就不需要和服務(wù)端交互了。

高可用怎么實(shí)現(xiàn)：
首先要安裝keeplivd程序， 相當(dāng)于一個(gè)路由，它通過(guò)一個(gè)腳本來(lái)檢測(cè)當(dāng)前服務(wù)器是否還活著，如果還活著則繼續(xù)訪問(wèn)，否則就切換到另一臺(tái)備份服務(wù)器。
修改配置文件，keepalived 將 nginx 服務(wù)器綁定到一個(gè)虛擬 ip ， nginx 高可用集群對(duì)外統(tǒng)一暴露這個(gè)虛擬 ip，客戶端都是通過(guò)訪問(wèn)這個(gè)虛擬 ip 來(lái)訪問(wèn) nginx 服務(wù)器 。

nignx原理：只是轉(zhuǎn)發(fā)操作，真正的處理請(qǐng)求是后端服務(wù)器做的。
一個(gè)master和若干worker進(jìn)程?？蛻舳税l(fā)送一個(gè)請(qǐng)求首先要經(jīng)過(guò) master，管理員收到請(qǐng)求后會(huì)將請(qǐng)求通知給 worker，多個(gè) worker 以爭(zhēng)搶的機(jī)制來(lái)?yè)寠Z任務(wù)，得到任務(wù)的 worker 會(huì)將請(qǐng)求經(jīng)由 tomcat（應(yīng)用容器） 等做請(qǐng)求轉(zhuǎn)發(fā)、反向代理、訪問(wèn)數(shù)據(jù)庫(kù)等

一個(gè) master 和多個(gè) worker 的好處？
可以使用 nginx -s reload 進(jìn)行熱部署。
每個(gè) worker 是獨(dú)立的進(jìn)程，如果其中一個(gè) worker 出現(xiàn)問(wèn)題，其它 worker 是獨(dú)立運(yùn)行的，會(huì)繼續(xù)爭(zhēng)搶任務(wù)，實(shí)現(xiàn)客戶端的請(qǐng)求過(guò)程，而不會(huì)造成服務(wù)中斷。

nignx的高級(jí)應(yīng)用？
跨域問(wèn)題：比如在一個(gè)前端項(xiàng)目里請(qǐng)求另一個(gè)后端；因?yàn)榭缬蛩哉?qǐng)求無(wú)法響應(yīng)。如果前后端都不想修改代碼，可以在nignx的server塊，add_header允許哪些跨域的請(qǐng)求、方法、cookie等。

配置SSL證書: 要在阿里云注冊(cè)域名，和SSL證書；然后為nginx加上http_ssl_module（：網(wǎng)站如果沒(méi)有備案，會(huì)被攔截，會(huì)導(dǎo)致不能訪問(wèn)，正規(guī)站點(diǎn)都是要備案的。）

防盜鏈配置 盜鏈通俗一點(diǎn)的理解就是別人的網(wǎng)站使用自己服務(wù)器的資源，比如常見(jiàn)的在一個(gè)網(wǎng)站引入其他站點(diǎn)服務(wù)器的圖片等資源，這樣被盜鏈的服務(wù)器帶寬等資源就會(huì)額外被消耗，在一定程度上會(huì)損害被盜鏈方的利益，所以防盜鏈?zhǔn)潜匾模贿@里通過(guò)nginx簡(jiǎn)單實(shí)現(xiàn)靜態(tài)資源防盜鏈的案例，原理很簡(jiǎn)單，就是判斷一下請(qǐng)求源是否被允許。在Location里面對(duì)于非法的直接return 403

總結(jié)：說(shuō)一下是什么和特點(diǎn)，原理，以及配置文件配置過(guò)程完成負(fù)載均衡，緩存；高可用實(shí)現(xiàn)；高級(jí)應(yīng)用。

（nginx,apache,tomcat區(qū)別）
首先nginx和apache都是只能處理靜態(tài)請(qǐng)求的。二者區(qū)別是nginx簡(jiǎn)單一點(diǎn)內(nèi)存低，apache支持的組件，配置，模塊比較復(fù)雜；第二就是nginx采用的是epoll+多進(jìn)程的非阻塞模型，高并發(fā)，apache是阻塞的多進(jìn)程。
tomcat主要功能是處理動(dòng)態(tài)元素（jsp,cgi,php等），是apache開(kāi)發(fā)的符合servelet標(biāo)準(zhǔn)的容器。一般nignx動(dòng)靜分離后動(dòng)態(tài)的就給tomcat處理。

rpc知識(shí)點(diǎn)（公司內(nèi)部通信）

遠(yuǎn)程過(guò)程調(diào)用，在微服務(wù)分布式背景下，涉及到不同服務(wù)器的協(xié)作。rpc就是為了讓調(diào)用遠(yuǎn)程方法根調(diào)用本地的一樣，只要規(guī)定參數(shù)名和參數(shù)就可以。
既然有了 http，為什么還要用 rpc 調(diào)用?
通信協(xié)議并不是rpc重點(diǎn)。rpc是一個(gè)方法，而http是一種協(xié)議.所以，更多的是封裝了 “服務(wù)發(fā)現(xiàn)”，“負(fù)載均衡”，“熔斷降級(jí)” 一類面向服務(wù)的高級(jí)特性?？梢赃@么理解，rpc框架是面向服務(wù)的更高級(jí)的封裝。
(rpc優(yōu)點(diǎn)：效率高二進(jìn)制但是不絕對(duì)因?yàn)閔ttp2也是二進(jìn)制； 簡(jiǎn)潔，方法多了后需要記住很多函數(shù)和參數(shù)（get,post等），rpc把方法存根在本地序列化傳送；最重要是封裝了高級(jí)特性） 缺點(diǎn)：可讀性低，雙方架構(gòu)需要一致。
http優(yōu)點(diǎn)：可讀性高，雙方語(yǔ)言架構(gòu)不需要一致。

常見(jiàn)的rpc: grpc,brpc, thrift,dubbo等
rpc調(diào)用框架
rpc調(diào)用框架是：服務(wù)端有個(gè)stub,他可以把服務(wù)B的接口對(duì)象（函數(shù)，參數(shù)）作為參數(shù)序列化，然后通過(guò)傳輸協(xié)議（http2，protobuf等）給B，B反序列化然后計(jì)算得到結(jié)果返回給A。

涉及到的技術(shù)：
1**.序列化協(xié)議**很重要的一部分
在網(wǎng)絡(luò)傳輸中，需要二進(jìn)制傳輸，所以要把對(duì)象轉(zhuǎn)換成字節(jié)序列。
序列化協(xié)議有哪些：
最早期的cobra com等太復(fù)雜需要匯編淘汰了 java自帶的庫(kù)，xml,json等（可讀性好但是時(shí)空效率低）protobuf 、Hessian2
protobuf核心就是消息message和接口service.服務(wù)端與服務(wù)端之間只需要關(guān)注接口方法名（service）和參數(shù)（message）即可通信，而不需關(guān)注繁瑣的鏈路協(xié)議和字段解析，極大降低了服務(wù)端的設(shè)計(jì)開(kāi)發(fā)成本。

動(dòng)態(tài)代理
RPC的調(diào)用內(nèi)部核心技術(shù)采用的就是動(dòng)態(tài)代理。
也就是要像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程。RPC 會(huì)自動(dòng)給我們生成一個(gè)動(dòng)態(tài)代理類，當(dāng)我們?cè)陧?xiàng)目中注入接口的時(shí)候，運(yùn)行過(guò)程中實(shí)際綁定是這個(gè)接口生成的代理類，這樣在接口方法被調(diào)用的時(shí)候，它實(shí)際上是被生成代理類攔截了，這樣我們就可以在生成的代理類里面，加入遠(yuǎn)程調(diào)用的邏輯。

服務(wù)注冊(cè)發(fā)現(xiàn)

（1）注冊(cè)與發(fā)現(xiàn)流程

服務(wù)注冊(cè)：服務(wù)提供方將對(duì)外暴露的接口發(fā)布到注冊(cè)中心內(nèi)，注冊(cè)中心為了檢測(cè)服務(wù)的有效狀態(tài)，一般會(huì)建立雙向心跳機(jī)制。
服務(wù)訂閱：服務(wù)調(diào)用方去注冊(cè)中心查找并訂閱服務(wù)提供方的 IP，并緩存到本地用于后續(xù)調(diào)用。

（2）如何實(shí)現(xiàn)：基于ZK

A. 在 ZooKeeper 中創(chuàng)建一個(gè)服務(wù)根路徑，可以根據(jù)接口名命名（例
如：/micro/service/com.laowang.orderService），在這個(gè)路徑再創(chuàng)建服務(wù)提供方與調(diào)用方目錄（server、
client），分別用來(lái)存儲(chǔ)服務(wù)提供方和調(diào)用方的節(jié)點(diǎn)信息。
B. 服務(wù)端發(fā)起注冊(cè)時(shí)，會(huì)在服務(wù)提供方目錄中創(chuàng)建一個(gè)臨時(shí)節(jié)點(diǎn)，節(jié)點(diǎn)中存儲(chǔ)注冊(cè)信息。
C. 客戶端發(fā)起訂閱時(shí)，會(huì)在服務(wù)調(diào)用方目錄中創(chuàng)建一個(gè)臨時(shí)節(jié)點(diǎn)，節(jié)點(diǎn)中存儲(chǔ)調(diào)用方的信息，同時(shí)watch 服務(wù)提供方的目錄（/micro/service/com.laowang.orderService/server）中所有的服務(wù)節(jié)點(diǎn)數(shù)據(jù)。當(dāng)服務(wù)端產(chǎn)生變化時(shí)ZK就會(huì)通知給訂閱的客戶端。
ZooKeeper方案的特點(diǎn)：
強(qiáng)一致性，ZooKeeper 集群的每個(gè)節(jié)點(diǎn)的數(shù)據(jù)每次發(fā)生更新操作，都會(huì)通知其它 ZooKeeper 節(jié)點(diǎn)同時(shí)執(zhí)行更新。

服務(wù)端調(diào)用代碼：生成一個(gè)zk類，開(kāi)啟，發(fā)布節(jié)點(diǎn)（包括服務(wù)和方法，服務(wù)是永久節(jié)點(diǎn)，方法是臨時(shí)節(jié)點(diǎn)，還會(huì)加ip+port）
客戶端：只要使用get_data方法就可以實(shí)現(xiàn)找到服務(wù)器的ip+port
客戶端還可以watch監(jiān)聽(tīng)服務(wù)，一旦有變化就能知道。

健康監(jiān)測(cè) 心跳機(jī)制

負(fù)載均衡和熔斷限流
負(fù)載均衡可以自己實(shí)現(xiàn)，一個(gè)計(jì)分器和指標(biāo)采集器，對(duì)cpu,內(nèi)存等打分，隨機(jī) 權(quán)重，輪詢，ip hash等策略進(jìn)行負(fù)載均衡。

限流：最簡(jiǎn)單的是計(jì)數(shù)器，還有平滑限流的滑動(dòng)窗口、漏斗算法以及令牌桶算法等等。比如響應(yīng)時(shí)間超過(guò)閾值那么接下來(lái)的時(shí)間窗口的服務(wù)都不接受。
一個(gè)服務(wù) A 調(diào)用服務(wù) B 時(shí)，服務(wù) B 的業(yè)務(wù)邏輯又調(diào)用了服務(wù) C，這時(shí)服務(wù) C 響應(yīng)超時(shí)，服務(wù) B 就可能會(huì)因?yàn)槎逊e大量請(qǐng)求而導(dǎo)致服務(wù)宕機(jī)，由此產(chǎn)生服務(wù)雪崩的問(wèn)題。

優(yōu)雅開(kāi)啟優(yōu)雅關(guān)閉
啟動(dòng)預(yù)熱，防止cache不熱；通過(guò)調(diào)用方通過(guò)服務(wù)發(fā)現(xiàn)獲取服務(wù)提供方的啟動(dòng)時(shí)間， 然后進(jìn)行降權(quán)，減少被負(fù)載均衡選擇的概率，從而實(shí)現(xiàn)預(yù)熱過(guò)程。
總結(jié):如何實(shí)現(xiàn)一個(gè)rpc框架
1、服務(wù)端、客戶端、zk
先進(jìn)行服務(wù)的注冊(cè)和發(fā)現(xiàn)，客戶端注冊(cè)，服務(wù)端發(fā)現(xiàn)（ip,port），以及監(jiān)聽(tīng)
客戶端通過(guò)動(dòng)態(tài)代理調(diào)用服務(wù)端的接口（里面有遠(yuǎn)程調(diào)用邏輯）,然后序列化協(xié)議傳參數(shù)，反序列化，計(jì)算結(jié)果，返回結(jié)果。

kafka介紹實(shí)戰(zhàn)
消息系統(tǒng)作用：解耦，異步，削峰。
整體架構(gòu)介紹一下。生產(chǎn)者，消費(fèi)者。 Kafka集群中，一個(gè)kafka服務(wù)器就是一個(gè)broker，Topic只是邏輯上的概念，partition在磁盤上就體現(xiàn)為一個(gè)目錄。不同分區(qū)可以在不同的broker上，增強(qiáng)并行能力。消費(fèi)者組，控制節(jié)點(diǎn)借助zookeepr進(jìn)行集群的管理。
副本節(jié)點(diǎn)分布在不同的broker實(shí)現(xiàn)高可用。

kafka優(yōu)秀架構(gòu)的思考：
高并發(fā)：三層網(wǎng)絡(luò)架構(gòu)：多selector- 多線程 -> 隊(duì)列的設(shè)計(jì)（NIO）.比傳統(tǒng)的reactor多了一層processor
高可用：副本機(jī)制
高性能： 寫方面實(shí)現(xiàn)了順序?qū)懘疟P：先寫到os內(nèi)核，在順序?qū)懘疟P，和rocks代表差不多，lsm樹。讀利用sendfile操作實(shí)現(xiàn)零拷貝操作，直接在內(nèi)核讀，不用拷貝到用戶。
以及一些日志分段存儲(chǔ)，以及isr機(jī)制保證可用性和一致性找到一個(gè)平衡，以及日志有offset，position兩個(gè)信息，稀疏索引寫在log里面，二分法查找。

生產(chǎn)環(huán)境：根據(jù)流量大小，按照最高的若干倍，評(píng)估需要多少物理機(jī)（以及硬盤若干T,內(nèi)存幾十個(gè)G，CPU32個(gè)，網(wǎng)速千兆萬(wàn)兆）文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-613739.html

到了這里，關(guān)于docker和k8s、nginx、rpc、kafka的學(xué)習(xí)介紹和實(shí)戰(zhàn)以及學(xué)習(xí)理念的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！