什么是微服務

今天就跟大家聊聊有關什么是微服務，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

單體架構

概念

單體架構也稱之為單體系統或者是單體應用。就是一種把系統中所有的功能、模塊耦合在一個應用中的架構方式。

特點

單體架構的特點主要有：

1. 打包成一個獨立的單元(導成一個唯一的jar包或者是war包)

2. 以一個進程的方式來運行

單體架構

優點

• 易于開發： 開發方式簡單，IDE 支持好，方便運行和調試。

• 易于測試： 所有功能運行在一個進程中，一旦進程啟動，便可以進行系統測試。

• 易于部署： 只需要將打好的一個軟件包發布到服務器即可。

• 易于水平伸縮：  只需要創建一個服務器節點，配置好運行時環境，再將軟件包發布到新服務器節點即可運行程序(當然也需要采取分發策略保證請求能有效地分發到新節點)。

缺點

維護成本大： 當應用程序的功能越來越多、團隊越來越大時，溝通成本、管理成本顯著增加;當出現 bug 時，可能引起 bug  的原因組合越來越多，導致分析、定位和修復的成本增加;并且在對全局功能缺乏深度理解的情況下，容易在修復 bug 時引入新的 bug。

• 持續交付周期長： 構建和部署時間會隨著功能的增多而增加，任何細微的修改都會觸發部署流水線。

• 新人培養周期長： 新成員了解背景、熟悉業務和配置環境的時間越來越長。

• 技術選型成本高： 單塊架構傾向于采用統一的技術平臺或方案來解決所有問題，如果后續想引入新的技術或框架，成本和風險都很大。

• 可擴展性差：  隨著功能的增加，垂直擴展的成本將會越來越大;而對于水平擴展而言，因為所有代碼都運行在同一個進程，沒辦法做到針對應用程序的部分功能做獨立的擴展

采用過時的單體架構的話，就會使得公司雇傭有潛力的開發者很困難，應用無法擴展，可靠性很低，那么我們再來看看微服務架構是怎樣的呢?

微服務架構

概念

微服務是一種架構風格。一個大型的復雜軟件應用，由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并且能夠很好的完成該任務。

架構核心

核心部分

• 網關集群：數據的聚合、實現對接入客戶端的身份認證、防報文重放與防數據篡改、功能調用的業務鑒權、響應數據的脫敏、流量與并發控制等。

• 業務集群：一般情況下移動端訪問和瀏覽器訪問的網關需要隔離，防止業務耦合。

• Local  Cache：由于客戶端訪問業務可能需要調用多個服務聚合，所以本地緩存有效的降低了服務調用的頻次，同時也提示了訪問速度。本地緩存一般使用自動過期方式，業務場景中允許有一定的數據延時。

• 服務層：原子服務層，實現基礎的增刪改查功能，如果需要依賴其他服務需要在 Service 層主動調用。

• Remote Cache：訪問 DB 前置一層分布式緩存，減少 DB 交互次數，提升系統的TPS。

• DAL：數據訪問層，如果單表數據量過大則需要通過 DAL 層做數據的分庫分表處理。

• MQ：消息隊列用來解耦服務之間的依賴，異步調用可以通過 MQ 的方式來執行。

• 數據庫主從：服務化過程中必經的階段，用來提升系統的 TPS

架構

常見的架構有：

1. 客戶端與服務端的

2. 基于組件模型的架構(EJB)

3. 分層架構(MVC)

4. 面向服務架構(SOA)

特點

1. 系統是由多個服務構成

2. 每個服務可以單獨獨立部署

3. 每個服務之間是松耦合的。服務內部是高內聚的，外部是低耦合的。高內聚就是每個服務只關注完成一個功能。

優點

• 邊界清晰：比如說一個電商平臺，我們以前是部署在一臺服務器上，所有的代碼打成一個war包。現在，我們可以給它拆分開：用戶服務，積分服務，支付服務，倉儲服務，信息服務，地圖服務等等，每一個微服務只關注一個特定的業務功能，這樣的話開發和維護單個服務都比較簡單，因為它的邊界足夠清晰，業務也足夠清晰，用戶服務，只做好用戶的事情就好了，相較于之前的大而全的單體服而言，每個微服務的代碼量也比較少。

