基于大數(shù)據(jù)與云計(jì)算的微服務(wù)如何運(yùn)作

微服務(wù)，你玩的起嗎？2微服務(wù)架構(gòu)-MartinFowler微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價(jià)值。每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級的通信機(jī)制互相溝通（通常是基于HTTP協(xié)議的RESTfulAPI）。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立的部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)當(dāng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對具體的一個(gè)服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對其進(jìn)行構(gòu)建。3為什么要采用微服務(wù)架構(gòu)？4初衷讓系統(tǒng)盡可能快的響應(yīng)變化！——Rebecca

Parsons5?服務(wù)足夠小

?獨(dú)立運(yùn)行

?輕量級通信機(jī)制

?獨(dú)立的部署

?去中心化?要多小？

?怎么部署？

?出錯(cuò)怎么辦？

?如何保證一致性6玩得起微服務(wù)的條件

Tall

enough服務(wù)器自演進(jìn)7背景介紹2012年初探微服務(wù)2014年?黑暗時(shí)代2015年服務(wù)治理2016年新的征程2009年82012年新的需求 業(yè)務(wù)系統(tǒng)A業(yè)務(wù)系統(tǒng)B9重復(fù)？10微服務(wù)架構(gòu)初步形成11那時(shí)的微服務(wù)12它給我們帶來了哪些好處？13新業(yè)務(wù)C三個(gè)月上線14更多服務(wù)更快一點(diǎn)？15服務(wù)越多，周期越來越短162014年問題倍出1 環(huán)境手工維護(hù)，頻頻出錯(cuò)部署成功率很低，部署時(shí)經(jīng)常有一堆環(huán)境修改需求，運(yùn)維人員出錯(cuò)機(jī)會(huì)增加，運(yùn)維效率極低。2缺乏有效監(jiān)控?zé)o法快速有效定位問題，無法快速有效知曉服務(wù)運(yùn)行狀態(tài)，服務(wù)資源浪費(fèi)。172014年問題倍出（二）3服務(wù)過大，堵塞交付快速增長的結(jié)果導(dǎo)致服務(wù)過大或者服務(wù)過小。而過大的服務(wù)導(dǎo)致整個(gè)提交流水線堵塞，測試人員無法拿到新的版本，交付延期4團(tuán)隊(duì)出現(xiàn)沖突，架構(gòu)腐化嚴(yán)重

交付不能完成導(dǎo)致各角色間的

沖突越來越嚴(yán)重，為了快速上

線質(zhì)量遭到犧牲。架構(gòu)無人守

護(hù)，各種不一致性，服務(wù)內(nèi)部

接口一?片混亂，核心人員離職18不要再添加任何服務(wù)19當(dāng)然不是！20業(yè)務(wù)迅速擴(kuò)張21技術(shù)選型靈活22助力客戶快速占領(lǐng)市場23那怎么辦？242015年服務(wù)治理25回到問題123服務(wù)過大，堵塞交付快速增長的結(jié)果導(dǎo)致服務(wù)過大或者服務(wù)過小。而過大的服務(wù)導(dǎo)致整個(gè)提交流水線堵塞，測試人員無法拿到新的版本，交付延期4團(tuán)隊(duì)出現(xiàn)沖突，架構(gòu)腐化嚴(yán)重交付不能完成導(dǎo)致各角色間的沖突越來越嚴(yán)重，為了快速上線質(zhì)量遭到犧牲。架構(gòu)無人守護(hù)，各種不一致性，服務(wù)內(nèi)部接口一片混亂，核心人員離職

環(huán)境手工維護(hù)，頻頻出錯(cuò)部署成功率很低，部署時(shí)經(jīng)常有?一堆環(huán)境修改需求，運(yùn)維人員出錯(cuò)機(jī)會(huì)增加，運(yùn)維效率極低。缺乏有效監(jiān)控?zé)o法快速有效定位問題，無法快速有效知曉服務(wù)運(yùn)?行狀態(tài)，服務(wù)資源浪費(fèi)。261.運(yùn)維自動(dòng)化1

