1.未來(lái)已經(jīng)在這里，它只是分布不均?！?威廉·吉布森

創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比香坊網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式香坊網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋香坊地區(qū)。費(fèi)用合理售后完善，十多年實(shí)體公司更值得信賴。

數(shù)字時(shí)代就在我們身邊。將軟件開發(fā)視為高成本開銷而不是競(jìng)爭(zhēng)力的企業(yè)將會(huì)舉步維艱。為了參與并在這個(gè)數(shù)字世界中繁榮興旺，企業(yè)必須學(xué)會(huì)適應(yīng)我們這個(gè)時(shí)代的不確定性—更快地將新產(chǎn)品推向市場(chǎng)，快速而有效地改進(jìn)當(dāng)前的產(chǎn)品，并為客戶提供有意義的數(shù)字體驗(yàn)。

為了實(shí)現(xiàn)這些目標(biāo)，企業(yè)需要將敏捷性/適應(yīng)性集成到三個(gè)領(lǐng)域：人、流程和技術(shù)。

人們需要適應(yīng)試驗(yàn)和改變。以“迭代”的形式推進(jìn)這一過(guò)程，并加強(qiáng)學(xué)習(xí)。技術(shù)，包括技術(shù)架構(gòu)，需要支持快速地交付產(chǎn)品與服務(wù)。

技術(shù)的敏捷性不能被忽視——敏捷的團(tuán)隊(duì)和流程并不能彌補(bǔ)笨重的技術(shù)所帶來(lái)的缺陷。

但作為一個(gè)高級(jí)管理人員，在這樣一個(gè)充滿了新技術(shù)的世界，你應(yīng)該將注意力投注在哪里呢?

這個(gè)問(wèn)題的答案被那些不停地討論著看似神秘話題的技術(shù)人員們所掩蓋。哪些神秘的話題需要得到管理層的注意呢?其中最重要的話題之一是微服務(wù)。原因如下所述：

微服務(wù)影響人、流程和技術(shù)：包括團(tuán)隊(duì)組織結(jié)構(gòu)，流程和實(shí)踐(如DevOps)，以及重新調(diào)整架構(gòu)以適應(yīng)我們要解決的問(wèn)題，而并非純技術(shù)層面。微服務(wù)促進(jìn)了每個(gè)領(lǐng)域的適應(yīng)性。它值得管理層花時(shí)間去了解其潛在的貢獻(xiàn)。

技術(shù)敏捷度

微服務(wù)架構(gòu)風(fēng)格的特性是由一組極小的服務(wù)組成，它們彼此獨(dú)立且單獨(dú)部署。微服務(wù)由Netflix這樣的公司推廣開來(lái)。每個(gè)服務(wù)包含一個(gè)離散的業(yè)務(wù)功能，它在技術(shù)上與其他服務(wù)相隔離，產(chǎn)生了類似樂(lè)高積木的效果：開發(fā)人員可以將服務(wù)切換為一個(gè)新的服務(wù)，而無(wú)需破壞其他服務(wù)。就像巨型的樂(lè)高模型可以由75,000塊樂(lè)高組成，大型的數(shù)字應(yīng)用程序也可以由這些受樂(lè)高思想啟發(fā)的服務(wù)所構(gòu)建。

這種架構(gòu)有一些明顯的好處。

首先，每個(gè)服務(wù)與其他服務(wù)高度解耦，這意味著它們是自包含的。因此，一個(gè)服務(wù)中的技術(shù)更改(例如數(shù)據(jù)結(jié)構(gòu)更改)不會(huì)影響另一個(gè)服務(wù)。服務(wù)仍然可以通過(guò)消息傳遞進(jìn)行通信，但是任何一個(gè)服務(wù)都不允許修改另一個(gè)服務(wù)的實(shí)現(xiàn)細(xì)節(jié)。

第二，因?yàn)殚_發(fā)人員不需要共享基礎(chǔ)設(shè)施，他們可以選用適合于該問(wèn)題復(fù)雜度的技術(shù)棧來(lái)實(shí)現(xiàn)每一個(gè)服務(wù)。考慮到當(dāng)今技術(shù)棧的復(fù)雜性，在同一應(yīng)用程序中，使用簡(jiǎn)單工具處理簡(jiǎn)單問(wèn)題和使用復(fù)雜工具處理復(fù)雜問(wèn)題的能力使開發(fā)團(tuán)隊(duì)在增加了靈活性的同時(shí)也降低了成本。***重視能將復(fù)雜問(wèn)題簡(jiǎn)化的技術(shù)專家。