• 效率高：單體服務隨著代碼量變得越來越多，比如說百萬行級別的代碼，僅僅編譯一次應用可能就需要花費很久，但是現在，如果一個地方有問題，比如說支付模塊有問題，只需要單獨修改支付模塊，修改完支付模塊之后，單獨測試支付功能，單獨部署支付模塊就可以了，而不會影響整體的部署速度。

• 技術棧不受限制：每一個服務可以使用不同的技術棧來實現，由于不同的服務之間是通過restful  API來通信的，所以每個服務可以使用不同的技術框架，使用不同的存儲庫來實現;

• 拓展性更強：隨著業務的發展，用戶量變得越來越多，或者說訂單量猛增，這時我們可以專門去優化這個訂單服務，給這個訂單服務提供更高配置的機器，而其他并沒有遇到瓶頸的業務，比如說短信服務，我們可以暫時不用動。

缺點

• 運維成本過高：以前只需要打個 war 包扔在 tomcat  下面就可以了，但現在，我們可能需要部署幾個甚至幾十個微服務，這樣的話，如何保證這幾十甚至上百個微服務正常的運行和互相通信協作，這給運維帶來了很大的挑戰;

• 分布式系統復雜：使用微服務這種架構，構建的是一個分布式的系統，在分布式系統當中會引入很多問題，比如說分布式鎖，分布式事務等等，這個時候我們需要對這個系統的，事務，冪等，網絡延遲，分區，熔斷，降級等問題都要有一個妥善的處理和應對方案;

• 通信成本高：由于之前的接口調用都在同一個進程內，我需要支付調用支付方法，需要積分直接調用添加積分的方法，但現在，由于積分模塊或者支付模塊都被拆成了單獨的服務，這個時候如果再想去調用的話，就是通過http方式的請求去調用，這種頻繁的跨服務通信是有很高的成本的，選擇一個適合自己業務的輕量級低成本的通信方式，也很關鍵。

• 服務拆分難：如何做好微服務的拆分?這個是需要我們不斷摸索的，從單體服務向微服務架構的演進，它是一個循序漸進的過程，在演進的過程中常常會根據業務變化來對微服務進行重構，甚至是重新劃分，從而讓這個架構更加合理。

架構區別

MVC架構

MVC 架構就是一個單體架構。我們常使用的技術：Struts2、SpringMVC、Spring、Mybatis等等。

RPC 架構

RPC(RemoteProcedureCall)：遠程過程調用。他一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。我們常使用的技術：Thrift、Hessian等等

實現原理：首先需要有處理網絡連接通訊的模塊，負責連接建立、管理和消息的傳輸。其次需要有編解碼的模塊，因為網絡通訊都是傳輸的字節碼，需要將我們使用的對象序列化和反序列化。剩下的就是客戶端和服務器端的部分，服務器端暴露要開放的服務接口，客戶調用服務接口的一個代理實現，這個代理實現負責收集數據、編碼并傳輸給服務器然后等待結果返回。

SOA 架構

SOA(ServiceorientedArchitecture):面向服務架構

ESB(EnterpariseServceBus):企業服務總線，服務中介。主要是提供了一個服務于服務之間的交互。ESB  包含的功能如：負載均衡，流量控制，加密處理，服務的監控，異常處理，監控告急等等。我們常使用的技術：Mule、WSO2

微服務架構

微服務就是一個輕量級的服務治理方案。我們常使用的技術：SpringCloud、dubbo等等。

架構區別

微服務原則

AKF拆分原則

業界對于可擴展的系統架構設計有一個樸素的理念,就是：通過加機器就可以解決容量和可用性問題。

