分布式微服务架构及演变过程
微服務架構的演變：
微服務是一種松散耦合的，每個服務之間高度自治并且使用輕量級協議進行通信的可持續部署的分布式架構體系，這句話包含了微服務的特點，微服務架構和其他架構有什么區別 ? 以下是一些常見的軟件架構：
一.單體應用架構：?
單體應用架構是最簡單的軟甲架構，常用于傳統的應用軟件開發以及傳統Web應用。傳統Web應用，一般將所有功能模塊都打包成（.jar/.war），在WEB應用服務器（Tomcat、Jboss、Jetty、webShare）中部署、運行。隨著業務復雜度增加、技術團隊規模擴大，在一個單體應用架構維護代碼，會降低開發效率，即便處理一個小小的需求，也需要將所有機器上的的應用全都部署一遍，增加運維的復雜度。
?弊端：被很多用戶使用以后，就會產生一些嚴重的問題，CPU、硬盤有一個性能上限，假如一臺只能接受5W同時訪問的服務器，那假如有一年用戶量暴漲到500W來訪問就會出現：
1、服務器過載 CPU、內存、打滿（服務器響應緩慢、宕機）
2、用戶通過HTTP請求，每一次請求會發送一定數量的數據包、帶寬被用盡-訪問轉圈圈，404無法訪問?
解決方法：
1.垂直擴容
可以通過更新硬件，提升帶寬
2.水平擴容
前面講到了用戶出現了500W并發訪問使用垂直擴容的方法可以解決，可以試想一下這樣一個場景。假如經過幾年的累加，用戶量達到了5000W呢
解決方法：
集群架構模式
那么就可以多開幾臺服務器來解決服務器的壓力，但是會出現一個問題就是每個服務器的屬名不一致（IP地址不一致）。用戶明明在注冊界面注冊了但是在登錄的時候查不到他注冊的信息登錄不了，問題是怎么導致的呢，就是不同的服務器不同的端口接收的請求不同，導致數據不同步,該怎么解決請看下面的圖：
?下面不同的端口號代表一個個服務器? 用戶去訪問只訪問qq.com10.123.243.220這個端口。通過負載均衡將所有請求，均衡分配給每一臺服務器。（然后老板就會說做的做的好，加薪）
二.SOA架構
當某一天使用單體架構發現很難推進需求的開發、以及日積月累的技術債時，很多企業會開始做單體服務的拆分，拆分的方式一般有水平拆分和垂直拆分。垂直拆分是把一個應用拆成松耦合的多個獨立的應用，讓應用可以獨立部署，有獨立的團隊進行維護；水平拆分是把一些通用的，會被很多上層服務調用的模塊獨立拆分出去，形成一個共享的基礎服務，這樣拆分可以對一些性能瓶頸的應用進行單獨的優化和運維管理，也在一定程度上防止了垂直拆分的重復造輪子。
SOA 也叫面向服務的架構，從單體服務到 SOA 的演進，需要結合水平拆分及垂直拆分。SOA 強調用統一的協議進行服務間的通信，服務間運行在彼此獨立的硬件平臺但是需通過統一的協議接口相互協作，也即將應用系統服務化。
舉個易懂的例子：
單體服務如果相當于一個快餐店，所有的服務員職責都是一樣的，又要負責收銀結算，又要負責做漢堡，又要負責端盤子，又要負責打掃，服務員之間不需要有交流，用戶來了后，服務員從前到后負責到底（一條龍服務）。SOA 相當于讓服務員有職責分工，收銀員負責收銀，廚師負責做漢堡，保潔阿姨負責打掃等，所有服務員需要用同一種語言交流，方便工作協調(分工合作)。
再回頭去看最上面的圖片，你會發現用戶管理、訂單管理、支付管理都是一起執行的，要崩潰就一起崩潰，要運行就一起運行。而且在公司項目都會分開來做，一旦報錯，責任都不好追究。每個人就互甩鍋，做用戶組的說沒有錯，做支付的也說沒有錯。老板啪的一聲全部留下來加班，但是如果將他們拆分就能了，哪個組不通過就留下來加班。同時在幾年后的今天用戶量達到了5個億，那么該怎么辦呢。那有人就會說了再在原有的服務器上擴充個十倍不就好了，一臺好的服務器市場價是200W 那么原有10臺服務器的基礎上擴充十倍就是兩個億，老板臉都可能青了。請那么多人來就是敗公司的？這時候老板就會想我不如花點錢請專家來設計一下。節約一下成本? 如圖所示：
這時候專家就總體分析了一遍，把常用的和不常用的劃分開來，通過驗證發現使用支付的占了%80，其他的只占了20%。90%業務處于數據讀取查詢，10%寫入。所以給18臺服務器專門做支付，其他的服務器做其他。這樣子既節約了成本，還劃分了區域。仔細的算筆帳，會發現原來需要100臺服務器，現在22臺服務器就做到了。一下省了一億多的米，這是一個普通人幾輩子的賺不到的。
那么恭喜這位專家，盆滿缽滿的唱著征服回家了（被自己的技術魅力征服了）。
微服務和SOA
微服務也是一種服務化，不過和SOA架構的服務化概念還是有區別的，可用以下關鍵字理解：
松耦合：
每個微服務內部都可以使用DDD（領域驅動設計）的思想進行設計領域模型。服務器盡量減少服務器的調用，多使用消息的方式讓領域時間進行解耦
輕量級協議：
Dubbo是SOA開源標準實現之一，類似還有像RPC、Thrift等，微服務更傾向于Restful風格的API。輕量級協議很好的支持跨語言開發的服務，所有的語言都有一個共同點就是支持Http協議通信。
高度自治和持續集成：
從底層的角度來說，SOA更加傾向于服務器和虛擬機的部署。每個應用部署在不同的機器上，一般持續集成工作更多的是運維團隊寫一些Shell腳本以及提供基于共同協議的開發部署頁面（比如Dubbo管理頁面）。微服務可以很好的和容器技術結合，容器技術比微服務出的晚，但是容器技術的出現讓微服務實施更加方便。目前Decker已經成為很多微服務實踐的基礎。因為容器的特點，所以一臺機器上可以部署幾十個甚至上百個不同的微服務，如果某個微服務的流量壓力比其他微服務大，可以在在不增加機器的基礎上。在一臺機器上多分配該微服務的容器實例。同時，因為 Docker 的容器編排社區日漸成熟，類似 Mesos、Kubernetes 及 Docker 官方提供的 Swarm 都可以作為持續集成部署的技術選擇。
其實從架構的演進的角度來看，整體的演進都是朝著越來越輕量級、越來越靈活的應用方向發展，甚至到近兩年日漸成熟起來的 Serverless（無服務）架構。從單體服務到分層的服務，再到面向服務、再到微服務甚至無服務，對于架構的挑戰是越來越大
微服務和SOA都屬于典型的分布式架構，只不過微服務部署的粒度更細，服務擴展更靈活。
微服務中的分布式
微服務的分層不僅僅是容器應用層面的分布式，其為了高度自治，底層的存儲體系也應該相互獨立。并不是所有的微服務都需要持久的存儲服務。就像一個“手機驗證碼”微服務可能底層存儲就用到一個非關系型數據庫Redis；一個”營銷活動搭建頁面“微服務可能就底層存儲就使用mongoDB。
三、分布式微服務架構
那么分布式到底是什么樣的呢，可以看到服務器變成了服務、如圖所示：
相比前面的架構而言?
微服務是真正的分布式的、去中心化的。把所有的“思考”邏輯包括路由、消息解析等放在服務內部，去掉一個大一統的 ESB，服務間輕通信，是比SOA更徹底的拆分。
分布式微服務架構強調的重點是業務系統需要徹底的組件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，運行和運維數據的小應用，這些小應用之間通過服務完成交互和集成。
可以分為六個組件
（1）業務接入層：
（請求的分發）：服務間路由和調度網關
（2）業務服務層：?
各個功能模塊服務 比如：支付，用戶，訂單
（3）服務注冊中心：
提供服務的注冊和發現以及編排和管理的功能,維護一個可用分的服務列表，當你在服務層上線了一個服務后必須要先在服務注冊中心注冊一下 和我們簽到是一個意思 如下：
服務注冊中心自帶了一個”心跳機制“?
心跳機制，每隔30秒會對每個服務發送一個非常小的請求，探測其他的服務還能不能被繼續使用,一旦發現不可用，就會從可用列表移除掉，就不會被訪問了，當服務恢復，Eureke下次心跳機制就會重新上線這個服務
?（4）RPC：
（遠程工程的調用）：每個獨立的服務項目之間的調用
（5）配置中心：
將配置的參數統一管理的場所
（6）消息中間介：
記錄用戶發起的請求，各個服務可以通過定時任務或者自由訪問消息中間介中的請求。
把原來的同步響應模式變成了異步響應模式。提升用戶的響應時間，隱藏實現細節。
1.服務注冊中心（Eurreck）（CAP理論 重點）
幫助我們管理所有業務服務，維護一個可用的服務列表。
?為什么維護列表需要用到CAP理論呢？
而也因為分布式微服務架構 是一個真正的分布式架構項目里的功能模塊都是獨立開來的包括數據也是獨立的，這就會造成數據不同步。
假如我用戶管理修改了年齡但由于我其他的功能模塊是獨立的數據所以就不同步這就是一個很嚴重的問題，那么就得使用CAP理論來解決這個嚴重的問題了
（1）C 數據一致性：
分為強數據一致性和最終數據一致性，強數據一致性就是當你在某個服務中修改了數據 那么其他服務就必須將數據同步（數據同步時會造成短暫的不可訪問狀態），最終一致性 字面意思 就是最終提交的數據我要他是數據同步
不管你前面改了啥 反正我最后提交的時候要數據同步提交
（2）A 可用性：
提供業務訪問的可用時間，就是你服務是不是可用一直開著可用一直訪問
一般都是999 99999 這樣子 一個禮拜停那么一兩個小時或者一個月停那么一兩個小時 可以率99%，爭取做到無限接近百分百
?（3）P 分區容錯率（必須滿足）
可以容忍某個服務不可用 但是必須不能影響整體服務器的運行
可以看出來 可用性和數據一致性 是互斥的（🐟和熊掌不可兼得） 因為你想要數據一致性就必須要停一會服務 讓他數據同步 這樣就會降低可用性 所以我們一般都是在這兩個選擇一個 然后在選上一個必選的分區容錯率
對于新手而已 Spring Cloud 他的服務注冊中心是用的Eureka 而Eureka 所選擇的是AP 也就是先可用性和分區容錯率
2.當服務器發生”服務雪崩“
由一次調用鏈路，中間有一項功能垮掉，就會牽扯整條服務鏈。導致系統整體崩潰，用戶訪問404
那么既然那么嚴重的Bug出現了肯定要解決的
這時候”三大劍客“就出現了
1.熔斷：只要發現一個服務器短路，就自動熔斷，避免出現連鎖反應導致雪崩
2.降級：找一個降級的備份替換，也可以指定其他服務
3.限流：用來輔助前面兩個使用，當出現雪崩現象就進行一波限流，規定只有多少用戶可以訪問，等待問題修復再解除。
3.負載均衡（重點）
負載均衡：
1.代理所有服務器的IP，提供一個統一的地址給外部訪問
2.將所有請求，均衡分配給每一臺服務器
一看到負載均衡想必大家都會想到這兩個：硬負載（硬件負載）、軟負載（軟件負載）
1.硬件負載均衡：是直接在服務器和外部網絡間安裝負載均衡設備。常用的硬件設備有：F5
2.軟件負載均衡：在系統服務器上安裝相應負載均衡軟件,進行相關的配置,達到均衡負載的目的｡它基于特定的使用環境､配置簡單､使用靈活､成本較低，能夠解決大部分需求問題。常用的軟件有：Nginx、Haproxy、Lvs、(Linux虛擬機群組)。
共同學習，共同成長 哪里寫的不對還需大佬指出。一定做到及時回復，及時修改，感謝支持。
總結
以上是生活随笔為你收集整理的分布式微服务架构及演变过程的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 类加载器ClassLoader的角色
- 下一篇： JNI----Native本地方法接口