大神告訴你如何理解微服務(wù)框架

因?yàn)镸artin Fowler和Chris Richardson兩位大神的布道，及NetFlix和Amazon公司的實(shí)踐，國(guó)內(nèi)對(duì)于微服務(wù)的一些基礎(chǔ)問題理解基本一致，但受限于自身單體應(yīng)用的限制，過度到微服務(wù)架構(gòu)，又要各想辦法，具體問題具體看了。本篇描述一下微服務(wù)架構(gòu)的基本概念及個(gè)人的一些理解。“微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間相互協(xié)調(diào)、互相配合，為用戶提供最終價(jià)值。每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)和服務(wù)之間采用輕量級(jí)的通信機(jī)制相互溝通（通常是基于HTTP的Restful API).每個(gè)服務(wù)都圍繞著具體的業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)盡量避免統(tǒng)一的、集中的服務(wù)管理機(jī)制，對(duì)具體的一個(gè)服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對(duì)其進(jìn)行構(gòu)"---- Martin Fowler的博客

專業(yè)成都網(wǎng)站建設(shè)公司，做排名好的好網(wǎng)站，排在同行前面，為您帶來客戶和效益!創(chuàng)新互聯(lián)為您提供成都網(wǎng)站建設(shè)，五站合一網(wǎng)站設(shè)計(jì)制作，服務(wù)好的網(wǎng)站設(shè)計(jì)公司，網(wǎng)站設(shè)計(jì)、做網(wǎng)站負(fù)責(zé)任的成都網(wǎng)站制作公司!

  微服務(wù)的特征與界定

單體應(yīng)用vs 微服務(wù)架構(gòu)

 優(yōu)點(diǎn)

1:提升開發(fā)交流，每個(gè)服務(wù)足夠內(nèi)聚，足夠小，代碼容易理解；

2:服務(wù)獨(dú)立測(cè)試、部署、升級(jí)、發(fā)布；

3:按需定制的DFX，資源利用率，每個(gè)服務(wù)可以各自進(jìn)行x擴(kuò)展和z擴(kuò)展，而且，每個(gè)服務(wù)可以根據(jù)自己的需要部署到合適的硬件服務(wù)器上；每個(gè)服務(wù)按4:需要選擇HA的模式，選擇接受服務(wù)的實(shí)例個(gè)數(shù)；

5:容易擴(kuò)大開發(fā)團(tuán)隊(duì)，可以針對(duì)每個(gè)服務(wù)（service）組件開發(fā)團(tuán)隊(duì)；

6:提高容錯(cuò)性（fault isolation），一個(gè)服務(wù)的內(nèi)存泄露并不會(huì)讓整個(gè)系統(tǒng)癱瘓；

7:新技術(shù)的應(yīng)用，系統(tǒng)不會(huì)被長(zhǎng)期限制在某個(gè)技術(shù)棧上；

缺點(diǎn)

沒有銀彈，微服務(wù)提高了系統(tǒng)的復(fù)雜度；開發(fā)人員要處理分布式系統(tǒng)的復(fù)雜性；服務(wù)之間的分布式通信問題；服務(wù)的注冊(cè)與發(fā)現(xiàn)問題；服務(wù)之間的分布式事務(wù)問題；數(shù)據(jù)隔離再來的報(bào)表處理問題；服務(wù)之間的分布式一致性問題；服務(wù)管理的復(fù)雜性，服務(wù)的編排；不同服務(wù)實(shí)例的管理。

Chris Richardson提出的微服務(wù)的三維擴(kuò)展模型：

X軸，服務(wù)實(shí)例水平擴(kuò)展，保證可靠性與性能；

Y軸，功能的擴(kuò)展，服務(wù)單一職責(zé)，功能獨(dú)立；

Z軸，數(shù)據(jù)分區(qū)，數(shù)據(jù)獨(dú)立，可靠性保證；

  通信問題

微服務(wù)的拆分一般會(huì)帶來IPC通信的問題。通信機(jī)制需要完備可靠，服務(wù)之間的通信選擇應(yīng)盡量單一，從兩個(gè)維度對(duì)通信的模式進(jìn)行劃分：

第一個(gè)維度是一對(duì)一還是一對(duì)多：

一對(duì)一：每個(gè)客戶端請(qǐng)求有一個(gè)服務(wù)實(shí)例來響應(yīng)。

一對(duì)多：每個(gè)客戶端請(qǐng)求有多個(gè)服務(wù)實(shí)例來響應(yīng)。

第二個(gè)維度是這些交互式同步還是異步：

同步模式：客戶端請(qǐng)求需要服務(wù)端即時(shí)響應(yīng)，甚至可能由于等待而阻塞。

異步模式：客戶端請(qǐng)求不會(huì)阻塞進(jìn)程，服務(wù)端的響應(yīng)可以是非即時(shí)的。

