引言
- 微服務是一種服務間松耦合的、每個服務之間高度自治並且使用輕量級協議進行通信的可持續集成部署的分布式架構體系
- 那么，微服務架構又與其它架構有何區別?
單體架構（Monolithic）
-
單體架構是最簡單的軟件架構，常用於傳統的應用軟件開發以及傳統 Web 應用，適用於用戶業務不復雜、訪問量較小的時候，甚至可以將應用服務、數據庫、文件服務器部署在一台服務器上（相信很多人都這么干過，_）
-
(MVC)三層設計模型（表示層、業務邏輯處理層、數據訪問層）：
- 表示層：通常理解為用於和用戶交互的視圖層；
- 業務邏輯處理層：用戶提交請求，經過業務邏輯層處理后，對用戶請求作出響應；
- 數據庫訪問層：主要用於操作數據庫。
-
缺點：
- 隨着業務越來越復雜，單體應用代碼量急劇膨脹，最終導致代碼可 讀性、可維護性和可擴展性得不到保證；
- 隨着用戶訪問量增加，單體應用的並發能力有限；
- 隨着系統代碼量的劇增，當修改應用程序或者新增需求時，測試難度成指數級增長；
- 部署效率低下（即使是一個很小的改動，也需要將所有機器上的應用全部部署一遍）， 增加運維復雜度；
- 技術選型單一。
留白
- 在某個陽光明媚、風和日麗的日子里，使用單體架構發現很難推進需求的開發、以及日積月累的技術債，終於爆發了，很多企業開始做單體服務的拆分，拆分的方式一般有水平拆分和垂直拆分，逐漸演變出了SOA（Service Oriented Architecture）架構， SOA 一出世，便被賦予了重大使命…
SOA 架構（Service Oriented Architecture）
-
SOA是個什么鬼？
- SOA 是一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。SOA 可以看作是 B/S 模型、XML（標准通用標記語言的子集）/Web Service 技術之后的自然延伸。
-
你說了這么多，但我還是不知道SOA是個什么鬼啊？你能說的通熟易懂點兒么？
- 單體服務如果相當於一個快餐店，老板（堪稱全能）又要負責收銀結算，又要負責做漢堡，又要負責端盤子，又要負責打掃，用戶來了后，老板從前到后負責到底（累死個人喲）。SOA 相當於老板按需招聘了些許服務員，有職責分工，收銀員負責收銀，廚師負責做漢堡，保潔阿姨負責打掃（老板沒事到處轉悠轉悠，曬曬太陽什么的，解放自己，坐等數票票）等，所有服務員需要用同一種語言交流，方便工作協調。
-
有什么優點嗎？
- 把模塊（即服務）拆分，使用接口通信，降低模塊之間的耦合度；
- 把項目拆分成若干個子項目，不同的團隊負責不同的子項目；
- 增加功能時只需要再增加一個子項目，調用其它系統的接口就可以；
- 可以靈活的進行分布式部署。
-
說了這么多優點，不可能一點缺點都沒有吧，不要王婆賣瓜自賣自誇哈…
- 和單體架構相比，增加了系統復雜度，系統整體性能有較大影響;
- 多服務數據通信協議之間轉換過程復雜，容易造成 ESB（Enterprise Service Bus）性能瓶頸。
SOA架構圖
-
ESB 架構
- 簡單說下， ESB 就像一根管道，用來連接各個服務節點。ESB的存在是為了集成基於不同協議的不同服務，ESB 做了消息的轉化、解釋以及路由的工作，以此來讓不同的服務互聯互通;
- 舉個栗子: 當業務越來越復雜，調用關系亂成一團， ESB 現身梳理了梳理各種應用系統的復雜關系，調用關系就會清晰很多（具體參照圖片）
ESB架構圖(簡)
總結
balabala… 說了一坨亂七八糟的東西之后，我們說一說SOA 到底解決了我們的那些問題：
-
系統間的集成【有序】
站在系統角度， 首先要解決的是各個系統之間的通信問題，
目的是將原先系統間散亂、無規划的網狀結構，梳理成規整、可治理的星形結構，這步的實現往往需要引入一些概念和規范，比如
ESB、以及技術規范、服務管理規范 -
系統的服務化【復用】
站在功能角度， 提出問題：
那么多業務就沒有通用的嗎？如果有，怎么抽象出通用業務邏輯，目的是要把原先固有的業務功能抽象設計為通用的業務服務、實現業務邏輯的快速復用; -
業務的服務化【高效】
站在全局角度，前面兩步都是從技術層面來解決系統調用、系統功能復用的問題，我們需要在業務層面，目的是封裝某一業務單元為服務，
微服務架構（MicroServices）
微服務的概念是 Martin Flower 在2014年寫的一篇論文《MicroServices》中提出來的
主要特點
- 每個服務按照業務划分；
- 服務之間通過輕量級 API 調用；
- 可以使用不同語言開發；
- 可以使用不同的數據存儲技術；
- 可獨立部署，服務之間互相不影響；
- 可針對用戶訪問流量大的服務單獨擴展，從而能夠節約資源；
- 管理自動化。
主要挑戰
- 微服務粒度大小難以划分，需要設計人員對業務有很好的掌握；
- 分布式復雜性，主要體現在分布式事務、網絡延遲、系統容錯等問題解決難度較大；
- 微服務之間通信成本較高，對微服務之間網絡穩定性、通信速度要求較高；
- 由於微服務數量較大，運維人員運維、部署有較大的挑戰
微服務架構和 SOA 架構
微服務架構和 SOA 架構非常類似,微服務是 SOA
的升華，只不過微服務架構強調的是“業務需要徹底的組件化及服務化”，原單個業務系統會被拆分為多個可以獨立開發、設計、部署運行的小應用。這些小應用間通過服務化完成交互和集成。
組件表示的就是一個可以獨立更換和升級的單元，就像 PC 中的 CPU、內存、顯卡、硬盤一樣，獨立且可以更換升級而不影響其他單元。若我們把
PC 中的各個組件以服務的方式構 建，那么這台 PC
只需要維護主板（可以理解為ESB）和一些必要的外部設備就可以。CPU、內存、硬盤等都是以組件方式提供服務，例如PC 需要調用 CPU
做計算處理，只需知道 CPU 這個組件的地址就可以了。
綜上，按照我們自己的理解，可以抽檢出幾個關鍵詞來表達對微服務的理解與開展
微服務的理解與開展
松耦合
DDD（領域驅動設計）的思想進行設計領域模型，服務間盡量減少同步的調用，多使用消息的方式讓服務間的領域事件來進行解耦
輕量級協議
更傾向於使用 Restful 風格的 API，輕量級的協議可以很好地支持跨語言開發的服務，並且Restful 風格的API 便於理解
高度自治和持續集成
微服務可以很好得和容器技術結合，容器技術比微服務出現得晚，但是容器技術的出現讓微服務的實施更加簡
便，目前 Docker 已經成為很多微服務實踐的基礎容器， 因為容器的特色，所以一台機器上可以部署幾十個、
幾百個不同的微服務。如果某個微服務流量壓力比其他微服務大，可以在不增加機器的情況下，在一台機器上
多分配一些該微服務的容器實例。同時，因為 Docker 的容器編排社區日漸成熟，類似 Mesos、Kubernetes 及
Docker 官方提供的 Swarm 都可以作為持續集成部署的技術選擇
架構的演進
- 方向
- 輕量級、靈活，甚至於 Serverless（無服務）架構
- 單體 ——> 分層 ——> 面向服務 ——> 微服務 ——> Serverless（無服務）
微服務&分布式關系
- 微服務架構屬於分布式系統嗎？那必須得是啊…
- 作為一個微服務，給其他人使用，不得保證高可用啊，然后分布式就自個兒蹦出來了…
- 微服務的分布式不僅僅是容器應用層面的分布式，其為了高度自治，底層的存儲體系也應該互相獨立，並且也不是所有的微服務都需要持久化的存儲服務
微服務&分布式理解
- 怎樣理解微服務中的分布式？以公司來舉例說明，一個公司內，多個部門，各司其職，相互配合，各自占據一塊區域，有些東西呢，只有該部門的人能使用，而有些呢，所有人都會使用，有些呢，自己部門沒有，其它部門卻擁有，既有專屬資源，又有共享資源，同時共享資源還得考慮各種使用要求什么的，大抵是這樣子
- 微服務的分布式不僅僅是容器應用層面的分布式，其為了高度自治，底層的存儲體系也應該互相獨立，並且也不是所有的微服務都需要持久化的存儲服務
- 微服務中的分布式場景除了服務本身需要有服務發現、負載均衡，微服務依賴的底層存儲也會有分布式的場景：為了高可用性和性能需要處理數據庫的復制、分區，並且在存儲的分庫情況下，微服務需要能保證分布式事務的一致性。
如有問題，請留言或及時聯系，感謝閱讀
– end –