這一理念在“云計算”概念瘋狂流行的今天，得到了廣泛的認可!對于一個規模迅速增長的系統而言，容量和性能問題當然是首當其沖的。但是隨著時間的向前，系統規模的增長，除了面對性能與容量的問題外，還需要面對功能與模塊數量上的增長帶來的系統復雜性問題以及業務的變化帶來的提供差異化服務問題。而許多系統，在架構設計時并未充分考慮到這些問題，導致系統的重構成為常態，從而影響業務交付能力，還浪費人力財力!對此，《可擴展的藝術》一書提出了一個更加系統的可擴展模型——AKF  可擴展立方(ScalabilityCube)。這個立方體中沿著三個坐標軸設置分別為：X、Y、Z。

Y 軸(功能)——關注應用中功能劃分，基于不同的業務拆分

Y  軸擴展會將龐大的整體應用拆分為多個服務。每個服務實現一組相關的功能，如訂單管理、客戶管理等。在工程上常見的方案是服務化架構(SOA)。比如對于一個電子商務平臺，我們可以拆分成不同的服務，組成下面這樣的架構：

服務化架構 SOA

但通過觀察上圖容易發現，當服務數量增多時，服務調用關系變得復雜。為系統添加一個新功能，要調用的服務數也變得不可控，由此引發了服務管理上的混亂。所以，一般情況下，需要采用服務注冊的機制形成服務網關來進行服務治理。系統的架構將變成下圖所示：

服務網關治理

X 軸(水平擴展)——關注水平擴展，也就是”加機器解決問題”

X  軸擴展與我們前面樸素理念是一致的，通過絕對平等地復制服務與數據，以解決容量和可用性的問題。其實就是將微服務運行多個實例，做集群加負載均衡的模式。為了提升單個服務的可用性和容量，對每一個服務進行X軸擴展劃分。

X 軸(水平擴展)

Z 軸(數據分區)——關注服務和數據的優先級劃分，如按地域劃分

Z 軸擴展通常是指基于請求者或用戶獨特的需求，進行系統劃分，并使得劃分出來的子系統是相互隔離但又是完整的。工程領域常見的Z軸擴展有以下兩種方案：

單元化架構：在分布式服務設計領域，一個單元(Cell)就是滿足某個分區所有業務操作的自包含閉環。如上面我們說到的Y軸擴展的SOA架構，客戶端對服務端節點的選擇一般是隨機的，但是，如果在此加上Z軸擴展，那服務節點的選擇將不再是隨機的了，而是每個單元自成一體。如下圖：

PC 用戶

移動端用戶

數據分區：為了性能數據安全上的考慮，我們將一個完整的數據集按一定的維度劃分出不同的子集。一個分區(Shard)，就是是整體數據集的一個子集。比如用尾號來劃分用戶，那同樣尾號的那部分用戶就可以認為是一個分區。數據分區為一般包括以下幾種數據劃分的方式：

• 數據類型 如：業務類型

• 數據范圍 如：時間段，用戶ID

• 數據熱度 如：用戶活躍度，商品熱度

• 按讀寫分 如：商品描述，商品庫存

前后端分離原則

何為前后端分離?前后端本來不就分離么?這要從尷尬的jsp講起。分工精細化從來都是蛋糕做大的原則，多個領域工程師最好在不需要接觸其他領域知識的情況下合作，才可能使效率越來越高，維護也會變得簡單。jsp  的模板技術融合了 html 和 java 代碼，使得傳統 MVC 開發中的前后端在這里如膠似漆，前端做好頁面，后端轉成模板，發現問題再找前端，前端又看不懂  java 代碼……前后端分離的目的就是將這尷尬局面打破。

前后端分離

前后端分離原則，簡單來講就是前端和后端的代碼分離，我們推薦的模式是最好采用物理分離的方式部署，進一步促使更徹底的分離。如果繼續直接使用服務端模板技術，如：jsp，把  java、js、html、css 都堆到一個頁面里，稍微復雜一點的頁面就無法維護了。

分離原則

這種分離方式有幾個好處：

1. 前后端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前端的用戶體驗優化效果更好。

2. 分離模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口簡潔明了，更容易維護。

3. 前端多渠道集成場景更容易實現，后端服務無需變更，采用統一的數據和模型，可以支持多個前端：例如：微信 h6 前端、PC 前端、安卓前端、IOS  前端

