分散式SOA架構涉及到了dubbo，它有2部分，服務的提供方和服務的消費方，官方推薦用zookeeper作為一個註冊中心，具體怎麼用呢？首先服務的提供方暴露出他所提供的服務介面，提供給zookeeper註冊中心進行註冊進行管理，當消費方需要使用的時候，它會到zookeeper中查詢相應的服務介面是否存在，如果找到了，那麼zookeeper註冊中心把服務訊息的提供方的具體IP地址返回給服務的消費方，然後由你的服務的消費方直接去服務的提供方上去使用，原理就是這麼個過程。但是dubbo是存在問題的，
1事務和異常問題，舉個例子，假設它呼叫了方法A，方法A查詢了資料庫，他的返回值被方法B使用了，那麼方法B又查詢了一次資料庫，假設我的資料庫初始化欄位是0，那麼方法A中進行加1的處理，然後又呼叫了方法B,方法B又進行了加2的處理，又回到方法A，又進行了加1的處理，假設都沒有異常的話，最終會變成4，那如果進行方法B的時候出現了異常，那異常怎麼辦？怎麼管理？就一直丟擲異常。這就是事務和異常的相關管理，事務的管理不明確。是外層管理理論還是內層管理需要定義傳播行為。
2程式碼的耦合性問題，一旦那邊的方法介面改變了，這邊就失敗了，你就必須重新修改你的埠，修改你呼叫的方法。
3效率問題，比如一個電商平臺，商品上架的時候，同時用到了2個技術，儲存在solr索引庫中和頁面靜態化。那麼此時2個是同步操作， 如果還有其他的操作，它也會一個個執行，先進行solr儲存啦，然後freemarker靜態化啦、這個時候用的時間很多，這個時候用到訊息服務中介軟體，JMS也就是一個訊息服務的訊息列，我們還要使用activeMQ技術之類，效率不高。
分散式SOA架構涉及到了dubbo，它有2部分，服務的提供方和服務的消費方，官方推薦用zookeeper作為一個註冊中心，具體怎麼用呢？首先服務的提供方暴露出他所提供的服務介面，提供給zookeeper註冊中心進行註冊進行管理，當消費方需要使用的時候，它會到zookeeper中查詢相應的服務介面是否存在，如果找到了，那麼zookeeper註冊中心把服務訊息的提供方的具體IP地址返回給服務的消費方，然後由你的服務的消費方直接去服務的提供方上去使用，原理就是這麼個過程。但是dubbo是存在問題的，
1事務和異常問題，舉個例子，假設它呼叫了方法A，方法A查詢了資料庫，他的返回值被方法B使用了，那麼方法B又查詢了一次資料庫，假設我的資料庫初始化欄位是0，那麼方法A中進行加1的處理，然後又呼叫了方法B,方法B又進行了加2的處理，又回到方法A，又進行了加1的處理，假設都沒有異常的話，最終會變成4，那如果進行方法B的時候出現了異常，那異常怎麼辦？怎麼管理？就一直丟擲異常。這就是事務和異常的相關管理，事務的管理不明確。是外層管理理論還是內層管理需要定義傳播行為。
2程式碼的耦合性問題，一旦那邊的方法介面改變了，這邊就失敗了，你就必須重新修改你的埠，修改你呼叫的方法。
3效率問題，比如一個電商平臺，商品上架的時候，同時用到了2個技術，儲存在solr索引庫中和頁面靜態化。那麼此時2個是同步操作， 如果還有其他的操作，它也會一個個執行，先進行solr儲存啦，然後freemarker靜態化啦、這個時候用的時間很多，這個時候用到訊息服務中介軟體，JMS也就是一個訊息服務的訊息列，我們還要使用activeMQ技術之類，效率不高。