微服務體系
什麼是微服務？
什麼是單體架構？
單體架構的問題？
1.複雜性高
1.1 代碼難以了解，複用性低
1.2 難以了解導緻代碼品質低，複雜性進一步增加
1.3 代碼難以被修改和重構
2.伸縮性差
2.1 單體隻能按整體橫向擴充，無法分子產品垂直擴充
2.2 IO密集型子產品和CPU密集型子產品無法獨立更新和擴容
3. 可靠性差
3.1 一個bug有可能引起整個應用的崩潰
4. 阻礙技術創新
4.1 受技術棧限制，團隊成員使用同一架構和語言，子產品得不到拆分，不能使用新的語言和架構
4.2 更新和變革技術架構變得困難，當有符合業務場景的新技術産生或者新版本時，更新和變革技術架構所帶來的重構成本和風險很高
4.3 想嘗試新的語言也變得很困難，因為開發成本的上升，重構和新需求疊代無法協調，所喲最終隻能是妥協繼續使用原來的架構和語言
什麼是服務化？
服務化就是把傳統的單機應用中的本地方法調用，改造成通過接口産生的遠端方法調用
通過服務化，可以解決單體應用膨脹，團隊開發耦合度高，協作效率低下的問題
微服務定義
服務拆分粒度更細
服務對立部署
服務對立維護
服務治理能力要求高
微服務的有點
易于開發與維護
獨立部署
伸縮性強
與組織結構相比對
技術異構型
微服務和Docker
服務拆分
什麼時候應該拆分單體應用？
服務化拆分具體該如何實施呢？
服務拆分的兩種方式：縱向拆分（業務），橫向拆分（公共功能，發郵件，檔案管理）
單體架構--微服務的問題
如何定義服務
如何釋出和訂閱服務
如何治理服務
如何定位
如何監控服務
服務治理
服務治理可以說是微服務架構中最為核心和基礎的子產品，它主要用來實作各個微服務執行個體的自動化注冊與發現
在微服務架構中，過多的服務會出現的問題：
1. 需要配置N個服務的網絡位置，加大配置的複雜性
2.服務的網絡位置變化，都需要改變每個調用者的配置
3.叢集的情況下，難以做負載
服務注冊和發現
1. 在服務發現架構中，通常都會建構一個注冊中心，服務提供者（就是提供服務的一方）按照一定格式的服務描述，向注冊中心注冊服務，聲明自己能夠提供哪些服務以及服務的位址是什麼，完成服務釋出
2. 服務消費者（就是調用服務的一方）請求注冊中心，查詢所需要調用服務的位址，然後以約定的通信協定向服務提供者發起請求，得到請求結果後再按照約定的協定解析結果
3.注冊中心的工作流程是：
服務提供者啟動：向注冊中心注冊自己提供的服務
消費者啟動，向注冊中心訂閱自己需要的服務
注冊中心傳回服務提供者的清單給消費者
消費者從服務提供者清單中，按照負載均衡算法，選擇一台發起請求
Consul 服務發現與配置