商城系統
按業務服務拆分
- 使用者服務（user）
- 訂單服務（order）
- 產品服務（product）
- 支付服務（pay）
- 售後服務（afterSale）
- …….
按呼叫方式拆分
| 區別 | API服務 | RPC服務 |
|---|---|---|
| 傳輸協議 | 基於HTTP協議 | 可以基於HTTP協議，也可以基於TCP協議 |
| 傳輸效率 | 如果是基於http1.1的協議，請求中會包含很多無用的內容，如果是基於HTTP2.0，那麼簡單的封裝下可以作為一個RPC來使用，這時標準的RPC框架更多的是服務治理。 | 使用自定義的TCP協議，可以讓請求報文體積更小，或者使用HTTP2協議，也可以很好的減小報文體積，提高傳輸效率 |
| 效能消耗 | 大部分是基於json實現的，位元組大小和序列化耗時都比thrift要更消耗效能 | 可以基於thrift實現高效的二進位制傳輸 |
| 負載均衡 | 需要配置Nginx、HAProxy配置 | 基本自帶了負載均衡策略 |
| 服務治理：（下游服務新增，重啟，下線時如何不影響上游呼叫者） | 需要事先通知，如修改NGINX配置。 | 能做到自動通知，不影響上游 |
總結：RPC 是一個更高效的呼叫方式 可以像呼叫本地函式一樣呼叫介面
主要用於公司內部服務呼叫，傳輸效率高（TCP，報文小），
效能消耗低（高效的二進位制傳輸、位元組小、序列化耗時少），服務治理方便。參考
建立專案目錄
cd xxx/gonivinck/code/ 在code 中新建專案
本作品採用《CC 協議》，轉載必須註明作者和本文連結