我們之前開發的新產品，去市場上推廣的時候，發現軟件推廣，教育用戶太難了。因此老闆決定再開發新產品的時候，將其融合到我們的現有業務中，首先在我們的現有用戶中推廣，之前開發的產品也要挪到一起。(從我們的推廣產品的經歷來看，大公司推廣產品是多麼容易，只要導流就好了)
這就涉及我們需要將現有的系統重新設計，打通用戶的賬戶，爲了業務之間互相獨立，每個業務都自己單獨有一個數據庫，自己有自己的服務，但是所有的服務都要操作公共的用戶賬戶中心，如果是用戶中心採用一個服務來維護自己的數據，那麼其他服務調用他的時候，不同服務之間的事務一致性就是問題了，我們需要考慮當一個服務提交成功，但是另一個服務提交失敗的後續處理，這個事務補償就是個很大的工作量。
研究了一下MySQL，他是支持跨庫事務的，就是我們在一個事務中，可以對這個數據庫實例上的其他的數據庫進行操作，如果回滾的話，數據會一起回滾。那我們就想把所有相關業務的數據庫放在一個實例的不同數據庫上，然後對於這種需要跨數據庫進行操作的，直接在每個業務系統中提交，不單獨再調用一個服務來進行提交。這樣的好處無疑是我們不用處理事務不一致的情況了，但是缺點就是我們的相關的業務數據都放在一起了，數據庫的增長會很快，還有就是每個業務都需要了解用戶中心的數據庫。權衡了一下，覺得這種方案，對於我們開發來說是很大的方便，不會給後續的工作留隱患。
然後再研究一下數據增長的問題，分庫分表的方案首先被否了，因爲他也不能解決跨庫事務一致性的問題。隨着newsql的成熟，等我們數據在一個庫上真的放不下的時候，可選的newsql應該很多了，研究了一下很早就關注的tidb，它已經發布了1.06版本了，並且支持這種跨庫的事務，阿里的oceanbase在阿里內部已經廣泛使用了，現在開放了測試版，估計過一段時間，他就可以開放了，跨庫事務這種功能應該可以支持。
綜合考慮，我們在現有條件的基礎上，我們第一步，先在mysql上開發，等以後數據庫處理不過來的時候，我們再把整個業務放到newsql上面。