較近一直在針對(duì)SpringCloud框架做項(xiàng)目,從中踩了不少的坑,也漸漸梳理出了一些內(nèi)容,由于SpringCloud作為一個(gè)全家桶,其中東西太多,所以這時(shí)候就要有所取舍,這里就想把自己比較常用組件及架構(gòu)推薦上來。
需要JAVA Spring Cloud大型企業(yè)分布式微服務(wù)云構(gòu)建的B2B2C電子商務(wù)平臺(tái)源碼
針對(duì)這個(gè)架構(gòu)圖我分層介紹一下:
1、是web服務(wù)器的選型,這個(gè)我選擇的是nginx+keepalived,haproxy也是一個(gè)選擇,但是haproxy在反向代理處理跨域訪問的時(shí)候問題很多。所以我們nginx有些地方做了keep-alive模式處理,減少了三次握手的次數(shù),提高了連接效率。keepalived做nginx的負(fù)載,虛擬一個(gè)vip對(duì)外,兩個(gè)nginx做高可用,nginx本身反向代理zuul集群。
2、api gateway,這里的zuul很多人詬病,說是速度慢推薦直接用nginx,這里我還是推薦使用zuul的,畢竟zuul含有攔截器和反向代理,在權(quán)限管理、單點(diǎn)登錄、用戶認(rèn)證時(shí)候還是很有用的,而且zuul自帶ribbon負(fù)載均衡,如果你直接用nginx,還需要單獨(dú)做一個(gè)feign或者ribbon層,用來做業(yè)務(wù)集群的負(fù)載層,畢竟直接把接口暴露給web服務(wù)器太危險(xiǎn)了。這里zuul帶有ribbon負(fù)載均衡和hystrix斷路器,直接反向代理serviceId就可以代理整個(gè)集群了。
3、業(yè)務(wù)集群,這一層我有些項(xiàng)目是分兩層的,就是上面加了一個(gè)負(fù)載層,下面是從service開始的,底層只是單純的接口,controller是單獨(dú)一層由feign實(shí)現(xiàn),然后內(nèi)部不同業(yè)務(wù)服務(wù)接口互調(diào),直接調(diào)用controller層,只能說效果一般,多了一次tcp連接。所以我推薦合并起來,因?yàn)樽鲞^spring cloud項(xiàng)目的都知道,feign是含有ribbon的,而zuul也含有ribbon,這樣的話zuul調(diào)用服務(wù)集群,和服務(wù)集群間接口的互調(diào)都是高可用的,保證了通訊的穩(wěn)定性。Hystrix還是要有的,沒有斷路器很難實(shí)現(xiàn)服務(wù)降級(jí),會(huì)出現(xiàn)大量請(qǐng)求發(fā)送到不可用的節(jié)點(diǎn)。當(dāng)然service是可以改造的,如果改造成rpc方式,那服務(wù)之間互調(diào)又是另外一種情況了,那就要做成負(fù)載池和接口服務(wù)池的形式了,負(fù)載池調(diào)用接口池,接口池互相rpc調(diào)用,feign client只是通過實(shí)現(xiàn)接口達(dá)到了仿rpc的形式,不過速度表現(xiàn)還是不錯(cuò)的。
4、redis緩存池,這個(gè)用來做session共享,分布式系統(tǒng)session共享是一個(gè)大問題。同時(shí)呢,redis做二級(jí)緩存對(duì)降低整個(gè)服務(wù)的響應(yīng)時(shí)間,并且減少數(shù)據(jù)庫(kù)的訪問次數(shù)是很有幫助的。當(dāng)然redis cluster還是redis sentinel自己選擇。
5、eurake注冊(cè)中心這個(gè)高可用集群,這里有很多細(xì)節(jié),比如多久刷新列表一次,多久監(jiān)測(cè)心跳什么的,都很重要。
6、spring admin,這個(gè)是很推薦的,這個(gè)功能很強(qiáng)大,可以集成turbine斷路器監(jiān)控器,而且可以定義所有類的log等級(jí),不用單獨(dú)去配置,還可以查看本地log日志文件,監(jiān)控不同服務(wù)的機(jī)器參數(shù)及性能,非常強(qiáng)大。它加上elk動(dòng)態(tài)日志收集系統(tǒng),對(duì)于項(xiàng)目運(yùn)維非常方便。
7、zipkin,這個(gè)有兩種方式,直接用它自己的功能界面查看方式,或者用stream流的方式,由elk動(dòng)態(tài)日志系統(tǒng)收集。但是我必須要說,這個(gè)對(duì)系統(tǒng)的性能損害非常大,因?yàn)殒溌纷粉櫟臅r(shí)候會(huì)造成響應(yīng)等待,而且等待時(shí)間非常長(zhǎng)接近1秒,這在生產(chǎn)環(huán)境是不能忍受的,所以生產(chǎn)環(huán)境較好關(guān)掉,有問題調(diào)試的時(shí)候再打開。
8、消息隊(duì)列,這個(gè)必須的,分布式系統(tǒng)不可能所有場(chǎng)景都滿足強(qiáng)一致性,這里只能由消息隊(duì)列來作為緩沖,這里我用的是Kafka。
9、分布式事物,我認(rèn)為這是分布式較困難的,因?yàn)椴煌臉I(yè)務(wù)集群都對(duì)應(yīng)自己的數(shù)據(jù)庫(kù),互相數(shù)據(jù)庫(kù)不是互通的,互相服務(wù)調(diào)用只能是相互接口,有些甚至是異地的,這樣造成的結(jié)果就是網(wǎng)絡(luò)延遲造成的請(qǐng)求等待,網(wǎng)絡(luò)抖動(dòng)造成的數(shù)據(jù)丟失,這些都是很可怕的問題,所以必須要處理分布式事物。我推薦的是利用消息隊(duì)列,采取二階段提交協(xié)議配合事物補(bǔ)償機(jī)制,具體的實(shí)現(xiàn)需要結(jié)合業(yè)務(wù),這里篇幅有限就不展開說了。
10、config配置中心,這是很有必要的,因?yàn)榉?wù)太多配置文件太多,沒有這個(gè)很難運(yùn)維。這個(gè)一般利用消息隊(duì)列建立一個(gè)spring cloud bus,由git存儲(chǔ)配置文件,利用bus總線動(dòng)態(tài)較新配置文件信息。
11、實(shí)時(shí)分布式日志系統(tǒng),logstash收集本地的log文件流,傳輸給elasticsearch,logstash有兩種方式,1、是每一臺(tái)機(jī)器啟動(dòng)一個(gè)logstash服務(wù),讀取本地的日志文件,生成流傳給elasticsearch。2、logback引入logstash包,然后直接生產(chǎn)json流傳給一個(gè)中心的logstash服務(wù)器,它再傳給elasticsearch。elasticsearch再將流傳給kibana,動(dòng)態(tài)查看日志,甚至zipkin的流也可以直接傳給elasticsearch。這個(gè)配合spring admin,一個(gè)查看動(dòng)態(tài)日志,一個(gè)查看本地日志,同時(shí)還能遠(yuǎn)程管理不同類的日志級(jí)別,對(duì)集成和運(yùn)維非常有利。
最后要說說,spring cloud的很多東西都比較精確,比如斷路器觸發(fā)時(shí)間、事物補(bǔ)償時(shí)間、http響應(yīng)時(shí)間等,這些都需要好好的設(shè)計(jì),而且可以優(yōu)化的點(diǎn)非常多。比如:http通訊可以使用okhttp,jvm優(yōu)化,nio模式,數(shù)據(jù)連接池等等,都可以很大的提高性能。
還有一個(gè)docker問題,很多人說不用docker就不算微服務(wù)。其實(shí)我個(gè)人意見,spring cloud本身就是微服務(wù)的,只需要jdk環(huán)境即可。編寫dockerfile也無非是集成jdk、添加jar包、執(zhí)行jar而已,或者用docker compose,將多個(gè)不同服務(wù)的image組合run成容器而已。但是帶來的問題很多,比如通訊問題、服務(wù)器性能損耗問題、容器進(jìn)程崩潰問題,當(dāng)然如果你有一套成熟的基于k8s的容器管理平臺(tái),這個(gè)是沒問題的,如果沒有可能就要斟酌了。而spring cloud本身就是微服務(wù)分布式的架構(gòu),所以個(gè)人還是推薦直接機(jī)器部署的,當(dāng)然好的DevOps工具將會(huì)方便很多。
無錫紅豬網(wǎng)絡(luò)科技有限公司專注于java,b2b2c,多用戶商城等
詞條
詞條說明
(十)Java springcloud B2B2C o2o多用戶商城 springcloud架構(gòu)-SSO單點(diǎn)登錄之OAuth2.0登錄認(rèn)證(1)
之前寫了很多關(guān)于spring cloud的文章,今天我們對(duì)OAuth2.0的整合方式做一下筆記,首先我從網(wǎng)上找了一些關(guān)于OAuth2.0的一些基礎(chǔ)知識(shí)點(diǎn),幫助大家回顧一下知識(shí)點(diǎn):?一、oauth中的角色client:調(diào)用資源服務(wù)器API的應(yīng)用Oauth 2.0 Provider:包括Authorization Server和Resource Server(1)Authorization
(十二)Java springcloud B2B2C o2o多用戶商城 springcloud架構(gòu)-- SSO單點(diǎn)登錄之OAuth2.0 登出流程(3)
之前寫了很多關(guān)于spring cloud的文章,今天我們對(duì)OAuth2.0的整合方式做一下筆記,首先我從網(wǎng)上找了一些關(guān)于OAuth2.0的一些基礎(chǔ)知識(shí)點(diǎn),幫助大家回顧一下知識(shí)點(diǎn):?一、oauth中的角色client:調(diào)用資源服務(wù)器API的應(yīng)用Oauth 2.0 Provider:包括Authorization Server和Resource Server(1)Authorization
java 商城 類似淘寶 京東 當(dāng)當(dāng)網(wǎng)
較近公司要開發(fā)商城,讓我多方咨詢,最后看了很多,要不就是代碼、表字段注釋不全,要不就是bug多,要么就是文檔缺少,最后決定自己開發(fā)一套商城。下面是開發(fā)的一些心得體會(huì),權(quán)且記錄下來,給自己做個(gè)記錄把。之**直都是在從事電商相關(guān)和互聯(lián)網(wǎng)金融開發(fā),處理過億級(jí)數(shù)據(jù)量,所以被目前這家公司看重。由于Java是開源的,較近幾年Hadoop等開源產(chǎn)品越來越成熟,而且是基于Java的,所以較終選擇Java最后后臺(tái)開
java springboot b2b2c shop 多用戶商城系統(tǒng)源碼-SpringCloud架構(gòu)設(shè)計(jì)
較近一直在針對(duì)SpringCloud框架做項(xiàng)目,從中踩了不少的坑,也漸漸梳理出了一些內(nèi)容,由于SpringCloud作為一個(gè)全家桶,其中東西太多,所以這時(shí)候就要有所取舍,這里就想把自己比較常用組件及架構(gòu)推薦上來。需要JAVA Spring Cloud大型企業(yè)分布式微服務(wù)云構(gòu)建的B2B2C電子商務(wù)平臺(tái)源碼針對(duì)這個(gè)架構(gòu)圖我分層介紹一下:1、是web服務(wù)器的選型,這個(gè)我選擇的是nginx+keepali
聯(lián)系人: 周慶達(dá)
電 話:
手 機(jī): 17503009512
微 信: 17503009512
地 址: 江蘇無錫濱湖區(qū)222號(hào)
郵 編: 123123
網(wǎng) 址: redpigmall.b2b168.com
聯(lián)系人: 周慶達(dá)
手 機(jī): 17503009512
電 話:
地 址: 江蘇無錫濱湖區(qū)222號(hào)
郵 編: 123123
網(wǎng) 址: redpigmall.b2b168.com
食檢實(shí)驗(yàn)室信息化LIMS系統(tǒng)
¥300000.00
¥1386.00
嘉科科技PCB板行業(yè)質(zhì)量追溯系統(tǒng)定制開發(fā)
¥300000.00
¥10000.00