第三，每個(gè)服務(wù)封裝了業(yè)務(wù)功能，它更容易促成圍繞特定問(wèn)題域的團(tuán)隊(duì)，而不是通過(guò)作業(yè)功能分割的團(tuán)隊(duì)。例如，服務(wù)團(tuán)隊(duì)通常包括開發(fā)人員、業(yè)務(wù)分析師、DBA、運(yùn)維人員和QA—即構(gòu)建和部署服務(wù)所需的一切角色。這樣一來(lái)便降低了協(xié)調(diào)成本。

“從功能性組織結(jié)構(gòu)向產(chǎn)品或服務(wù)結(jié)構(gòu)轉(zhuǎn)變”是敏捷企業(yè)轉(zhuǎn)型的一個(gè)日益增長(zhǎng)的趨勢(shì)。而微服務(wù)架構(gòu)支持了這種趨勢(shì)的變化。

***，因?yàn)槊總€(gè)服務(wù)是相互隔離的，所以以服務(wù)組成的架構(gòu)既快速又靈活。同時(shí)因?yàn)榉?wù)的業(yè)務(wù)范圍很小，對(duì)服務(wù)的更改可以快速地發(fā)生，這為開發(fā)人員提供了新的高級(jí)功能。一旦架構(gòu)師設(shè)計(jì)了一個(gè)小型獨(dú)立服務(wù)的系統(tǒng)，其中應(yīng)用程序由部署的多個(gè)服務(wù)之間的消息傳遞組成，多變量測(cè)試等操作就變得容易了。

例如，企業(yè)可能對(duì)他們網(wǎng)站的未來(lái)發(fā)展方向并不確定。因此他們?cè)O(shè)計(jì)了具有相似性但功能不同的兩種服務(wù)，并向不同的用戶組部署不同的版本，以獲取結(jié)果從而推動(dòng)未來(lái)的發(fā)展。像Facebook這樣的公司也是通過(guò)使用這種類型的A / B測(cè)試進(jìn)行試驗(yàn)來(lái)分析他們的用戶。

標(biāo)準(zhǔn)化一直是IT組織降低成本的方式之一。不幸的是，它也降低了靈活性—標(biāo)準(zhǔn)化越多，靈活性越少。通過(guò)采納微服務(wù)架構(gòu)，架構(gòu)師和開發(fā)人員可以使用更加多樣化且能夠緊密反映問(wèn)題復(fù)雜度的技術(shù)棧來(lái)設(shè)計(jì)應(yīng)用程序。

微服務(wù)架構(gòu)風(fēng)格與許多企業(yè)部署軟件和分配IT資源的方式相反。許多架構(gòu)風(fēng)格的主要目標(biāo)之一是有效地利用共享資源(操作系統(tǒng)、數(shù)據(jù)庫(kù)服務(wù)器、應(yīng)用程序服務(wù)器等)。由于資源的成本影響了底線，因此這些公司建立了軟件架構(gòu)以***化共享資源。

然而，共享資源有一個(gè)缺點(diǎn)。無(wú)論開發(fā)人員如何有效地構(gòu)建與這些服務(wù)器的隔離，都會(huì)出現(xiàn)對(duì)這些資源的競(jìng)爭(zhēng)。有時(shí)組件由于依賴管理而互相干擾，有時(shí)由于兩個(gè)組件爭(zhēng)用某些資源(例如CPU)而產(chǎn)生問(wèn)題。這就不可避免地會(huì)導(dǎo)致共享組件以并不期望的方式進(jìn)行交互。

容器和解耦

在軟件交付中，有兩個(gè)關(guān)鍵的技術(shù)“環(huán)境”：開發(fā)人員工作的開發(fā)環(huán)境，以及IT運(yùn)維人員管轄范圍的部署環(huán)境。傳統(tǒng)情況下，在這兩個(gè)環(huán)境之間移動(dòng)代碼充滿了技術(shù)錯(cuò)誤，冗長(zhǎng)的時(shí)間延遲以及組織層面的溝通不暢。

幾年前，一些有趣的事情發(fā)生了：Linux對(duì)于大多數(shù)企業(yè)足夠友好，Linux的變體在商業(yè)上免費(fèi)—但是這不足以影響技術(shù)架構(gòu)。