基礎(chǔ)設(shè)施自動(dòng)化實(shí)施了新的部署流程，成功率大大提高，部署時(shí)間縮短到30分鐘。2高效監(jiān)控服務(wù)提供狀態(tài)匯報(bào)，利用Splunk聚合日志，對服務(wù)運(yùn)行狀態(tài)進(jìn)行監(jiān)控，大大提高運(yùn)維效率。272.DevOps一家親28回到問題3服務(wù)過大，堵塞交付快速增長的結(jié)果導(dǎo)致服務(wù)過大或者服務(wù)過小。而過大的服務(wù)導(dǎo)致整個(gè)提交流水線堵塞，測試人員無法拿到新的版本，交付延期4團(tuán)隊(duì)出現(xiàn)沖突，架構(gòu)腐化嚴(yán)重交付不能完成導(dǎo)致各角色間的沖突越來越嚴(yán)重，為了快速上線質(zhì)量遭到犧牲。架構(gòu)無人守護(hù)，各種不一致性，服務(wù)內(nèi)部接口一片混亂，核心人員離職

環(huán)境手工維護(hù)，頻頻出錯(cuò)部署成功率很低，部署時(shí)經(jīng)常有?一堆環(huán)境修改需求，運(yùn)維人員出錯(cuò)機(jī)會(huì)增加，運(yùn)維效率極低。缺乏有效監(jiān)控?zé)o法快速有效定位問題，無法快速有效知曉服務(wù)運(yùn)?行狀態(tài)，服務(wù)資源浪費(fèi)。293.服務(wù)拆分30微服務(wù)的附加成本313.服務(wù)自演進(jìn)2341劃分合適的業(yè)務(wù)邊界進(jìn)行合適模塊化可測試的拒絕跨上下文的數(shù)據(jù)表連接32交付暢通33回到問題服務(wù)過大，堵塞交付快速增長的結(jié)果導(dǎo)致服務(wù)過大或者服務(wù)過小。而過大的服務(wù)導(dǎo)致整個(gè)提交流水線堵塞，測試人員無法拿到新的版本，交付延期4團(tuán)隊(duì)出現(xiàn)沖突，架構(gòu)腐化嚴(yán)重交付不能完成導(dǎo)致各角色間的沖突越來越嚴(yán)重，為了快速上線質(zhì)量遭到犧牲。架構(gòu)無人守護(hù)，各種不一致性，服務(wù)內(nèi)部接口一片混亂，核心人員離職

環(huán)境手工維護(hù)，頻頻出錯(cuò)部署成功率很低，部署時(shí)經(jīng)常有?一堆環(huán)境修改需求，運(yùn)維人員出錯(cuò)機(jī)會(huì)增加，運(yùn)維效率極低。缺乏有效監(jiān)控?zé)o法快速有效定位問題，無法快速有效知曉服務(wù)運(yùn)?行狀態(tài)，服務(wù)資源浪費(fèi)。34所有人？35康威定律設(shè)計(jì)一個(gè)系統(tǒng)的任何組織所產(chǎn)生的設(shè)計(jì)和架構(gòu)都等價(jià)于其組織間的溝通結(jié)構(gòu)。

—Melvyn

Conway,

196736康威逆定律逐漸改進(jìn)你的團(tuán)隊(duì)和組織結(jié)構(gòu)來促進(jìn)你所渴望的軟件系統(tǒng)架構(gòu)?！猄am

Newman37微服務(wù)架構(gòu)特性?????服務(wù)足夠小

獨(dú)立運(yùn)行

輕量級通信機(jī)制

獨(dú)立的部署

去中心化38新的團(tuán)隊(duì)結(jié)構(gòu)39沒有衡量就沒有改善，你衡量什么就得到什么！—Peter

F．Drucker40建立閉環(huán)反饋系統(tǒng)產(chǎn)品規(guī)劃需求澄清分析設(shè)計(jì)開發(fā)實(shí)現(xiàn)測試交付上線發(fā)布運(yùn)營持續(xù)交付