前言：
某科技的一個類似電商的系統，部署是使用war包的一個單體系統，使用的是8臺伺服器作為叢集，資料庫使用了oracle的雙活處理，但是隨著日活的增加，需要遷移到微服務架構，目前系統的日活是30萬，目標支援日活5000萬的微服務架構
基於之前的微服務的應用個例，某個汽車應用領域的APP日活達到了5000萬，因此，可以借鑑這個APP來轉到微服務架構。系統抽取了基礎層作為微服務，比如中介軟體的使用，如快取層的使用。
資料從oracle的1500萬條記錄遷移到PG庫，發現數據不一致問題，資料同步機制，目前諮詢了京東的架構師，王棟 說道：雙寫資料庫查詢支援大併發的查詢，保證order庫以及下單庫的資料庫一致。這裡提到的使用MQ丟資料，堆積資料的問題，而比如非主線業務可以丟資料，比如論壇，朋友圈等。
討論推薦架構：微服務+PG庫，基於核心業務(保單，支付，人的資訊)的資料隔離，服務拆分，論壇，朋友圈，海報等非主線的業務服務化，方便大流量時進行降級處理。
最後達到的理想化的效果，迭代交付，持續交付，資料隔離，服務隔離。
技術細節：DMZ接入層->活動服務 ， 使用者服務 ， 訂單服務 ->PG庫 備份 Orace庫。雙寫資料庫oracle以及PG。
會議結束，提到的分散式事務以及非主線業務的先使用微服務開發部署，主線業務還是使用原來的ssm+oracle+Pg。