接口測試（http 和 rpc）
接口測試主要分HTTP和RPC兩類，RPC類型裡面以Dubbo較為知名。
網際網路微服務架構，兩種接口都需要做接口測試的，不管是業務測試還是回歸測試；
為什麼要做接口測試？
1.比如‘下單’和‘訂單查詢’，分别在不同的機器不同的系統上，某種原因比如環境不行、包沒打好，可能下單的系統就不可用，但是‘訂單查詢’又得依賴人家下單的系統，這時候就可以mock下訂單查詢的接口的入參，去做訂單查詢的測試，不然就得等人家環境；
2.有的公司會區分前後端，以及前端測試和後端測試，這裡的後端指的是後端的接口（一般都是業務邏輯上的，比如前端在首次進入beike時會自動開通beike，這裡的開通其實是點選beike時調了後端的開通beike的接口，發獎、查詢發獎結果、問詢：有哪些可用的券、定價：選中某個券的利息），前端指的手機的app，app在操作時會調用後端的接口（當然前端一般也有自己的接口什麼的），是以作為後端測試，就要做接口測試；albb
3.還有一種接口是提供給别人用的，比如我們是一個預定商品的系統：商品沒貨了可以預定，這個系統不僅可以我們自己做商品無貨預定，還可以把商品無貨預定的接口給到客戶，讓客戶用自己的系統調我們的無貨預定的接口去預定，這樣，這個接口就需要測試；jd
接口測試（不管http還是rpc流程都是一樣的）：
1、首先本次項目都涉及哪些接口
2、每個接口的入參、出參、依賴（jar）應該是什麼、是什麼樣子
3、每個接口調通
4、按業務流程、業務邏輯依次執行接口，與預期作比較 如：建立測試賬号-->推薦權益-->查詢權益推薦的結果-->核銷權益
傳說中的三闆斧：
可灰階、可監控、可復原
Dubbo：Java棧的網際網路公司比如阿裡、美團、58、滴滴、京東等等都是差不多的服務端架構，是以這些公司，兩類接口測試也是必不可少的工作部分；
Dubbo是一個分布式服務架構，緻力于提供高性能和透明化的RPC遠端服務調用方案，以及SOA服務治理方案。簡單的說，dubbo就是個服務架構，如果沒有分布式的需求，其實是不需要用的，隻有在分布式的時候，才有dubbo這樣的分布式服務架構的需求，并且本質上是個服務調用的東東，說白了就是個遠端服務調用的分布式架構（告别Web Service模式中的WSdl，以服務者與消費者的方式在dubbo上注冊）
dubbo發展史
部落客第一次接觸dubbo的時候，那還是2015年的時候，那時候很多公司都在基于阿裡巴巴的dubbo封裝，各大公司基于 dubbo的開源使用，首當其沖的是有：京東jsf、新浪motan 、 螞蟻金服 sofa 、當當的dubboX等。先給大家普及下dubbo的曆史吧。dubbo在2012年由阿裡巴巴開源，那時候由梁飛（花名虛極）等人一起負責研發。後由于阿裡政策變化，2014年10月Dubbo停止維護，随後部分網際網路公司公開了自行維護的Dubbo版本，比較著名的如當當DubboX，新浪Motan等。經過三年的沉寂，在2017年9月，阿裡宣布重新開機Dubbo項目，并決策在未來對開源進行長期持續的投入。2018.2月，阿裡将Dubbo捐獻給Apache基金會，Dubbo成為Apache頂級孵化項目之一。也由原來的alibba.dubbo變成了apache.dubbo。
京東的JSF相比于Dubbo而言多了一個注冊中心尋址服務，為什麼會這樣呢？主要是因為2015年雙十一時候注冊中心挂了以後，後端容器服務重新開機以後之前緩存的服務位址清單丢失，服務無法調用。而且以Zookeeper為注冊中心的Dubbo，會受制于Zookeeper的缺點：在Zookeeper主節點挂了以後，新的主節點被選出來之前，Zookeeper叢集不可用。而且Zookeeper沒有動态水準擴充的能力。由此可見注冊中心是瓶頸是以京東在這一塊做了改進，我覺得就是抛棄Zookeeper叢集，自己取長補短的去實作一個服務治理。
發表于
2019-05-14 09:33
Susie\
閱讀(1335)
評論(0)
編輯
收藏
舉報