微服務(wù)架構(gòu)認(rèn)為，服務(wù)間通信應(yīng)該就只有這幾種模式。AC出于時(shí)延、編程模型等方面的考慮，提供了一套通信機(jī)制，業(yè)務(wù)之間的通信要按需選用。

  服務(wù)的發(fā)現(xiàn)與注冊(cè)

一般的微服務(wù)架構(gòu)里都有兩層API GetWay，一層是外部API GetWay，用于用戶訪問系統(tǒng)；一層是內(nèi)部API GetWay，內(nèi)部服務(wù)之間的API GetWay。內(nèi)部API GetWay要解決的問題就是服務(wù)發(fā)現(xiàn)和服務(wù)注冊(cè)。從這也能看出來，為什么通信的方式要盡量單一，API GetWay有一項(xiàng)工作就是協(xié)議轉(zhuǎn)換。

微服務(wù)可能是HA主備的，也可能是LB的，怎么找到一個(gè)服務(wù)？有兩種思路，客戶端發(fā)現(xiàn)（上圖）,客戶端去注冊(cè)中心查詢服務(wù)實(shí)例列表，自行選擇；另一種是服務(wù)端發(fā)現(xiàn)（下圖），添加LB模塊，客戶端把請(qǐng)求發(fā)向LB，由LB根據(jù)負(fù)載均衡策略選擇服務(wù)實(shí)例；

微服務(wù)注冊(cè)表的典型實(shí)現(xiàn):

 ETCD : 是一個(gè)高可用，分布式的，一致性的，鍵值表，用于共享配置和服務(wù)發(fā)現(xiàn)。兩個(gè)著名案例包括Kubernetes和Cloud Foundry。 ZK: 是一個(gè)廣泛使用，為分布式應(yīng)用提供高性能整合的服務(wù)。Apache ZooKeeper最初是Hadoop的子項(xiàng)目，現(xiàn)在已經(jīng)變成頂級(jí)項(xiàng)目。

微服務(wù)架構(gòu)的部署

微服務(wù)架構(gòu)對(duì)于部署的要求 ：

部署速率，Amazon與NetFlix都有千個(gè)服務(wù)，每個(gè)服務(wù)都有持續(xù)部署的要求，Amazon的服務(wù)每秒都會(huì)部署一次；

部署自動(dòng)化，一切都要自動(dòng)化，IaaS與PaaS解決I層與P層自動(dòng)化部署，微服務(wù)有自動(dòng)部署與運(yùn)維工具，并實(shí)現(xiàn)Auto-Scaling；

部署提供基礎(chǔ)機(jī)制，為實(shí)現(xiàn)分布式部署要求，部署機(jī)制一般都有資源池化、服務(wù)的生命周期來看，部署服務(wù)與服務(wù)注冊(cè)是一體的；

部署的粒度：

VM: 部署系統(tǒng)管理的VM的生命周期，如當(dāng)前AC的iDeploy部署，把AC部署拆分為每個(gè)VM的安裝、配置與啟動(dòng)；這種方式粒度粗，支撐不了微服務(wù)的部署(除非一個(gè)服務(wù)占用一個(gè)VM); 

App: 管理應(yīng)用的生命周期及部署形態(tài)，生命周期分為部署、配置、啟動(dòng)、升級(jí)等，部署形態(tài)有主備、LB、Daemon等；

Container: 相比于APP，容器有更好的隔離性和移植性；

微服務(wù)：一般的微服務(wù)要么是APP，要么是Container，但AC就不是。受限于ONOS架構(gòu)，我們的服務(wù)是一組feature；

MS部署的解決方案：

TOSCA: 云應(yīng)用拓?fù)錁?biāo)準(zhǔn)，一種描述云化部署的DSL，我司主推一個(gè)標(biāo)準(zhǔn)，PaaS的部署系統(tǒng)和MANO用的都是TOSCA；

Kubernetes:Google開源的容器管理系統(tǒng)，提出了Pod/Service/Labels等概念，以ETCD為中心，PaaS基于K8S開發(fā)出了我司的云化部署平臺(tái)；

Mesosphere:DCOS，數(shù)據(jù)中心操作系統(tǒng)，基于mesos實(shí)現(xiàn)資源池化，有自身的編排工具；分布式LAB基于DCOS的思想做出了一套部署與集群管理系統(tǒng)(HASEN)；

微服務(wù)的劃分

微服務(wù)的劃分主要是保證微服務(wù)功能內(nèi)聚，職責(zé)單一。一般使用DDD(Domain Drive Design)的思想與方法對(duì)微服務(wù)進(jìn)行劃分，這種方法有點(diǎn)類似于數(shù)據(jù)庫ER圖的劃分，不斷分解數(shù)據(jù)，保證關(guān)系型數(shù)據(jù)庫符合原子性、冗余性的范式要求。當(dāng)然，微服務(wù)的劃分比數(shù)據(jù)表劃分更復(fù)雜，也沒有微服務(wù)范式的概念，但思想是一致的。更多的內(nèi)容，請(qǐng)參考《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》這本書。

分布式一致性

有兩個(gè)大的思路：全局的分布式事務(wù)；事件驅(qū)動(dòng)；

