基于Dubbo服務(wù)化系統(tǒng)架構(gòu)

1、-12-12基于Dubbo服務(wù)化系統(tǒng)架構(gòu)1/24架構(gòu)演進(jìn)現(xiàn)實(shí)需求Dubbo 介紹與原理為何是 Dubbo 服務(wù)化最正確實(shí)踐都有誰在使用 Dubbo目錄2/24單一應(yīng)用架構(gòu) 垂直應(yīng)用架構(gòu) 分布式服務(wù)架構(gòu) 流動(dòng)計(jì)算架構(gòu) 架構(gòu)演進(jìn)3/24大規(guī)模服務(wù)化后管理繁重服務(wù)URL配置及負(fù)載均衡需求（注冊(cè)中心）梳理服務(wù)間依賴關(guān)系服務(wù)器規(guī)劃參考（服務(wù)調(diào)用量、響應(yīng)時(shí)間）現(xiàn)實(shí)需求4/24Dubbo 是什么？Dubbo 是阿里巴巴企業(yè)開源一個(gè)分布式服務(wù)框架，致力于提供高性能和透明化 RPC 遠(yuǎn)程服務(wù)調(diào)用方案，以及 SOA 服務(wù)治理方案。Dubbo 有何特點(diǎn)？遠(yuǎn)程通訊：基于長連接 NIO 框架抽象封裝集群容錯(cuò)：提供多協(xié)議

2、支持，以及軟負(fù)載均衡，失敗容錯(cuò)，地址路由，動(dòng)態(tài)配置等集群支持。自動(dòng)發(fā)覺：基于注冊(cè)中心目錄服務(wù)，使服務(wù)消費(fèi)方能動(dòng)態(tài)查找服務(wù)提供方，支持平滑降低或增加機(jī)器Dubbo 介紹 5/24Dubbo基本原理 6/24透明化遠(yuǎn)程方法調(diào)用，就像調(diào)用當(dāng)?shù)胤椒ㄒ粯诱{(diào)用遠(yuǎn)程方法，只需簡單配置，沒有任何API侵入。軟負(fù)載均衡及容錯(cuò)機(jī)制，降低單點(diǎn)。服務(wù)自動(dòng)注冊(cè)與發(fā)覺，不再需要寫死服務(wù)提供方地址，注冊(cè)中心基于接口名查詢服務(wù)提供者IP地址，而且能夠平滑添加或刪除服務(wù)提供者。為何是 Dubbo7/24支持各種協(xié)議Dubbo協(xié)議、Hessian協(xié)議、HTTP協(xié)議、RMI協(xié)議、WebService協(xié)議、Thrift協(xié)議、Memc

3、ached協(xié)議、Redis協(xié)議支持各種序列化Kryo、FST、Dubbo Serialization、Hessian、FastJson、Json、Java Serialization為何是 Dubbo8/24卓越性能利用socket長連接，降低握手利用NIO及線程池在單連接上并發(fā)拼包處理消息二進(jìn)制流壓縮數(shù)據(jù)，比常規(guī)HTTP等短連接協(xié)議更加快在阿里巴巴內(nèi)部，天天支撐多個(gè)服務(wù)，30多億訪問量，最大單機(jī)支撐天天近1億訪問量為何是 Dubbo9/24完善服務(wù)監(jiān)控管理為何是Dubbo10/24為何是Dubbo11/24為何是Dubbo12/24為何是Dubbo13/24服務(wù)化最正確實(shí)踐14/24分包提議

4、將服務(wù)接口，服務(wù)模型，服務(wù)異常等均放在API包中，因?yàn)榉?wù)模型及異常也是API 一部分，同時(shí)，這么做也符合分包標(biāo)準(zhǔn)：重用公布等價(jià)標(biāo)準(zhǔn)(REP)，共同重用標(biāo)準(zhǔn)(CRP)。假如需要，也能夠考慮在API包中放置一份spring引用配置，這么使用方，只需在spring 加載過程中引用此配置即可，配置提議放在模塊包目錄下，以免沖突， 如：com/alibaba/china/xxx/dubbo-reference.xml。服務(wù)化最正確實(shí)踐15/24粒度服務(wù)接口盡可能大粒度，每個(gè)服務(wù)方法應(yīng)代表一個(gè)功效，而不是某功效一個(gè)步驟，不然將 面臨分布式事務(wù)問題，Dubbo暫未提供分布式事務(wù)支持。服務(wù)接口提議以業(yè)務(wù)場景

