業務背景
假設你現在正在一個創業公司擔任 CTO，因為微信工作生活娛樂不區分，已經發生了很多次将敏感資訊發錯人甚至發錯群的尴尬事件了！你司 CEO 決定做一款 IM 工具，為了差別微信和 QQ 大衆化的 IM 需求，你們公司主打安全 IM，這款産品的競争力如下：主打私密聊天，嚴格控制私密好友的數量，而不是像微信一樣，買個菜都可能要加個微信。
【公司背景】
1. 技術團隊大約10個人，後端6個，前端2個， Android 2個， iOS 還沒有；
2. 後端 Java 為主，大部分是 3-5年左右的；
3. 後端具備 MySQL、微服務、 Redis 等開發使用經驗；
4. 後端沒有大資料和推薦相關經驗。
業務基本場景
1. 每個使用者都會通過算法生成非對稱的公鑰和私鑰；
2. 使用者發送的消息會通過公鑰加密，接收使用者的消息使用自己的私鑰解密；
3. 隻能建立一對一聊天；
4. 聊天消息“閱後即焚”，最多隻保留60分鐘；
5. 無需使用手機号注冊；
6. 每個使用者最多20個好友。
總體架構思路
老闆說我們3年内要做到1千萬注冊使用者，作為 CTO 的你應該如何做架構設計？
十萬：落地快，但是如果業務發展很快， 架構很快不适應了怎麼辦？
百萬：落地慢一些，但同樣面臨業務發展過 快的風險。
千萬：落地時間可能要6個月以上，但基本上3年内無需再動架構。
超前設計，架構真的不用動麼？
1. 業務規模變化
可以超前化設計應對。
2. 業務多樣性
無法預測會做什麼功能， 業務多樣 性會導緻團隊人數增多到多少更加 無法預測。
3. 技術發展
無法預測，尤其是和法律政策相關的，例如區塊鍊、國産化。
十萬使用者規模存儲性能估算
【注冊】
十萬使用者注冊資訊。
【登入】
雖然 IM 是比較活躍的産品，但由于是全新的産品，我們假設十萬注冊使用者，每天活躍使用者有40%，登入每天4萬。
【加好友】
每個活躍使用者最多20個好友，好友關系數 4萬 * 20 = 80萬 關系資料。
【聊天】
假設每個活躍使用者每天向5位好友發送100條消息，則消息數量為：4萬 * 5 * 100 = 2000萬，且資料當天基本都被删除了， 是以寫入、讀取、删除次數都可以估算為2000萬。
存儲架構設計
10萬使用者注冊資訊， 4萬登入請求 ，80萬關系資料。
2000萬寫入， 2000萬讀取， 2000萬删除。
十萬使用者規模計算性能估算
【注冊】
1年達到十萬使用者注冊，注冊 TPS 很低。
【登入】
雖然 IM 是比較活躍的産品，但由于是全新的産品，我們假設十萬注冊使用者，每天活躍使用者有40%，假設登入時間集中在早晚4小時，登入 TPS均值：4萬 / 14400 = 3。
【加好友】
每個活躍使用者最多20個好友，好友關系數 4萬 * 20 = 80萬資料，按照1年内來計算， TPS 可以忽略不計。
【聊天】
假設每個活躍使用者每天向5位好友發送100條消息，則消息數量為：4萬 * 5 * 100 = 2000萬;
假設每天集中在早中晚3個時間段6小時内(早上1小時中午1小時晚上4小時)；
發送消息 TPS ：2000萬/ ( 3600*6) ≈ 1000；
讀取消息 QPS = 發送消息 TPS，删除消息 TPS ≈發送消息 TPS。
計算架構之負載均衡
計算架構之緩存架構
可擴充架構設計
高可用架構設計 - 同城資料災備