接下來(lái)，開源的創(chuàng)新與敏捷開發(fā)技術(shù)的結(jié)合鼓勵(lì)了開發(fā)人員創(chuàng)建各種工具，將許多繁瑣的運(yùn)維手工操作自動(dòng)化。這被許多人稱為DevOps革命。

這場(chǎng)革命使得開發(fā)團(tuán)隊(duì)和IT運(yùn)維人員通過(guò)使用Puppet、Chef和Docker等高級(jí)工具更加緊密地聯(lián)系在一起。意外地，Linux的變體允許免費(fèi)操作，開發(fā)人員可以在不受干擾的情況下將其組件部署到一個(gè)原始的操作系統(tǒng)。一整個(gè)可能的錯(cuò)誤類別就突然消失了，因?yàn)榻M件之間能夠相互解耦。

如果開發(fā)人員可以構(gòu)建他們自己的現(xiàn)實(shí)環(huán)境，他們必須減少與運(yùn)維部門的協(xié)調(diào)，也就減少了組織間的摩擦。用程序啟動(dòng)類生產(chǎn)環(huán)境的能力消除了測(cè)試、集成、共享環(huán)境下的資源競(jìng)爭(zhēng)、以及一系列其他問(wèn)題。

21世紀(jì)的架構(gòu)敏捷度

在治理方面，微服務(wù)架構(gòu)風(fēng)格有其他的好處。傳統(tǒng)的做法是，企業(yè)架構(gòu)師定義了組織的共享技術(shù)棧，以***化項(xiàng)目間的資源使用，同時(shí)***程度地減少支撐成本。例如，一個(gè)大型企業(yè)可能將Java和Oracle標(biāo)準(zhǔn)化以作為其主要開發(fā)平臺(tái)。如果每個(gè)人都使用Oracle，那么該企業(yè)的一切都可以存儲(chǔ)在一個(gè)工業(yè)強(qiáng)度的數(shù)據(jù)庫(kù)中。

規(guī)范化治理有一個(gè)缺點(diǎn)—通常，為了標(biāo)準(zhǔn)化的某一目的，團(tuán)隊(duì)必須使用并不太理想的工具。與此同時(shí)，還有一個(gè)潛在的更微妙的缺點(diǎn)。例如，考慮一個(gè)已經(jīng)選擇在特定消息隊(duì)列上標(biāo)準(zhǔn)化的大型企業(yè)。在評(píng)估需要此共享基礎(chǔ)設(shè)施的所有項(xiàng)目時(shí)，企業(yè)架構(gòu)師會(huì)找出最復(fù)雜的場(chǎng)景，并選擇一個(gè)適合這種復(fù)雜度的工具來(lái)處理它們。

然而，許多項(xiàng)目并不具備這個(gè)最復(fù)雜的場(chǎng)景。但因?yàn)槊總€(gè)項(xiàng)目必須共享相同的基礎(chǔ)設(shè)施，所以每個(gè)團(tuán)隊(duì)都得承擔(dān)其他團(tuán)隊(duì)的***復(fù)雜度。這種情況也發(fā)生在數(shù)據(jù)庫(kù)層。許多項(xiàng)目只需要幾個(gè)記錄的簡(jiǎn)單數(shù)據(jù)存儲(chǔ)，并不需要復(fù)雜的查詢功能，但最終都使用了具有工業(yè)強(qiáng)度的數(shù)據(jù)庫(kù)服務(wù)器，只因?yàn)檫@個(gè)企業(yè)的標(biāo)準(zhǔn)如此。

容器化技術(shù)解決了這個(gè)問(wèn)題，因?yàn)樗h(yuǎn)離了共享基礎(chǔ)設(shè)施—每個(gè)項(xiàng)目都部署在自己原始的、容器化的環(huán)境中。因?yàn)椴淮嬖诠蚕淼膭?dòng)力去選擇工具，所以每個(gè)項(xiàng)目刻意選擇更適合自己的工具。

當(dāng)然，如果企業(yè)架構(gòu)師允許每個(gè)項(xiàng)目選擇自己的技術(shù)棧，那么會(huì)存在一些嚴(yán)重的缺點(diǎn)。我們經(jīng)?？吹揭粋€(gè)稱之為“Goldilocks治理”(企業(yè)架構(gòu)師選擇幾個(gè)技術(shù)棧—簡(jiǎn)單、中等和復(fù)雜，并根據(jù)規(guī)模分配新項(xiàng)目)的實(shí)踐，它適用于高度解耦的環(huán)境。這些知識(shí)是可遷移的，該公司仍然可以從中受益，但是卻可以遠(yuǎn)離那些由于疏忽大意而將問(wèn)題過(guò)于復(fù)雜化的行為。