無狀態服務

對于無狀態服務，首先說一下什么是狀態：如果一個數據需要被多個服務共享，才能完成一筆交易，那么這個數據被稱為狀態。進而依賴這個“狀態”數據的服務被稱為有狀態服務，反之稱為無狀態服務。

無狀態服務

那么這個無狀態服務原則并不是說在微服務架構里就不允許存在狀態，表達的真實意思是要把有狀態的業務服務改變為無狀態的計算類服務，那么狀態數據也就相應的遷移到對應的“有狀態數據服務”中。

場景說明：例如我們以前在本地內存中建立的數據緩存、Session  緩存，到現在的微服務架構中就應該把這些數據遷移到分布式緩存中存儲，讓業務服務變成一個無狀態的計算節點。遷移后，就可以做到按需動態伸縮，微服務應用在運行時動態增刪節點，就不再需要考慮緩存數據如何同步的問題。

RestFul 的通訊風格

原則來講本來應該是個“無狀態通信原則”

無狀態通信

在這里我們直接推薦一個實踐優選的 Restful 通信風格，因為他有很多好處：

1. 無狀態協議 HTTP，具備先天優勢，擴展能力很強。例如需要安全加密，有現成的成熟方案HTTPS即可。

2. JSON 報文序列化，輕量簡單，人與機器均可讀，學習成本低，搜索引擎友好。

3. 語言無關，各大熱門語言都提供成熟的 RestfulAPI 框架，相對其他的一些 RPC 框架生態更完善。

通信

服務通信

WebService、WCF、WebAPI，以及 ASHX,ASPX。

• 主動觸發

• 數據序列化傳遞

• 跨平臺。

• 跨語言

• Http 穿透防火墻。

進程通信

• Net Remoting：Net 平臺督郵的，不支持跨平臺。

• gRPC：高性能、開源和通用 RPC框架，面向服務端和移動端，基于 HTTP/2 設計，推薦使用。

WebService

注冊中心 Eureka

注冊中心主要提供三個核心功能：

1. 服務注冊

服務提供者啟動時，會通過 Eureka Client 向 Eureka Server 注冊信息，Eureka Server  會存儲該服務的信息，Eureka Server 內部有二層緩存機制來維護整個注冊表

2. 提供注冊表

服務消費者在調用服務時，如果 Eureka Client 沒有緩存注冊表的話，會從 Eureka Server 獲取最新的注冊表

3. 同步狀態

Eureka Client 通過注冊、心跳機制和 Eureka Server 同步當前客戶端的狀態。

Eureka 流程

網關 Zuul

API  網關是一個更為智能的應用服務器，它的存在就像是整個微服務架構系統的門面，所有的外部客戶端訪問都需要經過它來進行調度和過濾。除了需要實現請求路由，負載均衡及校驗過濾等功能外還需要與服務治理框架的結合，請求轉發時的熔斷機制，服務的聚合等一系列高級功能。主要核心功能：

• 服務路由轉發

• 鑒權校驗過濾

• 熔斷限制保護

網關

認證&授權

現在的應用開發層出不窮，基于瀏覽器的網頁應用，基于微信的公眾號、小程序，基于 IOS、Android 的 App，基于 Windows 系統的桌面應用和  UWP  應用等等，這么多種類的應用，就給應用的開發帶來的挑戰，我們除了分別實現各個應用外，我們還要考慮各個應用之間的交互，通用模塊的提煉，其中身份的認證和授權就是每個應用必不可少的的一部分。而現在的互聯網，對于信息安全要求又十分苛刻，所以一套統一的身份認證和授權就至關重要。

IdentityServer4 就是這樣一個框架，IdentityServer4 是為 ASP.NET CORE 量身定制的實現了 OpenId  Connect 和 OAuth3.0 協議的認證授權中間件。

IdentityServer4

分布式日志

一般我們需要進行日志分析場景：直接在日志文件中 grep、awk  就可以獲得自己想要的信息。但在規模較大也就是日志量多而復雜的場景中，此方法效率低下，面臨問題包括日志量太大如何歸檔、文本搜索太慢怎么辦、如何多維度查詢。需要集中化的日志管理，所有服務器上的日志收集匯總。常見解決思路是建立集中式日志收集系統，將所有節點上的日志統一收集，管理，訪問。