5、為單位劃分，并對(duì)相近業(yè)務(wù)做抽象，預(yù)防接口數(shù)量爆炸。不提議使用過于抽象通用接口，如：Map query(Map)，這么接口沒有明確語義，會(huì)給后 期維護(hù)帶來不便。服務(wù)化最正確實(shí)踐16/24版本每個(gè)接口都應(yīng)定義版本號(hào)，為后續(xù)不兼容升級(jí)提供可能，提議使用兩位版本號(hào)，因?yàn)榈谌话姹咎?hào)通常表示兼容升級(jí)，只有不兼容時(shí)才需要變更服務(wù) 版本。當(dāng)不兼容時(shí)，先升級(jí)二分之一提供者為新版本，再將消費(fèi)者全部升為新版本，然后將剩下二分之一 提供者升為新版本。服務(wù)化最正確實(shí)踐17/24兼容性服務(wù)接口增加方法，或服務(wù)模型增加字段，可向后兼容，刪除方法或刪除字段，將不兼容， 枚舉類型新增字段也不兼容，需經(jīng)過變更版本號(hào)升級(jí)。各協(xié)議

6、兼容性不一樣服務(wù)化最正確實(shí)踐18/24枚舉值假如是完備集，能夠用Enum，比如：ENABLE, DISABLE。假如是業(yè)務(wù)種類，以后顯著會(huì)有類型增加，不提議用Enum，能夠用String代替。假如是在返回值中用了Enum，并新增了Enum值，提議先升級(jí)服務(wù)消費(fèi)方，這么服務(wù)提供 方不會(huì)返回新值。假如是在傳入?yún)?shù)中用了Enum，并新增了Enum值，提議先升級(jí)服務(wù)提供方，這么服務(wù)消 費(fèi)方不會(huì)傳入新值。服務(wù)化最正確實(shí)踐19/24序列化服務(wù)參數(shù)及返回值提議使用POJO對(duì)象，即經(jīng)過setter,getter方法表示屬性對(duì)象。服務(wù)參數(shù)及返回值不提議使用接口，因?yàn)閿?shù)據(jù)模型抽象意義不大，而且序列化需要接口實(shí) 現(xiàn)

7、類元信息，并不能起到隱藏實(shí)現(xiàn)意圖。服務(wù)參數(shù)及返回值都必需是byValue，而不能byReference，消費(fèi)方和提供方參數(shù) 或返回值引用并不是同一個(gè)，只是值相同，Dubbo不支持引用遠(yuǎn)程對(duì)象。服務(wù)化最正確實(shí)踐20/24異常提議使用異常匯報(bào)錯(cuò)誤，而不是返回錯(cuò)誤碼，異常信息能攜帶更多信息，以及語義更友好。假如擔(dān)心性能問題，在必要時(shí)，能夠經(jīng)過override掉異常類fillInStackTrace()方法為空 方法，使其不拷貝棧信息。查詢方法不提議拋出checked異常，不然調(diào)用方在查詢時(shí)將過多try.catch，而且不能 進(jìn)行有效處理。服務(wù)化最正確實(shí)踐21/24服務(wù)提供方不應(yīng)將DAO或SQL等異常拋給消費(fèi)方，應(yīng)在服務(wù)實(shí)現(xiàn)中對(duì)消費(fèi)方不關(guān)心異常 進(jìn)行包裝，不然可能出現(xiàn)消費(fèi)方無法反序列化對(duì)應(yīng)異常。調(diào)用不要只是因?yàn)槭荄ubbo調(diào)用，而把調(diào)用try.catch起來。try.catch應(yīng)該加上適當(dāng) 回滾邊界上。對(duì)于輸入?yún)?shù)校驗(yàn)邏輯在Provider端要有。如有性能上