一，什么是微服務
什么是服務化？
把傳統的單擊應用中的本地方法調用，改造成通過RPC,HTTP產生的遠程方法調用
把模塊從單體應用中拆分出來，獨立成一個服務部署
-
用戶模塊就可以獨立開發，測試，上線和運維，可以交由專門的團隊來做，與主模塊不耦合
在這里插入圖片描述
什么是微服務？ 一種架構風格
開發單個應用作為一系列小型服務的套件，其中每個服務都運行在自己的進程中，并且通過輕量級的機制實現彼此間的通信，這通常是http資源API
這些服務是圍繞著業務功能構建的，并且可以通過完全自動化的部署機制進行獨立部署
這些服務的集中式管理做到了最小化（比如docker相關技術），每一種服務都可以通過不同的編程語言進行編寫，并且可以使用不同的數據存儲技術。
二，微服務的特點
組件以服務的形式來提供：微服務面向服務，提倡以獨立部署的服務來作為一個個組件，而不是提供包括類庫，本地方法之間的調用的形式，這樣我們需要明確組件間的接口和通信協議
產品不是項目（傳統開發中我們一般把它當做項目，做完了交給維護部門去維護即可。微服務不是這樣的，需要對整個生命周期去負責，這樣也導致不方便進行外包，因為涉及到的人力會非常多）
輕量級通信，獨立進程（會更加傾向于restful，http，rpc，或愿意采用輕量級的消息隊列，比如rabbitmq，而不是更加復雜的協議）
分散治理，去中心化治理（微服務會把單體框架的組件拆成不同的服務，構建時候是比較分散的，意味著責任下放，不同團隊需要對自己的項目負責）
容錯性設計（現在每個服務是獨立的，所以對于每一個模塊，都要提供日常的故障檢測。使用微服務一方面整體的容錯性提高了，因為一個模塊的故障不會影響全部，但是對個人而言壓力更大了，因為一個模塊的錯誤可能會影響其他模塊）
-
會帶來團隊組織架構的調整（從橫向編程斜向）
在這里插入圖片描述
結論：
微服務系統需要滿足一系列條件和原則，但是并不代表你使用了某個技術或框架就是微服務了。微服務可用模塊非常多，我們應該按照項目需要進行選取
三，微服務的優缺點
優點：
1）服務簡單，便于學習和上手，相對易于維護
2）獨立部署，靈活擴展
3）技術棧豐富，比如語言，開發工具，中間件等技術（非常有利于去引入新技術，可以在某一個小模塊先進行使用，等成熟之后再推廣到其他模塊）
缺點：
1）運維成本過高
2）接口可能不匹配
3）代碼可能重復
4）架構復雜度提高
不同復雜度情況下，單體應用和微服務的優劣勢
橫軸復雜度，數軸生產率，綠色是單體應用，藍色是微服務架構
四，微服務的兩大門派
ps：無只是表示dubbo沒有，但是它可以使用三方插件來實現
總結和選型建議：
dubbo誕生于阿里系，而且這個也廣泛應用，但是因為誕生之初是為阿里的業務服務的，所以各個組件不太全面，增加了使用難度。spring cloud是spring家族的，專注企業級微服務領域，而且迭代快，組件全，開發起來非常簡單便捷。dubbo再次之前有很長時間的停止維護，但是現在正常更新了
比喻：組裝電腦，品牌機
如果想穩定可靠，就選擇spring cloud，如果想了解dobbo，或者覺得文檔全，就選擇dubbo，需要根據自身的研發水平和所處階段選擇
五，微服務的拆分
什么時候進行服務化拆分：
第一階段的主要目標是快速開發和驗證想法（通常第一階段都打包在一起進行開發運維，這是最高效也最節省成本的方式）
進一步增加更多的新特性來吸引更多的目標用戶
同時進行開發的人員超過10人，這個時候就該考慮進行服務化拆分了
不適合拆分的情況：
小團隊，技術基礎較為薄弱
流量不高，壓力小，業務變化也不大（比如企業內部的管理系統）
對延遲很敏感的低延遲高并發系統
微服務拆分的兩種方式：
縱向拆分：按照業務維度去拆分，關聯程度緊的就拆分成一個微服務，功能比較獨立的拆分成一個微服務。比如社交app，可以對評論，消息，個人主頁獨立拆分
橫向拆分：按照公共領域去拆分，比如社交app，評論，消息，個人主頁都需要用到用戶模塊，如果縱向拆分里這幾個模塊都分別實現用戶模塊，成本就太高了，可以把用戶服務作為橫向拆分出來，并且把這個功能提供給各個模塊，這樣用戶服務復用性就很高
-
結合業務綜合分析，一般需要同時采用橫向和縱向兩種，無論是采用橫向還是縱向拆分，不一定是拆分的越細越好，過細會讓服務數量膨脹，變得難以管理，要結合實際進行拆分，建議每個開發負責的服務不超過3個。
六，服務擴展
在這里插入圖片描述
x軸-水平復制：把系統作為一個整體，直接重新部署幾套，然后前面加幾個負載均衡器解決問題（效果部署特別好，資源存在浪費）
y軸-功能解耦：微服務拆解，效率比x軸高
z軸-數據分區：在系統更大之后，數據庫是需要分區獨立的，可以按照不同屬性值進行數據拆分，獨立提供資源，提高系統的可用性和性能
自動按需擴展：
根據cpu負載程度，特定時間（比如周末），消息中間件的隊列長度，業務具體規則，預測等來決定是否擴展
自動分配一個新的服務實例，提高可用性
提高了可伸縮性（雙11之后，自動減少服務器）
具有最佳使用率，節約成本
六，微服務重要模塊
服務描述：說明是http服務還是其他類型的，接口什么樣子，返回什么內容
注冊中心：不注冊消費者就不知道去哪里找到
服務框架：注冊好后還需要解決以下問題，比如采用什么協議，傳輸類型等，服務框架就會對此進行統一
負載均衡
熔斷與降級：服務多了以后，如果某一個服務發生故障，那還有兜底策略
網關：當服務多了以后，需要統一網關，然后由網關進行下一步的分發，還有進行統一轉換，權限校驗，過濾等
