慢慢來比較快义屏，虛心學技術

原文鏈接（歡迎造訪，多多支持）：https://www.yuque.com/keep_zero/spring_cloud/kiis1m

什么是微服務？

微服務強調(diào)的是服務的大小闽铐，關注于某一個點蝶怔，是具體解決一個問題或提供落地對應服務的一個服務應用。

換句話說兄墅，微服務就是將傳統(tǒng)的一站式應用踢星，根據(jù)業(yè)務拆分成一個個的服務，每個微服務提供單個業(yè)務功能隙咸，徹底解耦沐悦。

什么是微服務架構(gòu)？

簡單地說五督，微服務架構(gòu)是系統(tǒng)架構(gòu)上的一種設計風格藏否，它的主旨是將一個原本獨立的系統(tǒng)拆分成多個小型服務****，這些小型服務都在各自獨立的****進程中****運行充包，服務之間通過基于 HTTP的 RESTflul API 進行通信協(xié)作副签。被拆分成的每一個小型服務都圍繞著系統(tǒng)中的某一項或一些耦合度較高的業(yè)務功能進行構(gòu)建，并且每個服務都維護著自身的數(shù)據(jù)存儲基矮、業(yè)務開發(fā)淆储、自動化測試案例以及獨立部署機制。由于有了輕量級的通信協(xié)作基礎家浇，所以這些微服務可以使用不同的語言來編寫

微服務架構(gòu)演變

微服務架構(gòu)演變過程：單體架構(gòu)——>垂直架構(gòu)——>分布式架構(gòu)——>SOA面向服務架構(gòu)——>微服務架構(gòu)

單體架構(gòu)

特點:

1本砰、所有功能集中在一個應用中（稱為單體應用）

2、部署時打包成一個歸檔包（war包）部署到服務器中

3钢悲、通過集群（session共享）的方式提高性能

4点额、此時的****數(shù)據(jù)訪問框架（ORM，用于簡化數(shù)據(jù)庫操作）是關鍵

類比場景：王麻子一個人開的小飯館莺琳，一個人即做廚師咖楣，又做服務員，還做財務（雖然是小飯館）

優(yōu)點：

項目架構(gòu)簡單芦昔，前期開發(fā)成本較低，周期較短娃肿，適合小型項目

缺點：

1咕缎、維護成本較高，所有功能集中在一個工程料扰，耦合性非常高

2凭豪、系統(tǒng)性能擴展通過擴展集群節(jié)點實現(xiàn)，成本太高

3晒杈、技術棧受限嫂伞，整體應用必須使用統(tǒng)一語言及技術。

應用場景：業(yè)務場景簡單,網(wǎng)站流量很小，投入開發(fā)人員數(shù)量不多

垂直架構(gòu)

當訪問量增大帖努，單一應用增加機器帶來的加速度逐漸減少撰豺，遂將應用劃分為幾個互不相干的應用

特點：

1、將單體架構(gòu)的系統(tǒng)應用根據(jù)業(yè)務劃分出互不相干的獨立子系統(tǒng)

2拼余、各子系統(tǒng)間通過接口調(diào)用的方式進行交互

3污桦、用于加速前端開發(fā)的****Web框架是關鍵

類比場景：隨著生意日漸火爆，王麻子后面忙不過來了匙监，就請了幾個伙計凡橱，一個負責廚房，一個負責傳菜亭姥，一個負責下訂單稼钩，王麻子負責去采購，當然了达罗，王麻子有小媳婦兒了坝撑，小媳婦兒負責餐館的財務收支，這樣子氮块，整個餐館的運營瞬間清晰了起來绍载，如果哪一部分人手不夠僅僅需要添加該部分的人手即可。

優(yōu)點：

1滔蝉、系統(tǒng)拆分實現(xiàn)了流量分擔击儡，解決并發(fā)問題

2、可以針對單個模塊功能進行優(yōu)化蝠引，且各子系統(tǒng)或模塊可以使用不同的技術

3阳谍、方便對系統(tǒng)進行水平擴展，負載均衡

缺點：

1螃概、服務之間通過接口相互調(diào)用矫夯，其中某個子系統(tǒng)的接口IP變更后，調(diào)用的系統(tǒng)需要手動更改

2吊洼、搭建集群后训貌，實現(xiàn)負載均衡的參考會更加復雜

3、數(shù)據(jù)同步問題冒窍，由于使用不同的數(shù)據(jù)庫递沪，數(shù)據(jù)庫之間會存在共同冗余信息需要同步（可能存在大量重復性代碼，如上述的訂單功能）

