建站
咨詢
售后
建站咨詢
新聞中心
這幾天可真是熱啊，泡個海澡是再好不過了。玩的正起勁，突然腳底絆上一股暗流，然后我就一直在水里旋轉(zhuǎn)旋轉(zhuǎn)旋轉(zhuǎn)。終于眼前一黑，愛的魔力轉(zhuǎn)圈圈，我穿越了......
威寧網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),威寧網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為威寧成百上千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的威寧做網(wǎng)站的公司定做！
鄰國相望，雞犬之聲相聞，民至老死不相往來。這個世界被小諸侯給切的七零八落，一鍋亂麻。
而現(xiàn)實是，我的國家因為常年打仗，剩下的女人很多，需要打通遠嫁他方的通道;而 A 國盛產(chǎn)長得和豬一樣大的耗子，賣的很好。它們可以做成皮大氅，用來取暖。所以交流是在所難免的。
現(xiàn)實是這樣的：
- A 國不知道 B 國身處何方，經(jīng)常有牧民捧著藏寶圖一樣的破布，葬身在崎嶇的山路上。
- B 國聽不懂 C 國含糊不清的吐詞，感覺他們在求救，等跑近一看，卻發(fā)現(xiàn)其實是在罵娘。
- C 國生產(chǎn)的南瓜就知道賣給 D 國，剩下的都爛在了地里，E 國都開始吃樹皮了。
- F 國倒是遠近聞名，但四面八方蜂擁而至的難民，讓他們非?？鄲?。其中，G 國的難民，最是惡劣。
曾有其他大陸板塊的使者，5 年不得要領(lǐng)。見神粥大地現(xiàn)狀，作詩一首：《真 TM 亂》。
作為一個穿越者，一個憐憫眾生的剩人。我要留給這個世界一張藍圖，好讓后人記住我的名字。同時，我也想起了，我為什么有這種這種強大的自信。
“回憶”的片段將我?guī)Щ氐?21 世紀。
我要聊點技術(shù)了：單體應(yīng)用
我們剛開始的服務(wù)，其實并沒有那么復雜。我只有一臺配置非常低的機器，我的應(yīng)用，我的代碼，我的聰明才智，全部在這一個小小的工程里面。
由于我是搞 IT 的，所以我的項目名字就叫 jisuanji。有人說我用中文拼音做項目名，太那個。
我不聽，我就是這么命名。我還把公共模塊叫 gg，密碼字段叫 mm，誰管得著呢。
對，看下面的圖，就是這么簡單。項目能活到用 Nginx 來做負載均衡這一步，就算是小成功了。
這個時候，所有的代碼就是一個整體，用戶訪問什么，我直接給就是。
我拆成了兩個服務(wù)
可能是我和我一樣二的人有點多，我的項目訪問量越來越大，這也許就叫臭味相投吧。
我自己的開發(fā)速度，已經(jīng)追不上頭腦里的 Idea，是時候招個人對服務(wù)進行拆分了。
不能拆的太過火，所以剛開始，我把 jisuanji 拆成了兩個服務(wù)。其中的服務(wù) B，僅僅部署了一個節(jié)點，因為它的壓力還不是太大。
即使這樣，我不得不買上 3 臺服務(wù)器來部署服務(wù)節(jié)點，真是肉痛。我這么摳門的人，數(shù)據(jù)庫當然也是共用的。雖然有時候機器壓力有點大，但暫時還死不了人。
這個時候我就面臨了一個選擇問題：服務(wù) A 要怎么訪問服務(wù) B 呢?
由于我搞過一段時間的 Web Service，首先就想到了它。但這玩意太重了，我還不如通過 HTTP 訪問來的舒爽。
通過 HTTP Client，或者 Ok Http，我的服務(wù) A，現(xiàn)在可以直接模擬 HTTP 請求訪問服務(wù) B 了。
當團隊里有第二個人，就開始吐槽我的項目了。以下是他羅列的，我的項目的罪狀：
- 復雜度太高，代碼嚴重耦合。
- 技術(shù)債務(wù)多，拍腦袋需求一籮筐。
- 代碼不規(guī)范，一坨屎。
- 技術(shù)創(chuàng)新難，一個類幾千行…
至于么?從一個服務(wù)拆成兩個，就這么吐槽我。不過為了以后能拆出成百上千個服務(wù)，這口氣我暫時忍了，畢竟我這人還是比較虛心的。
亂成一鍋粥了
等過去半年一看，好家伙，服務(wù)給我拆了了幾十個。當我的同伴把系統(tǒng)結(jié)構(gòu)圖拿給我看，我直接懵逼了。
我挑了 9 個能看的服務(wù)，畫了張圖：
首先進行了業(yè)務(wù)拆分。比如支付業(yè)務(wù)，訂單業(yè)務(wù)，用戶中心，商品中心等，都組建了獨立的團隊。每個業(yè)務(wù)又進行了細分，拆分成不同的服務(wù)。
在這之間，進行了下面的改動：
- 有小伙伴寫了個通用的 HTTP Client 調(diào)用組件，自己的負載均衡策略。
- 有另外一個小伙伴，習慣 Protobuf，所以選了 gRPC。
- 事實證明 SOA 還是有市場的，這不，就有幾個服務(wù)的交互引入了 Web Service。
- 有人想要用 RMI，被我及時發(fā)現(xiàn)、否決，腹死胎中了。
- 每次建個新服務(wù)，都需要更新一下 Excel，然后將這個 Excel 周知出去。
現(xiàn)在的整個系統(tǒng)，簡直是個四不像。什么通信方式都有，什么交互格式都不缺。
拿最要命的 D 服務(wù)來說，光通訊模塊，就引入了 20 幾個 Jar 包。如果應(yīng)用擴展到上千個…My God…
更要命的是，這么多服務(wù)，每次上線一個模塊都膽戰(zhàn)心驚，因為他不知道到底會有什么連鎖反應(yīng)。
是時候叫出超級飛俠了。哦不，叫出微服務(wù)了。
微服務(wù)來襲
目前，最火的微服務(wù)框架，就是 Spring Cloud 了。雖然 Netflix 公司對某些組件的維護經(jīng)常爽約，但有些核心組件還是非常經(jīng)典的。
注冊中心：Eureka
服務(wù) A，怎么找到服務(wù) B，有很多種方式。比如你生活在一個小鎮(zhèn)上，你問 xjjdog 是誰，老王可能認識他，但小李可能并不知曉;但小李認識老王，所以通過他最終也能找到 xjjdog，只不過麻煩一些。
你可以隨便拉小鎮(zhèn)上的一個人，來問 xjjdog 是誰。你還會變戲法一樣拿出一個小本本，把你認識的人，都告訴他們。當你腦殘式的問了一個遍，到最后所有人都知道 xjjdog 了。
上面說的就是 Gossip 協(xié)議。最終，你們都能夠知道彼此，因為都是大嘴巴。
比如小鄭生了個孩子，過不了多少時間，全鎮(zhèn)子的人都把這個孩子記錄在本子上了。用這種方式，服務(wù)都能夠知道彼此，完成通信。
可惜這并不美好，從小鎮(zhèn)的東頭跑到西頭，需要很長時間。在這個時間里，小鄭剛生的孩子可能因為先天疾病夭折了。我們需要一種信息集中度和實效性更高的方式。
這就需要一個中心，那里的信息就是權(quán)威。 在 Spring Cloud 體系中，最常用的注冊中心就是 Eureka。
任何服務(wù)啟動以后，都會把自己注冊到 Eureka 的注冊表中;當服務(wù)死亡的時候，也會通知 Eureka。
這樣，當服務(wù) A 想要找服務(wù) B 的時候，只需要問一下 Eureka Server 就可以了，它什么都知道。
為了達到這個目的，還是要有一部分工作量的。且看下圖。這個注冊動作，是由一個叫做 Eureka Client 的組件來完成的。
服務(wù)啟動和關(guān)閉的時候，會通過這個組件推銷自己;而當服務(wù) A 想要調(diào)用服務(wù) B 的時候，直接問 Eureka Server 就可以了。服務(wù) A 拿到結(jié)果后，會把結(jié)果緩存在本地的注冊表里。
你可以認為是一個拷貝。所以 Eureka Server 死掉后，并不影響服務(wù) A 找到服務(wù) B。
負載均衡組件：Ribbon
現(xiàn)在問題來了。服務(wù) A 拿到服務(wù) B 的實例列表以后，發(fā)現(xiàn)有兩臺。
- 10.0.0.12
- 10.0.0.16
接下來麻煩了，該調(diào)哪臺機器呢?這就是 Spring Cloud 中組件 Ribbon 的作用。
其實 Round Robin 是一個通用的計算機術(shù)語。它是最常用的負載均衡策略，請求會均勻的分配給后面的每臺服務(wù)器。
Ribbon 工作時，會做下面四件事：
- 優(yōu)先選擇在一個 Zone 且負載較少的 Eureka Server，進行連接。
- 定期從 Eureka 更新、過濾服務(wù)和實例列表。
- 根據(jù)負載均衡策略，從注冊表中選擇一個真正的實例地址。
- 通過 Rest Client 對服務(wù)發(fā)起調(diào)用。
可以看到，Ribbon 背后，還是采用的 HTTP 協(xié)議進行交互?？匆韵麓a，就可以直接實現(xiàn)對遠端服務(wù)的調(diào)用：
- @Bean
- @LoadBalanced
- RestTemplate restTemplate(){
- return new RestTemplate();
- }
- ...
- @Autowired
- RestTemplate restTemplate;
- public String test() {
- return restTemplate.getForObject("http://test-service/test", String.class);
- }
Ribbon 的 Filter 會查找 Test-Service，并替換成相應(yīng)的實例地址。
Ribbon 不僅僅提供了輪詢的策略，還有其他的，比如：
- 隨機 Random
- 根據(jù)響應(yīng)時間加權(quán)
- 自定義
拿輪詢來說，最終的選擇邏輯就在 RoundRobinRule 類中：
- private int incrementAndGetModulo(int modulo) {
- for (;;) {
- int current = nextServerCyclicCounter.get();
- int next = (current + 1) % modulo;
- if (nextServerCyclicCounter.compareAndSet(current, next))
- return next;
- }
- }
為簡化代碼而生：Feign
可以看到，Ribbon 需要自己構(gòu)建 HTTP 請求，模擬 HTTP 請求然后使用 RestTemplate 發(fā)送給其他服務(wù)，步驟相當繁瑣。而且返回類型不安全，也表達不出什么語義。
其實，通過 Ribbon 方式，已經(jīng)能夠完成微服務(wù)之間的調(diào)用了。但 Spring Cloud 的開發(fā)語言是 Java，肯定要進行更加高級的封裝，才能體現(xiàn)它的逼格。
Feign 得益于 Java 的動態(tài)代理機制，最終封裝出一套簡潔的接口調(diào)用方式，將需要調(diào)用的其他服務(wù)的方法定義成抽象方法即可，不需要自己構(gòu)建 HTTP 請求。
首先，F(xiàn)eign 會根據(jù) @FerignClient 注解，通過動態(tài)代理，創(chuàng)建一個動態(tài)代理類。
接下來，你只要通過調(diào)用接口的方式，就可以構(gòu)造上面提到的 Ribbon 調(diào)用參數(shù)，這個過程會自動填充。最后，通過構(gòu)造的 Ribbon 請求，發(fā)起真正的調(diào)用，并通過反射組裝返回值。
所以，F(xiàn)eign 只是一層皮，最終還是要通過 Ribbon 進行調(diào)用。在我看來，把 Ribbon 和 Feign 合成一個組件，也是合理的。
它們有一個比較通用的名詞，就叫做 RPC(遠程調(diào)用)。
異常的保護傘：斷路器 Hystrix
下面以一個支付請求為例，說一下不是風平浪靜的情況下，服務(wù)會有什么反應(yīng)。
每一個真正的支付請求，都會調(diào)用其他四個服務(wù)。首先，使用鑒權(quán)服務(wù)，獲取用戶的支付權(quán)限;然后，風控服務(wù)會做一些規(guī)則驗證。
為了更好的推銷產(chǎn)品，會調(diào)用營銷業(yè)務(wù)，獲取一些推薦信息;最后，調(diào)用聚合支付服務(wù)，進行真正的支付。
其中，營銷業(yè)務(wù)其實是可有可無的。讓用戶首先把錢花出去，是我們的首要任務(wù)。
考慮下面一種場景，營銷業(yè)務(wù)由于系統(tǒng)故障或者負載問題，發(fā)生了大面積的不可用或者超時。然后，所有的請求都卡在了獲取營銷信息的代碼上。
如圖所示，鑒權(quán)和風控都已經(jīng)通過了。因為一個旁路功能：營銷業(yè)務(wù)，導致真正的支付無法進行。這個時候，如果有人調(diào)用支付請求，會發(fā)現(xiàn)支付請求也出錯了。
因為它們最終都卡在了營銷這一段小代碼上：
所以，對于營銷業(yè)務(wù)這種不是鏈路上必備的服務(wù)提供者，要有一個手段，讓它在發(fā)生問題的時候，隔離它一段時間。
負責這個功能的組件，就叫做 Hystrix。以我們編程的思維來說，這就是個 if 條件：
- if(服務(wù)發(fā)生問題){
- return "暫時不要處理";
- }
但我們不能這么編碼在業(yè)務(wù)代碼里。所以 Hystrix 對每個服務(wù)開了一個線程池，并有比較復雜的規(guī)則，來控制這些出問題的服務(wù)的行為。
比如，在2分鐘內(nèi)，直接返回營銷業(yè)務(wù)的默認結(jié)果，而不是一直卡在那里。
這個過程，就叫熔斷。就像電源一樣，出了問題，先切斷保險絲，別把電器給燒了。
此網(wǎng)關(guān)非彼網(wǎng)關(guān)：Zuul
API 網(wǎng)關(guān)是一個反向的路由，它屏蔽了內(nèi)部的細節(jié)，為調(diào)用者提供了統(tǒng)一的入口。
網(wǎng)關(guān)，其實是一堆過濾器的幾何，可以實現(xiàn)一系列和業(yè)務(wù)無關(guān)的橫切面功能。
熟悉 Spring 的都知道 AOP，路由的一個功能，就是針對于分布式服務(wù)的一個 AOP。
還是先說下網(wǎng)關(guān)的職責吧。簡單羅列幾個：
- 安全認證。提供統(tǒng)一的認證方式和鑒權(quán)功能，避免重復開發(fā)。
- 熔斷，限流。針對問題服務(wù)，進行熔斷操作;對流量進行預估，限制訪問。
- 日志監(jiān)控。統(tǒng)一流量入口，進行流量分析和監(jiān)控。
- 屏蔽內(nèi)部細節(jié)，對外提供一致的接口。
- 實現(xiàn)灰度。使用自定義策略實現(xiàn)分流，達到測試的目的。
網(wǎng)關(guān)的位置，大體就如下圖：
可以看到，我們平常用的 Nginx，就可以當作網(wǎng)關(guān)。但對于微服務(wù)來說，Nginx 的配置實在是太麻煩了。
不是說 Nginx 功能不夠強大，而是因為它們不是一個體系的，就存在整合成本(比如 Kong)。
Zuul 就不一樣了，它和 Spring Cloud 的其他組件，是一家子的。一家子的，當然會特殊照顧。
Zuul 本身就是一個 Servlet，外部請求經(jīng)過一系列 Filter 后，會達到真正的服務(wù)。上面說的熔斷器，就是高度集成的。
一張聚合圖
有了上面關(guān)鍵組件，事情就明了的多了。我們把它放在一張圖中，就是下面的樣子：
我們將其簡化一下，就可以得到一張更簡潔的圖?？梢钥吹剑恍枰?3 個關(guān)鍵點：
- 服務(wù)注冊中心，統(tǒng)一管理所有服務(wù)的信息，默認組件是 Eureka。
- RPC，網(wǎng)絡(luò)通信組件，服務(wù) A 怎么調(diào)用服務(wù) B。在 Spring Cloud 中，就是 Ribbon+Feign。
- 網(wǎng)關(guān)，拆分的服務(wù)怎么暴露接口，最終見人的樣子。默認組件是 Zuul。
一點道理
處理雜亂無章的事情，最有效的途徑，就是集權(quán)和中心化。集權(quán)和中心化的核心就是授權(quán)或者認同，否則注定失敗。
授權(quán)是對上，各位當權(quán)者應(yīng)該同意我的做法，所以我需要用極其易懂的語言，去說服他們接受這個體系;認同，是對下，最好是從人民的抱怨聲中，出具的改善措施，所以要權(quán)威專業(yè)。
和微服務(wù)一樣，需要給一些陳舊的概念，強行賦予看起來比較自然的新意義。比如我把統(tǒng)一語言，叫做文化融合，就顯得高大上一些。
第二個，就是把職責拆的足夠細。夠細才能夠精，每個位置上的人才能各司其職。
還有一點，整個過程，要能夠系統(tǒng)化，能夠進行推演。如果一件事有著不可預料的后果，那是冒險家干的事情。
一些途徑
為了對世界進行初步的了解，我成立了資源統(tǒng)計部，對山川河流進行了初步的勘查，繪制出有章可循的地圖。對社會的現(xiàn)狀和錯綜復雜的關(guān)系進行了摸底。
我把這些信息出版成圖書，遭到藏寶圖收藏者們的嫉妒和憎惡。他們躲藏在不為人知的角落，齷齪行事。
我還選了一個自己覺得好聽的方言，統(tǒng)一了每個諸侯國的語言。在推行的過程中，多次受到土著們強烈的反對，拒不改正。被我強行斬首了幾個之后，以后的推行，就快的多了。
對于所有的重要商品，進行了集中管控。這個世界貴重的不是黃金，而是食物，所以我還修建了四通八達的道路和無孔不入的交易中心。
從此之后，很少餓死過人。由于這部分是在我的控制范圍內(nèi)，所以進行的很順暢。
G 國的民風比較彪悍，經(jīng)常發(fā)生暴力事件。這也難免，從剛開始，這個國家就難以馴化。好在缺了他們，這個系統(tǒng)也能循環(huán)的下去。
前不久 G 國又發(fā)生了重大的事件，所有其他國家聯(lián)合抵制，禁止 G 國國民入境。但時間是化解傷痛的良藥，我估計這樣的限制不會持續(xù)很久。
但糟粕還是有的。有人的地方，就有江湖，就有壓迫。但這樣的糟粕我是不想讓其他人看到的。
來訪的使者，應(yīng)該只能夠看到歌舞升平、安居樂業(yè)，這注定了不能讓他們和底層接觸，否則就發(fā)現(xiàn)金玉其外敗絮其中的現(xiàn)狀了。
他們和外交官打的不亦樂乎，我很欣慰。
結(jié)語
我清楚的知道，為了建立一個和諧自然的系統(tǒng)，曾經(jīng)花費了多大的代價。這其中的組成部分，并不能總是完美無缺的運行。
而且，在這個看似平和的整體上，就滋生了其他無數(shù)令人頭痛的問題 ，不過這是另外一個話題了。
就是這樣。我所做的一切，我所有的期望，只不過是為了：當新的機會在我身后，我能夠從容的、華麗的轉(zhuǎn)身。
這就是我為了有一天能夠穿越，所做的準備。
網(wǎng)站欄目：一次性講明白SpringCloud核心組件
網(wǎng)頁路徑：http://www.5511xx.com/article/coigidh.html