分布式事務(wù)就是現(xiàn)在AC的思路，在設(shè)計(jì)開發(fā)中；

事件驅(qū)動(dòng)，忽略了事務(wù)的概念，由每個(gè)服務(wù)在應(yīng)用層面保存服務(wù)的狀態(tài)，服務(wù)之間的通信使用事件機(jī)制通知；此種方法可以保證微服務(wù)間的獨(dú)立性，但把問題交給了服務(wù)的設(shè)計(jì)者；具體事件驅(qū)動(dòng)的案例見參考材料；

數(shù)據(jù)隔離問題

微服務(wù)之間數(shù)據(jù)隔離可以保證服務(wù)的獨(dú)立升級(jí)與部署，數(shù)據(jù)隔離有三個(gè)維度：

數(shù)據(jù)表級(jí)隔離；數(shù)據(jù)表之間獨(dú)立，沒有外鍵關(guān)系；

數(shù)據(jù)庫級(jí)隔離；不同服務(wù)有不同的數(shù)據(jù)庫；

DBMS級(jí)隔離；不同服務(wù)有不同的數(shù)據(jù)庫管理系統(tǒng)；

一般做到數(shù)據(jù)庫級(jí)隔離就可以了，服務(wù)之間的數(shù)據(jù)交換使用服務(wù)間接口。

從單體到微服務(wù)

微服務(wù)架構(gòu)是一個(gè)衍生架構(gòu)，都是從單體架構(gòu)演化而來的。

因?yàn)槲⒎?wù)架構(gòu)本身的復(fù)雜性，初創(chuàng)系統(tǒng)出于快速開發(fā)、快速驗(yàn)證的考慮，很少在一開始就使用微服務(wù)架構(gòu)。加之微服務(wù)的概念在這兩年才火，大型單體應(yīng)用也是看到了開發(fā)與維護(hù)的成本在不斷增加，才會(huì)有轉(zhuǎn)型微服務(wù)的動(dòng)力。因此，如何從單體到微服務(wù)是一個(gè)普遍問題。

從單體到微服務(wù)的原則：

逐步演進(jìn)，不要全部重構(gòu) 。

全部重構(gòu)，帶來極大的成本和風(fēng)險(xiǎn)，系統(tǒng)會(huì)有很長(zhǎng)的不穩(wěn)定期。而且，最終的效果也不會(huì)很好，在設(shè)計(jì)時(shí)很難想到所有問題。微服務(wù)架構(gòu)的演化思路應(yīng)該是一步步鋪基礎(chǔ)設(shè)施，一點(diǎn)點(diǎn)拆分微服務(wù)。

演化建議（個(gè)人建議）

1. 不要增加新的耦合；

不要有編譯依賴，如直接import其它模塊的類；

使用版本建議的通信方式，不要使用osgiservice，這個(gè)耦合還是很強(qiáng)；不要直接訪問其它模塊的數(shù)據(jù)表；

避免不必要的親合性，注意特性之間的狀態(tài)，如A特性訪問B特性的2個(gè)請(qǐng)求有狀態(tài)，那這兩個(gè)特性實(shí)例就有親合性；

2. 前后端分離；

  前后端業(yè)務(wù)分離，前端之間不會(huì)耦合，能前端做的，就放在前端；

3. 獨(dú)立的服務(wù)逐漸拆出；

  逐步拆出功能獨(dú)立的微服務(wù)，對(duì)有特殊DFX要求的微服務(wù)也可以優(yōu)先拆出；

DevOps與微服務(wù)架構(gòu)

DevOps 是09年提出來的概念，但一直沒有太火。直到14年，容器與微服務(wù)架構(gòu)的提出，DevOps才得到了快速的發(fā)展。DevOps不單是一個(gè)實(shí)現(xiàn)自動(dòng)化的工具鏈，而是組織、流程與技術(shù)的結(jié)合。組織上強(qiáng)調(diào)全棧團(tuán)隊(duì)、團(tuán)隊(duì)特性專一、團(tuán)隊(duì)自治；技術(shù)上打通開發(fā)與運(yùn)維；流程上強(qiáng)調(diào)端到端、可視化、灰度升級(jí)、A/B測(cè)試等。

對(duì)于DevOps，MS不是必須的，但MS為DevOps提供了最好的架構(gòu)支撐，對(duì)于組織和流程的要求也是一致的。所以，也有人稱MS是DevOps架構(gòu)。

目前國(guó)內(nèi)多家巨頭都對(duì)微服務(wù)的支持投入巨大，例如騰訊云micro-service、 華為云微服務(wù)云應(yīng)用平臺(tái)ServiceStage 等等。

本文名稱：大神告訴你如何理解微服務(wù)框架
轉(zhuǎn)載注明：http://bm7419.com/article38/gocipp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導(dǎo)航、網(wǎng)站維護(hù)、網(wǎng)頁設(shè)計(jì)公司、網(wǎng)站導(dǎo)航、網(wǎng)站設(shè)計(jì)、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)