應用場景：訪問量較大综液，高并發(fā)情況款慨，且子系統(tǒng)間交互不多

分布式架構(gòu)

當垂直應用越來越多，應用之間交互不可避免谬莹，將核心業(yè)務抽取出來檩奠，作為獨立的服務桩了，逐漸形成穩(wěn)定的基礎服務中心，使前端應用能快速響應市場需求

特點：

1埠戳、將垂直架構(gòu)中的應用核心業(yè)務抽取出來作為基礎服務中心

2井誉、各業(yè)務系統(tǒng)調(diào)用基礎服務中心，避免業(yè)務系統(tǒng)間的互相調(diào)用乞而。

3送悔、此時，用于提高業(yè)務服務與整合的****分布式服務架構(gòu)（RPC）是關鍵

類比場景：生意一天天越來越好爪模，店小二也從當初的一個變成了多個欠啤，餐館的菜式并不再局限于一種，所以招聘了好幾個廚師分別做川菜屋灌、粵菜洁段、湘菜、蘇菜,且采購也從當初的王麻子變成三個人共郭，當然祠丝，財務就由王麻子和他媳婦兒管了，也是美滋滋除嘹。那么由于生意好了写半，訂單自然也就多了，而且訂單五花八門尉咕，人手去記錄自然是慢的不行了叠蝇，王麻子就采購了一個點單機和采購機，聯(lián)通餐館前臺和后臺年缎，避免了中間的口頭傳達錯誤

優(yōu)點：

1悔捶、將基礎服務抽取出來作為獨立服務，各應用直接調(diào)用单芜，提高了代碼復用和開發(fā)效率

2蜕该、各子系統(tǒng)之間相互解耦，容錯率提高

缺點：

1洲鸠、業(yè)務系統(tǒng)和基礎服務系統(tǒng)間耦合度增加堂淡，調(diào)用復雜，難以維護

2扒腕、搭建集群之后绢淀，負載均衡難以實現(xiàn)

應用場景：訪問量較大，高并發(fā)情況袜匿，且子系統(tǒng)間交互復雜

SOA面向服務架構(gòu)（Service Oriented Architecture,服務治理）

當服務越來越多，需要管理的地址也會越來越多稚疹，依賴關系越來越復雜居灯，服務狀態(tài)難以管理（某個服務宕掉還得去排查才會發(fā)現(xiàn)）祭务，且小服務帶來的資源浪費也是越來越明顯，此時需要一個調(diào)度中心和資源管理中心基于訪問壓力實時管理集群容量怪嫌，提升集群利用率

特點：

1义锥、服務注冊中心，實現(xiàn)服務自動注冊與發(fā)現(xiàn)岩灭，無需人為記錄服務地址（像是字典）

2拌倍、服務自動訂閱，服務列表自動推送噪径，服務調(diào)用透明化柱恤，無需關心依賴關系

3、動態(tài)監(jiān)控服務狀態(tài)

4找爱、SOA通過稱為數(shù)據(jù)總線ESB的中間組件進行系統(tǒng)之間的交互控制

5梗顺、用于提高機器利用率的 資源調(diào)度和治理中心(SOA) 是關鍵

類比場景：王麻子的餐館越來越大，也越來越忙,后廚也從當初的四大菜系發(fā)展到了八大菜系车摄，人員劇增寺谤，各部門之間的交流日漸困難，如廚房八大菜系要叫采購部門采購的材料五花八門吮播，有時候還找不到對應的人变屁；訂單錯誤也找不到人對應負責。所以王麻子又創(chuàng)建了后勤管理部意狠，統(tǒng)一管理后勤調(diào)配和業(yè)務粟关，增減各部門人員等，廚師和采購摄职，財務等部門之間的交流不再是直接交流誊役，解決了先前所有人交流混亂的問題

優(yōu)點：

1、服務調(diào)用透明化谷市，服務間不需要知道服務的具體地址蛔垢，無需關心其依賴關系

2、SOA會監(jiān)控各個服務的運行狀態(tài)迫悠，一旦發(fā)生服務狀態(tài)變更可以立馬發(fā)現(xiàn)

3鹏漆、數(shù)據(jù)總線可以動態(tài)控制各服務集群容量大小，提高集群利用率

4创泄、每個服務都可以使用自己的技術艺玲，只需要統(tǒng)一接口即可

缺點：

1、可靠性鞠抑，SOA架構(gòu)沒有為服務間調(diào)用的事務一致性做好準備

