springcloud中有eureka、ribbon、feign、hystrix、zuul這幾個重要元件
●建立服務註冊與發現中心（eureka-server）
●feign的乙個關鍵機制就是使用了動態**
1、首先，如果你對某個介面定義了@feignclient註解，feign就會針對這個介面建立乙個動態**
2、接著你要是呼叫那個介面，本質就是會呼叫 feign建立的動態**，這是核心中的核心
4、最後針對這個位址，發起請求、解析
響應●ribbon負載均衡ribbon是和feign以及eureka緊密協作，完成工作的
1、首先ribbon會從 eureka client裡獲取到對應的服務登錄檔，也就知道了所有的服務都部署在了哪些機器上，在監聽哪些埠號。
2、然後ribbon就可以使用預設的round robin演算法，從中選擇一台機器
3、feign就會針對這台機器，構造並發起請求。
●hystrix
1、如果系統處於高併發的場景下，大量請求湧過來的時候，訂單服務的100個執行緒都會卡在請求積分服務這塊。導致訂單服務沒有乙個執行緒可以處理請求
2、然後就會導致別人請求訂單服務的時候，發現訂單服務也掛了，不響應任何請求了
3、我們結合業務來看：支付訂單的時候，只要把庫存扣減了，然後通知倉庫發貨就ok了
4、如果積分服務掛了，大不了等他恢復之後，慢慢人肉手工恢復資料！為啥一定要因為乙個積分服務掛了，就直接導致訂單服務也掛了呢？不可以接受！
5、那人家又說，兄弟，積分服務掛了你就熔斷，好歹你幹點兒什麼啊！別啥都不幹就直接返回啊？沒問題，咱們就來個降級：每次呼叫積分服務，你就在資料庫裡記錄一條訊息，說給某某使用者增加了多少積分，因為積分服務掛了，導致沒增加成功！這樣等積分服務恢復了，你可以根據這些記錄手工加一下積分。這個過程，就是所謂的降級。
總結：
eureka：各個服務啟動時，eureka client都會將服務註冊到eureka server，並且eureka client還可以反過來從eureka server拉取登錄檔，從而知道其他服務在**
ribbon：服務間發起請求的時候，基於ribbon做負載均衡，從乙個服務的多台機器中選擇一台
feignhystrix：發起請求是通過hystrix的執行緒池來走的，不同的服務走不同的執行緒池，實現了不同服務呼叫的隔離，避免了服務雪崩的問題
zuul：如果前端、移動端要呼叫後端系統，統一從zuul閘道器進入，由zuul閘道器**請求給對應的服務
初次接觸perl
今天貝在煩乙個程式，也為難他了，剛學perl不到兩天，就讓他寫程式完成功能，雖然現在他有很大的提高，但是也還是心裡沒底啊。第一次布置的任務，他說如果不完成還是挺不好的，呵呵，沒辦法，我就樂於助人，趕緊看了看perl的大概語法，變數迴圈等，然後找了相關的網頁看了看，還好，因為比較熟悉c語言，而且上過s...
初次接觸powershell
在linux下接觸shell後，發現shell的功能是如此的強大！window呢？同樣，學習了 nix的做法，實現了shell，稱為powershell，在我看來，這個名字取得不過份，它通過。net與shell的結合，提供了強大的平台操作功能，提供了與 nix的相同的命令的語法，令 nix的程式設計...
初次接觸VBS
隨便找了段vbs程式，分析語句on error resume next 使程式按照產生錯誤的語句之後的語句繼續執行，具體見 dim sourcepath dim numb dim應該是定義變數吧，猜得set初始化變數 sub filew 寫檔案 dim fso,myfile set fso crea...