什麼是微服務
原始的SOA
把以往的單體服務中的某些模塊拆分出來，每一個模塊都是單體的功能，模塊之間相互之間又相互有一些依賴，之間會有相互的調用。
這種架構用WebService就能實現，稱作SOA，單指服務治理的模型。
以往微服務主要的技術棧指SpringCloud，Dubbo
原來，我們把單體服務按照業務線拆分爲組件，
後來，我們根據功能把系統拆分爲模塊，比如日誌監控系統、上傳文件功能
但這些都不叫微服務
微服務
單體模塊在進行架構設計的時候，是獨立的存在，不依賴任何其他功能
微服務功能之間沒有任何的依賴：不主動、不拒絕、不負責
- 不主動去推數據，而是等別人來取——不主動，避免一致性問題、腦裂問題
- 跨平臺的，基於Http的Restful的遠程調用——不拒絕任何遠程調用
- 如果別的服務來調用我，能不能調通，是別人的事情——服務的容錯、重試，全部責任倒置，由調用方來負責
關於RPC
Dubbo做遠程服務調用的時候是基於RPC的，傳輸的是Java序列化對象，不能跨平臺（跨語言）
DubboX使用 http 傳輸 JSON，替代RPC，可以跨平臺（跨語言）；XML也可以跨平臺，但是效率更低
RMI：java本身提供了一種RPC框架
服務拆分和服務治理
服務拆分原則、方法論僅供參考，一定要自己多拆…
業務線的拆分
要對用量瓶頸進行拆分，比如磁盤讀寫、網絡帶寬的使用（生成頭像、下載報表）、計算密集型…可以把它們拆開，主要目的是在資源的使用上互不影響。
對於2M以上的報表、瘋狂刷磁盤的業務，可以拆分出來。
基於技術棧的拆分
將文件上傳、搜索服務、通知/推送服務、郵件服務 拆分出來，供所有業務使用。
中臺
前臺：前端、接入層
後臺：業務邏輯CRUD、數據庫
中臺，介於前臺和後臺之間，提供複用
可以分爲技術中臺、業務中臺、數據中臺
做中臺的條件是之前的業務要有足夠多，要有積累，才適合直接轉化爲多租戶的服務
服務治理
微服務的運維成本遠高於單體應用
億級流量網關係統架構與設計
網關可以設置在整個系統的最外邊（流量網關），也可以設置在系統內部（業務網關）
流量網關不能使用LVS，應該擁有識別功能（支持編寫程序）AWF
可以使用Java（Tomcat、Netty），或Nginx+C+Lua
Tomcat 性能低，因爲他要建立會話（上下文），不適合用來做網關
APR：異步網絡傳輸
Nginx寫的網關：用C/Lua寫的
基於nginx的二次開發：用Lua語言寫
可以nginx直接請求redis，返回html頁面
https://tengine.taobao.org/
OpenResty