2饭聚、復雜性，提升了整體應用的復雜性搁拙，服務之間調(diào)用通過http協(xié)議交互秒梳，增加了性能消耗

3法绵、由于復雜性帶來的負載均衡困難問題，因為服務間的依賴關系變復雜了

應用場景：訪問量較大酪碘，高并發(fā)情況朋譬，且子系統(tǒng)間交互復雜，要求提高機器利用率

微服務架構(gòu)

SOA架構(gòu)雖然確保了應用能夠交互操作,但是每個應用依舊是一個大的體系兴垦，難以擴展徙赢，且應用與應用之間的依賴性太強，而微服務架構(gòu)更注重組件化和去中心化思想探越。將系統(tǒng)分為更細的獨立的服務狡赐，而且每個服務獨立自治，擁有自己獨立的數(shù)據(jù)庫和邏輯功能扶关，服務與服務之間互不相關,一個服務的崩潰并不影響別的服務運行阴汇，每個服務提供Rest API，統(tǒng)一通過API網(wǎng)關向外提供接口訪問节槐。

特點：

1搀庶、縱向劃分體系，每一個體系都是完整獨立的應用

2铜异、去中心化哥倔，每個微服務有自己的數(shù)據(jù)庫，且不能訪問其他服務的數(shù)據(jù)庫

3揍庄、組件化咆蒿，開發(fā)者不需要協(xié)調(diào)其他服務部署對本服務的影響

類比場景：王麻子的餐館越做越大，但是由于所有菜系都集中在一家店里蚂子，就會有很多不同地域愛好的人來就餐沃测，那么，有時候一個季度可能其中幾個菜系點的人很多食茎，其他菜系點的少蒂破，就會造成人員閑著，而且各地域的客戶就餐習慣迥異别渔，統(tǒng)一服務就很有可能發(fā)生沖突（“打起來都有可能”）附迷。王麻子打算開分店，每個分店負責不同菜系的供應哎媚，互不干擾喇伯，且擁有自己完整的一個經(jīng)營體系，每個季度根據(jù)火爆程度對分店數(shù)量進行調(diào)控拨与，比如川菜店生意更火稻据，則多開幾家，魯菜店生意慘淡买喧，則收拾幾家捻悯。還可能擴展出西餐箩朴、日料、韓料等餐廳秋度，靈活可控。自此钱床，王麻子和小媳婦兒在大江南北逍遙快樂荚斯。。查牌。事期。。

優(yōu)點：

1纸颜、技術異構(gòu)性兽泣，微服務可以輕松采用不同的技術棧。

2胁孙、容錯性唠倦，一個服務不可用不會導致整個系統(tǒng)不可用

3、可擴展性涮较，可以單獨對某個服務進行功能擴展

4稠鼻、簡化部署，每次部署僅需部署部分服務狂票，而不是全盤部署

缺點：

1候齿、當服務數(shù)量增加，管理維護成本上升

2闺属、兼具分布式本身的復雜性

3慌盯、接口調(diào)整的成本上升，某個微服務的接口經(jīng)過調(diào)整掂器，可能多個調(diào)用該接口的微服務需要同時更改

4亚皂、重復勞動，如在某個微服務的工具類在別的服務也需要使用唉匾，但是又不可以直接調(diào)用孕讳，就需要在每一個微服務上都創(chuàng)建這么一個工具類，造成代碼重復巍膘。

應用場景：訪問量較大厂财，功能模塊數(shù)量較多，調(diào)用依賴關系復雜峡懈。

常用微服務框架：Dubbo（阿里,JAVA）璃饱，Motan（微博,JAVA）、Tars（騰訊肪康，C++）,SpringCloud（Pivotal公司荚恶，JAVA）

總結(jié)

1撩穿、微服務架構(gòu)是系統(tǒng)架構(gòu)上的一種設計風格，它的主旨是將一個原本獨立的系統(tǒng)拆分成多個小型服務谒撼，這些小型服務都在各自獨立的進程中運行食寡，服務之間通過基于 HTTP的 RESTflul API 進行通信協(xié)作

2、微服務架構(gòu)的演進歷史：單體架構(gòu)——>垂直架構(gòu)——>分布式架構(gòu)——>SOA面向服務架構(gòu)——>微服務架構(gòu)

3廓潜、架構(gòu)演進的過程抵皱，也是系統(tǒng)不斷細化控制和開發(fā)，提高靈活性和抗風險性的過程辩蛋，應了設計模式的理念：****天下大道呻畸，分之合之

參考文章：

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

如有貽誤，還請評論指正

點擊關注悼院，持續(xù)更新哦