關於webservice的問題效率問題

由於項目中很多介面需要維護，而業務方在調用介面的時候需要需要判斷緩衝情況，沒有的話在直接從DB取資料，這樣子帶來了很多問題，業務方需要同時關注緩衝和DB，現在有個方案就是採用服務化架構，把所有的介面都分裝在服務裡面，那麼業務方只需要調用介面就好，不用管其他的，那麼我的問題是：之前我通過取緩衝或者DB 直接取出資料的，現在要走server(比如webservice) 走的是HTTP，那麼豈不是更慢了？求解，謝謝。

回複內容：

由於項目中很多介面需要維護，而業務方在調用介面的時候需要需要判斷緩衝情況，沒有的話在直接從DB取資料，這樣子帶來了很多問題，業務方需要同時關注緩衝和DB，現在有個方案就是採用服務化架構，把所有的介面都分裝在服務裡面，那麼業務方只需要調用介面就好，不用管其他的，那麼我的問題是：之前我通過取緩衝或者DB 直接取出資料的，現在要走server(比如webservice) 走的是HTTP，那麼豈不是更慢了？求解，謝謝。

是會慢了，但是整個項目的結構就清晰了，以後開發速度和分工就更容易了，這也就是犧牲速度的原因。項目總是逐步增大的，隨著項目的增大，就要逐漸考慮對其進行拆分，拆分的目的我想也不用多說，而拆分的方式大多就是把每個子塊進行服務化，對外只暴露少部分必要的介面。

而至於剛才說到的變慢的問題，還有很多方式進行最佳化可以彌補這部分的慢，比如採用更高速的網路通道等。

通過對服務的分層，可以將項目變得更加條理清晰，開發的過程能夠更加模組化，有助于敏捷開發。代碼的重用率會更加提高。
當需要跨語言或者跨伺服器的時候可以使用thrift等RPC架構進行傳輸，當需要使用其他語言的第三方內容的時候這樣子架構的優勢就上來了。