大型系統通常都是一個分布式部署的架構，不同的服務模塊部署在不同的服務器上，問題出現時，大部分情況需要根據問題暴露的關鍵信息，定位到具體的服務器和服務模塊，構建一套集中式日志系統，可以提高定位問題的效率。

Exceptionless 是一個開源的實時的日志收集框架，它可以應用在基于 ASP.NET，ASP.NET Core，Web Api，Web  Forms，WPF，Console，MVC 等技術棧的應用程序中，并且提供了 Rest 接口可以應用在 Javascript，Node.js  中。它將日志收集變得簡單易用并且不需要了解太多的相關技術細節及配置。在以前，我們做日志收集大多使用 Log4net，Nlog  等框架，在應用程序變得復雜并且集群的時候，可能傳統的方式已經不是很好的適用了，因為收集各個日志并且分析他們將變得麻煩而且浪費時間。

現在 Exceptionless 團隊給我們提供了一個更好的框架來做這件事情，我認為這是非常偉大并且有意義的，感謝他們。

ELK是三個開源軟件的縮寫，分別為：Elasticsearch 、 Logstash 以及 Kibana , 它們都是開源軟件。不過現在還新增了一個  Beats，它是一個輕量級的日志收集處理工具(Agent)，Beats 占用資源少，適合于在各個服務器上搜集日志后傳輸給  Logstash，官方也推薦此工具，目前由于原本的 ELK Stack 成員中加入了 Beats 工具所以已改名為 Elastic  Stack，推薦使用。

ELK

配置中心 ConfigSpring

Config 首推基于 git 的管理方式，提供了兩個管理維度，一個是 label(即 branch)，一個是  profile。主要核心功能：

• 業務配置

• 功能開關

• 服務配置

Spring Config

異步隊列 MQMQ

大家都熟悉，現在主流的MQ有rabbitMQ，rocketMQ，kafka。想要了解更多關于 rabbitMQ 和 kafka  的知識可以在這兩篇文章里查看：

圖文詳解：阿里寵兒【小兔】RabbitMQ的養成攻略

圖文詳解：Kafka到底有哪些秘密讓我對它情有獨鐘呢?

核心功能：削峰填谷

流量削峰

容錯限流  Hystrix

它設計用來當分布式系統發生不可避免的異常的時候去隔離當前服務和遠程服務、系統、三方包的聯系，防止出現級聯失敗的情況，從而導致整個系統雪崩。主要核心功能：

• 失敗轉移和優雅降級

• 實時監控更改相關配置

• 基于線程和信號量的斷路器隔離

容錯限流

負載均衡、服務調用

ribbon是一個負載均衡客戶端，可以很好的控制htt和tcp的一些行為。

Feign默認集成了ribbon。ribbon主要功能是提供客戶端的軟件負載均衡算法。Ribbon就屬于進程內負載均衡，它只是一個類庫，集成于消費方進程，消費方通過它來獲取到服務提供方的地址。主要核心功能：負載均衡

負載均衡

持續集成  Jenkins

在項目多的時候，重復操作極大的浪費時間。如果遇到同一時間不同項目組打包項目，打包和部署服務器就要排隊使用，測試人員只能在等待中浪費時間。為了解決這些問題，選擇尋找合適的持續集成方案。來自動化完成重復的步驟。jenkins  還包含了很多插件，比如代碼校驗等等。是 CI/CD 的基本技術。核心功能：

• 拉取代碼

• 打包構建

• 將資源送往目標服務器

持續集成

分布式緩存 RedisRedis

是一款基于 ANSI C 語言編寫的，BSD 許可的，日志型 key-value  存儲組件，它的所有數據結構都存在內存中，可以用作緩存、數據庫和消息中間件。核心功能：

• 內存數據庫

• 基于內存數據庫的各種擴展功能

分布式緩存 Redis

分布式事務