為什么我們會(huì)談到這兒?

Eric Evans的《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》一書對(duì)微服務(wù)架構(gòu)發(fā)展產(chǎn)生了巨大的影響。它介紹了一種將大問(wèn)題空間分解為領(lǐng)域或重要實(shí)體(如客戶和訂單)及其關(guān)系(客戶下訂單)和行為的技術(shù)。領(lǐng)域定義的一部分是有關(guān)邊界上下文的概念：每個(gè)領(lǐng)域形成一個(gè)圍繞實(shí)現(xiàn)細(xì)節(jié)的封裝層。

例如，如果分析人員識(shí)別了一個(gè)Customer領(lǐng)域，那么它存在于自己的邊界上下文中。在Customer的上下文中，開發(fā)人員知道所有的實(shí)現(xiàn)細(xì)節(jié)：類結(jié)構(gòu)，數(shù)據(jù)庫(kù)模式等。

但是，其他邊界上下文(如Orders)不能看到這些實(shí)現(xiàn)細(xì)節(jié)。雖然領(lǐng)域可以為了協(xié)調(diào)的目的互相發(fā)送消息，但是任何一個(gè)領(lǐng)域都不能穿透另一個(gè)領(lǐng)域的邊界上下文。因此，在一個(gè)邊界上下文中的開發(fā)人員可以自由地更改實(shí)現(xiàn)，而不必?fù)?dān)心破壞其他領(lǐng)域。

微服務(wù)中的容器是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)中邊界上下文的物理表現(xiàn)：每個(gè)容器代表了一層封裝，以防止實(shí)現(xiàn)細(xì)節(jié)干擾系統(tǒng)的其他部分。邊界上下文提供的隔離展示了結(jié)構(gòu)化軟件架構(gòu)的不同方式。

在過(guò)去，設(shè)計(jì)架構(gòu)主要圍繞技術(shù)架構(gòu)：架構(gòu)模式、庫(kù)、框架等。例如，分層架構(gòu)在許多組織中是很常見(jiàn)的：

圖1：傳統(tǒng)的分層架構(gòu)

在圖1中，架構(gòu)師沿技術(shù)層進(jìn)行分離，使之在需要時(shí)可以很容易地替換一整層的內(nèi)容。例如，如果開發(fā)人員需要更改持久機(jī)制，所有相關(guān)代碼都會(huì)出現(xiàn)在持久層中。

那么開發(fā)人員多久更換一次整個(gè)持久層呢?幾乎從不。但你的團(tuán)隊(duì)多長(zhǎng)時(shí)間基于像Customer這樣的概念工作呢?每天!

在圖1分層架構(gòu)中，Customer處于哪一層呢?其中部分在表示層、業(yè)務(wù)層、持久層等等。因此，項(xiàng)目架構(gòu)上通用單元的變化在分層架構(gòu)中并沒(méi)有得到很好的支持，原因是通用的變更影響到了每一層。

如果不同層代表了開發(fā)團(tuán)隊(duì)的不同部分，其影響會(huì)更嚴(yán)重。例如，對(duì)Customer的更改可能涉及到用戶界面、業(yè)務(wù)邏輯、持久層和其他特性。如果你的組織由開發(fā)人員、DBA、用戶界面設(shè)計(jì)師和運(yùn)維人員組成，而他們?cè)谙嗷ジ綦x的HR部門下，那么進(jìn)行常見(jiàn)更改的協(xié)調(diào)成本是巨大的。

微服務(wù)強(qiáng)調(diào)解耦和容器化，翻轉(zhuǎn)了圖1中的傳統(tǒng)做法，使領(lǐng)域成為架構(gòu)的主要元素，如圖2所示。

圖2：以領(lǐng)域?yàn)橹行牡募軜?gòu)

在圖2中，分層結(jié)構(gòu)仍然存在，但是其耦合邊界是領(lǐng)域的邊界，它將技術(shù)架構(gòu)歸入實(shí)現(xiàn)細(xì)節(jié)，并用領(lǐng)域?qū)ζ溥M(jìn)行封裝。以技術(shù)為中心的組織單元中，員工與員工彼此隔離，要想在這樣的組織中構(gòu)建以領(lǐng)域?yàn)橹行牡募軜?gòu)是很難的。

