大型網(wǎng)站架構(gòu)2微服務(wù)介紹

一、微服務(wù)介什么是微服pizza團隊最早是亞馬遜CEOBezos提出來的，意思是說單個服務(wù)的設(shè)計，所有參開發(fā)、測試、運維所有2）所謂服務(wù)，一定要區(qū)別于系統(tǒng)，服微服務(wù)由微服務(wù)最早由MartinFowlerJamesLewis2014年共同提出，微服務(wù)架構(gòu)風(fēng)格是一為什么需要微服務(wù)，差，可靠性不高成本高。到后面引入了SOA服務(wù)化，但是，由于SOA早期均使用了總線模，切換時間太長，成本太高，新系統(tǒng)穩(wěn)定性的收斂也需要一些時間。最終SOA看起來很美，但卻成最期的單體架構(gòu)帶比的項目有幾十萬行代碼各個模塊之間區(qū)別比較模糊，邏輯比較代碼越多復(fù)雜性越高越難解決遇到的問題。技術(shù)逐漸上謂的技術(shù)越來越多。二十分鐘，這是多么的事情啊，啟動幾次項目一天的時間就過去了，留給開發(fā)者開發(fā)的時間就非常少了。比如以前的某個項目使用trt2用sringmvc來重構(gòu)這個項目將是非常的付出的成本將非常大所以的時候公司不得不硬著頭皮繼續(xù)使用老的trts架構(gòu)，這就阻礙了技術(shù)的創(chuàng)新。比如說模塊是CU密集型的模塊而訂單模塊是O密集型的模塊假如我們要提升訂單模塊的性能比如加大內(nèi)存、增加硬盤，但是由于所有的模塊都在一個架構(gòu)下，因此我們在擴展訂單模塊的性能時不得不考慮其它模塊的因素，因為我們不能因為擴展某個模塊的性能而損害其它模塊的性能，從而無法按需進行伸縮。微服務(wù)與單體架構(gòu)單體架構(gòu)所有的模塊全都耦合在一塊代碼量大， 微服務(wù)每個模塊就相當(dāng)于一個單獨的項目代碼量明顯少，遇到問題也相對來說比較好解決。單體架構(gòu)所有的模塊都共用一個數(shù)據(jù)庫，方式比較單一，微服務(wù)每個模塊都可以使用不同的方式（比的redis，有的用mysql等），數(shù)據(jù)庫也是單個模塊對應(yīng)自己的數(shù)據(jù)庫單體架構(gòu)所有的模塊開發(fā)所使用的技術(shù)一樣，微服務(wù)每個模塊都可以使用不同的開發(fā)技術(shù)，開發(fā)模式更靈活微服務(wù)與SOA區(qū)一個微服務(wù)的系可以有Java編寫的服務(wù)以有Python微服務(wù)本問等等微服務(wù)提倡的理念團隊間應(yīng)該是er-operate是定什么樣的項目適合微服微服務(wù)可以按照業(yè)務(wù)功能本身的獨立性來劃分，如果系統(tǒng)提供的業(yè)務(wù)是非常底層的，如：操作?。何⒎?wù)體積小，2pizza團隊獨：能夠獨立的部署和運行輕：使用輕量級的通信機制和架構(gòu)松：為服務(wù)之間是松耦合的從單體式結(jié)構(gòu)轉(zhuǎn)向微服務(wù)架構(gòu)中會持續(xù)碰到服務(wù)邊界劃分的問題：比如user服務(wù)來提供用戶的基礎(chǔ)信息，那么用戶的頭像和等是應(yīng)該單獨劃分為一個新的service更好還是應(yīng)該合并user服務(wù)里呢？如果服務(wù)的粒度劃分的過粗，那就回到了單體式的老路；如果過細(xì)，那服務(wù)間調(diào)用拆分的大原則是當(dāng)一塊業(yè)務(wù)不依賴或極少依賴其它服務(wù)，有獨立的業(yè)務(wù)語義，為超過2個的其他服意思是每個微服務(wù)只需要實現(xiàn)自己的業(yè)務(wù)邏輯就可以了，比如訂單管理模塊，它只需要處理訂單的業(yè)務(wù)邏輯就可以了，其它的不必考慮。意思是每個微服務(wù)從開發(fā)、測試運維等都是獨立的包括的數(shù)據(jù)庫也都是獨立的，自己就有一套完整的流程我們完全可以把它當(dāng)成一個項目來對待。不必依賴于其它模塊。輕量級通信原特每個服務(wù)為獨立的業(yè)務(wù)開發(fā)，一個微服務(wù)一般完成某個特定的功能，比如：訂單管理，用戶管理等微服務(wù)之間通過一些輕量級的通信機制進行通信，例如通RESTAPI或者RPC的方式進行調(diào)用特從而易于開發(fā)和。這是相對單個微服務(wù)來講的，相比于啟動單體架構(gòu)的整個項目，啟動某個模塊的服務(wù)速度明顯是要快很多的g我們只需要解決那個模塊的bg就可以了，解決完g之后，我們只需要重啟這個模塊的服務(wù)即可，部署相對簡單，不必重啟整個項目從而大大節(jié)約時間。比如訂單微服務(wù)和微服務(wù)原來都是用jva寫的，現(xiàn)在我們想把微服務(wù)改成nodJs技術(shù)，這是完全可以的，而且由于所關(guān)注的只是的邏輯而已，因此技術(shù)更換的成本也就會少很多。我們上面說了單體架構(gòu)在想擴展某個模塊的性能時不得不考慮到其它模塊的性能會不會受影響，對于我們微服務(wù)來講，完全不是問題，模塊通過什么方式來提升性能不必考慮其它模塊的情況。缺對于單體架構(gòu)來講我們只需要好這一個項目就可以了但是對于微服務(wù)架構(gòu)來講由于項目是由多個微服務(wù)構(gòu)成一步通過dbg的方式來，這就對運維人員提出了很高的要求。分布式的復(fù)雜接口調(diào)整成本比如用戶微服務(wù)是要被訂單微服務(wù)和微服務(wù)所調(diào)用的一旦用戶微服務(wù)的接口發(fā)生大的變動那么所有依賴它的微服務(wù)都要做相應(yīng)的調(diào)整，由于微服務(wù)可能非常多，那么調(diào)整接口所造成的成本將會明顯提高。微服務(wù)開發(fā)框SpringCloud：（現(xiàn)在非常流行的微服務(wù)架構(gòu)Dropwizard：（關(guān)注單個微服務(wù)的開發(fā)Consul、etcd&etc.（微服務(wù)的模塊Sprintcloud和Sprintboot區(qū)Spring旨在簡化創(chuàng)建產(chǎn)品級的Spring應(yīng)用和服務(wù)，簡化了配置文件，使用嵌入式web服務(wù)器，含有諸多開箱即用微服務(wù)springcloud聯(lián)合部署。Spring二、微服務(wù)實踐先客戶端如何這些服務(wù)？（API傳統(tǒng)的開發(fā)方式，所有的服務(wù)都是本地的，UI可以直接調(diào)用，現(xiàn)在按功能拆分成獨立的服務(wù)，跑在獨立的一般都在獨立的虛擬機上的Java進程了。客戶端UI如何他的？有N個服務(wù)，前所以，一般在N個服務(wù)和UI之間一般會一個或者叫APIGateway，他的作用包提供統(tǒng)一服務(wù)，讓微服務(wù)對前臺透聚合的服務(wù)，節(jié)省流量，提升性提供安全，過濾，流控等API管理功我的理解其實這個APIGteyVC框架甚至是一個Nodjs的服務(wù)端他們最重要的作用是為前（通常是移動應(yīng)用）提供服務(wù)的聚合提供一個統(tǒng)一的服務(wù)出口，解除他們之間的耦合，不過APIGtwy也有可能成為單點故障點或者性能的瓶頸。服務(wù)之間如何通信？（服務(wù)調(diào)用因為所有的微服Java進程跑在獨立的虛擬機上，所以服務(wù)展開來講都可以寫本書，而且大家一般都比較熟悉細(xì)節(jié)了，就不展開講了。REST（JAX-RS，SpringRPC（Thrift,異步消息調(diào)用(Kafka,的時候。RESTfulRPC的比較也是一個很有意思的話題。一般REST基于HTTP，更容易實有特殊的要求，只HTTPSDK就能調(diào)用，所以相對使用的廣一些。RPC用之間的緩沖，確保消息積壓不會沖垮被調(diào)用方，同時能保證調(diào)用方的服務(wù)體驗，繼續(xù)干自己該干有就是服務(wù)一般要實現(xiàn)冪等性，因為消息發(fā)送出于性能的考慮一般會有重復(fù)（保證消息的被技術(shù)積累，對broker分布式管理也是一個很大的。這么多服務(wù)怎么查找？（服務(wù)發(fā)現(xiàn)可能應(yīng)對臨時壓力增加新的服務(wù)節(jié)點。服務(wù)之間如何相互感知？服務(wù)如何管理？這就是服務(wù)發(fā)現(xiàn)的問題了。一般有兩類做法，也各有優(yōu)缺點?；径际峭ㄟ^zookeeper等類似技術(shù)做服務(wù)心跳維持長，實時更新信息。服務(wù)調(diào)用者通過ZK尋址，根據(jù)可定制算法，找到一個服務(wù)，還可以將服務(wù)信息緩存在本地以提高性能。當(dāng)服務(wù)下線時，ZK會發(fā)通知給服務(wù)客戶端。地址，有技術(shù)難度，一般大公司都有成內(nèi)部框架支持，比如Dubbo。服務(wù)掛分布式最大的特性就是網(wǎng)絡(luò)是不可靠的。通過微服務(wù)拆分能降低這個風(fēng)險，不過如果沒有特別的保障，結(jié)局肯定是噩夢。我們剛遇到一個線上故障就是一個很不起眼的SQL計數(shù)功能，在，用。所以當(dāng)我們的系統(tǒng)是由一系列的服務(wù)調(diào)用鏈組成的時候須確保任一環(huán)節(jié)出問題都不至于 ，重試機限熔斷機負(fù)載均降級（存）這些很詳Netflix的Hystrix微服務(wù)需要考慮的問API服務(wù)間服務(wù)發(fā)服務(wù)容服務(wù)部數(shù)據(jù)調(diào)三、微服務(wù)重要部微服務(wù)基本能服務(wù)中 服務(wù)中心是服務(wù)發(fā)現(xiàn)的。它保存了各個可用服務(wù)實例的網(wǎng)絡(luò)地址（IPAddress和Port）。服務(wù)中心必須要有高可用性和實時更新功能。上面提到的NetflixEureka就是一個服務(wù)中心。它提供了服務(wù)和查詢服務(wù)信息的RESTAPI。服務(wù)通過使用POST請求自己的IPAddress和Port。每30秒發(fā)送一個PUT請求刷新信息。通過DELETE請求注銷服務(wù)?？蛻舳送ㄟ^GET請求獲取可用的服務(wù)實例信息。Netflix的高可用（Netflixachieveshighavailability）AmazonEC2運行多個實例來實現(xiàn)的,每一個Eureka服務(wù)都有一個彈性區(qū)Eureka服務(wù)器地址。其他能夠作為服務(wù)中心的有：etcd—–高可用，分布式，強一致性的，key-value，KubernetesCloudFoundry都是使用了etcdconsul—–一個用于discovering和configuring的工具。它提供了允許客戶端和發(fā)現(xiàn)服務(wù)的API。Consul可以zookeeper——在分布式應(yīng)用中被廣泛使用，高性能的協(xié)調(diào)服務(wù)。ApacheZookeeper最初為Hadoop的一個子zookeeper服務(wù)和發(fā)zookeeper的某一路徑上:/{service}/{version}/{ip:port},比如我們的oWorldService部署到兩臺機器，那么zookeeper上就會創(chuàng)建兩條：分別為/zookeeper提供了“心跳檢測”功能，它會定時向各個服務(wù)提供者發(fā)送一個請求（實際上建立的是一個socket長連接），如果長期沒有響應(yīng)，服務(wù)中心就認(rèn)為該服務(wù)提供者已經(jīng)“掛了”，并將其剔除，比如2這臺機器如果宕機了，那么zookeeper上的路徑就會只剩加或減少），zookeeper都會通知服務(wù)消費方服務(wù)提供者地址列表已經(jīng)發(fā)生改變，從而進行更新。更為重要的是zookeeper與生俱來的容錯容災(zāi)能力（比如leader），可以確保服務(wù)表的負(fù)載均負(fù)載均衡的常見策隨輪輪例如：服務(wù)器A的權(quán)值被設(shè)計成1，B的權(quán)值是3，C的權(quán)值是6A、B、C將分別接受IP這種方式通過生IP的哈希值，并通過這個哈希值來找到正確的真實服務(wù)器。最少連接更加符合實際情況，負(fù)載更加均衡。此種均衡算法適合長時處理的請求服務(wù)，如FTP容容錯策快速失失效切失敗安失敗安全，當(dāng)服務(wù)調(diào)用出現(xiàn)異常時，直接忽略。通常用于寫入日志等操作失敗自動恢forking來設(shè)置最大并行廣播調(diào)熔序自RPC調(diào)用,來防止錯誤進一步擴大。實現(xiàn)一個熔斷器主要是考慮三種模式，關(guān)閉，我們在處理異常的時候，要根據(jù)具體的業(yè)務(wù)情況來決定處理方式，比如我們調(diào)用商品接口，對 機來實現(xiàn)關(guān)閉Closed)：默認(rèn)情CircuitBreaker是關(guān)閉的，此時允許操作執(zhí)行。CircuitBreaker內(nèi)部記錄著最近失敗CircuitBreaker會轉(zhuǎn)換到開啟Open狀態(tài)。在開啟狀態(tài)中，CircuitBreaker會啟用一個超時計時器，設(shè)這個計時器的目的是給集群相應(yīng)的時間來恢復(fù)故障。當(dāng)計時器時間到的時候，CircuitBreaker會轉(zhuǎn)換到半開啟(Half-Open)開啟(Open)：在此狀態(tài)下，執(zhí)行對應(yīng)的操作將會立即失敗并且立即拋出異半開啟(Half-Open)：在此狀態(tài)下CircuitBreaker會允許執(zhí)行一定數(shù)量的操作。如果所有操作全部成功，CircuitBreaker就會假定故障已經(jīng)恢復(fù)，它就會轉(zhuǎn)換到關(guān)閉狀態(tài)，并且重置失敗次數(shù)。如果其中任意一次操作失敗了，CircuitBreaker就會認(rèn)為故障仍然存在，所以它會轉(zhuǎn)換到開啟狀態(tài)并再次開啟計時器（再給系統(tǒng)一些時間使失敗中恢復(fù)限流和降的一份合同，其中定義了服務(wù)類型、服務(wù)質(zhì)量和客戶付款等術(shù)語。典型的SLA包括以下項目：分配給客戶的最小帶客戶帶寬極限能同時服務(wù)的客戶數(shù)在可能影響用戶行為的網(wǎng)絡(luò)變化之前安排撥入可用性運用統(tǒng)計學(xué)服務(wù)供應(yīng)商支持的最小網(wǎng)絡(luò)利用性能，如99.9%有效工作時間或每天最多為1分鐘的停機時間各類客戶的流量優(yōu)先客戶技術(shù)支持和服務(wù)懲罰規(guī)定，為服務(wù)供應(yīng)商不能滿足SLA需求所指定API網(wǎng)多級緩最簡單的緩存就是查一次數(shù)據(jù)庫然后將數(shù)據(jù)寫入緩存比如redis中并設(shè)置過期時間。因為有過期失效因此我們要關(guān)注下緩存的率，這個率的計算，比如查詢方法queryOrder(調(diào)用率就是300/1000,在這種使用緩存的方式下是要重視率的率大了說明緩存的效果入一個時間戳每次數(shù)據(jù)的時候用系統(tǒng)當(dāng)前時間和上次設(shè)置的這個時間戳做對比比如超過5分鐘，那么就再查一次數(shù)據(jù)庫。這樣可以保證redis里面有數(shù)據(jù)，一般是對DB的一種容錯方法。還有一個就是真正的redisDB使用。就是圖里面畫的通過訂閱數(shù)據(jù)庫binlog通過數(shù)據(jù)異構(gòu)系統(tǒng)將數(shù)據(jù)推送給緩存，同時將將緩存設(shè)置為多級?？梢酝ㄟ^jvmcache作為應(yīng)用內(nèi)的一級緩存，一般是體積小，頻率大的更適合這種jvmcache方式，將一套redis作為二級remote緩存，另外最外層redis作為持久化緩存。超時和重超時與重試機制也是容錯的法，凡是發(fā)生RPC調(diào)用的地方，比如redis，db，mq些環(huán)節(jié)，一次正常的調(diào)用統(tǒng)計的耗時主要包括：①調(diào)用端RPC框架執(zhí)行時間②網(wǎng)絡(luò)發(fā)送時間③服務(wù)端RPC框架執(zhí)行時間+④服務(wù)端業(yè)務(wù)代碼時間。調(diào)用方和服務(wù)方都有各自的性能，比時間都花在什么地方了呢，兩種原因，客戶端調(diào)用方，還有一個原因是網(wǎng)絡(luò)發(fā)生TCP重傳。所以要線程在抗量這個環(huán)節(jié)，Servlet3異步的時候，有提到過線程。線程的之間優(yōu)勢就是防級聯(lián)故障，甚至是雪崩。當(dāng)網(wǎng)關(guān)調(diào)用N多個接口服務(wù)的時候，我們要對每個接口進行線程。比降級和限關(guān)于降級限流的方法業(yè)界都已經(jīng)有很成方法了，比如FAILBACK機制