分布式事務的實現方式主要有：

• 2PC(two-phase commit protocol，強一致性，沒有可用性)

• 3PC

• TCC(Try-Confirm-Cancel)

• 本地消息表，推薦 RabbitMQ。

• Saga 模式

本地消息表：MQ分布式事務—本地消息表—基于消息的一致性。

• 上有投遞消息

• 下游獲取消息

• 上游投遞穩定性

• 下游接受穩定性

消息隊列異步

分庫分表 sharding jdbc

Sharding-JDBC定位為輕量級 Java 框架，在 Java 的 JDBC 層提供額外的服務，以 jar  包形式提供服務，無需額外部署和依賴，可以理解為增強版的 JDBC 驅動，完全兼容 JDBC 和各種 ORM 框架。核心功能：

• 數據分片

• 讀寫分離

• 透明的使用jdbc訪問各個數據庫

Sharding-JDBC

SpringCloud

SpringCloud，從命名我們就可以知道，Spring Cloud 是大名鼎鼎的 Spring家族的產品，  專注于企業級開源框架的研發。

Spring Cloud 自從發布到現在，仍然在不斷的高速發展，幾乎考慮了服務治理的方方面面，開發起來非常的便利和簡單。

Spring Cloud 架構

• Service Provider： 暴露服務的提供方。

• Service Consumer： 調用遠程服務的服務消費方。

• EureKa Server： 服務注冊中心和服務發現中心。

Spring Cloud 架構

支持協議

Spring Cloud 使用 HTTP 協議的 REST API。

Spring Cloud 組件運行

所有請求都統一通過 API 網關(Zuul)來訪問內部服務。

網關接收到請求后，從注冊中心(Eureka)獲取可用服務。

由 Ribbon 進行均衡負載后，分發到后端的具體實例。

微服務之間通過 Feign 進行通信處理業務。

Spring Cloud 組件運行

Dubbo

Dubbo 出生于阿里系，是阿里巴巴服務化治理的核心框架，并被廣泛應用于中國各互聯網公司;只需要通過 Spring  配置的方式即可完成服務化，對于應用無入侵，設計的目的還是服務于自身的業務為主。

雖然阿里內部原因 Dubbo 曾經一度暫停維護版本，但是框架本身的成熟度以及文檔的完善程度，完全能滿足各大互聯網公司的業務需求。

Dubbo 架構

• Provider：暴露服務的提供方，可以通過 jar 或者容器的方式啟動服務。

• Consumer：調用遠程服務的服務消費方。

• Registry：服務注冊中心和發現中心。

• Monitor：統計服務和調用次數，調用時間監控中心。(Dubbo 的控制臺頁面中可以顯示，目前只有一個簡單版本。)

• Container：服務運行的容器。

Dubbo 架構

支持協議

Dubbo 使用 RPC 通訊協議，提供序列化方式如下：

Dubbo：Dubbo 缺省協議采用單一長連接和 NIO  異步通訊，適合于小數據量大并發的服務調用，以及服務消費者機器數遠大于服務提供者機器數的情況。

RMI：RMI 協議采用 JDK 標準的 java.rmi.* 實現，采用阻塞式短連接和 JDK 標準序列化方式。

Hessian：Hessian 協議用于集成 Hessian 的服務，Hessian 底層采用 HTTP 通訊，采用 Servlet 暴露服務，Dubbo  缺省內嵌 Jetty 作為服務器實現。

HTTP：采用 Spring 的 Http Invoker 實現。

Webservice：基于 CXF 的 frontend-simple 和 transports-http 實現。

Dubbo 組件運行

每個組件都是需要部署在單獨的服務器上，Gateway 用來接受前端請求、聚合服務，并批量調用后臺原子服務。每個 Service 層和單獨的 DB  交互。

Dubbo 組件運行儲

Gateway：前置網關，具體業務操作，Gateway 通過 Dubbo 提供的負載均衡機制自動完成。

Service：原子服務，只提供該業務相關的原子服務。

Zookeeper：原子服務注冊到 ZK 上。

看完上述內容，你們對什么是微服務有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。