許多技術(shù)人員在構(gòu)建數(shù)字化企業(yè)中會(huì)遇到這樣的問(wèn)題：想要支持如移動(dòng)應(yīng)用等新舉措，卻被那些需要拆分的遺留系統(tǒng)所拖累。如今，這些企業(yè)越來(lái)越多地引入微服務(wù)作為這種拆分過(guò)程的關(guān)鍵戰(zhàn)略。

Greenfield項(xiàng)目得益于DDD實(shí)踐。通過(guò)DDD理解了他們的問(wèn)題領(lǐng)域以及重要組件之間的接口所在。對(duì)于現(xiàn)有項(xiàng)目，更加模塊化的系統(tǒng)會(huì)促使開發(fā)者解開事務(wù)性的泥球，并且可以在那些屬于一起的組件和偶然耦合的組件之間做更清楚地區(qū)分。

團(tuán)隊(duì)

你還將遇到微服務(wù)對(duì)團(tuán)隊(duì)影響：一個(gè)架構(gòu)風(fēng)格是如何推動(dòng)開發(fā)團(tuán)隊(duì)重組的。

1968年，梅爾文·康威對(duì)軟件開發(fā)做了一個(gè)很有預(yù)見(jiàn)性的觀察，被稱為康威定律：設(shè)計(jì)系統(tǒng)的組織，其產(chǎn)生的設(shè)計(jì)等價(jià)于這些組織間的溝通結(jié)構(gòu)。

康威定律對(duì)軟件開發(fā)的意義是什么呢?你的設(shè)計(jì)反映了你的團(tuán)隊(duì)結(jié)構(gòu)。企業(yè)常見(jiàn)的團(tuán)隊(duì)結(jié)構(gòu)是由人力資源部門推動(dòng)的，他們將職能類似的技術(shù)專家組織在一起。雖然這是一種符合邏輯的排序算法，但這種結(jié)構(gòu)在設(shè)計(jì)自包含服務(wù)時(shí)效果不佳。

如我們認(rèn)為的康威逆定律，現(xiàn)在許多公司在圍繞業(yè)務(wù)領(lǐng)域組織跨職能團(tuán)隊(duì)，而不是圍繞技術(shù)分層構(gòu)建。例如，一個(gè)Customer服務(wù)可能包括一個(gè)業(yè)務(wù)分析師、開發(fā)人員、QA、UX、DBA和運(yùn)維人員。

團(tuán)隊(duì)會(huì)在準(zhǔn)備好之后再部署服務(wù)，而不是先構(gòu)建一些東西傳遞到運(yùn)維人員，使之包含在下一個(gè)巨大的發(fā)布中。許多選擇微服務(wù)的公司使用持續(xù)部署，以盡快將變更投入生產(chǎn)環(huán)境中。

總結(jié)

企業(yè)高管可能會(huì)認(rèn)為“微服務(wù)”是***流行詞而不予考慮，但那些了解這種架構(gòu)影響的人可以獲得實(shí)實(shí)在在的好處。微服務(wù)可以提高交付速度，增強(qiáng)靈活性，并提高效率。他們將工作進(jìn)行重組，并與業(yè)務(wù)問(wèn)題域保持一致，而不是技術(shù)域;從一組獨(dú)立，更易于開發(fā)和維護(hù)的服務(wù)中創(chuàng)建業(yè)務(wù)應(yīng)用程序;更好地匹配技術(shù)解決方案與業(yè)務(wù)問(wèn)題的復(fù)雜程度;構(gòu)建可以幫助重組現(xiàn)有遺留系統(tǒng)以及創(chuàng)建能夠快速響應(yīng)不斷變化的業(yè)務(wù)條件的新產(chǎn)品和服務(wù)的自適應(yīng)架構(gòu)。

威廉·吉布森是正確的—許多公司已經(jīng)將IT競(jìng)爭(zhēng)力看作魯棒性一個(gè)新的度量。對(duì)于這些企業(yè)來(lái)說(shuō)，未來(lái)已經(jīng)在這里了。其他還沒(méi)有意識(shí)到這一點(diǎn)的公司可能會(huì)發(fā)現(xiàn)他們的未來(lái)已經(jīng)受到了影響。

【本文是專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

當(dāng)前名稱：給CxO的微服務(wù)指南｜洞見(jiàn)
網(wǎng)址分享：http://uogjgqi.cn/article/dpeospg.html