慢慢來比較快，虛心學技術
原文鏈接（歡迎造訪，多多支持）：https://www.yuque.com/keep_zero/spring_cloud/kiis1m
什麼是微服務？
微服務強調的是服務的大小，關注於某一個點，是具體解決一個問題或提供落地對應服務的一個服務應用。
換句話說，微服務就是將傳統的一站式應用，根據業務拆分成一個個的服務，每個微服務提供單個業務功能，徹底解耦。
什麼是微服務架構？
簡單地說，微服務架構是系統架構上的一種設計風格，它的主旨是將一個原本獨立的系統拆分成多個小型服務****，這些小型服務都在各自獨立的****進程中****運行，服務之間通過基於 HTTP的 RESTflul API 進行通信協作。被拆分成的每一個小型服務都圍繞着系統中的某一項或一些耦合度較高的業務功能進行構建，並且每個服務都維護着自身的數據存儲、業務開發、自動化測試案例以及獨立部署機制。由於有了輕量級的通信協作基礎，所以這些微服務可以使用不同的語言來編寫
微服務架構演變
微服務架構演變過程：單體架構——>垂直架構——>分佈式架構——>SOA面向服務架構——>微服務架構
單體架構
特點:
1、所有功能集中在一個應用中（稱爲單體應用）
2、部署時打包成一個歸檔包（war包）部署到服務器中
3、通過集羣（session共享）的方式提高性能
4、此時的****數據訪問框架（ORM，用於簡化數據庫操作）是關鍵
類比場景：王麻子一個人開的小飯館，一個人即做廚師，又做服務員，還做財務（雖然是小飯館）
優點：
項目架構簡單，前期開發成本較低，週期較短，適合小型項目
缺點：
1、維護成本較高，所有功能集中在一個工程，耦合性非常高
2、系統性能擴展通過擴展集羣節點實現，成本太高
3、技術棧受限，整體應用必須使用統一語言及技術。
應用場景：業務場景簡單,網站流量很小，投入開發人員數量不多
垂直架構
當訪問量增大，單一應用增加機器帶來的加速度逐漸減少，遂將應用劃分爲幾個互不相干的應用
特點：
1、將單體架構的系統應用根據業務劃分出互不相干的獨立子系統
2、各子系統間通過接口調用的方式進行交互
3、用於加速前端開發的****Web框架是關鍵
類比場景：隨着生意日漸火爆，王麻子後面忙不過來了，就請了幾個夥計，一個負責廚房，一個負責傳菜，一個負責下訂單，王麻子負責去採購，當然了，王麻子有小媳婦兒了，小媳婦兒負責餐館的財務收支，這樣子，整個餐館的運營瞬間清晰了起來，如果哪一部分人手不夠僅僅需要添加該部分的人手即可。
優點：
1、系統拆分實現了流量分擔，解決併發問題
2、可以針對單個模塊功能進行優化，且各子系統或模塊可以使用不同的技術
3、方便對系統進行水平擴展，負載均衡
缺點：
1、服務之間通過接口相互調用，其中某個子系統的接口IP變更後，調用的系統需要手動更改
2、搭建集羣后，實現負載均衡的參考會更加複雜
3、數據同步問題，由於使用不同的數據庫，數據庫之間會存在共同冗餘信息需要同步（可能存在大量重複性代碼，如上述的訂單功能）
應用場景：訪問量較大，高併發情況，且子系統間交互不多
分佈式架構
當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作爲獨立的服務，逐漸形成穩定的基礎服務中心，使前端應用能快速響應市場需求
特點：
1、將垂直架構中的應用核心業務抽取出來作爲基礎服務中心
2、各業務系統調用基礎服務中心，避免業務系統間的互相調用。
3、此時，用於提高業務服務與整合的****分佈式服務架構（RPC）是關鍵
類比場景：生意一天天越來越好，店小二也從當初的一個變成了多個，餐館的菜式並不再侷限於一種，所以招聘了好幾個廚師分別做川菜、粵菜、湘菜、蘇菜,且採購也從當初的王麻子變成三個人，當然，財務就由王麻子和他媳婦兒管了，也是美滋滋。那麼由於生意好了，訂單自然也就多了，而且訂單五花八門，人手去記錄自然是慢的不行了，王麻子就採購了一個點單機和採購機，聯通餐館前臺和後臺，避免了中間的口頭傳達錯誤
優點：
1、將基礎服務抽取出來作爲獨立服務，各應用直接調用，提高了代碼複用和開發效率
2、各子系統之間相互解耦，容錯率提高
缺點：
1、業務系統和基礎服務系統間耦合度增加，調用複雜，難以維護
2、搭建集羣之後，負載均衡難以實現
應用場景：訪問量較大，高併發情況，且子系統間交互複雜
SOA面向服務架構（Service Oriented Architecture,服務治理）
當服務越來越多，需要管理的地址也會越來越多，依賴關係越來越複雜，服務狀態難以管理（某個服務宕掉還得去排查纔會發現），且小服務帶來的資源浪費也是越來越明顯，此時需要一個調度中心和資源管理中心基於訪問壓力實時管理集羣容量，提升集羣利用率
特點：
1、服務註冊中心，實現服務自動註冊與發現，無需人爲記錄服務地址（像是字典）
2、服務自動訂閱，服務列表自動推送，服務調用透明化，無需關心依賴關係
3、動態監控服務狀態
4、SOA通過稱爲數據總線ESB的中間組件進行系統之間的交互控制
5、用於提高機器利用率的 資源調度和治理中心(SOA) 是關鍵
類比場景：王麻子的餐館越來越大，也越來越忙,後廚也從當初的四大菜系發展到了八大菜系，人員劇增，各部門之間的交流日漸困難，如廚房八大菜系要叫採購部門採購的材料五花八門，有時候還找不到對應的人；訂單錯誤也找不到人對應負責。所以王麻子又創建了後勤管理部，統一管理後勤調配和業務，增減各部門人員等，廚師和採購，財務等部門之間的交流不再是直接交流，解決了先前所有人交流混亂的問題
優點：
1、服務調用透明化，服務間不需要知道服務的具體地址，無需關心其依賴關係
2、SOA會監控各個服務的運行狀態，一旦發生服務狀態變更可以立馬發現
3、數據總線可以動態控制各服務集羣容量大小，提高集羣利用率
4、每個服務都可以使用自己的技術，只需要統一接口即可
缺點：
1、可靠性，SOA架構沒有爲服務間調用的事務一致性做好準備
2、複雜性，提升了整體應用的複雜性，服務之間調用通過http協議交互，增加了性能消耗
3、由於複雜性帶來的負載均衡困難問題，因爲服務間的依賴關係變複雜了
應用場景：訪問量較大，高併發情況，且子系統間交互複雜，要求提高機器利用率
微服務架構
SOA架構雖然確保了應用能夠交互操作,但是每個應用依舊是一個大的體系，難以擴展，且應用與應用之間的依賴性太強，而微服務架構更注重組件化和去中心化思想。將系統分爲更細的獨立的服務，而且每個服務獨立自治，擁有自己獨立的數據庫和邏輯功能，服務與服務之間互不相關,一個服務的崩潰並不影響別的服務運行，每個服務提供Rest API，統一通過API網關向外提供接口訪問。
特點：
1、縱向劃分體系，每一個體系都是完整獨立的應用
2、去中心化，每個微服務有自己的數據庫，且不能訪問其他服務的數據庫
3、組件化，開發者不需要協調其他服務部署對本服務的影響
類比場景：王麻子的餐館越做越大，但是由於所有菜系都集中在一家店裏，就會有很多不同地域愛好的人來就餐，那麼，有時候一個季度可能其中幾個菜系點的人很多，其他菜系點的少，就會造成人員閒着，而且各地域的客戶就餐習慣迥異，統一服務就很有可能發生衝突（“打起來都有可能”）。王麻子打算開分店，每個分店負責不同菜系的供應，互不干擾，且擁有自己完整的一個經營體系，每個季度根據火爆程度對分店數量進行調控，比如川菜店生意更火，則多開幾家，魯菜店生意慘淡，則收拾幾家。還可能擴展出西餐、日料、韓料等餐廳，靈活可控。自此，王麻子和小媳婦兒在大江南北逍遙快樂。。。。。
優點：
1、技術異構性，微服務可以輕鬆採用不同的技術棧。
2、容錯性，一個服務不可用不會導致整個系統不可用
3、可擴展性，可以單獨對某個服務進行功能擴展
4、簡化部署，每次部署僅需部署部分服務，而不是全盤部署
缺點：
1、當服務數量增加，管理維護成本上升
2、兼具分佈式本身的複雜性
3、接口調整的成本上升，某個微服務的接口經過調整，可能多個調用該接口的微服務需要同時更改
4、重複勞動，如在某個微服務的工具類在別的服務也需要使用，但是又不可以直接調用，就需要在每一個微服務上都創建這麼一個工具類，造成代碼重複。
應用場景：訪問量較大，功能模塊數量較多，調用依賴關係複雜。
常用微服務框架：Dubbo（阿里,JAVA），Motan（微博,JAVA）、Tars（騰訊，C++）,SpringCloud（Pivotal公司，JAVA）
總結
1、微服務架構是系統架構上的一種設計風格，它的主旨是將一個原本獨立的系統拆分成多個小型服務，這些小型服務都在各自獨立的進程中運行，服務之間通過基於 HTTP的 RESTflul API 進行通信協作
2、微服務架構的演進歷史：單體架構——>垂直架構——>分佈式架構——>SOA面向服務架構——>微服務架構
3、架構演進的過程，也是系統不斷細化控制和開發，提高靈活性和抗風險性的過程，應了設計模式的理念：****天下大道，分之合之
參考文章：
https://blog.csdn.net/qq_41531324/article/details/80806168
https://www.cnblogs.com/lonelyxmas/p/10495705.html
https://msd.misuland.com/pd/2884250137616453946
https://blog.csdn.net/HistoryCreator/article/details/89059711
https://cloud.tencent.com/developer/article/1378077
如有貽誤，還請評論指正
點擊關注，持續更新哦