一尖昏、服務的演變之路
1.1）單體架構（all in one）
單體項目缺點：
某些服務比如庫存更加依賴IO构资，可以偏向于數倉磁盤進行針對性提升抽诉，某些服務比如會員服務針對于會員的下單習慣進行算法推薦更依賴CPU計算，可以偏向于高CPU/高內存進行針對性提升吐绵。而單體只能又是大磁盤迹淌、又是高CPU高內存河绽。
在于服務選型方面比如訂單服務需要將Hibernetes轉型為mybatis需要排除對于其它服務的影響，而且很容易牽一發(fā)動全身很多框架之間不兼容的隱性Bug出現
單體項目優(yōu)點：
比微服務省略很多維護成本唉窃，部署簡單一個jar包不關心啟動順序耙饰，不需要RPC調用都是本地效率高，像初創(chuàng)公司也不需要很多研發(fā)人員纹份。
架構也就是M（Model）V（View）C（Controller）榔幸，Model層對應infrastructure負責邏輯計算，View對應Service層負責計算出來結果展現矮嫉，Contorller對應Web負責計算出來結果承裝從而向外部展現
1.2）集群級垂直化
隨著競品越來越多服務量增大削咆，服務進行橫向拆分不同系統(tǒng)打包成不同war包，有時間的將數據庫也進行拆分蠢笋，內部通訊可以使用RPC外部可以使用Http拨齐，原先10個請求只能打到一個Tomcat服務器，現在兩個Tomcat平攤各自只需要承擔5個請求昨寞，再往下平攤到不同的war包上又分攤了壓力
以系統(tǒng)為粒度會出現不同系統(tǒng)對于差不多的功能都需要自己去反復實現
1.3）SOA
隨著服務量越來越大SOA的承載力全部壓在ESB企業(yè)服務總線，超過一定量級還是滿足不了
1.4）微服務
服務演變可以通過一個例子進行概括：
比如一個請求直接打到單體項目（地球）享怀，直接打到縱向拆分中（中國羽峰、美國），直接打到SOA（上海添瓷、北京梅屉、深圳），直接打到微服務（海淀區(qū)鳞贷、閔行區(qū)坯汤、南山區(qū)、番禺區(qū)）搀愧，隨著粒度越來越精細所能夠承擔的壓力也越來越分散
自動部署解決了運維壓力大的問題搓幌，通過docker和k8s研發(fā)人員自己就可以搞定
微服務對于研發(fā)人員的壓力增大在于原先一個服務中能調用的，現在拆分到十個微服務中眷蚓，我需要的數據不在我的微服務中需要調用其它服務鼻种，又需要重新開放接口打成jar包反番，我的微服務再引用jar包——拆分沒有具體標準拆的太細會導致通信成本過高（可以按DDD拆分）
二篙贸、Spring Cloud介紹
Config對應Nacos配置中心，Eureka對應Nacos服務發(fā)現爵川，Zuul對應Gateway（Sping Cloud自己研發(fā)團隊）敷鸦，Ribbon和Feign組合成OpenFeign對應Dubbo，Hystrix對應Sentinel
三寝贡、什么是服務
3.1）服務發(fā)現的概念
3.2）服務發(fā)現的兩種方式——客戶端服務發(fā)現
3.3）服務發(fā)現的兩種方式——服務端服務發(fā)現
3.4）服務發(fā)現技術對比
3.5）Nacos架構圖
Config Service表示配置中心，Naming Service表示服務發(fā)現抢韭，Nacos Core核心包薪贫，Consistency Protocol底層協(xié)議，Nacos Console控制界面網頁
四刻恭、Nacos實戰(zhàn)（代碼演示單機啟動）
五瞧省、Nacos核心源碼解析
5.1）SpringCloud完成服務注冊的時機
5.2）NacosServiceRegistry的實現原理
5.3）服務提供者地址查詢原理
5.4）服務注冊原理
5.5）服務發(fā)現原理
服務地址動態(tài)感知原理
