《刷爆硅谷的四條微服務(wù)軍規(guī)》要點(diǎn)：
本文介紹了刷爆硅谷的四條微服務(wù)軍規(guī)，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

當(dāng)下,微服務(wù)是一個(gè)炙手可熱的跨時(shí)代架構(gòu).跟進(jìn)這個(gè)新趨勢(shì),就意味著你得處理舊應(yīng)用.尤其在大型組織,雞蛋不會(huì)只放在一種架構(gòu)籃子里.

企業(yè)對(duì)微服務(wù)的興趣漸漸高漲,就好像技術(shù)行業(yè)的任何正向趨勢(shì).話說(shuō)到這里,其實(shí)我想說(shuō)更重要的是：請(qǐng)保持對(duì)事物前景的透視.雖然微服務(wù)已經(jīng)是“今天的事”,但是你不能只針對(duì)這個(gè)特定的趨勢(shì)做優(yōu)化.除非你是一個(gè)小初創(chuàng)公司,實(shí)在沒(méi)有富余資源來(lái)做投入,否則可能要在以后支持成本更高的混合流程.

微服務(wù)最大亮點(diǎn)之一：不用局限在單一的發(fā)布周期來(lái)對(duì)系統(tǒng)一個(gè)或多個(gè)部分打補(bǔ)丁做優(yōu)化,也不必把所有內(nèi)容都部署在一起.如果你想優(yōu)化一段代碼或糾正錯(cuò)誤,就像在用單片應(yīng)用程序那樣,不必等到下一個(gè)發(fā)布周期.

貌似看起來(lái)很高端,對(duì)不對(duì)?

然而,微服務(wù)方法并不是所有軟件開(kāi)發(fā)和交付的靈丹妙藥.除非你有點(diǎn)厲害,對(duì)基本所有的問(wèn)題了如指掌,否則光是報(bào)錯(cuò)就足夠讓你懷疑人生.

下面是我給到的四點(diǎn)建議,希望能幫你避開(kāi)大坑,用好微服務(wù).

1. 代碼之前請(qǐng)先分解數(shù)據(jù)

用微服務(wù),你把整體應(yīng)用分成不同服務(wù)以便完成不同任務(wù).電商類應(yīng)用就是個(gè)方便貫徹微服務(wù)拆分思想的好例子：用戶登錄,瀏覽產(chǎn)品,看到建議(詳情、評(píng)價(jià)等),添加購(gòu)物車、下單、付款.

如果計(jì)劃將現(xiàn)有單片應(yīng)用遷移成微服務(wù)體系結(jié)構(gòu),則需要對(duì)系統(tǒng)以及所有服務(wù)如何對(duì)接與交互有深入的了解,避免分解過(guò)程中誤判而做了無(wú)用功.要知道,你對(duì)數(shù)據(jù)庫(kù)模式做出的決定,無(wú)論是要為每個(gè)服務(wù)設(shè)置單獨(dú)的數(shù)據(jù)庫(kù),還是對(duì)每個(gè)服務(wù)設(shè)置專用表 ,甚至使用外鍵執(zhí)行的操作,都會(huì)對(duì)開(kāi)銷、總體和成本產(chǎn)生直接影響.

所以這塊我的建議是：分解代碼之前,先分解數(shù)據(jù).

2. 還不是大巨人,那就先做小巨人

如果你的微服務(wù)改造從一張白紙開(kāi)始,從一個(gè)空白新應(yīng)用的一小塊開(kāi)始.首先,你得弄清它涉及的域的樣子以及存在什么類型的數(shù)據(jù)關(guān)系?你在處理事務(wù)數(shù)據(jù)還是關(guān)系數(shù)據(jù)?這些答案將對(duì)數(shù)據(jù)結(jié)構(gòu)產(chǎn)生很大影響.

對(duì)于微服務(wù),大多數(shù)從業(yè)者需要更好地自動(dòng)化部署管道,從代碼檢入到生產(chǎn),并且更好地監(jiān)控環(huán)境.你可能看到某個(gè)服務(wù)有個(gè)問(wèn)題,但很可能實(shí)際上是另一個(gè)問(wèn)題在上游的癥狀.在這種情況下,就需要有自動(dòng)化過(guò)程來(lái)回滾動(dòng)服務(wù),或者說(shuō)在新舊版本之間做切換.

在將應(yīng)用程序重構(gòu)到微服務(wù)之前,得先了解依賴關(guān)系.

3. 注意服務(wù)間的通信

服務(wù)虛擬化和服務(wù)間通信也會(huì)導(dǎo)致大問(wèn)題.微服務(wù)一個(gè)重要的考量標(biāo)準(zhǔn)是擁有定義良好的公共API,方便探查以及每個(gè)微服務(wù)做交互.它不care開(kāi)發(fā)人員是否用了REST、HTTP或JSON,而更在于知道它們?nèi)绾斡脜f(xié)議來(lái)啟用強(qiáng)大的服務(wù)間通信.畢竟如果服務(wù)之間的呼叫由于接口設(shè)計(jì)不當(dāng)而延遲或中斷,那這故事說(shuō)起來(lái)可就長(zhǎng)了.

微服務(wù)通常傾向于部署在容器中,因?yàn)槿萜魈峁└綦x,容易設(shè)置或刪除,并且只運(yùn)行一個(gè)進(jìn)程.它們還具有比虛擬機(jī)更小的占用空間,因此資源利用率具有相對(duì)顯著的差異.

但是如果你有100個(gè)服務(wù)在100個(gè)容器中運(yùn)行,你就要從運(yùn)營(yíng)和管理角度看待事物.首先部署會(huì)變得更復(fù)雜,而且諸如監(jiān)視,日志記錄和修復(fù)動(dòng)作會(huì)變得越來(lái)越重要.

4. 做一把好菜刀的充分條件

俗話說(shuō),好鋼用在刀刃上.改造應(yīng)用,粗淺技術(shù)執(zhí)行起來(lái)肯定困難重重,你要確保的是,既然想做一把好菜刀,那你就得有好鋼好手藝.

微服務(wù)允許你為每個(gè)服務(wù)選擇完全不同的技術(shù)棧.你可以用Java做這個(gè)微服務(wù),用PHP做那個(gè)微服務(wù),這個(gè)用靜態(tài)內(nèi)容,那個(gè)用Apache…隨便你,微服務(wù)允許你這樣選擇.也就是說(shuō),你就能以更小,更獨(dú)立的團(tuán)隊(duì)來(lái)處理單個(gè)服務(wù).只要分解得當(dāng),理論上你的IT管理能力永遠(yuǎn)足夠你所能接手的項(xiàng)目.每個(gè)團(tuán)隊(duì)可以在獨(dú)立發(fā)布的生命周期上工作,不會(huì)受到分發(fā)影響.

大規(guī)模運(yùn)行容器和微服務(wù)還需要許多目前在組織中還沒(méi)普及開(kāi)的多學(xué)科技能,它和曾經(jīng)的單一應(yīng)用開(kāi)發(fā)思維完全不同.在技術(shù)和文化層面,熟悉DevOps和持續(xù)交付的最佳實(shí)踐非常重要.

正好,我們本就應(yīng)該抱著“活到老學(xué)到老”的積極態(tài)度面對(duì)這個(gè)繽紛的世界,對(duì)吧?

原文來(lái)自微信公眾號(hào)：DevOps研究院

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4303.html